SLO-first Beobachtbarkeit: Welche Logs, Metriken und Traces wirklich nötig sind

Einstieg: Das Problem mit der Telemetrie-Explosion

Viele Teams sammeln heute „alles“: jede Logzeile, jede Metrik, jeden Trace. Das Ergebnis ist oft das Gegenteil von Observability: Datenberge ohne Fokus, hohe Kosten, Alert-Fatigue und trotzdem langsame Diagnosen. Dieser Artikel zeigt einen pragmatischen Gegenentwurf für Entwicklerinnen und Entwickler in Deutschland: SLO-first Observability. Statt mit Datenquellen anzufangen, definieren wir zuerst Serviceziele und Diagnosefragen – und leiten daraus ab, welche Logs, Metriken und Traces wirklich gebraucht werden.

Warum SLOs und Diagnosefragen zuerst kommen müssen

Service Level Objectives (SLOs) beschreiben messbar, was Nutzerinnen und Nutzer von einem Dienst erwarten. Der Google-SRE-Ansatz empfiehlt, Monitoring und Alerting genau daran auszurichten, nicht an beliebigen Rohmetriken. So vermeiden Teams Lärm und konzentrieren sich auf das, was Verfügbarkeit und Nutzererlebnis tatsächlich definiert. Siehe dazu das Google SRE Workbook (Kapitel Monitoring) und das SRE-Buch zu SLOs/SLIs.

Beispielhaft – Werte sind kontextabhängig und dienen nur zur Illustration:

• SLI 1 (Erfolgsquote): Anteil erfolgreicher Checkout-Transaktionen pro Zeitintervall; mögliches SLO: mindestens 99,9 % in einem 28‑Tage‑Fenster.
• SLI 2 (Latenz): P95 der End-to-End-Latenz für „Add to Cart → Zahlung“; mögliches SLO: unter 300 ms im Normalbetrieb.

Mit sauberen SLOs ergibt sich ein klarer Fragekatalog, den Observability beantworten muss:

• Ist der Dienst aus Kundensicht erreichbar und schnell genug? (Verfügbarkeit, P95/P99-Latenzen)
• Wo steigt die Fehlerquote – Client, Edge, Upstream-Dependency oder Service-intern?
• Welche Änderung (Release, Feature-Flag, Konfiguration) korreliert mit der Regression?
• Wo hängt die Transaktion im kritischen Pfad? (Datenbank, Queue, externer Dienst)
• Reicht die Kapazität? (Threads, Worker, Queues, Ratenbegrenzung)

Diese Fragen sind der Filter für die Auswahl von Metriken, Logs und Traces – nicht umgekehrt. Vgl. Google SRE Workbook zum Prinzip „Alerts auf SLOs statt auf Rohmetriken“.

Signale einordnen: Metriken, Logs, Traces – Rollen und Grenzen

OpenTelemetry fasst Observability als Zusammenspiel komplementärer Signale auf. In der Praxis hat jede Signalart eine Kernstärke:

• Metriken: schnell, kosteneffizient, ideal für SLOs, Trends, Kapazität und Alerting. Aggregierbar und damit sparsam zu speichern. (Vgl. OTel Observability Primer)
• Logs: detailreich für Einzelfälle, aber volumenschwer. Am besten strukturiert, selektiv und zeitlich begrenzt einsetzen.
• Traces: zeigen Kausalität und kritische Pfade über Servicegrenzen; gut für verteilte Diagnosen, Sampling kann Volumen stark reduzieren. (Vgl. OTel Observability Primer)

Konsequenz: Für Verfügbarkeit und Latenz reichen oft Metriken als Primärsignal; Logs und Traces kommen gezielt für Diagnosefragen dazu, die ohne Kontextfluss oder Detailinformationen nicht beantwortbar sind.

Prinzipien für datenarme Instrumentierung

Ziel ist nicht „wenig Daten um jeden Preis“, sondern „nur Daten mit klarem Nutzen“. Drei Prinzipien helfen sofort:

• Purpose-driven Metrics: Jede Metrik braucht einen klaren Zweck (Alerting auf SLO/SLI, Trendbeobachtung, Kapazitätsplanung). Ohne Zweck – nicht instrumentieren. Das deckt sich mit dem Google-SRE-Ansatz.
• Labels und Kardinalität diszipliniert einsetzen: In Prometheus steht jede einzigartige Labelkombination für eine neue Zeitreihe. Hohe Kardinalität (z. B. User-IDs, E-Mails) treibt Kosten/Last stark nach oben und wird explizit nicht empfohlen. Verwenden Sie Basiseinheiten (Seconds, Bytes) und sinnvolle Suffixe. Siehe Prometheus Best Practices zu Naming und Instrumentierung: keine hochkardinalen Werte in Labels, konsistente Einheiten, semantisch klare Metriken. Prometheus Naming, Prometheus Instrumentation
• Sampling bewusst einsetzen: Nicht jede Anfrage muss getraced werden. OpenTelemetry beschreibt Head- vs. Tail-Sampling sowie probabilistische Varianten. Sampling reduziert Volumen, verändert aber die Diagnosemöglichkeiten – das ist ein bewusster Trade-off. OTel Sampling

Wann reichen Metriken allein? Wann sind Logs oder Traces nötig?

• Metriken reichen oft für: SLO-Überwachung (Erfolgsquote, Verfügbarkeit, Latenzperzentile), Kapazität (CPU, Speicher, Queue-Tiefe), Auslastung/Rate (Requests/s), Fehlerraten (Ratio aus Countern). Sie sind das bevorzugte Ausgangssignal für Alerts.
• Logs sind nötig, wenn: Sie konkrete Fehlerzustände oder Geschäftskontexte nachzeichnen müssen (z. B. Validierungsfehler, seltene Edge-Cases). Nutzen Sie strukturierte Logs, die sich filtern lassen. Vermeiden Sie vertrauliche Informationen und unkontrollierte Textfelder.
• Traces lohnen sich, wenn: Transaktionen über mehrere Services laufen, Pfade variieren und Performance-Probleme oder Fehler Orte im Pfad haben. Traces helfen, Kausalität zu verstehen und Bottlenecks sichtbar zu machen (kritischer Pfad, Teil-Span-Latenzen). OpenTelemetry rahmt diese Rolle explizit. OTel Observability Primer

Sampling und Auswahl: Head vs. Tail – und was praktikabel ist

OpenTelemetry unterscheidet im Kern:

• Head-Sampling: Entscheidung beim Trace-Start (im SDK). Günstig und einfach, aber ohne Wissen über spätere Ereignisse.
• Tail-Sampling: Entscheidung am Ende des Traces (typisch im Collector) basierend auf vollständigem Kontext (z. B. nur Fehlerstatus oder Ausreißer behalten). Aufwendiger, aber zielgenauer. OTel Sampling, Grafana OTel Collector – Sampling

Wichtig zur Reihenfolge: Tail-Sampling wirkt sinnvoll nur, wenn die Daten bis zum Collector überhaupt ankommen. Ein vorangestelltes restriktives Head-Sampling im SDK kann potenziell genau die Traces verwerfen, die Tail-Regeln später auswählen würden. In vielen Setups gilt daher: Entweder Tail-Sampling im Collector als zentrale Stelle nutzen oder Head-Sampling moderat/gezielt konfigurieren und die Implikationen dokumentieren. Kombinierte Strategien sind möglich, sollten aber bewusst die Verwerfungsstellen und Ziele berücksichtigen.

Plattformspezifisch gibt es zusätzlich Optionen wie Fixed-Rate- oder Rate-limited-Sampling; diese können Volumen und Kosten begrenzen, erfordern aber eine bewusste Abwägung zwischen Kostenzielen und Diagnosefähigkeit (z. B. in Azure Application Insights – OpenTelemetry Sampling).

Minimal-Setup: ein pragmatischer Startpunkt

Der folgende Vorschlag deckt die meisten Web-/API- und Service-Szenarien ab. Er ist absichtlich knapp und rollenspezifisch gegliedert.

Empfohlene minimale Metriken und SLIs (rollenbasiert)

Für jedes Rollenprofil steht die Liste für SLO-/Alerting-Tauglichkeit und Diagnose-Grundlagen. Werte und Grenzwerte hängen vom Produktkontext ab.

• Edge/API-Gateway und öffentliches Frontend
• http_requests_total (mit Labels code, method)
• request_duration_seconds als Histogramm (auswertbar für P50/P95/P99)
• error_ratio (ableitbar aus Codes; alternativ errors_total)
• SLIs: Erfolgsquote und Latenz-Perzentile am Kundenschnittpunkt (z. B. Checkout-Fluss)
• Service-intern (Business- und Data-Services)
• in_progress_requests
• dependency_call_duration_seconds (Client- und Server-seitig, differenziert nach Abhängigkeit)
• queue_depth und worker_inflight für asynchrone Verarbeitung
• Fehlerraten je Abhängigkeit (Ratio pro Dependency)
• Batch/ETL-Jobs
• last_success_timestamp_seconds
• stage_duration_seconds (grobe Phasen)
• processed_records_total

Hinweis zu Typen und Einheiten: Nutzen Sie Basiseinheiten, sprechende Suffixe und trennen Sie unterschiedliche Größen in eigene Metriken. Vermeiden Sie Label-Werte mit hoher Kardinalität. Siehe Prometheus Best Practices zu Naming und Instrumentierung.

Logging-Minimalismus

• Strukturierte Logs mit Leveln (INFO/WARN/ERROR), korreliert mit Trace-/Span-IDs, aber ohne personenbezogene Daten oder Geheimnisse.
• Fokus auf Fehlersituationen, Validierungsfehler, Retry-/Backoff-Ereignisse und rare Pfade. Keine Dauer-„Debug“-Logs in Produktion.
• Kurze Aufbewahrungszeit für Standardlogs; längerfristige Audit-Logs strikt getrennt und zweckgebunden.

Tracing-Minimalismus

• Start mit einer moderaten Sampling-Rate oder gezielten Regeln auf Fehler/Extreme (z. B. Tail-Sampling im Collector für Span-Status ERROR oder sehr hohe Latenz). Beachten Sie die Reihenfolge der Sampling-Entscheidungen (siehe oben), damit Regeln nicht ins Leere laufen.
• Instrumentieren Sie den kritischen Geschäftsfluss End-to-End (z. B. Checkout), inklusive der wichtigsten externen Abhängigkeiten.

Retention, Aggregation und Recording Rules

• Recording Rules dienen primär der Voraggregation (z. B. Perzentile, Fehlerquoten, SLO-bezogene Reihen) und der Entlastung von Abfragen. Unterschiedliche Aufbewahrungszeiten je Metrik sind plattformspezifisch und erfordern in der Regel Langzeit-/Remote-Storage mit Downsampling; in Prometheus Core ist die Retention global konfiguriert. Prüfen Sie daher Architektur und Ziele, bevor Sie Rohdaten kürzer und abgeleitete Kennzahlen länger vorhalten.
• Regelmäßig überprüfen, welche Metriken tatsächlich in Alerts, Dashboards und Kapazitätsplanung verwendet werden.

Alerting ohne Alarmmüdigkeit

• Alerts auf SLOs/SLIs statt auf Rohmetriken: Ein roher CPU-Peak ohne Nutzerwirkung ist selten alertwürdig. Ein drohendes Überschreiten des Error-Budgets schon. Dies ist Kern des Google-SRE-Ansatzes. (Siehe Google SRE Workbook und SRE-Buch zu SLOs)
• Wenige, klare Eskalationspfade mit Runbooks: Jede Alarmregel braucht eine Kurzbeschreibung, Prüfschritte und eine Zuordnung (Ownership). So wird Triage reproduzierbar.
• Rate Limiting und Deduplication im Benachrichtigungskanal, um Stürme zu vermeiden.

Kosten- und Betriebsaspekte: Messen, steuern, begrenzen

• Messgrößen: Anzahl aktiver Zeitreihen, Label-Kardinalität pro Metrikfamilie, Logzeilen/s nach Level, Trace-Spans/s und Sampling-Rate. Diese Größen machen „Datenmüll“ sichtbar.
• Kontrollpunkte: Ingestion-Quotas, Sampler-Konfiguration, Retention-Policies, Label-Review. Sampling kann Kosten senken, darf aber nicht blind Diagnoseziele unterlaufen. OTel Sampling, Grafana Collector – Sampling
• Budgetmechanismen: Rate-Limits und (wo verfügbar) tägliche Kostengrenzen/Quotas helfen, Ausreißer abzufangen. Plattformspezifisch gibt es Fixed-Rate- oder Rate-limited-Sampling (z. B. Azure Application Insights); testen Sie Regeln gezielt, da jede Reduktion Diagnosemöglichkeiten in Einzelfällen einschränken kann.

DSGVO & Logs: knappe Praxisleitplanken

Für Teams in Deutschland ist Datenschutz Teil der Observability-Architektur. Zu berücksichtigen sind u. a. DSGVO-Grundsätze wie Datenminimierung, Zweckbindung und Speicherbegrenzung. Daraus folgen praktikable Regeln:

• Personenbezogene Daten (PII) und Geheimnisse nicht loggen; wenn geschäftlich nötig, dann sparsam, strukturiert und mit Redaction/Pseudonymisierung vor Speicherung.
• Zweck und Aufbewahrung pro Log-Kategorie dokumentieren; Standardlogs kurz halten, Audit-Logs getrennt, geschützt und nur so lange wie erforderlich speichern.
• Löschkonzepte und Zugriffskontrollen definieren; Korrelation über IDs so planen, dass keine unnötigen PII in Telemetrie fließen.

Orientierung zu Auslegung und Praxis bieten Veröffentlichungen des European Data Protection Board (EDPB); ein Einstieg ist das EDPB-Portal: EDPB – Home

Trade-offs und typische Fallstricke

• Zu wenig vs. zu viel: Reine „Minimal“-Setups ohne Traces scheitern bei verteilten Performanceproblemen; ungebremstes Logging scheitert an Kosten und Rauschen. Starten Sie klein, messen Sie Nutzen, erweitern Sie gezielt.
• Kardinalität unterschätzt: User-IDs oder dynamische Felder als Labels explodieren Zeitreihen. Prometheus rät ausdrücklich ab – halten Sie die Kardinalität niedrig. Prometheus Naming, Prometheus Instrumentation
• Sampling falsch verortet: Ein restriktives Head-Sampling im SDK kann Tail-Regeln im Collector aushebeln. Reihenfolge und Ziele vorab festlegen. OTel Sampling

Typische Fehlentscheidungen und wie man sie vermeidet

Viele der häufigen Probleme sind vermeidbar, wenn Teams strukturierte Regeln und Review-Prozesse einführen. Praktische Fallen und wie man sie umgeht:

• Fehlentscheidung: Alle Rohdaten sammeln „für den Fall der Fälle“.
• Warum das scheitert: Unkontrolliertes Logging und Metriken ohne Zweck führen zu hohen Kosten, schwer durchsuchbaren Datenbeständen und Alert‑Rauschen.
• Vermeidung: Definieren Sie zuerst SLOs/SLIs und die Diagnosefragen; instrumentieren Sie nur Metriken und Logs, die einen klaren Nutzungsfall (Alerting, Debugging, Kapazitätsplanung) erfüllen. (Vgl. Google SRE Workbook)
• Fehlentscheidung: Labels mit hoher Kardinalität nutzen (z. B. User‑IDs) statt aggregierter Kennzeichen.
• Warum das scheitert: Jede einzigartige Labelkombination erzeugt eine neue Zeitreihe, was Speicher- und Abfragelasten exponentiell erhöht.
• Vermeidung: Sparsame Label‑Strategie gemäß Prometheus‑Leitfaden: nur ergänzende, begrenzte Labels verwenden; hoch‑kardinale Werte pseudonymisieren oder weglassen. Prometheus Naming
• Fehlentscheidung: Head‑Sampling zu restriktiv setzen und damit wertvolle Tail‑Traces verwerfen.
• Warum das scheitert: Regeln, die Fehler erst am Ende erkennen (Tail‑Sampling), funktionieren nicht, wenn relevante Spans schon im SDK verworfen wurden.
• Vermeidung: Falls Tail‑Sampling geplant ist, sorgen Sie dafür, dass Traces bis zum Collector gelangen oder konfigurieren Sie im SDK eine moderate Sampling‑Rate; testen Sie die Pipeline, um Verwerfungsstellen zu erkennen. OTel Sampling
• Fehlentscheidung: Alerts auf Rohmetriken ohne SLO‑Kontext.
• Warum das scheitert: Resultat sind viele Pager, die nicht den Nutzerimpact widerspiegeln.
• Vermeidung: Alerts an Error‑Budget‑Verbrauch oder SLO‑Verletzungen koppeln; Rohmetriken nur als unterstützende Hinweise nutzen (Google SRE‑Ansatz).
• Fehlentscheidung: Keine Governance und regelmäßige Reviews der Telemetrie.
• Warum das scheitert: Metriken und Logs wachsen unkontrolliert, alte, nicht genutzte Zeitreihen bleiben aktiv.
• Vermeidung: Quartalsweise Review‑Zyklen einführen: welche Metriken/Logs/Traces wurden genutzt, welche nicht; ungenutzte Telemetrie entfernen und Namens-/Label‑Konventionen durchsetzen.

Diese Empfehlungen sind bewusst allgemein und stützen sich auf die dokumentierten Praxisleitfäden (Google SRE, Prometheus, OpenTelemetry). Sie zielen darauf ab, typische Fehlentscheidungen technisch nachvollziehbar und operativ behebbar zu machen, ohne unbelegte Detailbehauptungen einzuführen.

Konkrete Umsetzungsschritte für Teams

So kommen Sie in wenigen Iterationen zu „SLO-first Observability“:

1. SLOs formulieren und SLIs auswählen

• Nutzerzentrierte SLIs (Erfolgsquote, Latenz) definieren; Grenzwerte explizit als Beispiel starten und mit Stakeholdern validieren. Dokumentieren Sie den kritischen Pfad.

1. Minimal-Setup instrumentieren

• Metriken gemäß Rollenliste implementieren; Einheiten/Typen konsistent halten. Für zentrale Flows Tracing aktivieren (gerne mit moderatem Sampling). Logs strukturieren, PII/Secrets ausschließen.

1. Alerting an SLOs koppeln

• Alerts auf Error-Budget-Verbrauch/Latenz-Perzentile; Runbooks und Ownership ergänzen. Rohmetriken nur als unterstützende Signale nutzen.

1. Kosten- und Datenkontrollen aktivieren

• Sampling- und Retention-Policies festlegen, Kardinalität/Serien zählen. Regeln im Team reviewen; Anpassungen versionieren und testen.

1. Regelmäßige Reviews

• Quartalsweise: Welche Metriken/Logs/Traces wurden genutzt? Welche nicht? Unbenutzte Telemetrie entfernen, Lücken gezielt schließen. Governance: Label- und Namenskonventionen pflegen (vgl. Prometheus-Best-Practices).

Takeaway: Kleine, wiederholbare Schritte mit sichtbarem Nutzen schlagen „Big-Bang“-Programme.

Fazit: Beobachtbar bleiben – ohne Datenmüll

Observability wird dann wirksam, wenn sie von SLOs und Diagnosefragen ausgeht und Signale zweckgebunden einsetzt. Metriken bilden das belastbare Rückgrat für SLOs und Alerts. Logs bleiben fokussiert und kurzlebig. Traces liefern Kausalität – mit bewusstem Sampling und richtiger Platzierung. Disziplin bei Kardinalität, Sampling und Aufbewahrung senkt Kosten und erhöht die Signalqualität. Wer diesen Rahmen beibehält, kann Systeme verlässlich betreiben – ohne im Telemetrie-Rauschen zu versinken.

Quellenhinweise zur Vertiefung (Auswahl):

• Google SRE: Monitoring & Alerting auf SLOs (Workbook) und Service Level Objectives (SRE Book)
• OpenTelemetry: Observability Primer und Sampling-Konzepte
• Prometheus: Metric/Label Naming und Instrumentierungs-Best-Practices
• Grafana Docs: OpenTelemetry Collector – Sampling
• EDPB: DSGVO-Grundsätze (Datenminimierung, Zweckbindung, Speicherbegrenzung)