Telemetrie-Pipeline

Was ist eine Telemetrie-Pipeline?

Eine Telemetrie-Pipeline, auch Observability-Pipeline genannt, ist die Infrastruktur, die Telemetrie von ihrem Entstehungsort zum Ort der Analyse transportiert. Statt dass jede Anwendung und jeder Agent Daten direkt an ein Backend schickt, sitzt die Pipeline dazwischen und übernimmt drei Aufgaben: sammeln, verarbeiten und routen.

Pipelines sind zentral geworden, weil das Telemetrievolumen schneller wächst als die Budgets. Ohne Kontrollpunkt wird jedes Debug-Log, jede Metrik mit hoher Kardinalität und jeder Trace eines Health Checks zum vollen Preis gespeichert, und sensible Daten gelangen womöglich in Systeme, die sie nie sehen sollten.

Die drei Stufen

1. Sammeln

Receiver nehmen Daten von SDKs, Agents und Infrastruktur entgegen: OTLP von OpenTelemetry-SDKs, Prometheus-Scrapes, Syslog, Datei-Tails, Streams von Cloud-Anbietern oder Kafka-Topics. Gutes Sammeln umfasst Pufferung und Backpressure, damit ein langsames Backend nicht zu Datenverlust an der Quelle führt.

2. Verarbeiten

Prozessoren verändern die Daten unterwegs. Typische Operationen:

• Filtern und verwerfen: Debug-Logs, Health-Check-Spans oder ungenutzte Metriken entfernen.
• Sampeln: einen repräsentativen Anteil der Traces behalten, idealerweise per Tail-based Sampling, das Fehler und langsame Requests bewahrt.
• Anreichern: Ressourcenattribute wie Cluster, Region, Team oder Deployment-Version ergänzen.
• Maskieren und schwärzen: personenbezogene Daten, Tokens und Secrets vor der Speicherung entfernen oder hashen.
• Transformieren: unstrukturierte Logs in Felder zerlegen, Attribute nach Semantic Conventions umbenennen, Logs in Metriken umwandeln.
• Aggregieren: Kardinalität reduzieren oder Metriken aus Spans vorberechnen.

3. Routen

Exporter senden jeden Datenstrom an sein Ziel: sicherheitsrelevante Logs an ein SIEM, vollständige Rohdaten in günstigen Archivspeicher, kuratierte Daten an das Observability-Backend und EU-Daten ausschließlich in EU-Regionen.

Beispiel: eine Pipeline im OpenTelemetry Collector

Der OpenTelemetry Collector ist der verbreitetste Open-Source-Baustein. Eine beispielhafte Log-Pipeline, die Debug-Logs verwirft, ein personenbezogenes Attribut löscht und die Daten vor dem Export bündelt:

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
  filter/drop-debug:
    error_mode: ignore
    logs:
      log_record:
        - 'severity_number < SEVERITY_NUMBER_INFO'
  attributes/pii:
    actions:
      - key: user.email
        action: delete
  batch: {}

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [memory_limiter, filter/drop-debug, attributes/pii, batch]
      exporters: [otlp]

Die Reihenfolge ist wichtig: Der Memory Limiter steht vorn und schützt den Prozess, gefiltert wird früh, damit spätere Prozessoren weniger Daten verarbeiten, und das Batching kommt zuletzt vor dem Export.

Wo Telemetrie-Pipelines laufen

Die meisten Produktionsumgebungen kombinieren mehrere Ebenen statt einer einzigen zentralen Instanz:

• Agent-Ebene: Ein Collector oder Agent auf jedem Host oder als Kubernetes-DaemonSet sammelt lokale Daten, ergänzt Host- und Pod-Metadaten und wendet günstige Filter nah an der Quelle an.
• Gateway-Ebene: Ein horizontal skalierter Pool von Collectors empfängt Daten von Agents und Anwendungen, setzt zentrale Richtlinien wie PII-Maskierung und Tail-based Sampling durch und übernimmt den Export. Für Tail-based Sampling müssen alle Spans eines Traces dieselbe Gateway-Instanz erreichen, meist über ein Load Balancing nach Trace-ID.
• Puffer-Ebene: Bei sehr hohen Volumina entkoppelt eine Message Queue wie Kafka die Producer von der Verarbeitung und fängt Backend-Ausfälle ab.
• Verwaltete Ebene: Die Ingest-Pipeline der Observability-Plattform wendet Regeln an, nachdem die Daten angekommen sind, aber bevor sie gespeichert werden.

Warum eine Telemetrie-Pipeline wichtig ist

• Kostenkontrolle: Daten, die vor der Speicherung verworfen oder gesampelt werden, verursachen keine Speicherkosten. Filtern am Eingang ist meist der größte einzelne Hebel für die Observability-Kosten.
• Compliance: Wer personenbezogene Daten schon beim Ingest maskiert, unterstützt DSGVO und interne Datenrichtlinien, weil sensible Werte nie gespeichert werden.
• Datenqualität: Einheitliche Attributnamen und Anreicherung sorgen dafür, dass Abfragen und Korrelation teamübergreifend funktionieren.
• Flexibilität: Routing entkoppelt Quellen von Backends. Sie können Ziele ändern oder ergänzen, ohne Anwendungen neu zu instrumentieren.

Best Practices

• Pipelines als Code definieren, Änderungen wie Anwendungscode reviewen und schrittweise ausrollen.
• Die Pipeline selbst überwachen: angenommene, abgelehnte und verworfene Elemente, Größe der Exporter-Queue und Latenz.
• Bewusst filtern und sampeln und dokumentieren, was verworfen wird, damit niemand nach Daten sucht, die nie gespeichert wurden.
• Volumenreduktion nah an der Quelle durchführen und Richtlinien wie PII-Regeln zentral pflegen, damit sie überall gelten.

Typische Fehler

• Eine Pipeline ohne Pufferung bauen, sodass ein Backend-Ausfall Daten kostet.
• Traces nur head-based sampeln und dann genau die seltenen Fehler verpassen, die man gebraucht hätte.
• PII in manchen Pipelines maskieren, in anderen nicht, und so Lücken in der Compliance lassen.
• Prozessoren ohne Tests ändern, sodass ein falscher Filter unbemerkt ganze Datenströme verwirft.

Wie Obseria hilft

Obseria Pipeline filtert, reichert an, maskiert PII und routet Daten beim Ingest. Gefilterte Daten kosten nur die Ingestion, keine Speicherung. Die Pipeline arbeitet mit OpenTelemetry-Daten, unterstützt Tail-based Sampling, und Sie können Daten jederzeit per OTLP exportieren. Einen praktischen Ansatz beschreibt der Beitrag Observability-Kosten senken mit Pipeline-first.