Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Specification:

...

Platform sensor

Table of Contents

...

outlinetrue

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 information 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:

...

With this monitoring and management APIs it's possible to get extended informations information 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 information like the cpu usage directly from the underlying OS.

...

With this monitoring and management APIs it's possible to get extended informations information 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 information 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.

...

  • 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 information we're getting out of the JMX Agent can also be used by other clients such as inspectIT

...

  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 information 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 information 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.

...

With this APIs we can get informations information 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.

...

  • 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.

...

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

...

The approach with JMX is currently not needed, because we only want to get measurements / informations information about the instrumented application. With JMX we can also manage an application and perform specified operations through self-created MBeans. For the SystemSensors Platform Sensors it's enough to get the informations information 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 Platform Sensors.

Realization

Image Added

Explanation

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

Implementation

Agent5.0

The information classes are part of the SystemSensors.the Agent5.0 project and work only with Java SE 5.0 or higher. The inherited update()-method gets all the necessary information 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 information 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 platform 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 information. A detailed description of the data objects can be found