Java APM und JVM-Monitoring
Binden Sie den OpenTelemetry Java Agent ein, und Obseria zeigt Request-Traces, Heap, Garbage Collection, Threads und CPU-Profile jedes Java-Service, korreliert mit Logs und Infrastruktur.
Warum Java mit Obseria überwachen
Instrumentierung ohne Code
Der OpenTelemetry Java Agent instrumentiert Spring, Servlet-Container, JDBC, Kafka, gRPC und HTTP-Clients beim Start, ohne Eingriff in Ihren Code.
JVM-Interna im Kontext
Heap-Pools, GC-Pausen und Thread-Zahlen stehen direkt neben den betroffenen Traces. So erkennen Sie, ob Latenz aus Code, JVM oder einer Abhängigkeit kommt.
Bis auf die Methode
Continuous Profiling mit unter 1 % Overhead zeigt, welche Methoden in Produktion CPU verbrauchen oder Speicher allokieren.
Java-Frameworks und Runtimes, die Obseria überwacht
- Spring Boot und Spring MVC/WebFlux. Controller, RestTemplate, WebClient und Spring-Data-Aufrufe erscheinen automatisch als Spans.
- Jakarta EE und Servlet-Container. Tomcat, Jetty, Undertow, WildFly und weitere Container werden auf Request-Ebene getract.
- Quarkus und Micronaut. Cloud-native Frameworks werden über den Agent oder ihre eingebauten OpenTelemetry-Erweiterungen erfasst.
- JDBC, Hibernate und Connection Pools. Jedes SQL-Statement wird zum Client-Span, die Auslastung von HikariCP erscheint als Metrik.
- Kafka-, JMS- und RabbitMQ-Clients. Producer- und Consumer-Spans tragen den Trace-Kontext über Queues hinweg.
- HotSpot-, OpenJDK- und GraalVM-JVMs. Runtime-Metriken folgen den OpenTelemetry-Semantic-Conventions für die JVM ab Java 8.
Die Java-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Tempo für Nutzer
Zeigt, wie schnell Ihre Java-Dienste auf Anfragen antworten, die Kennzahl, die für Ihre Kunden am meisten zählt.
Zustand des Speichers
Zeigt, wie viel Speicher Ihre Anwendung nutzt und ob sie sich mit der Zeit langsam ihrer Grenze nähert.
Pausen beim Aufräumen
Macht sichtbar, wie lange die Anwendung pausiert, um Speicher freizugeben, was Nutzer als plötzliche Hänger erleben.
Last der Verarbeitung
Zeigt, wie ausgelastet Ihre Anwendung ist und wie viele Aufgaben und Komponenten sie gerade gleichzeitig ausführt.
Alle 8 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
jvm.memory.used | By | Speicher je Pool (Eden, Survivor, Old Gen, Metaspace), Grundlage zur Leak-Erkennung. |
jvm.memory.used_after_last_gc | By | Lebender Heap nach der Collection; stetiges Wachstum deutet auf ein Memory Leak. |
jvm.memory.limit | By | Maximale Größe je Pool, um die Heap-Auslastung gegenüber -Xmx zu berechnen. |
jvm.gc.duration | s | Dauer der Garbage Collections je Collector; lange Pausen erhöhen die Latenz. |
jvm.thread.count | {thread} | Aktive Threads je Zustand; viele blockierte Threads zeigen Contention. |
jvm.class.loaded | {class} | Seit dem Start geladene Klassen; unerwartetes Wachstum weist auf Classloader-Leaks. |
jvm.cpu.recent_utilization | 1 | Aktuelle CPU-Nutzung des JVM-Prozesses, um CPU-Sättigung von Wartezeiten zu trennen. |
http.server.request.duration | s | Latenz-Histogramm eingehender HTTP-Requests je Route und Statuscode. |
Java-Monitoring in wenigen Minuten einrichten
- Schritt 1
Java Agent herunterladen
Laden Sie die offizielle opentelemetry-javaagent.jar oder installieren Sie den Obseria Agent, der sie auf Hosts und in Kubernetes-Pods einbinden kann.
- Schritt 2
Auf Obseria zeigen
Setzen Sie OTEL_SERVICE_NAME, den OTLP-Endpoint und Ihr Token als Umgebungsvariablen.
- Schritt 3
Mit -javaagent starten
Ergänzen Sie den Startbefehl der JVM um -javaagent; Traces und JVM-Metriken treffen nach wenigen Minuten ein.
# Offiziellen OpenTelemetry Java Agent herunterladen
curl -L -o opentelemetry-javaagent.jar \
https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar
export OTEL_SERVICE_NAME="checkout"
export OTEL_RESOURCE_ATTRIBUTES="deployment.environment.name=production,service.version=1.8.0"
export OTEL_EXPORTER_OTLP_ENDPOINT="${OBSERIA_OTLP_ENDPOINT}"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer%20${OBSERIA_TOKEN}"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
java -javaagent:./opentelemetry-javaagent.jar -jar checkout.jarSofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- JVM-Übersicht: Heap, GC, Threads, Klassen
- Service-Health mit RED-Metriken je Endpoint
- Alert bei zu langen GC-Pausen
- Alert bei steigendem Heap nach GC
- Langsamste SQL-Statements je Service
Java-Monitoring: Darauf kommt es an
Warum Java APM wichtig ist
Java betreibt nach wie vor einen großen Teil geschäftskritischer Backends: Zahlungsverkehr, Auftragsabwicklung, Kernbankensysteme und unzählige Spring-Boot-Microservices. Gesunde Java-Services sind schnell, doch die JVM liegt als zusätzliche Schicht zwischen Code und Betriebssystem. Garbage Collection, JIT-Compiler, Thread-Pools und Connection Pools beeinflussen die Antwortzeit. Java APM verbindet Distributed Tracing mit JVM-Monitoring, damit Sie erkennen, ob ein langsamer Request am eigenen Code, an der Runtime oder an einer nachgelagerten Datenbank liegt.
Klassisches Java Performance Monitoring setzte auf proprietäre Bytecode-Agents. Heute bietet der OpenTelemetry Java Agent denselben Zero-Code-Ansatz als offenen Standard: Eine JAR-Datei, per -javaagent eingebunden, instrumentiert Hunderte Bibliotheken und sendet Traces, Metriken und Logs per OTLP.
Die wichtigsten JVM-Signale
Ein sinnvolles Java Performance Monitoring beobachtet neben den Golden Signals jedes Service eine überschaubare Zahl an Runtime-Signalen:
- Heap und Memory Pools:
jvm.memory.usedje Pool sowiejvm.memory.used_after_last_gc. Letztere ist entscheidend, denn der lebende Heap nach der Collection zeigt den tatsächlichen Speicherbedarf. - Garbage Collection:
jvm.gc.durationje Collector (G1, ZGC, Parallel). Häufige oder lange Pausen schlagen direkt auf die Tail-Latenz durch. - Threads:
jvm.thread.countje Zustand. Viele blockierte Threads deuten auf Lock-Contention oder erschöpfte Pools. - CPU:
jvm.cpu.recent_utilizationzeigt, ob der Prozess CPU-gebunden ist oder auf I/O wartet. - Requests und Abhängigkeiten:
http.server.request.durationplus Datenbank- und Messaging-Spans liefern Rate, Fehler und Dauer je Endpoint.
Typische Performance-Probleme in Java erkennen
Memory Leaks
Ein Leak zeigt sich, wenn der Heap nach GC über Stunden oder Tage schrittweise steigt, gefolgt von längeren Collections und schließlich einem OutOfMemoryError. Ein Alert auf den Trend statt auf einen festen Schwellwert greift, bevor Nutzer etwas merken.
GC-Druck
Hohe Allokationsraten erzwingen häufige Young-Generation-Collections. Traces mit Lücken, die zeitlich mit GC-Ereignissen zusammenfallen, machen die Auswirkung sichtbar; Allokationsprofile zeigen die verantwortlichen Codepfade.
Erschöpfte Pools
Ist ein JDBC- oder HTTP-Client-Pool zu klein, stauen sich Requests. Sie sehen steigende Latenz, viele wartende Threads und Spans, die Zeit vor der eigentlichen Abfrage verbringen.
Langsame Queries und N+1-Muster
ORM-Frameworks wie Hibernate setzen pro Request mitunter Dutzende Statements ab. Im Trace-Wasserfall sind N+1-Muster sofort erkennbar.
Lock-Contention und hängende Threads
Synchronized-Blöcke um gemeinsam genutzte Caches oder alte Singletons serialisieren Requests unter Last. Typisch ist eine wachsende Zahl von Threads im Zustand BLOCKED, während die CPU-Last flach bleibt und die Latenz steigt. Lock-Profile und Thread-Dumps aus genau diesem Zeitraum zeigen, auf welchen Monitor alle warten.
Langsamer Start und kalter JIT-Compiler
Direkt nach einem Deployment hat der JIT-Compiler die heißen Codepfade noch nicht optimiert, die ersten Requests sind langsamer. Wer die Latenz je service.version in den ersten Minuten nach dem Rollout vergleicht, trennt Aufwärmeffekte von echten Regressionen. Das verhindert unnötige Rollbacks ebenso wie übersehene Fehler.
Logs ohne Kontext
Stacktraces in Logdateien helfen wenig, wenn unklar ist, zu welchem Request sie gehören. Der Java Agent schreibt Trace- und Span-IDs automatisch in den MDC von Logback und Log4j, sodass Sie vom Fehler-Log direkt zum zugehörigen Trace springen.
Best Practices für JVM-Monitoring
- Setzen Sie
service.name,service.versionunddeployment.environment.namefür jeden Service, um Releases vergleichen zu können. - Nutzen Sie den Agent für breite Abdeckung und ergänzen Sie manuelle Spans über die OpenTelemetry API nur für relevante Geschäftslogik.
- Betrachten Sie Heap nach GC und GC-Dauer immer gemeinsam; jeder Wert allein kann täuschen.
- Stimmen Sie Container-Memory-Limits und
-Xmxaufeinander ab und überwachen Sie JVM und cgroup. - Verwenden Sie Tail-based Sampling, um alle langsamen und fehlerhaften Traces zu behalten und Routineverkehr zu verwerfen.
So unterstützt Obseria Java APM
Obseria nimmt die Daten des standardmäßigen OpenTelemetry Java Agent per OTLP entgegen; ein proprietärer Agent ist nicht nötig. Auf Hosts und in Kubernetes kann der Obseria Agent den Java Agent automatisch einbinden und ergänzt Host-, Container- und Logdaten. TopoGraph ordnet jeden Java-Service seinen Datenbanken, Queues und Aufrufern zu. Continuous Profiling mit unter 1 % Overhead verknüpft Hotspot-Methoden mit den Traces, die sie bremsen. Steigt die Latenz, korreliert Obseria Intelligence GC-Spitzen, Deployments oder langsame Queries und präsentiert die Ursache mit nachvollziehbarer Beweiskette. Dashboards, Alerts und SLOs sind inklusive, und alle Daten bleiben per OTLP exportierbar.
Verwandte Integrationen
Passende Funktionen
Distributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenContinuous Profiling
Dauerhaftes Continuous Profiling zeigt, welche Funktionen in Produktion CPU, Speicher und Locks beanspruchen, mit unter 1 % Overhead und Verknüpfung zu Traces.
Mehr erfahrenFehler-Tracking
Die Errors Inbox gruppiert Exceptions aus Backend, Frontend und Mobile Apps zu Issues, zeigt deren Auswirkung und bündelt Zuweisung und Lösung in einem Workflow.
Mehr erfahrenMehr erfahren
Was ist APM (Application Performance Monitoring)?
Was ist APM? Wie Application Performance Monitoring Latenz, Durchsatz und Fehler misst, wie Distributed Tracing funktioniert und welche Kennzahlen zählen.
Was ist OpenTelemetry?
Was ist OpenTelemetry? So erzeugen API, SDKs, Collector, OTLP und Semantic Conventions herstellerneutrale Traces, Metriken, Logs und Profile.
Häufige Fragen zum Java-Monitoring
Nein. Der OpenTelemetry Java Agent instrumentiert gängige Frameworks und Bibliotheken beim Start. Sie ergänzen nur das Flag -javaagent und einige Umgebungsvariablen. Manuelle Spans sind optional.
Der OpenTelemetry Java Agent unterstützt Java 8 und neuer auf HotSpot, OpenJDK und weiteren gängigen JVMs. Obseria verarbeitet alles, was der Agent per OTLP sendet.
Der Overhead hängt von Traffic und Anzahl der instrumentierten Bibliotheken ab. Sampling und das Abschalten nicht benötigter Instrumentierungen halten ihn gering. Continuous Profiling in Obseria läuft mit unter 1 % Overhead.
Ja. Der Java Agent liefert standardmäßig JVM-Runtime-Metriken. Zusätzliche MBeans, etwa von Kafka oder Tomcat, erfassen Sie über die JMX-Unterstützung von OpenTelemetry oder den Collector.
Ja. Installieren Sie den Obseria Agent per Helm als DaemonSet oder nutzen Sie den OpenTelemetry Operator, um den Java Agent in Pods zu injizieren. Traces werden mit Pod-, Namespace- und Node-Metadaten angereichert.
Starten Sie heute mit dem Java-Monitoring
Binden Sie Java in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.