OpenTelemetry: Der Türöffner zur Fernauslesung

Bei Cloudanwendungen spielt die Möglichkeit zur Fernauslesung eine zentrale Rolle, um die Performance sicherzustellen. Anhand von Telemetrie-Daten wie Logs, Metriken und Traces lassen sich Fehler analysieren und die Anwendung überwachen, sei es die Speicherkapazität oder die CPU-Auslastung. Um diese Daten zu verarbeiten, werden oft proprietäre Werkzeuge genutzt. Ein Wechsel gestaltet sich dann schwer und kompliziert. Auch die Unterstützung von Systemen verschiedener Hersteller für verschiedene Umgebungen (lokale Tests vs. Produktion) erfordert viel Aufwand. All dies wäre viel einfacher, wenn es einen Service übergreifenden Standard für die Erfassung und Verwertung von Telemetrie-Daten gäbe. Die Antwort lautet: OpenTelemetry!

Fernmessung leicht gemacht mit OpenTelemetry (© Erick Dachselt – pixabay)

1x1 der Telemetrie

Telemetrie-Daten verraten uns aus der Ferne, wie es um die Performance und den Zustand von Anwendungen steht. Dabei gibt es verschiedene Arten von Daten, die unterschiedliche Informationen liefern:

• Logs: Aufzeichnungen von Ereignissen und Aktivitäten eines Systems, zur Fehlersuche und Behebung.
• Metriken: Datenpunkte, die den Zustand des Systems zu einem bestimmten Zeitpunkt widerspiegeln, um Trends zu identifizieren und Probleme frühzeitig zu erkennen.
• Spans: eine lokale Operationseinheit mit Zugehörigkeits-ID.
• Traces: Eine Sammlung von Spans mit gleicher Zugehörigkeits-ID, um den Weg einer Anfrage durch die verschiedenen Komponenten der Anwendung zu verfolgen, um Zusammenhänge besser zur verstehen und Engpässe zu identifizieren.

Aus der Ferne betrachtet 

Gerade bei komplexen, dezentralen Servicelandschaften ist die Fernmessung elementar, um Probleme schnell zu identifizieren. Allerdings gestaltet sich die Observability dabei auch besonders schwer, denn es sind verschiedene Frameworks, Bibliotheken und Programmiersprachen im Spiel. Für eine reibungslose Kommunikation ist es jedoch essenziell, die gleiche Sprache zu sprechen. Hier kommt OpenTelemetry ins Spiel. Der Open-Source-Standard für Telemetrie-Daten beinhaltet alles, was es zur Erfassung und Verwertung von Daten aus Cloud-native Anwendungen braucht. Die wichtigsten Funktionen sind folgende:

• OTel Spezifikation: Ein standardisiertes Datenmodell für Logs, Metriken und Traces. Es bildet die Grundlage für alle weiteren Komponenten.
• OTel SDK: Die Implementierung der Spezifikation für eine bestimme Programmiersprache, unterstützt werden u.a. Java, Go, Python und Javascript.
• OTLP: Ein Protokoll (auf HTTP oder gRPC-Basis) zum Versenden von Telemetrie-Daten im OTel Format.
• OTel Collector: Eine eigenständige Anwendung zum Einsammeln und Verarbeiten von Telemetrie-Daten aus verschiedenen Systemen.
• OTel Autoinstrumentation: Eine Bibliothek, die Telemetrie-Daten für bekannte Frameworks automatisch erzeugt, verarbeitet und über OTLP an den Collector sendet.

OpenTelemetry in der Praxis

Die Anwendung und die Infrastruktur, auf der die Anwendung läuft, erzeugen Telemetrie-Daten. Diese Daten können über das OTLP-Protokoll an den Collector gesendet werden. Für Java-Anwendungen erzeugt die Autoinstrumentation die Telemetrie-Daten. Dafür muss nur eine zusätzliche Jar-Datei beim Start eingebunden werden. Anschließend erkennt diese bekannte Bibliotheken und Frameworks (wie z.B. Log4j oder Spring Boot) automatisch. Für die CPU-Auslastung und den Netzwerkverkehr wird beispielsweise eine entsprechende Metrik erstellt. Wird das Framework nicht unterstützt, so können die Telemtrie-Daten mithilfe des OTel SDK manuell erzeugt und versendet werden. 

Zusammenspiel der OTel-Komponenten in der Praxis (© eXXcellent solutions)

Zusätzlich unterstützt der Collector viele bekannte Systeme und kann Daten von diesen selbständig abholen. Unterstützt werden z.B. Prometheus-Endpunkte, MySQL und Postgres-Datenbanken, nginx und Apache Web Server oder die Kubernetes-API.

Über welche Wege Daten in den Collector fließen können, wird über eine Datei konfiguriert. Der Collector kann die Daten bearbeiten und z.B. Logs nach Log-Level filtern oder Labels mit Metadaten anhängen. Der Export an Dritt-Systeme, wie z.B. Prometheus oder Jaeger, wird ebenfalls in der Datei konfiguriert. Auch hier unterstützt der Collector viele verschiedene Systeme. Telemetrie-Daten werden automatisch in das Format des Zielsystems konvertiert.

Kompatibler Support

Das OpenTelemetry-Projekt beschäftigt sich hauptsächlich mit dem Erzeugen und Verarbeiten von Telemetrie-Daten. Für die Speicherung und Aufbereitung bzw. Visualisierung werden Systeme von Drittanbietern benötigt. Für Metriken ist Prometheus die bekannteste Datenbank zum Speichern. Daneben gibt es noch Jaeger und Grafana Tempo für Traces, Grafana Loki für Logs oder auch Anbieter wie DataDog und SigNoz. Cloud-Anbieter wie Google Cloud oder AWS bieten hier ihre eigenen Lösungen an. Die Unterstützung verschiedener Systeme ist mit dem OpenTelemetry Collector keine Herausforderung mehr. Es sind lediglich verschiedene Konfigurationen notwendig, die meist mit geringem Aufwand geschrieben sind. Gespeicherte Daten können dann bspw. in Grafana Dashboards visualisiert werden. 

Passgenaue Observability

OpenTelemetry standardisiert nicht nur die Erfassung von Telemetrie-Daten, sondern passt sich auch an unterschiedliche Bedingungen und Systeme an. Bei der Entwicklung unserer Softwarelösungen, steht für uns immer die Passgenauigkeit im Vordergrund. OpenTelemetry bietet hier viele Vorteile, die über eine passgenaue Entwicklung hinaus, auch eine passgenaue Observability ermöglichen:

• Reaktionszeiten: Die Autoinstrumentation nimmt Entwicklern viel Arbeit ab, dadurch lassen sich Reaktionszeiten verkürzen und Kapazitäten werden freigesetzt.
• Entkopplung: Der Collector entkoppelt die Anwendung und die Zielsysteme. Verschiedene Zielsysteme bzw. Umgebungen lassen sich ohne Änderungen am Code der Anwendung unterstützen. Lediglich verschiedene Konfigurationen des Collectors sind notwendig.
• Wiederverwendbarkeit: Konfigurationen können für verschiedene Projekte leicht wiederverwendet werden.
• Konvertierung: Der Collector kann zwischen vielen Formaten konvertieren. Auch Systeme, die kein OTLP sprechen, können so leicht eingebunden werden.
• Zentralität: Daten von verschiedenen Microservices können an einer Stelle zentral eingesammelt und verarbeitet werden.
• Kompatibilität: Der Collector kann Telemetrie-Daten von Drittsystemen, auf deren Sourcecode kein Zugriff besteht, einsammeln – z.B. Metriken von Kubernetes oder einer Postgres-Datenbank.
• Migration: Die einfache Anpassung an verschiedene Systeme erleichtert die Migration zu einem anderen Cloudanbieter.

Dank dieser Vorteile ist OpenTelemetry der Türöffner für eine Fernmessung ohne Hemmschwellen und erlaubt es uns, die Performance unserer Lösungen noch besser zu gewährleisten und an die Bedürfnisse unserer Kunden anzupassen.

Weitere Informationen:

Über Christoph Löser: