In the software world, application monitoring is critical for the administrators as well as for the maintenance teams. Obviously, monitoring is very useful for the administrators. They need to monitor the real-time behavior of the application to give uninterrupted service to the end users, but monitoring is even important to the support teams to track down the issues of the applications.
Doing support is the most important phase of the software development life cycle after delivering the product. End users report different kind of issues and support engineers need some information related to the application behavior to solve the issues. Some issues are domain-related and we can simply recreate the issues in our local environment. Fixing the issue is not a big deal if we can reproduce the same behavior in our local setup, but some issues are not easy to replicate in the local environment because they aren’t continuously happening in the production setup.
So, identifying the exact root cause is the challenge. Concurrency issues, thread spinning issues, and memory issues are in the top of the order. Software developers should have a proper plan to report the status of the application with required details when the application has some issues. Putting log messages with the proper details and proper place are the most important. In some cases, such as like high CPU usage, developers need some more information (such as thread dump) to track the issue.
Support engineers or developers may identify the issue by looking at the logs, thread dumps, or heap dumps, but application-specific information is needed for some cases. Proper monitoring mechanisms can fulfill that requirement. There are different types of monitoring applications available in the industry for different purposes but all these applications are developed as the general purpose applications. Application developers need to implement application-specific monitoring mechanisms for achieving that requirement.
Note: Proper monitoring mechanisms can be the marketing factor because clients can incorporate JMX APIs with their existing monitoring dashboards seamlessly or we can provide our own monitoring dashboard to the customers.
JMX (Java Management Extension)
The JMX technology provides the tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven network. Starting with the J2SE platform 5.0, JMX technology is included in the Java SE platform. JMX is the recommended way to monitor and manage java applications. As an example, administrators can stop or start the application or dynamically can change the configurations. Monitoring and management are the basic use of the JMX. JMX can be used for design the full modularize applications which can enable and disable the modules at any time via the JMX, but the main intention of this article is for discussing management and monitoring capabilities of the JMX.
Three main layers can be identified in the JMX architecture.
1. Prob Level
The level closed to the application is called the instrumentation layer or prob layer. This level consists of four approaches for instrumenting application and system resources to be manageable (i.e., making them managed beans), as well as a model for sending and receiving notifications. This level is the most important level for the developers because this level prepares resources to be manageable. We can identify main two categories when we consider about the instrumentation level.
Application resources (i.e., connection pool, thread pool, etc.) that need to be manageable through the JMX must provide the metadata about a resource’s features are known as its management interface. Management applications may interact with the resources via management interface.
There are four instrumentation approaches defined by JMX that we can use to describe the management interface of a resource: standard, dynamic, model, and open.
2. Agent Level
The agent level of the JMX architecture is made up of the MBean server and the JMX agent services. The MBean server has two purposes: it serves as a registry of MBeans and as a communications broker between MBeans and management applications (and other JMX agents). The JMX agent services provide additional functionality that is mandated by the JMX specification, such as scheduling and dynamic loading.
3. Remote Management Level
The top level of the JMX architecture is called the distributed services level. This level contains the middleware that connects JMX agents to applications that manage them (management applications). This middleware is broken into two categories: protocol adaptors and connectors.