Debugging From the Other Direction Using JMXTerm | by Shai Almog | Jul, 2022

Half 3 of this collection explores extra instruments to debug your initiatives

When monitoring a bug, we have to take a two-pronged strategy much like tongs that wrap the buggy module from either side and squeeze to search out the problematic half. Up till now, we mentioned instruments which can be very low degree. Some can be utilized to debug system-level companies. Right this moment we’ll focus on the opposite aspect of the stack however nonetheless a really superior administration device. To know this, it’s essential to perceive the sphere we’re in.

As builders, we cope with code and functions. Deployment is for OPS/DevOps, and their tooling is usually alien to us. It’s not that they’ve unhealthy instruments. Quite the opposite, they’ve wonderful instruments. However they’re often designed for enormous scale. When it’s essential to handle 1000’s of servers, you want a strategy to management issues in all of them. For that, we want a unique set of instruments.

Administration instruments allow us to traverse via clouds of machines and handle the functions operating on them. We don’t want the previous, however the latter is a strong device that’s very helpful for builders. Some requirements implement software administration, and Java launched JMX to encapsulate their variations. JMX lets functions, and the JDK itself, expose data and performance for manipulation by exterior instruments.

It is a outstanding characteristic that exposes data and tuning levers for dynamic manipulation in runtime environments. Activating JMX is exterior the scope of this tutorial, so I received’t go into a lot element, however you may verify a few of the fundamentals on this Oracle article here. As soon as that is operating, we will use visible instruments to debug, however I’ll concentrate on command-line tooling. That is necessary since I can use a few of this tooling instantly on the manufacturing servers from the console.

JMX exposes administration “beans” (MBeans). These are objects that characterize management factors within the software. Your software can publish its personal beans, which helps you to expose performance for runtime monitoring and configuration. That is very cool, as you may export data that an administrator can wire on to a dashboard (APM, Prometheus, Grafana, and so on.) and use that for choice making.

In case your server has a number of customers related concurrently, you may expose that quantity in JMX, and it could seem within the firm dashboard due to some wiring from DevOps. In your aspect, most work would expose a getter for the worth of curiosity. You may as well expose operations comparable to “purge customers,” and so on. An operation is a technique you may invoke on a JMX bean.

Spring additionally helps exposing many server particulars as administration beans by way of actuator. It is a remarkably cool characteristic. You may learn extra about it here. It exposes very deep metrics in regards to the software and helps you leap proper into “manufacturing prepared” standing!

Often, one controls and reads JMX by way of net interface instruments or devoted administration tooling. When you’ve got entry to any of them, I counsel you decide one in all them up and use them as it will work fairly effectively. I’ve used a few of these in some firms, and I really choose them in some circumstances. I additionally get pleasure from utilizing IntelliJ/IDEA Ultimates help for Actuator, which is a reasonably highly effective visualization device.

JMXTerm is simply as highly effective however doesn’t embrace the visualization facet. In that sense, it’s exceptionally handy when we have to perceive one thing rapidly on a server that could be alien. It’s additionally fairly helpful for getting high-level insights from the server internals. We will get began by downloading JMXTerm from here.

As soon as downloaded, we will use it to hook up with a server utilizing the next command:

java -jar ~/Downloads/jmxterm-1.0.2-uber.jar --url localhost:30002

It’s best to replace the hostname/port primarily based in your connection. As soon as related, we will listing the JMX domains utilizing the immediate:

#following domains can be found

We will then decide a particular area to discover. That is the place the visible device is often helpful, as it could give you quicker navigation via the hierarchy and fast evaluation of the data. On this case, I simply wish to set the logging degree. Right here’s how to try this:

$>area java.util.logging
#area is about to java.util.logging

We will observe this by itemizing the beans throughout the area. Then decide the bean we want to use since there’s just one bean on this particular area. Right here’s the code:

#area = java.util.logging:
$>bean java.util.logging:sort=Logging
#bean is about to java.util.logging:sort=Logging

What can I do with this bean? For that, we’ve the information command that lists the operations and attributes of the bean:

#mbean = java.util.logging:sort=Logging
#class identify = solar.administration.ManagementFactoryHelper$PlatformLoggingImpl
# attributes
%0 - LoggerNames ([Ljava.lang.String;, r)
%1 - ObjectName (, r)
# operations
%0 - java.lang.String getLoggerLevel(java.lang.String p0)
%1 - java.lang.String getParentLoggerName(java.lang.String p0)
%2 - void setLoggerLevel(java.lang.String p0,java.lang.String p1)
#there's no notifications

Once I have these, I can check the current logger level. It isn’t set since we didn’t set it explicitly, and the global default is used. Here’s how:

$>run getLoggerLevel "org.apache.tomcat.websocket.WsWebSocketContainer"
#calling operation getLoggerLevel of mbean java.util.logging:type=Logging with params [org.apache.tomcat.websocket.WsWebSocketContainer]
#operation returns:

I can explicitly set it to INFO after which get it once more to confirm that the operation labored as anticipated utilizing this code:

$>run setLoggerLevel org.apache.tomcat.websocket.WsWebSocketContainer INFO
#calling operation setLoggerLevel of mbean java.util.logging:sort=Logging with params [org.apache.tomcat.websocket.WsWebSocketContainer, INFO]
#operation returns:
$>run getLoggerLevel "org.apache.tomcat.websocket.WsWebSocketContainer"
#calling operation getLoggerLevel of mbean java.util.logging:sort=Logging with params [org.apache.tomcat.websocket.WsWebSocketContainer]
#operation returns:

That is simply the tip of the iceberg. We will get many issues comparable to spring settings, inner VM data, and so on. On this instance, I can question VM data instantly from the console with the next code:

#area is about to
#area =
#bean is about to
#mbean =
#class identify =
# attributes
%0 - DiagnosticOptions ([Ljavax.administration.openmbean.CompositeData;, r)
%1 - ObjectName (javax.administration.ObjectName, r)
# operations
%0 - void dumpHeap(java.lang.String p0,boolean p1)
%1 - javax.administration.openmbean.CompositeData getVMOption(java.lang.String p0)
%2 - void setVMOption(java.lang.String p0,java.lang.String p1)
#there isn't any notifications

JMX is a outstanding device that we largely use to wire administration consoles. It’s outstanding for that, and you need to very a lot export JMX settings in your initiatives. Having mentioned that, you may take it to the subsequent degree by leveraging JMX as a part of your debugging course of.

Server functions run with no UI or with deep UI separation. JMX can typically work as a type of person interface and even as a command line interface, as is the case in JMXTerm. In these circumstances, we will set off conditions for debugging or observe the outcomes of a debugging session throughout the administration UI.

More Posts