Reputation: 33
This question is not about how JMX works or what JMX does. As far as I know On top of using JMX we can get OS level metrics and JVM specific metrics (such as: Garbage collection time & frequency, heap utilisation etc)
My Question is What are the aspects can be monitored with JMX in Java applications(internal metric)?
Upvotes: 3
Views: 1403
Reputation: 340350
Java Management Extensions (JMX) is a standard way for you to embed code within your own app to report at runtime the state of your app’s operations.
This embedding of a reporting agent (a “probe”) within a larger piece of software is known as “instrumenting” your code. JMX enables you a framework to surface those pieces of static information at runtime, so you need not invent that reporting-system plumbing yourself. At runtime, you, or your system administrator, can use any of a number of standard monitoring apps sometimes known as “consoles” or “dashboards”.
JMX handles transporting the updates to the monitoring apps without you needing to do any additional programming. The monitoring app need not be local, instead could be running remotely over the network. Which monitoring app is chosen by your sysadmin, and where they choose to run it, has no effect on your code in your app. JMX is a buffer, a layer of indirection, separating your compile-time code from these practical run-time configuration issues.
The purpose is to provide a control room like this, but for your software:
The key advantage here is using standard protocols for reporting status, rather than you inventing your own protocols.
If your app is a web app, then your Jakarta EE server or web container such as Tomcat or Jetty may be instrumented with JMX. So you can monitor its operations. For example, you can see what user-sessions are currently open.
Some JVM implementations are themselves instrumented using JMX to report the status of various aspects of the JVM’s operations. As your Question mentioned, some of those reports may be on memory usage, garbage collector activity, etc. You sysadmin’s monitoring app can watch both the JVM and your app, each reporting a stream of status updates.
Your operating system may also be instrumented to report on its internal operations as well, though not likely using JMX. One powerful dynamic tracing framework for this purpose is DTrace, built into macOS, FreeBSD, and Solaris.
So your sysadmin may be watching all four sets of status information on her monitoring app: the OS, the JVM, the app server, and your app.
Read the Wikipedia page for basic info.
JMX provides not only read-access to monitor current status, but also writing. Your chosen external monitoring app can be used to alter the state within your app in whatever way you choose in your programming. For example, you could change the size of thread pools or caches.
Continuing our metaphor of the control room seen above, you can think of read-access via JMX as watching the gauges seen on those control room panels.
Think of write-access as turning the knobs, switches, and sliders on those panels.
Upvotes: 3