Application Observability mit Grafana und OpenTelemetry

Fragen, die Antworten fordern

Das Monitoring von Software-Applikationen wirft Fragen auf, die die Integration verschiedener Tools erfordern. 

• Funktioniert meine Applikation wie beabsichtigt?
• Wie hoch ist die Fehlerquote?
• Tritt ein ungewöhnliches Fehlverhalten auf, und wenn ja, welche Anfragen sind dafür verantwortlich?
• Reagieren meine Endpunkte ausreichend schnell, um eine gute Benutzererfahrung zu gewährleisten? 
• Existieren Memory Leaks? 
• Verbessert die neue Applikationsversion die Performance im Vergleich zur alten? 
• Bringt das Framework-Update einen zusätzlichen Performance-Boost oder sehen wir eine Regression in den Antwortzeiten? 
• Welche Endpunkte werden am häufigsten angefragt, und wie effizient sind sie? 
• Wie viele Anfragen pro Sekunde verarbeitet meine Anwendung derzeit? 
• Sind zusätzliche Caching-Maßnahmen erforderlich, und sollten bestimmte Datenbank-Abfragen optimiert werden?

Die Eckpfeiler der Application Observability

Um diese Fragen zu beantworten, sind in der Application Observability bestimmte Überwachungstechniken unverzichtbar. Dazu gehören Logging, Tracing, Metriken und Error Tracking. Sie bilden das Rückgrat, um den Zustand, die Performance und die Fehlerrate der Anwendungen effektiv zu überwachen. Hier ein kurzer Überblick:

Metriken

Metriken bieten quantitative Messwerte über die Leistung und den Zustand einer Anwendung. Sie liefern z. B. Einblicke in Ressourcennutzung, Durchsatz und Antwortzeiten. Metriken sind entscheidend, um den Zustand einer Anwendung zu überwachen, frühzeitig auf Abweichungen zu reagieren und die Skalierbarkeit zu optimieren. Durch das Sammeln und Analysieren von Metriken können wir auf Probleme reagieren und die User-Experience verbessern.

Logging

Logging ist wichtig für die Identifizierung, Diagnose und Behebung von Fehlern in einer Anwendung. Durch das Aufzeichnen von relevanten Ereignissen, Nachrichten und Warnungen erhalten wir Einblicke in den Zustand der Anwendung. Log-Streams ermöglichen es, den Ablauf von Aktivitäten nachzuvollziehen und so Fehlerquellen zu lokalisieren.

Traces

Tracing ermöglicht eine detaillierte Verfolgung von Anfragen über verschiedene Komponenten hinweg. Dies hilft uns besonders in verteilten Systemen Engpässe und Latenzen zu identifizieren. Durch das Verfolgen des Pfads einer Anfrage durch verschiedene Services können wir Interaktionen besser verstehen und Optimierungsmöglichkeiten erkennen.

Error Tracking

Error Tracking ermöglicht uns, Echtzeitinformationen über auftretende Fehler zu erhalten, einschließlich detaillierter Call-Stacks und Kontextinformationen. Durch die Integration von Error-Tracking-Tools können wir proaktiv auf auftretende Probleme reagieren, bevor sie sich auf die Benutzer:innen auswirken. Dies erleichtert nicht nur die Fehlerbehebung, sondern auch die kontinuierliche Verbesserung der Anwendungsqualität. Error Tracking ist somit ein unverzichtbarer Bestandteil der Gesamtstrategie für die Application Observability.

Grafana: Open Source Observability 

Nachdem wir die Grundpfeiler genauer betrachtet haben, stellt sich die Frage: Welche Observability Tools eignen sich am besten, um diese Anforderungen zu erfüllen? Es gibt zweifellos eine Vielzahl, darunter Dynatrace, DataDog, NewRelic, AppDynamics, Grafana und viele mehr. Die Auswahl kann überwältigend sein. In unserem Team, das Open Source und offene Standards bevorzugt, fiel die Wahl nach umfangreicher Recherche auf Grafana. Grafana ist ein leistungsstarkes Open-Source-Observability-Tool, mit dem wir Metriken, Traces und Logs aus Infrastruktur und Applikation kombinieren und analysieren können. Es unterstützt verschiedene Datenquellen wie Prometheus-Metriken, Cloud-Provider-Metriken und Tracings.

Sehr praktisch: Open Source Observability ermöglicht ein einfaches lokales Testing im Docker-Container und verhindert einen Vendor-Lock durch proprietäre Observability-Dienste.

Während es also theoretisch möglich ist, Grafana mit den notwendigen Storage-Diensten selbst zu betreiben, haben wir uns für die Cloud-Variante »Grafana Cloud« von Grafana Labs entschieden. Sie bietet ein faires und nutzungsabhängiges Preismodell. Wir möchten uns schlussendlich um die Überwachung unserer eigenen Anwendungen kümmern und nicht auch die Überwachungstools überwachen.

Das OpenTelemetry-Projekt

Wer sich mit Application Observability auseinandersetzt, stößt auf das OpenTelemetry-Projekt. OpenTelemetry (OTel) ist ein plattformübergreifender, offener Standard zur Sammlung und Übertragung von Telemetriedaten. Ziel ist die Standardisierung von Protokollen und Konventionen im Observability-Bereich, um die Interoperabilität und Austauschbarkeit zu erhöhen. Es beinhaltet unter anderem:

• APIs für Bibliotheken, um Telemetriedaten während der Laufzeit des Codes zu erfassen.
• Semantische Konventionen definieren Standards für die Benennung und den Inhalt der Telemetriedaten. (Es macht Sinn, dass Apps, die Telemetriedaten produzieren, und die Tools, die die Daten empfangen, sich darauf einigen, was verschiedene Arten von Daten bedeuten und welche Arten von Daten nützlich sind, damit die Tools effektive Analysen bereitstellen können.)
• Eine Schnittstelle für Exporter. Exporter sind Plugins, die es ermöglichen, Telemetriedaten in bestimmten Formaten an verschiedene Telemetrie-Backends zu übertragen.
• Das OTLP-Protokoll ist eine anbieterneutrale Netzwerkprotokolloption zur Übertragung von Telemetriedaten. Einige Tools und Anbieter unterstützen dieses Protokoll zusätzlich zu bereits vorhandenen proprietären Protokollen, die sie möglicherweise haben.

Die Verwendung von OTel ermöglicht die Nutzung vieler APM-Systeme, einschließlich Open Source Observability Tools wie Prometheus und Grafana. Oder Systeme von APM-Anbietern, die mit OpenTelemetry zusammenarbeiten.

Die Architektur in einem Kubernetes Environment

Wie wird das Ganze nun in unsere Cloud-Architektur integriert? In der Regel ist die Installation von Agents notwendig, die die Telemetriedaten regelmäßig sammeln und an die Observability-Plattform versenden. In unserem Fall verwenden wir den Grafana Agent, der als Kubernetes Helm Chart im EKS Cluster verteilt wird. Der Grafana Agent Helm Chart bringt verschiedene Komponenten mit:

• Log-Agent Daemon Set, welches auf jedem Node läuft, die Standard-Output (StdOut) Logs sammelt und an den Grafana-Agent übermittelt.
• Grafana Agent Deployment, welches Prometheus Metriken von den verschiedenen Pods einsammelt und die gesammelten Logs, Traces und Metriken an die Grafana Cloud übermittelt.

Sobald der Agent konfiguriert und installiert ist, beginnt er mit der Sammlung der Daten und sendet die Metriken an das Grafana Prometheus Backend und die Logs an den Grafana Log-Service. Im Grafana Dashboard können wir dann auf eine Vielzahl vorgefertigter Dashboards zugreifen oder unsere eigenen Dashboards erstellen und konfigurieren:

Fazit zu Application Observability

Das Application Observability Universum ist zu Beginn überwältigend und man hat bei den Tools die Qual der Wahl. Durch unseren Fokus auf Open-Source konnten wir uns aber sehr schnell auf Grafana einigen und haben in den letzten Jahren sehr gute Erfahrungen damit gemacht.