...
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:
...
- Advantages of JNI
- direct access to OS resources
- native code is faster than Java code
- 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 LevelThe 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.