Wie Sie aufhören, Code für Logs und Metriken umzuschreiben

Stellen Sie sich vor: Sie haben ein Dutzend Java-Microservices in der Produktion. Irgendwann beginnt einer davon zu „hängen". Sie öffnen die Logs, aber da ist nichts – die Standardmeldungen reichen nicht aus, um zu verstehen, in welcher genauen Phase die Anfrage stecken bleibt. Vertrautes Szenario? In der Regel geht der Entwickler nun in den Code, dekoriert Methoden mit Annotationen, fügt Tracing-Abhängigkeiten hinzu, baut das Projekt neu und deployt es erneut. Und wenn es Hunderte von Services gibt, die auf verschiedenen Frameworks geschrieben wurden?

Im OpenTelemetry-Ökosystem gibt es ein Projekt, das dieses Problem elegant und, was besonders schön ist, fast faul löst. Das ist opentelemetry-java-instrumentation. Es ist ein spezieller Java-Agent, der zur Laufzeit in Ihre Anwendung „einschleusen" und Telemetrie sammeln kann, ohne eine einzige Zeile neuen Code.

Was dieser Agent ist und warum Sie ihn brauchen

Im Wesentlichen ist es eine JAR-Datei, die Sie beim Start der JVM anhängen. Er verwendet dynamische Bytecode-Injection. Wenn Ihre Anwendung Klassen aus beliebten Bibliotheken lädt (zum Beispiel Spring, Hibernate, gRPC oder Kafka), injiziert der Agent sorgfältig Logik zum Erstellen von Spans und Sammeln von Metriken.

Dies ist eine ideale Option für zwei Szenarien. Erstens, wenn Sie schnell Observability zu einem Legacy-Projekt hinzufügen müssen, das man nur ungern anfasst. Zweitens, wenn Sie die Datensammlung im gesamten Unternehmen standardisieren möchten, ohne dass jedes Team manuell das SDK konfiguriert.

Drei coole Features, die das Leben erleichtern

Automatische Magie out of the box

Der Agent unterstützt eine enorme Anzahl von Bibliotheken. Wenn Sie einen Standard-Stack wie Spring Boot mit PostgreSQL und Redis verwenden, müssen Sie überhaupt nichts konfigurieren. Sie hängen einfach den Agenten an, und in Ihrem Monitoring-System (zum Beispiel Jaeger oder Zipkin) erhalten Sie einen Aufrufbaum: vom eingehenden HTTP-Request bis zur Datenbankabfrage und Cache-Antwort.

Kontext in Logs propagieren (MDC)

Eines der nützlichsten Dinge beim täglichen Debugging ist das automatische Einfügen der Trace-ID in Logs. Der Agent kann Ihre Logger (Logback, Log4j2) selbst finden und die ID des aktuellen Trace zu MDC hinzufügen. Jetzt können Sie, wenn Sie einen Fehler in den Logs sehen, einfach die ID kopieren und den gesamten Pfad dieser Anfrage über alle Services hinweg finden. Kein Raten mehr, welcher Benutzer diese NullPointerException ausgelöst hat.

Flexible Konfiguration ohne Neuerstellung

Alle Parameter – wohin Daten gesendet werden, wie oft sie gesampled werden, welche Attribute zu Spans hinzugefügt werden – werden über Umgebungsvariablen oder Java-System-Properties übergeben. Das bedeutet, dieselbe Binary Ihrer Anwendung kann Daten in der Entwicklung an die Konsole senden und in der Produktion an einen leistungsstarken OpenTelemetry-Collector-Cluster.

Wie Sie das zum Laufen bringen

Der Einrichtungsprozess ist überraschend einfach. Laden Sie zunächst die neueste opentelemetry-javaagent.jar von der Releases-Seite herunter. Fügen Sie dann ein Flag zum Startbefehl Ihrer Anwendung hinzu:

java -javaagent:path/to/opentelemetry-javaagent.jar \
     -Dotel.resource.attributes=service.name=my-cool-service \
     -jar myapp.jar

Standardmäßig erwartet der Agent, dass ein Collector, der Daten über das OTLP-Protokoll akzeptiert, irgendwo unter localhost:4318 läuft. Wenn Sie etwas anderes verwenden möchten, zum Beispiel Zipkin, ändern Sie es mit einem Flag: -Dotel.traces.exporter=zipkin.

Unter der Haube und Erweiterbarkeit

Interessanterweise beschränkt Sie das Projekt nicht nur auf „Automatisierung". Wenn die integrierten Funktionen nicht ausreichen, können Sie den Erweiterungsmechanismus nutzen. Sie können Ihre eigene JAR-Datei schreiben, die benutzerdefinierte Instrumentierungsregeln oder unternehmensspezifische Attribute hinzufügt.

Für diejenigen, die der Agenten-Magie überhaupt nicht vertrauen, liefert das Projekt dieselben Instrumentierungsbibliotheken separat aus. Sie können sie als reguläre Abhängigkeiten hinzufügen und manuell konfigurieren, müssen dann aber die Notwendigkeit akzeptieren, Code zu ändern.

Lohnt es sich?

Ich stoße oft auf die Meinung, dass Java-Agents eine „Black Box" sind, die eine Anwendung verlangsamen können. Daran ist etwas Wahres: Der Agent verbraucht Ressourcen für die Bytecode-Transformation beim Start und fügt einen kleinen Overhead bei der Ausführung von Requests hinzu. In 95% der Fälle ist dieser Overhead jedoch vernachlässigbar im Vergleich zum Nutzen, den Sie beim Aufspüren von Bugs in einem verteilten System erhalten.

Wem wird es besonders gut passen:

1. Teams, die auf Microservices umsteigen und ohne Tracing im Chaos versinken.
2. Support, der „gestern" braucht, um zu verstehen, warum der alte Monolith langsam ist.
3. Architekten, die einen einheitlichen Monitoring-Standard implementieren.

Wenn Sie OpenTelemetry in Ihren Java-Projekten noch nicht ausprobiert haben, ist dieser Agent der schnellste und schmerzloseste Weg, um anzufangen. Probieren Sie es einfach lokal aus und sehen Sie, wie viele interessante Dinge Sie über das Verhalten Ihres Codes unter Last erfahren.