|
What is the eG Java Monitor? |
 |
The eG Java Monitor is a set of new performance metrics and detailed diagnostics added to the eG universal agent to allow for more complete monitoring of Java applications. The eG Java Monitor tracks the status and performance of the Java Virtual Machine (JVM) which is the core engine that powers any Java application. To obtain the new metrics, the eG Java Monitor interfaces with JVMs using the Java Management eXtension (JMX) interfaces supported by most modern JVMs. The eG Java Monitor can also collect the same metrics using SNMP interfaces of the JVMs. |
|
|
What is the Java Management eXtension (JMX)? |
|
The JSR 3 specification (Java Management Extensions (JMX)) Specification - http://jcp.org/en/jsr/detail?id=3) provide a management architecture, APIs and services for building Web-based, distributed, dynamic and modular solutions to manage Java enabled resources. The JSR 160 specification (Java Management Extensions (JMX) Remote API - http://jcp.org/en/jsr/detail?id=160) defines a set of interfaces that clients use to connect to a JMX agent. |
|
|
What type of Java system monitoring information can the eG Java Monitor gather and display? |
|
The types of metrics gathered included:
- Java class loading and unloading metrics : Classes loaded, Classes unloaded
- Java thread level metrics : The number of threads in each state - Total, Blocked, Timed waiting, Waiting, Runnable, Started, Deadlocked, high, medium, and low CPU threads.
- JVM garbage collection metrics : Number of garbage collections, Time taken by garbage collections, percentage of time spent in garbage collection
- JVM memory metrics : Initial, Available, Currently used, Currently free, Percentage used value for heap and non-heap memory
- JVM uptime metrics : Uptime of the JVM including when it was last restarted and the uptime value before the restart
|
|
|
What are some of the ways in which these metrics can be used? |
|
Using these statistics, administrators can figure out the following:
- Has the Java heap been sized properly?
- How effective is garbage collection? Is it impacting application performance?
- Is there excessive blocking between threads due to synchronization issues during application design?
- Are there runaway threads, which are taking too many CPU cycles? If such threads exist, which portions of code are responsible for spawning such threads?
- Is the Java Virtual Machine (JVM) managing its memory resources efficiently or is the free memory on the JVM very less? Which type of memory is being utilized by the JVM increasingly?
- Has a scheduled JVM restart occurred? If so, when?
|
|
|
What is the minimum version of the Sun Java Virtual Machine that is supported by the eG Java Monitor? |
| |
The eG Java Monitor can monitor Sun JVM 1.5 or higher. |
|
|
Can the eG Java Monitor monitor other JVMs - from JRockit, IBM, etc.? |
| |
Any Java virtual machine that supports the JSR 174 specification (Monitoring and Management Specification for the Java Virtual Machine - http://jcp.org/en/jsr/detail?id=174) can be supported by the eG Java Monitor. JRockit and IBM JVM are supported by the eG Java Monitor. JRockit 5.0 R27.1 and above supports JSR 174. |
|
|
Is the Java monitoring supported using agents or is agentless monitoring also supported? |
| |
Agent-based and agentless monitoring of the JVM are supported by eG Enterprise. At the time of deployment, administrators can determine which monitoring mode is to be used. Administrators have complete flexibility to determine which servers to monitor in an agent-based manner and which ones in an agentless manner. |
|
|
How is the eG Java Monitor licensed? |
| |
The eG Java Monitor is licensed per server (irrespective of the version of the JVM used, the hardware capabilities of the server on which it is running etc.). |
|
|
Is the eG Java Monitor a standard part of the eG agent, or do I need to install any additional plug-in? |
| |
The eG Java Monitor is a part of the eG agent package. No additional plug-ins need to be installed. |
|
|
Can I monitor multiple Java applications on the same server using an eG agent? |
| |
Yes, a single eG agent can monitor all the Java applications and virtual machines running on a server. |
|
|
Is JMX the only means by which Java applications can be monitored using the eG Java Monitor? |
| |
No, the eG Java Monitor can be configured to use SNMP to obtain the same set of metrics as it can using the JMX interface. For SNMP-based monitoring to work, the JVM being monitored should be configured to expose metrics using SNMP. |
|
|
What TCP port does the eG Java Monitor use for monitoring JVMs? |
| |
The TCP port that the eG Java Monitor uses to communicate with the JVM is configurable. Administrators can also determine if SSL communication is necessary over this port. Multiple JVMs running on the same system need to use different TCP ports to expose metrics using JMX. |
|
|
If I am using agent-based monitoring, does the TCP port used for JVM monitoring need to be opened across the corporate firewall? |
| |
With agent-based monitoring, the eG agent installed on a server communicates with the JVMs running on the server. Hence, communication over the pre-configured JMX port is handled local to the server. Therefore, this port need not be opened across a corporate firewall. |
|
|
What operating system platforms does the eG Java Monitor support? |
| |
The eG Java Monitor supports agent-based monitoring on all platforms that the eG agent runs on - i.e., Linux, Solaris, Windows, AIX, and HPUX. Agentless monitoring of the JVM is supported on any operating system, as long as the JMV supports the JSR 174 specification. |
|
|
I am running my critical applications on J2EE application servers such as SAP Netweaver, WebLogic, WebSphere, etc. Can the eG Java Monitor be used to monitor these applications? |
| |
Yes, any J2EE application server can be monitored as long as the underlying JVM supports JSR 174. |
|
|
What about public domain J2EE engines like Tomcat and JBoss? |
| |
Yes, any J2EE application server can be monitored as long as the underlying JVM supports JSR 174. |
|
|
How does the eG Java Monitor compare with other in-depth monitors for these J2EE application servers? |
| |
The eG Java Monitor focuses on monitoring the underlying JVM only. It does not monitor the application-server specific capabilities such as EJB, database connection pools, servlets, etc. Additional monitors available in eG Enterprise (e.g., the WebLogic monitor, WebSphere monitor, etc.) can provide this additional level of detail about the application. |
|
|
I have a custom-built Java application. Can the eG Java Monitor be used to monitor this application? |
| |
Yes, any custom-built Java application can be monitored as long as the underlying JVM supports JSR 174. |
|
|
My Java application is running on a Java Runtime Environment (JRE) and not on the Java Development Kit (JDK). Can the eG Java Monitor monitor this application? |
| |
Yes, the JVM that the eG Java Monitor is an integral part of the JRE and the JDK. Hence, the eG Java Monitor will function with any application that uses the JRE or the JDK. |
|
|
How does the eG Java Monitor compare relative to JVM utilities such as jconsole and jvisual VM? |
| |
Jconsole and jvisual VM bundled with the JRE are useful for real-time monitoring of the JVM. Since the metrics collected are not logged to a database, they do not provide historical information that can be used to trace back problems that have occurred. Troubleshooting JVM problems including identifying which thread is consuming the highest amount of CPU, which thread is blocking another and at which line of code, etc., can be time consuming and laborious tasks. With its simple to use, browser-based interface and ability to store historical performance metrics and present them in different easy to use forms (e.g., top CPU consuming threads, blocked threads, etc.), the eG Java Monitor makes problem diagnosis for business critical Java applications very simple. |
|
|
How does the eG Java Monitor compare with byte-code instrumentation tools that have been used for Java monitoring earlier? |
| |
Byte-code instrumentation has been a common way to monitor Java applications. This instrumentation approach has been used for several years and is effective even in cases when the underlying JVM does not support JSR 174. Since it entails a higher overhead, byte code instrumentation has to be deployed and used carefully.
Byte code instrumentation is complementary to the JVM monitoring capabilities offered by the eG Java Monitor. With byte code instrumentation, it is possible to monitor each and every method call and object access and to log response times for each of these calls. This information can be handy in identifying slow methods and often accessed objects. |
|
|
What is the overhead of using the eG Java Monitor for monitoring my Java applications? Can it be used in production environments? |
| |
The instrumentation in-built into the JVM has the least overhead of any Java monitoring approach. Byte-code instrumentation, overloading, and other Java monitoring approaches have much higher overhead. The low overhead of the instrumentation makes the monitoring approach used by the eG Java Monitor ideal for production environments supporting mission-critical Java applications. |
|
|
Can the eG Java Monitor be used in development environments as well? |
| |
Development environments too can benefit greatly from the eG Java Monitor. Developers can see first hand whether there are any thread leakages, deadlocks between threads, high CPU consuming modules or threads, etc. The eG Java Monitor can be used during development to weed out such problems. It can also be used in conjunction with stress testing tools to understand where the application bottlenecks are at high load. |
|
|
How does one obtain an evaluation copy of the eG Java Monitor? |
| |
Being part of the eG Enterprise suite, the eG Java Monitor is a part of the eG universal agent. Contact your eG sales representative or eG authorized partner for an evaluation copy of this software. |
|
 |
Get Your Free Trial
