Skip to main content
ComponentsAgentEngine
Availability2022.1 or later

Configure the Java Agent

Per-app agent.properties control

JVM & Process Monitoring

JVM health and processes

Configure Custom Method Monitoring

Instrument app-specific methods

Validate the Configuration

Expand after initial validation

​
Overview

Once the GermainUX Java Agent and/or Engine is deployed, configure the monitoring scope, data collection, analytics, alerts, and automation appropriate for your Java environment. GermainUX configuration can range from lightweight JVM health monitoring to deep transaction, database, API, code-level, user-impact, and business-process analysis.

​
Configure the Java Agent

Java Agent capabilities are controlled through the application’s agent.properties file. Monitoring can be enabled or disabled individually, allowing each Java application to collect only the telemetry required for its use case.

​
HTTP Monitoring

GermainUX can monitor inbound application requests and outbound HTTP calls. Enable inbound Servlet monitoring and outbound HTTP monitoring:
Monitoring can capture information such as:
  • URL
  • HTTP method
  • Response code
  • Response time
  • Payload size
  • Outbound target
  • Transaction failures

​
Session Correlation

HTTP session ID collection can be enabled when session-level correlation is required:
For web-based Java applications, this can help correlate backend transactions with user activity and workflows monitored by GermainUX.

​
JDBC / SQL Monitoring

Enable JDBC monitoring:
GermainUX can capture:
  • SQL statement
  • Execution time
  • Error state
  • Slow database activity
  • Database impact on application transactions
Low-value or repetitive SQL statements such as health checks can be excluded:
Additional exclusions can be added using sequential indexes.

​
JMS Monitoring

Enable JMS monitoring:
GermainUX can monitor:
  • Destination
  • Inbound/outbound direction
  • Processing time
  • Errors
Message-body collection can be disabled when messages contain sensitive information or when payload size could create unnecessary overhead:
Always review data-privacy requirements before collecting message content.

​
Elasticsearch Monitoring

Elasticsearch monitoring is available but disabled by default. Enable it with:
GermainUX can monitor Elasticsearch REST activity including:
  • Index
  • Operation
  • Response time

​
JVM & Process Monitoring

Enable JVM/process metrics:
GermainUX can collect JVM metrics such as:
  • Heap memory
  • Non-heap memory
  • Garbage collection activity
  • Thread counts and states
  • Heap histograms
Heap histogram collection can be disabled independently:
Adjust the collection interval based on the required monitoring granularity and acceptable overhead.

​
Thread Pool Monitoring

Enable thread-pool monitoring:
GermainUX can monitor thread-pool activity to identify capacity constraints and thread starvation. Specific metrics can be selected when required:

​
Connection Pool Monitoring

Enable connection-pool monitoring:
GermainUX can monitor:
  • Active connections
  • Idle connections
  • Waiting threads
  • Wait time
  • Pool exhaustion
Dedicated HikariCP monitoring is also available:
Specific metrics can be selected:

​
Configure CPU Profiling

GermainUX’s CPU Profiler uses stack sampling to identify CPU-intensive code paths while minimizing application overhead. Enable CPU profiling:
Configure the sampling window:
Results can be analyzed in GermainUX using visualizations such as flame graphs and transaction waterfalls.

​
Limit Profiling Scope

Exclude framework or low-value packages:
Or restrict profiling to your application code:
Use filtering to reduce noise, data volume, and monitoring overhead.

​
On-Demand CPU Profiling

CPU profiling can also be controlled at runtime through JMX:
This allows profiling to be activated for a specific workload without restarting the JVM.

​
Configure Custom Method Monitoring

GermainUX can instrument application-specific Java methods, classes, or packages that are not covered by standard HTTP, JDBC, JMS, or other built-in monitoring. Enable method monitoring:

​
Monitor a Specific Method

​
Monitor an Entire Class

​
Monitor a Package

Package-level instrumentation should be used carefully because monitoring large numbers of methods can increase application overhead and telemetry volume.

​
Configure Method-Level Data Collection

When required for troubleshooting, GermainUX can capture method arguments and return values:
Non-public methods can also be instrumented:
Only enable these capabilities when necessary and after reviewing privacy, security, and performance requirements.

​
Configure User & Transaction Correlation

For web-based applications, Java telemetry can be correlated with other GermainUX monitoring data to provide visibility across the complete user and application journey:
User ActionBrowserJava TransactionAPI / ServiceDatabase
This can help teams determine:
  • Which backend transaction affected a user
  • Which Java error caused a workflow to fail
  • Which SQL call contributed to a slow transaction
  • Which backend issue caused repeated user actions
  • Which technical issue affected productivity, adoption, conversion, or abandonment
When GermainUX User Monitoring and Session Replay are deployed, backend insights can be combined with the actual user experience for faster root-cause analysis.

​
Configure Data Privacy & Exclusions

Review all monitored data before enabling detailed instrumentation in production. Depending on the application, this can include:
  • SQL text
  • HTTP/session information
  • JMS messages
  • Method arguments
  • Return values
  • User identifiers
  • Business data
Configure exclusions or disable unnecessary data collection wherever sensitive information does not need to be monitored. The objective should be to collect the information necessary for troubleshooting and analysis while minimizing unnecessary or sensitive data collection.

​
Configure KPIs, Dashboards & Reports

Java telemetry collected by GermainUX can be analyzed through configurable real-time KPIs, dashboards, and automated reports. Examples include:
  • Application availability
  • Error rate
  • Response time
  • JVM memory and garbage collection
  • Slow transactions
  • CPU hotspots
  • Database performance
  • API performance
  • Connection-pool utilization
  • Thread-pool utilization
  • Business transaction performance
  • User impact
Dashboards and reports can combine Java telemetry with data from other GermainUX monitoring sources to provide application, user, process, and business context.

​
Configure Alerts & SLAs

Configure alerts for conditions that require attention, such as:
  • New Java errors
  • Error-frequency increases
  • Slow transactions
  • JVM resource saturation
  • Excessive garbage collection
  • CPU hotspots
  • Connection-pool exhaustion
  • Thread-pool saturation
  • Slow SQL
  • API failures
  • Application availability issues
  • SLA violations
Thresholds, frequency, time windows, recipients, and escalation logic can be customized according to operational requirements.

​
Configure Automation

GermainUX can trigger automated actions when defined Java application conditions occur. For example:
DetectAnalyzeAlertCreate TicketTrigger Action
Depending on the use case, automation can include:
  • Alerts and notifications
  • Ticket or incident creation
  • Script execution
  • Program / RPA execution
  • HTTP calls
  • SQL execution
  • SSH execution
  • Scheduled actions
  • Custom workflows
  • Remediation actions
Automation can be triggered by technical conditions, SLA violations, user impact, business impact, or combinations of monitored events. Use automated remediation selectively for well-understood and safely recoverable conditions.

​
Tune Monitoring Overhead

Monitoring depth should match the diagnostic requirements of each environment. For production environments:
  1. Start with JVM metrics and critical transactions.
  2. Enable HTTP, JDBC, pools, and other relevant integrations.
  3. Add CPU profiling where deeper performance analysis is required.
  4. Instrument specific business-critical methods when built-in monitoring does not provide sufficient visibility.
  5. Avoid unnecessarily broad package-level instrumentation.
  6. Adjust sampling and collection intervals where appropriate.
  7. Review data volume and application overhead after configuration changes.
This progressive approach provides deep visibility where needed while minimizing unnecessary monitoring overhead.

​
Validate the Configuration

After making configuration changes:
  • Restart the JVM when required for instrumentation changes.
  • Confirm that expected telemetry is being collected.
  • Validate transaction and application naming.
  • Confirm exclusions are working correctly.
  • Review CPU and application overhead.
  • Test alerts and SLA thresholds.
  • Test automation actions in a non-production environment.
  • Validate user/backend correlation where applicable.
  • Confirm that sensitive data is not being collected unintentionally.
Progressively expand monitoring once the initial configuration has been validated.

​
Get Help

Contact GermainUX Support

The Germain Team can help you set this up.

Can't find what you need?

Search all GermainUX docs with Ctrl + K, or use the feedback buttons at the bottom of this page to tell us what is missing.

The content of this document is proprietary to GERMAIN SOFTWARE LLC.