Features for Java
Germain monitors Uptime, Performance and Users of Java application. The main features of Germain's Java Application monitoring include:
CPU and Memory Usage Monitoring
Track the utilization of CPU and memory resources by the Java application to identify potential performance bottlenecks and resource constraints.
HTTP Requests Monitoring
Monitor inbound and outbound HTTP requests made by the Java application. Track response times, status codes, and payload sizes to ensure proper functioning and performance of web interactions.
JMS Messages Monitoring
Monitor inbound and outbound JMS (Java Message Service) messages exchanged by the Java application. Track message rates, processing times, and potential errors to ensure reliable and efficient message communication.
SQL Transactions Monitoring
Monitor SQL transactions executed by the Java application, including query execution times, transaction rates, and potential errors. This helps identify performance issues or inefficiencies related to database interactions.
Germain allows you to define a custom list of class methods to monitor at the application startup. This enables you to track specific method invocations and their execution times for performance analysis or troubleshooting purposes.
Sampler for CPU profiling
Germain provides a CPU profiling sampler to collect detailed information about CPU usage and performance hotspots in the Java application. This helps identify CPU-intensive code sections and optimize application performance.
Germain supports JMX (Java Management Extensions) access, allowing you to remotely inspect agent statistics or configure the monitoring setup. This feature provides additional flexibility and control over the monitoring process.
Inspecting the agent via JMX
The Germain Java agent registers multiple MBeans via JMX to expose additional statistics at run-time. Any JMX client, such as VisualVM with the MBeans plugin, can be used to connect to the Java process and browse the exported objects.
Caveats of CPU sampling
The agent runs inside the JVM; that means that program errors can affect the monitored application - this is true for any profiler
The agent runs inside the JVM, thus it is subject to Java timer accuracy and garbage collection
The agent cannot distinguish between overloaded methods because they are stored ambiguously in the stack trace.
The agent only counts threads which are in RUNNABLE state
Time spent in filtered methods will be attributed to the last unfiltered caller method
For more detailed information, please reach out to us. We will provide you with further guidance and assistance tailored to your needs.
Feature Availability: 8.6.0 or later