Observability Stack

Warum Observability¶

Monitoring sagt, dass der Server 95% CPU hat. Observability sagt, dass es an einer einzigen SQL-Abfrage am /api/orders-Endpunkt liegt, die seit dem gestrigen Deploy die gesamte Tabelle scannt statt den Index zu nutzen.

Der Unterschied? Monitoring erkennt Symptome. Observability deckt Ursachen auf. In einem verteilten System mit Dutzenden Microservices, Message Queues und Datenbanken reicht es nicht zu wissen, dass etwas kaputt ist. Sie muessen wissen warum, wo und seit wann — in Minuten, nicht Stunden.

Drei Saeulen¶

Observability ruht auf drei Arten von Telemetriedaten:

Metriken — numerische Werte ueber die Zeit. CPU, Speicher, Request-Anzahl, Fehlerrate, Latenz. Schnell abzufragen, guenstig zu speichern, ideal fuer Dashboards und Alerts. Prometheus ist der De-facto-Standard.

Logs — strukturierte Aufzeichnungen von Ereignissen. Request kam an, Abfrage lief, Fehler trat auf. Kontext, den Metriken nicht haben. Loki aggregiert Logs aus der gesamten Infrastruktur an einem Ort.

Traces — der Pfad eines Requests durch das gesamte System. Benutzer klickte → API Gateway → Auth Service → Order Service → Datenbank → Response. Distributed Tracing zeigt, wo der Request Zeit verbrachte und wo er verloren ging. Tempo/Jaeger visualisieren die gesamte Reise.

Die Staerke liegt in der Korrelation. Alert auf hohe Latenz → Klick auf Metrik → Wechsel zu Trace → Drill-down in den Log des spezifischen Service. Ein nahtloser Flow vom Symptom zur Ursache.

OpenTelemetry — Instrumentierung ohne Vendor Lock-in¶

OpenTelemetry (OTel) ist ein Open-Source-Framework fuer die Sammlung von Telemetriedaten. Ein CNCF-Projekt, unterstuetzt von allen grossen Anbietern, De-facto-Industriestandard.

Warum OTel¶

Vendor-Neutralitaet: Sie instrumentieren Ihre Anwendung einmal mit dem OTel SDK. Daten werden ueber den OTel Collector ueberallhin gesendet — Grafana Stack, Datadog, New Relic, Honeycomb. Backend wechseln? Collector-Config aendern, nicht den Anwendungscode.

Auto-Instrumentierung: Fuer die meisten Sprachen (Java, Python, Node.js, Go, .NET) ist Auto-Instrumentierung verfuegbar. Eine Abhaengigkeit hinzufuegen und Sie erhalten Traces fuer HTTP-Requests, Datenbank-Abfragen, gRPC-Aufrufe — ohne eine einzige Codezeile. Manuelle Instrumentierung wird nur hinzugefuegt, wo spezifischer Kontext benoetigt wird.

Standardisierte Semantiken: OTel definiert Konventionen fuer die Benennung von Metriken, Attributen und Span-Namen. http.request.method, db.system, server.address — konsistent ueber Sprachen und Frameworks. Dashboards und Alerts funktionieren universell.

OTel Collector¶

Der Collector ist der zentrale Punkt fuer Empfang, Verarbeitung und Export von Telemetriedaten. Er nimmt Daten von Anwendungen entgegen, transformiert sie (filtert, anreichert, sampelt) und sendet sie an Backends.

Deployment-Patterns: - Sidecar — Collector als Sidecar-Container neben jeder Anwendung. Isolation, Einfachheit. - Agent — DaemonSet auf jedem Node. Sammelt Daten von allen Pods auf dem Node. - Gateway — Zentralisierter Collector-Cluster. Alle Daten fliessen durch einen Punkt. Horizontal skalierbar.

Typischerweise kombinieren wir: Agents auf Nodes fuer Sammlung, Gateway fuer Processing und Routing.

Prometheus — Metriken¶

Prometheus ist eine Zeitreihendatenbank und Monitoring-System. Pull-Modell — Prometheus scrappt aktiv Metriken von Ihren Anwendungen ueber einen HTTP-Endpunkt.

Was wir messen¶

RED-Metriken fuer Services: - Rate — Requests pro Sekunde - Errors — Anteil fehlerhafter Antworten - Duration — Latenz (p50, p95, p99)

USE-Metriken fuer Infrastruktur: - Utilization — wie stark die Ressource genutzt wird - Saturation — wie ueberlastet sie ist (Queue-Tiefe) - Errors — Ressourcen-Fehlerrate

Business-Metriken: - Bestellungen pro Minute - Conversion Rate - Umsatz pro Minute - Queue-Tiefe

PromQL (Prometheus Query Language) ermoeglicht anspruchsvolle Abfragen: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) — Fehlerrate der letzten 5 Minuten. Alerts direkt in PromQL definiert.

Grafana — Visualisierung und Alerting¶

Grafana bringt alle Daten an einem Ort zusammen. Dashboards fuer Prometheus-Metriken, Loki-Logs, Tempo-Traces — mit Drill-through zwischen ihnen.

Dashboards¶

Service-Ueberblick: Golden Signals fuer jeden Service — Request Rate, Fehlerrate, Latenz. Auf einen Blick sehen Sie den Zustand des gesamten Systems. Rot? Drill-down.

Infrastruktur: Node-Level-Metriken — CPU, Speicher, Disk, Netzwerk. Kubernetes-Pod-Metriken. Cluster Health. Kapazitaetsplanung.

Business: Echtzeit-Business-Metriken neben technischen. Bestellungen ruecklaeufig? Geschaeftsproblem (Kampagne beendet) oder technisch (Zahlungsgateway antwortet nicht)?

Alerting¶

Grafana Alerting mit Multi-Condition-Regeln. Nicht nur „CPU > 90%” — kombinierte Bedingungen: „Fehlerrate > 5% UND Request Rate > 100 rps UND es dauert laenger als 5 Minuten.” Wir reduzieren False Positives und erhoehen das Signal-to-Noise-Verhaeltnis.

Benachrichtigungen: Slack, PagerDuty, OpsGenie, E-Mail, Webhook. Eskalationsregeln — Alert geht zuerst an Slack; nach 15 Minuten ohne Bestaetigung an PagerDuty On-Call.

Distributed Tracing¶

In einem Monolithen ist Debugging straightforward — der Stack Trace sagt alles. In einer Microservices-Architektur durchlaeuft ein Request Dutzende Services. Wo ist der Engpass? Distributed Tracing beantwortet das.

Wie es funktioniert¶

Jeder Request bekommt eine eindeutige Trace ID. Jede Operation innerhalb des Requests ist ein Span — mit Startzeit, Dauer, Attributen und Beziehung zu einem Parent Span. Das Ergebnis: ein Baum von Spans, der den gesamten Pfad des Requests durch das System repraesentiert.

Beispiel: Ein Benutzer oeffnet eine Produktseite. - Frontend → API Gateway (5ms) - API Gateway → Product Service (2ms) - Product Service → PostgreSQL-Abfrage (45ms) ← Engpass - Product Service → Redis Cache Write (1ms) - Product Service → Recommendation Service (15ms) - Recommendation Service → ML-Modell-Inferenz (12ms)

Der Trace zeigt, dass der 45ms-Datenbankaufruf das Problem ist. Klick auf den Span, SQL-Abfrage, Explain Plan, Connection Pool Stats sichtbar. Problem in Minuten identifiziert.

Sampling¶

In Produktion mit Tausenden Requests pro Sekunde speichern wir nicht jeden Trace. Sampling-Strategien:

• Head-based Sampling: Entscheidung am Anfang — 10% der Traces werden aufgezeichnet. Einfach, kann aber interessante Traces verpassen.
• Tail-based Sampling: Entscheidung am Ende — wir zeichnen Traces mit Fehlern, hoher Latenz, spezifischen Attributen auf. Intelligenter, aufwaendiger zu implementieren.

Typischerweise kombinieren wir: 5-10% Head-based Sampling + 100% der Traces mit Fehlern und hoher Latenz.

Log-Aggregation mit Loki¶

Loki von Grafana Labs ist ein Log-Aggregationssystem inspiriert von Prometheus. Es indiziert nur Labels (Metadaten), nicht den Volltext — was es deutlich guenstiger als Elasticsearch macht.

Structured Logging: Anwendungen loggen im JSON-Format mit standardisierten Feldern. trace_id, service, level, user_id — filterbar, korrelierbar mit Traces und Metriken.

LogQL: Eine Abfragesprache aehnlich PromQL. {service="order-api"} |= "error" | json | duration > 1s — finde Error-Logs vom Order-API, bei denen die Operation laenger als eine Sekunde dauerte.

Wie wir implementieren¶

1. Assessment — wir kartieren den aktuellen Monitoring-Stand und identifizieren Luecken
2. Architektur — wir entwerfen den Observability Stack nach Skalierung, Budget und Anforderungen
3. Infrastruktur — wir deployen Prometheus, Grafana, Loki, Tempo (Self-hosted oder Cloud)
4. Instrumentierung — OTel Auto-Instrumentierung + manuelle Instrumentierung kritischer Pfade
5. Dashboards und Alerts — Golden Signals, Business-Metriken, Eskalationsregeln
6. Runbooks — was zu tun ist wenn ein Alert ausloest. Direkt vom Alert verlinkt.
7. Schulung — das Team lernt Dashboards zu lesen, mit Traces zu debuggen und PromQL-Abfragen zu schreiben

Stack¶

Metriken: Prometheus, Thanos/Mimir (Langzeitspeicher), VictoriaMetrics.

Logs: Grafana Loki, Elasticsearch (Legacy), Fluentd/Fluent Bit.

Traces: Grafana Tempo, Jaeger, Zipkin.

Instrumentierung: OpenTelemetry SDK, OTel Collector.

Visualisierung: Grafana, Grafana Cloud.

Alerting: Grafana Alerting, Alertmanager, PagerDuty, OpsGenie.

Verwandt mit