Observability-Kosten um über 50 % senken: der Pipeline-First-Ansatz

Wenn Ihre Observability-Rechnung schneller wächst als Ihr Traffic, liegt das selten am Preis pro Gigabyte. Das Problem ist, dass standardmäßig alles gespeichert wird: jede Debug-Logzeile, jeder erfolgreiche Health-Check-Span, jedes Metrik-Label, das jemand vor zwei Jahren während eines Incidents ergänzt hat. Der wirksamste Weg, Observability-Kosten zu senken, besteht darin, die Entscheidung über Behalten oder Verwerfen an den Anfang des Datenflusses zu verlegen, also in eine Pipeline, statt hinterher mit Aufbewahrungsfristen und Abfragelimits zu kämpfen.

Dieser Beitrag beschreibt den Pipeline-First-Ansatz, den wir empfehlen, geht die Techniken in der Reihenfolge ihrer Wirkung durch und endet mit einem durchgerechneten Kostenbeispiel auf Basis der veröffentlichten Obseria-Preise.

Warum Observability-Kosten explodieren

Das Telemetrievolumen skaliert mit drei Faktoren gleichzeitig: Traffic, Anzahl der Services und Ausführlichkeit der Instrumentierung. Der Umstieg auf Microservices vervielfacht die Spans pro Request. Kubernetes vervielfacht die Logquellen. Auto-Instrumentierung erzeugt Spans für jeden Datenbankaufruf und jeden HTTP-Client. Nichts davon ist falsch, aber kaum ein Team fragt mehr als einen Bruchteil dessen ab, was es sammelt.

Typische Quellen von Verschwendung, die wir sehen, wenn Teams ihre Daten analysieren:

• Health- und Readiness-Checks, die alle paar Sekunden pro Pod einen Span und eine Logzeile erzeugen.
• Logs auf Debug- und Trace-Level, die nach einer Analyse in Produktion aktiv geblieben sind.
• Erfolgreiche, schnelle Traces, die zu 100 % gespeichert werden, obwohl nur eine kleine Stichprobe jemals geöffnet wird.
• Doppelte Events, etwa derselbe Fehler, geloggt von Anwendung, Sidecar und Ingress Controller.
• Metrik-Labels mit hoher Kardinalität wie User-IDs oder vollständige URLs, die die Zahl der Zeitreihen vervielfachen.

Was Pipeline-First bedeutet

Pipeline-First heißt: Jedes Signal durchläuft eine Verarbeitungsschicht, bevor es gespeichert wird, und diese Schicht hat für jede Datenklasse explizite Regeln. Die Entscheidung lautet nicht mehr „alles speichern, später löschen“, sondern „speichern, was einen bekannten Abnehmer hat“. In der Praxis kann diese Pipeline der OpenTelemetry Collector sein, Obseria Pipeline beim Ingest oder eine Kombination aus beiden.

Die entscheidende Einsicht ist wirtschaftlich. Bei nutzungsbasierter Abrechnung ist das Speichern von Daten meist deutlich teurer als ihre Annahme. Bei Obseria kosten Logs, Spans und RUM-Events 0,060 $ pro Million beim Ingest, aber 0,540 $ pro Million bei der Speicherung. Daten, die Obseria Pipeline herausfiltert, kosten nur den Ingest-Preis. Jeder Datensatz, den Sie nicht speichern, spart also 90 % seiner Kosten, und jeder Datensatz, den Sie bereits vor dem Verlassen des Clusters verwerfen, spart sie vollständig.

Schritt 1: Rauschen an der Quelle filtern

Beginnen Sie mit dem günstigsten Hebel: Daten ganz ohne Abnehmer. Health Checks, Readiness Probes und Debug-Logs lassen sich in der Regel ohne lange Diskussion entfernen. Im OpenTelemetry Collector erledigt das der filter-Prozessor, noch bevor die Daten den Cluster verlassen:

processors:
  filter/drop-noise:
    error_mode: ignore
    traces:
      span:
        - attributes["http.route"] == "/healthz"
        - attributes["http.route"] == "/metrics"
    logs:
      log_record:
        - severity_number < SEVERITY_NUMBER_INFO
        - IsMatch(body, ".*GET /healthz.*")

Messen Sie, bevor Sie etwas verwerfen. Eine einzige OQL-Abfrage zeigt, welche Services und Log-Level das meiste Volumen erzeugen, sodass Sie die größten Verursacher zuerst angehen:

fetch logs
| summarize records = count(), by:{service.name, level}
| sort records desc
| limit 20

In den meisten Umgebungen stehen die ersten fünf Zeilen dieser Abfrage für einen großen Teil des gesamten Logvolumens, und mindestens eine davon ist ein Level oder eine Quelle, die niemand ansieht.

Schritt 2: Traces nach Wert sampeln, nicht nach Zufall

Head-based Sampling entscheidet zu Beginn eines Requests, ob ein Trace behalten wird, bevor irgendjemand weiß, ob er fehlschlagen wird. Tail-based Sampling wartet, bis der Trace vollständig ist, und behält, was wertvoll ist: Fehler, langsame Requests, seltene Endpunkte und eine kleine Basisstichprobe von allem anderen.

processors:
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: keep-errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: keep-slow
        type: latency
        latency: { threshold_ms: 1000 }
      - name: baseline
        type: probabilistic
        probabilistic: { sampling_percentage: 10 }

Mit 10 % Basisstichprobe plus allen Fehlern und langsamen Requests speichern viele Teams 10 bis 20 % ihrer Spans und behalten trotzdem jeden Trace, den sie während eines Incidents tatsächlich öffnen würden. Ratenbasierte Metriken wie Request-Anzahl und Latenz-Perzentile sollten vor dem Sampling berechnet werden, damit Dashboards korrekt bleiben.

Schritt 3: Aggregieren und Kardinalität reduzieren

Metriken sind pro Datenpunkt günstiger, aber die Kardinalität vervielfacht sie. Ein Latenz-Histogramm mit einem user_id-Label erzeugt eine Zeitreihe pro Nutzer. Entfernen oder bündeln Sie solche Labels in der Pipeline:

processors:
  transform/cardinality:
    error_mode: ignore
    metric_statements:
      - context: datapoint
        statements:
          - delete_key(attributes, "user_id")
          - delete_key(attributes, "request_id")
          - replace_pattern(attributes["http.url"], "/orders/[0-9]+", "/orders/{id}")

Ein zweiter Hebel ist die Umwandlung repetitiver Logs in Metriken. Wird eine Logzeile ohnehin nur gezählt („payment declined“, „cache miss“), beantwortet eine Counter-Metrik dieselbe Frage zu einem Bruchteil der Kosten. Behalten Sie eine Stichprobe der Rohzeilen für den Kontext und verwerfen Sie den Rest.

Schritt 4: Maskieren und nach Wert routen

Nicht jeder Datensatz braucht dieselbe Behandlung. Audit- und Security-Logs benötigen unter Umständen eine lange Aufbewahrung, Anwendungslogs eine schnelle Suche über 30 Tage, und ausführliche Debug-Ausgaben sind nur in der Stunde nach einem Deployment nützlich. Routen Sie jede Klasse explizit, statt alles mit einer einzigen Aufbewahrungsrichtlinie an ein Ziel zu schicken. Maskieren Sie im selben Schritt personenbezogene Daten wie E-Mail-Adressen, IP-Adressen und Zahlungsreferenzen. Daten ohne PII brauchen keine besonderen Zugriffskontrollen, Löschprozesse oder separate Speicherung. Das spart Kosten und Compliance-Aufwand zugleich.

Ein Rechenbeispiel mit Obseria-Preisen

Nehmen wir eine mittelgroße Plattform mit den folgenden monatlichen Volumina. Grundlage sind die Obseria-Listenpreise pro Million Datensätze: Logs und Spans 0,060 $ beim Ingest und 0,540 $ bei der Speicherung, Metrik-Datenpunkte 0,020 $ beim Ingest und 0,180 $ bei der Speicherung.

Signal	Volumen pro Monat	Vorher: Ingest + Speicherung	Pipeline-Regel	Nachher
Logs	20 Mrd. Datensätze	1.200 $ + 10.800 $ = 12.000 $	60 % in Obseria Pipeline gefiltert (nur Ingest)	1.200 $ + 4.320 $ = 5.520 $
Spans	10 Mrd. Spans	600 $ + 5.400 $ = 6.000 $	Tail-based Sampling im Collector behält 15 %	90 $ + 810 $ = 900 $
Metriken	5 Mrd. Datenpunkte	100 $ + 900 $ = 1.000 $	30 % der Zeitreihen per Kardinalitätsregeln entfernt	70 $ + 630 $ = 700 $
Gesamt		19.000 $		7.120 $

Die Rechnung für Logs: 20.000 Millionen Datensätze mal 0,060 $ ergeben 1.200 $ für den Ingest. Ohne Filterung kostet die Speicherung aller Datensätze 20.000 mal 0,540 $, also 10.800 $. Filtert Obseria Pipeline beim Ingest 60 % heraus, werden weiterhin alle 20.000 Millionen angenommen (1.200 $), aber nur 8.000 Millionen gespeichert. Das kostet 4.320 $.

Bei den Spans findet das Sampling bereits im Collector statt. Gesendet werden nur die behaltenen 15 % (1.500 Millionen Spans): 90 $ für den Ingest und 810 $ für die Speicherung. Bei den Metriken verlassen die entfernten Zeitreihen den Cluster gar nicht erst: 3.500 Millionen Datenpunkte kosten 70 $ beim Ingest und 630 $ bei der Speicherung.

Die Gesamtsumme sinkt von 19.000 $ auf 7.120 $ pro Monat, eine Ersparnis von 11.880 $ oder 62,5 %. Fehler, langsame Traces und jede Logzeile mit bekanntem Abnehmer bleiben erhalten. Ihre eigenen Zahlen werden abweichen, die Struktur der Rechnung bleibt aber gleich, und der größte Hebel ist fast immer die Speicherung.

Damit es so bleibt: Ownership und Leitplanken

Einsparungen verpuffen, wenn niemand für sie verantwortlich ist. Drei Gewohnheiten sichern sie dauerhaft:

1. Volumen Teams zuordnen. Ergänzen Sie in der Pipeline ein Ressourcenattribut team und prüfen Sie das Volumen pro Team monatlich. Teams, die ihre eigenen Zahlen sehen, ändern ihr eigenes Logging.
2. Regeln wie Code reviewen. Pipeline-Regeln liegen in Git, werden reviewt und über die CI ausgerollt. Eine Regel, die Daten verwirft, verdient dieselbe Sorgfalt wie eine Schemamigration.
3. Einen Notausgang vorsehen. Erlauben Sie einen Debug-Header oder ein Feature Flag, das für einen einzelnen Request oder Mandanten während einer Analyse volles Sampling und ausführliche Logs erzwingt.

Achten Sie außerdem darauf, was Sie nie verwerfen: Audit-Logs, Security-Events und alles, was für Compliance erforderlich ist, sollten Sampling-Regeln vollständig umgehen und explizit geroutet werden.

Wie Obseria den Pipeline-First-Ansatz unterstützt

Obseria Pipeline filtert, reichert an, maskiert PII und routet Daten beim Ingest, und das ist in jedem Tarif enthalten. Da gefilterte Daten nur den Ingest kosten, können Sie breit starten, beobachten, was Sie tatsächlich abfragen, und die Regeln nach und nach verschärfen, ohne Services neu zu instrumentieren. Tail-based Sampling wird nativ unterstützt, bestehende OpenTelemetry-Collector-Pipelines funktionieren unverändert weiter. Abgerechnet wird pro Signal, mit unbegrenzt vielen Nutzern und ohne Host- oder Lizenzgebühren pro Seat. Das Volumen, das Sie steuern, sind die Kosten, die Sie steuern.

Am schnellsten finden Sie Ihr eigenes Sparpotenzial, wenn Sie die Volumenabfrage von oben auf eine Woche echter Daten anwenden. Die 14-tägige Testphase kommt ohne Kreditkarte aus, und die ersten Traces aus bestehenden OTel-SDKs treffen in der Regel innerhalb von 15 Minuten ein.