Java APM and JVM monitoring

Why Java APM matters

Java still runs a large share of business-critical backends: payment systems, order processing, banking cores and countless Spring Boot microservices. These services are fast when they are healthy, but the JVM adds a layer between your code and the operating system. Garbage collection, JIT compilation, thread pools and connection pools all influence response times. Java APM combines distributed traces with JVM monitoring so you can tell whether a slow request is caused by your code, by the runtime or by a downstream database.

Classic Java performance monitoring relied on proprietary bytecode agents. Today the OpenTelemetry Java agent provides the same zero-code approach as an open standard: one jar, attached with -javaagent, instruments hundreds of libraries and emits traces, metrics and logs over OTLP.

JVM signals that matter

A useful Java performance monitoring setup watches a small set of runtime signals alongside the golden signals of each service:

• Heap and memory pools: jvm.memory.used per pool and jvm.memory.used_after_last_gc. The second one matters most, because live data after collection shows the real memory footprint.
• Garbage collection: jvm.gc.duration by collector (G1, ZGC, Parallel). Frequent or long pauses translate directly into tail latency.
• Threads: jvm.thread.count by state. Many blocked threads point to lock contention or exhausted pools.
• CPU: jvm.cpu.recent_utilization tells you whether the process is CPU-bound or waiting on I/O.
• Requests and dependencies: http.server.request.duration plus database and messaging client spans give rate, errors and duration per endpoint.

Common Java performance problems and how to detect them

Memory leaks

A leak shows up as heap after GC rising step by step across hours or days, followed by longer collections and eventually an OutOfMemoryError. Alerting on the trend rather than on a fixed threshold catches it before users notice.

GC pressure

High allocation rates force frequent young-generation collections. Traces with gaps that line up with GC events reveal the impact; allocation profiles show which code paths allocate the most.

Pool exhaustion

When a JDBC or HTTP client pool is too small, requests queue up. You see rising latency, many waiting threads and spans that spend time before the actual query starts.

Slow queries and N+1 patterns

ORM frameworks such as Hibernate can issue dozens of statements per request. Trace waterfalls make N+1 patterns obvious at a glance.

Lock contention and stuck threads

Synchronized blocks around shared caches or legacy singletons serialize requests under load. A rising number of threads in the BLOCKED state, together with CPU that stays flat while latency grows, is the typical fingerprint. Lock profiles and thread dumps taken at that moment show which monitor everyone waits for.

Slow startup and cold JIT

Right after a deployment, the JIT compiler has not optimized hot paths yet, and the first requests are slower. Comparing latency per service.version over the first minutes after rollout separates warm-up effects from real regressions.

Best practices for JVM monitoring

1. Set service.name, service.version and deployment.environment.name on every service so you can compare releases.
2. Prefer the agent for broad coverage and add manual spans with the OpenTelemetry API only for business logic that matters.
3. Watch heap after GC and GC duration together; either one alone can mislead.
4. Keep container memory limits and -Xmx aligned, and monitor both the JVM and the cgroup.
5. Use tail-based sampling to keep all slow and failed traces while dropping routine ones.

How Obseria helps with Java APM

Obseria accepts the standard OpenTelemetry Java agent output over OTLP, so there is no proprietary agent to maintain. On hosts and Kubernetes, the Obseria Agent can inject the Java agent automatically and adds host, container and log data. TopoGraph maps each Java service to its databases, queues and callers. Continuous profiling with under 1% overhead links hot methods to the traces they slow down. When latency rises, Obseria Intelligence correlates a GC spike, a deployment or a slow query and presents the root cause with its chain of evidence. Dashboards, alerts and SLOs for Java services are included, and all data stays exportable via OTLP.