Telemetrie gestalten, bevor sie gespeichert wird

Was ist eine Telemetrie-Pipeline?

Eine Telemetrie-Pipeline, auch Observability Pipeline oder Log-Pipeline genannt, ist die Verarbeitungsschicht zwischen den Quellen, die Telemetrie erzeugen, und den Systemen, die sie speichern und auswerten. Sie nimmt Logs, Metriken, Traces und Events entgegen, verarbeitet sie nach festgelegten Regeln und leitet das Ergebnis an ein oder mehrere Ziele weiter.

Ohne eine solche Schicht landet jedes Byte, das eine Anwendung ausgibt, unverändert im Speicher. Dazu gehören ausführliche Debug-Ausgaben, sich wiederholende Health Checks, personenbezogene Daten, die nie hätten geloggt werden sollen, und Attribute mit hoher Kardinalität, die niemand abfragt. Eine Pipeline schafft einen zentralen Ort, an dem Sie entscheiden, was behalten wird, in welcher Form und wohin es geht.

Warum eine Telemetrie-Pipeline wichtig ist

Das Telemetrievolumen wächst mit jedem neuen Service, Cluster und Feature. Die Kosten wachsen meist mit, während der Anteil der Daten, der tatsächlich zur Fehlersuche genutzt wird, klein bleibt. Gleichzeitig verlangt die DSGVO, personenbezogene Daten zu minimieren und zu schützen. Das lässt sich vor der Speicherung deutlich leichter umsetzen als danach.

Eine Pipeline löst beide Aufgaben. Plattformteams reduzieren Rauschen zentral, statt jedes Anwendungsteam um geändertes Logging zu bitten. Security- und Compliance-Teams definieren Maskierungsregeln an einer Stelle. Entwicklerinnen und Entwickler erhalten weiterhin die Signale, die sie brauchen, angereichert mit einheitlichem Kontext.

Typische Verarbeitungsschritte

• Filtern: Datensätze nach Schweregrad, Attribut, Quelle oder Muster verwerfen, etwa Debug-Logs aus der Produktion oder Health Checks des Load Balancers.
• Anreichern: Attribute wie Team, Service, Umgebung, Region, Kubernetes-Metadaten oder die aktuelle Deployment-Version ergänzen.
• PII maskieren: Felder wie E-Mail-Adressen, IP-Adressen, Session-Tokens oder Kundennummern schwärzen, hashen oder entfernen.
• Sampeln: Head-based Sampling für planbares Volumen nutzen oder Tail-based Sampling, das erst nach Abschluss eines Traces entscheidet und Traces mit Fehlern oder auffälliger Latenz behält.
• Aggregieren: umfangreiche Log-Ströme in Metriken umwandeln, zum Beispiel Anfragen pro Statuscode und Endpunkt.
• Routen: jeden Datenstrom an die Speicherstufe, Aufbewahrungsdauer oder das Ziel leiten, das zu seiner Nutzung passt.

So funktioniert Obseria Pipeline

Obseria Pipeline ist Teil des Ingest-Pfads der Obseria-Plattform. Sie nimmt Daten von OpenTelemetry SDKs und dem OpenTelemetry Collector per OTLP, vom optionalen Obseria Agent und über Prometheus Remote Write entgegen. Ihre bestehende Instrumentierung müssen Sie nicht ersetzen.

Regeln werden pro Quelle, Service oder Attribut definiert und gelten für Logs, Metriken, Traces und Events gleichermaßen. Die verarbeiteten Daten landen in Obseria Lake, dem indexfreien Speicher für alle Signale, und lassen sich dort mit OQL, PromQL oder SQL abfragen. Da die Pipeline vor dem Speicher sitzt, verursachen verworfene Daten keine Speicherkosten, und aggregierte Metriken ersetzen große Mengen roher Logs, wo die Details nicht gebraucht werden.

Eine einfache Regel könnte so aussehen:

when source == "checkout" and level == "debug"
  drop
when attribute exists "user.email"
  mask "user.email"
when trace has error or duration > 2s
  keep trace

Regeln lassen sich vor der Aktivierung mit Beispieldaten testen. Änderungen werden versioniert, sodass Teams nachvollziehen können, was sich wann geändert hat.

Tail-based Sampling für Traces

Head-based Sampling entscheidet zu Beginn einer Anfrage, ob ein Trace behalten wird. Das ist günstig, aber zufällig, sodass seltene Fehler verloren gehen können. Tail-based Sampling wartet, bis alle Spans eines Traces eingetroffen sind, und entscheidet dann anhand des Ergebnisses. So behalten Sie jeden Trace mit Fehler, jeden Trace oberhalb einer Latenzschwelle und einen repräsentativen Anteil des normalen Verkehrs. Obseria Pipeline unterstützt beide Verfahren, die Sie pro Service kombinieren können.

Best Practices für Telemetrie-Pipelines

1. Zuerst messen. Prüfen Sie, welche Quellen und Attribute das meiste Volumen erzeugen, bevor Sie Regeln schreiben.
2. Früh maskieren. Wenden Sie PII-Regeln möglichst nah am Ingest an und behandeln Sie sie als Grundlage für alle Quellen.
3. Aggregieren statt löschen. Wird ein Log-Strom nur für Zählungen genutzt, machen Sie daraus eine Metrik.
4. Nach Ergebnis sampeln. Behalten Sie Fehler und langsame Anfragen, sampeln Sie erfolgreiche Routinepfade.
5. Regeln regelmäßig prüfen. Services ändern sich, und Regeln aus dem letzten Quartal können heute nützliche Daten verbergen.