Requirements

In complex Java applications performance problems can occur due to various factors. These problems should be detected and retaliatory actions performed. Monitoring the cpu usage (per core), the amount of total and free physical memory or the process cpu time are only a few points.

Monitoring should be possible with little impact on the design of the instrumented application. Instrumenting the VM would give us informations about such as the number of classes loaded, uptime of the JVM, the amount of memory consumed, number of threads running and deadlock detection. Another point would be the monitoring of the runtime stack.

It would be an advantage if the monitoring agent doesn't need to know anything about the application to instrument. Due to that, we would achieve an encapsulation. It should be considered in which intervals the monitoring happens and what the trigger is. The amount of the instrumentation should also be configurable (whole application or only pieces).

Possible Approaches

There are a few possible ways to achieve the points listed above. Java SE 6 provides an in-depth focus on performance, offering expanded tools for managing and monitoring applications and for diagnosing common problems. The improvements include:

• Monitoring and management API enhancements
• Official support for an improved graphical monitoring tool called JConsole
• Enhanced instrumentation of the Java virtual machine (JVM)

With this monitoring and management APIs it's possible to get extended informations about the VM such as current threads running, heap state or the memory usage. But there is one thing that can't be done with pure Java. That's where the JNI (Java Native Interface) comes into play. With the JNI it's possible to get informations like the cpu usage directly from the underlying OS.

ere are a few possible ways to achieve the points listed above. Java SE 6 provides an in-depth focus on performance, offering expanded tools for managing and monitoring applications and for diagnosing common problems. The improvements include:

• Monitoring and management API enhancements
• Official support for an improved graphical monitoring tool called JConsole
• Enhanced instrumentation of the Java virtual machine (JVM)

With this monitoring and management APIs it's possible to get extended informations about the VM such as current threads running, heap state or the memory usage. But there is one thing that can't be done with pure Java. That's where the JNI (Java Native Interface) comes into play. With the JNI it's possible to get informations like the cpu usage directly from the underlying OS.

JMX

The Java Management Extensions (JMX) API is a standard API for management and monitoring of local and remote applications, devices, services, and the Java virtual machine. JMX became a standard part of the Java platform in in J2SE 5.0. Using JMX technology, a given resource is instrumented by one or more Java objects known as Managed Beans (MBeans). These MBeans are registered in a core managed object server (MBean server) that acts as a management agent and can run on most devices enabled for the Java programming language.

JMX technology enables Java applications to be managed without heavy investment: A JMX technology agent can run on most Java technology-enabled devices, thus Java applications can become manageable with little impact on their design. A Java application simply needs to embed a managed object server and make some of its functionality available as one or several managed beans (MBeans) registered in the object server; that is all it takes to benefit from the management infrastructure.
The architecture of JMX is shown below
At the instrumentation level components called MBeans provide the application-specific management information. The MBeans provide the essential visibility and control for managing applications.

• The Agent level (MBean server) interfaces to the MBean components and provides a management interface to these components. The MBean Server is the key component in this layer, and provides a set of management functions useful to managing MBeans.
• The Connector Level consists of one or more connector (or protocol adaptor) components that provide access to remote management systems. Depending on the protocols supported by the JMX implementation, remote managers supporting SNMP, HTTP, or other management protocols can access the management information and control exposed by the MBeans for each application. Multiple management systems using different protocols can now simultaneously access the application management capability.
• With the management console (JConsole) it's possible to inspect and interact with MBeans as well as set any properties and invoke operations. JMX does not have a graphical user interface, but the informations we're getting out of the JMX Agent can also be used by other clients such as inspectIT

1. Advantages of JMX
   • fully integrated since J2SE 5.0
   • can be used for out-of-the-box management of the Java VM

1. Disadvantages of JMX
   • no direct access to the underlying OS (for cpu usage)
   • needs more implementation effort for Java 1.4

JNI

The Java Native Interface is needed for getting informations like the cpu usage of der underlying OS. It's impossible querying for cpu usage with pure Java so we need to go through the JNI to call native methods. Getting the informations out of Windows it's needed to compile the DLLs with a C-Compiler and under Linux it's needed to compile the .so (shared objects) files.
The architecture of JNI is shown below:

1. Advantages of JNI
   • direct access to OS resources
   • native code is faster than Java code
2. Disadvantages of JNI
   • subtle errors in the use of JNI can destabilize the entire JVM in ways that are very difficult to reproduce and debug
   • no garbage collection for the JNI side
   • portability

Design

Since Java SE 6 there are a few APIs, which can help us in monitoring. These packages are also available in Java SE 5, so that it shouldn't be a problem with Java 5 applications.

• java.lang.management - Enables monitoring and managing the Java virtual machine and the underlying operating system. The API enables applications to monitor themselves and enables JMX-compliant tools to monitor and manage a virtual machine locally and remotely.

• com.sun.management - Sun Microsystems' platform extension to the java.lang.management API and the management interface for some other components of the platform.
• java.util.logging.LoggingMXBean - Enables you to retrieve and set logging information.

• Java Management Extensions (JMX) APIs - Defines the architecture, design patterns, interfaces, and services for application and network management and monitoring in Java.

With this APIs we can get informations about:

Summary

• Uptime: Total amount of time since the Java VM was started.
• Process CPU Time: Total amount of CPU time that the Java VM has consumed since it was started.
• Total Compile Time: Total accumulated time spent in JIT compilation. The Java VM determines when JIT compilation occurs.

Threads

• Live threads: Current number of live daemon threads plus non-daemon threads.
• Peak: Highest number of live threads since Java VM started.
• Daemon threads: Current number of live daemon threads.
• Total threads started: Total number of threads started since Java VM started, including daemon, non-daemon, and terminated threads.

Classes

• Current classes loaded: Number of classes currently loaded into memory.
• Total classes loaded: Total number of classes loaded into memory since the Java VM started, including those that have subsequently been unloaded.
• Total classes unloaded: Number of classes unloaded from memory since the Java VM started.

Memory

• Current heap size: Number of kilobytes currently occupied by the heap.
• Committed memory: Total amount of memory allocated for use by the heap.
• Maximum heap size: Maximum number of kilobytes occupied by the heap.
• Objects pending for finalization: Number of objects pending for finalization.
• Garbage collector: Information about garbage collection, including the garbage collector names, number of collections performed, and total time spent performing GC.

Operating System

• Total physical memory: Amount of random-access memory (RAM) the operating system has.
• Free physical memory: Amount of free RAM available to the operating system.
• Committed virtual memory: Amount of virtual memory guaranteed to be available to the running process.

Other Information

• VM arguments: The input arguments the application passed to the Java VM, not including the arguments to the main method.
• Class path: The class path that is used by the system class loader to search for class files.
• Library path: The list of paths to search when loading libraries.
• Boot class path: The boot class path is used by the bootstrap class loader to search for class files.

JMX

JMX technology provides a tiered architecture where managed resources and management applications can be integrated. A given resource is instrumented by one or more MBeans, which are registered in an MBean server. This server acts as a management agent and can run on most Java-enabled devices.

1. Instrumentation Level

The instrumentation level defines the requirements for implementing JMX manageable resources. JMX resources can be anything that is developed in Java or provides a Java wrapper.
The level consists of three main components:

• MBeans
• Notification model elements
• MBean metadata classes

1.1 MBean

• Java object which implements one of the standard MBean interfaces
• follows the associated design patterns
• doesn't require knowledge of the JMX agent
• The scope of the management interface of an MBean includes:
  • attribute values that may be accessed by name
  • operations/methods that may be invoked
  • notifications or events that may be emitted
  • constructors for the MBean's Java class

• JMX defines four types of MBeans to support different management needs:
  • Standard MBeans (use Java naming conventions)
  • Dynamic MBeans (expose their management interface at runtime for greatest flexibility)
  • Open MBeans (rely on basic, self-describing, user-friendly data types for universal manageability and are an extension of Dynamic MBeans)
  • Model MBeans (simplify the instrumentation of resources by providing default behavior. Are also an extension of Dynamic MBeans)

1.2 Notification ModelMBeans can generate notifications, for example to signal a state change, a detected event, or a problem. To generate notifications, an MBean has to implement the interfaces listed below.

• JMX notifications are an extension of the Java event model
• MBean Server + MBeans can send notifications to provide informations
• interface for event sending: <<NotificationBroadcaster?>>
• interface for event receiving: <<NotificationListener?>>

1.3 MBean Metadata ClassesMetadata classes contain the structures to describe all components of an MBean's interface (its attributes, methods, notifications and constructors). The metadata includes for each of this a name, a description and its particular characteristics (for example, attribute: is it readable/writable? - method: signature and return types).

2. Agent LevelThe agent level contains the JMX agents used to expose the MBeans. It provides a specification for implementing agents, which control the resources and make them available to remote management applications. The JMX agent consists of an MBean server and a set of services for handling MBeans.

2.1 MBean ServerThe MBean server is a registry for MBeans that makes the MBean management interface available for use by management apps. MBean server never directly exposes the MBean object itself. Any object registered with the MBean server becomes visible to management applications. The server provides a standardized interface for accessing MBeans within the same JVM, giving local objects all the benefits of manipulating manageable resources.
MBeans can be instantiated and registered by the following:

• another MBean
• the agent itself
• a remote management application

2.2 Agent ServicesAgent services are objects that support standard operations on the MBeans.
The JMX API defines the following Agent Services available in J2SE 5.0:

• Dynamic Class loader: Through the management applet service, retrieves and instantiates new classes and native libraries from an arbitrary network location
• Monitors: Observe the numerical or string value of an attribute of several MBeans and can notify other objects of several types of changes in the target
• Timers: Provide a scheduling mechanism based on a one-time alarm-clock notification or on a repeated, periodic notification
• The relation service: Defines associations between MBeans and enforces the cardinality of the relation based on predefined relation types

3. Manager (or Distributed Services) LevelThis tier contains the components that enable management applications to communicate with JMX agents. It provides the interfaces for implementing JMX managers and defines the management interfaces and components that operate on agents. Such components provide an interface for a management application to interact with an agent and its JMX manageable resources through a connector, and also expose a management view of a JMX agent and its MBeans by mapping their semantic meaning into the constructs of a data-rich protocol (such as HTML).

MXBeansAn MXBean is a type of MBean that references only a predefined setof data types. In this way, we can be sure that our MBean will be usable by any client, including remote clients, without any requirement that the client have access to model-specific classes representing the types of the MBeans. MXBeans provide a convenient way to bundle related values together, without requiring clients to be specially configured to handle the bundles.

Design Decision

The approach with JMX is currently not needed, because we only want to get measurements / informations about the instrumented application. With JMX we can also manage an application and perform specified operations through self-created MBeans. For the SystemSensors it's enough to get the informations of the virtual machine through MXBeans provided by the java.lang.management and com.sun.management packages. You can see here the design of the SystemSensors.

Realization

Explanation

All Information classes implement the IPlatformSensorinterface. The Information classes have one or more MXBeans to get the informations out of the virtual machine. The informations will be provided over the getters, which will called later by another service.

Implementation

Agent5.0

The information classes are part of the Agent5.0 project and work only with Java SE 5.0 or higher. The inherited update()-method gets all the necessary informations through the MXBeans. The update()-method retrieves for a data object from the value storage. If the data object we're retrieving is empty here, then a new data object will be created and the specified data will be set, otherwise we're only updating the data object.
The SystemInformation class contains only static informations about the vm, which don't change at runtime. On startup, update() is called once, after that the data object of SystemInformation will only be updated by a request from the user.

The refresh time

The refresh time in which the system sensors get updated is defined in the core service (also known as value storage) of the agent. The refresh time is by default 1000ms. This can be changed by setting the platformSensorRefreshTime.

Data objects
All data objects are in Commons. The data objects will be persisted and notthe information classes. The CMR receives the data objects and persists them right away. The user interface uses the data objects to show the specific informations. A detailed description of the data objects can be found