OpenTelemetry läuft in Ihrem Unternehmen nicht gut? Bringen Sie es in 90 Tagen auf Kurs.

Ihre Observability‑Rechnung hat sich im letzten Quartal verdoppelt und niemand findet den Trace für genau die eine Anfrage, auf die es ankommt. Währenddessen durchsuchen Ingenieur:innen weiterhin Logs mit grep, während Milliarden Spans in einen Anbieter fließen, an den Sie sich nicht binden wollen. Wenn Sie die jüngsten "OTel läuft nicht gut"‑Threads gelesen haben, sind Sie nicht allein. Das Problem ist nicht OpenTelemetry. Es ist, wie Sie es eingeführt haben.

Dies ist ein 90‑Tage‑, SLO‑getriebener Rettungsplan, der Kosten um 50–70 % senkt, Kardinalitätsexplosionen stoppt und Traces in der Incident Response messbar nützlich macht. Er funktioniert für Monolithen, Microservices, Serverless und Edge‑Funktionen. Er ist in US‑SaaS‑Umgebungen mit 100–10.000 RPS und polyglotten Stacks praxiserprobt.

Warum Ihr OTel‑Rollout aus dem Ruder lief

• Sie haben alles roh verschickt. Head‑Sampling mit 1 % und Spans direkt zu einem Anbieter zu pushen sorgt für die Illusion von Adoption und die Realität von Schmerz. Tail‑Events kommen nicht an. Hot Paths sind unterrepräsentiert. Ihre „Baseline“ ist Rauschen.
• Kardinalität hat Ihre Zeitreihen gesprengt. Jemand hat user_id, email oder request_path als Labels hinzugefügt. Zehn Labels mit je 100 Werten ergeben 10^10 theoretische Reihen. Ihr Metrik‑Backend ist geschmolzen, also haben Sie Exemplare abgeschaltet oder so stark heruntergesampelt, dass es nutzlos wurde.
• Kontextpropagierung ist dort kaputt, wo es zählt. HTTP ist in Ordnung. Ihr gRPC‑Gateway, Message Bus, Cron und Serverless‑Trigger sind es nicht. Parent‑Child‑Links werden gekappt; Baggage trägt PII; Exemplare haben kein Zuhause.
• Keine semantische Governance. service.name driftet über Sprachen hinweg. Teams erfinden eigene Attributschlüssel. Ihr Service‑Graph ist ein Schulterzucken‑Emoji.
• Logs sind eine Deponie, keine Pipeline. Alles geht heiß; nichts ist strukturiert; request_id überbrückt Logs, Metriken und Traces nicht. On‑Call verlässt sich auf Stammeswissen und Glück.

Die Nordsterne (entscheiden Sie das zuerst)

OpenTelemetry ist nur die Rohrleitung. Entscheiden Sie, wofür Sie sie verlegen.

1. Incident‑Response‑SLOs: Sie wollen p50‑MTTR unter 30 Minuten und das erste nützliche Signal in unter 5. Jede Entscheidung in diesem Plan wird gegen diese SLOs gemessen.
2. Datenbudget: Deckeln Sie auf eine Zahl, die Sie Ihrem CFO verteidigen können. Faustregel: 0,1–0,3 % des Umsatzes oder 20–50 $ pro Host und Monat. Wenn Sie das 2–3× bezahlen, subventionieren Sie Entropie.
3. Golden Paths: Wählen Sie 2–3 Journeys, die die Rechnungen bezahlen. Diese erhalten reichhaltigere Traces, 100 % Fehleraufbewahrung und Exemplare. Alles andere wird probabilistisch behandelt.

Eine Architektur, die nicht gegen Sie arbeitet

Es gibt viele richtige Optionen. Diese funktionieren in der heutigen Realität:

• Setzen Sie stets einen OpenTelemetry Collector in die Mitte. Collectors sind Ihre Control Plane: Sampling, Attributbereinigung, Kardinalitäts‑Guards und Routing. Betreiben Sie sie als DaemonSet in k8s und als Sidecar/VM am Edge. Siehe OpenTelemetry Collector.
• Tail‑basiertes statt Head‑basiertem Sampling für Produktions‑User‑Traffic. Behalten Sie 100 % der Fehler und langsamen Traces. Sample normale Traces auf ein Budget herunter. Verwenden Sie tail_sampling mit regelbezogenen Budgets und einem globalen Circuit Breaker.
• Exemplare verdrahten Metriken mit Traces. Ohne Exemplare haben Sie zwei Inseln gebaut. Verwenden Sie span‑to‑metrics, um RED (Requests, Errors, Duration) zu befüllen, und hängen Sie Exemplare an die Top‑Charts an.
• Logs sind eine zweistufige Pipeline. Hot (7–14 Tage) strukturierte, Request‑scoped Logs; Cold (90–365 Tage) Objektspeicher mit günstiger Search‑on‑Read. Zahlen Sie keine Hot‑Preise für Compliance‑Aufbewahrung.
• Wählen Sie Speicher, den Sie sich leisten können zu behalten. Vendor oder Self‑Host ist eine Business‑Entscheidung. Wenn Sie selbst hosten, ist ein pragmatischer Stack Grafana Tempo für Traces, Prometheus/Mimir für Metriken und ClickHouse oder Loki für Logs. Speicherkosten: ~20–30 % der Managed‑Vendor‑Kosten bei Scale, mit Ops, die Sie selbst verantworten.

Konkrete Zahlen (kein Handwaving)

Nehmen wir an, Sie fahren 10.000 RPS über zehn Services. Der mediane Trace hat 10 Spans. Ein minimaler Span liegt gebatcht im Schnitt bei 400–800 Byte. Bei 100 % Sampling schreiben Sie 10.000 × 10 × 600 B ≈ 60 MB/s, also ~5 TB/Tag nur für Traces. Das sprengt das Budget.

• Tail‑Sampling auf 5 % (100 % der 5xx + p95‑Latenz behalten): ~250 GB/Tag Traces.
• Attribute mit hoher Kardinalität droppen, die Sie nicht brauchen (user_id, request_path mit Parametern): 30–50 % kleinere Spans.
• Batching + Kompression im Collector bringen typischerweise weitere 20–30 % Einsparung auf der Leitung.

Netto: von 5 TB/Tag auf ~100–150 GB/Tag, ohne das zu verlieren, was On‑Call braucht. Das sind 97 % weniger gespeichertes Volumen – mit besserem Incident‑Signal.

Der 90‑Tage‑Plan

Tage 0–30: Blutung stoppen und Leitplanken setzen

1. Inventarisieren und abbilden. Listen Sie jede Workload mit Telemetrie nach Runtime, Version, Library und Ziel auf. Erfassen Sie, was tatsächlich aktiv ist: Metriken, Traces, Logs, Profiler. Rechnen Sie mit Überraschungen.
2. Eine zentrale Collector‑Schicht einziehen. Routen Sie alle Telemetriedaten zu regionalen Collectors. Aktivieren Sie die Prozessoren: batch, memory_limiter, attributes (PII‑Scrubbing), k8sattributes (falls auf k8s) und transform für semantische Korrekturen. Nur die Collectors sprechen mit Anbietern oder Speicher.
3. Service‑Identität standardisieren. Erzwingen Sie service.namespace, service.name und service.version über alle Sprachen. Brechen Sie Builds, die nicht konform sind. Ohne Identität ist alles andere egal.
4. Baggage by default abschalten. Baggage leakt PII und lässt die Kardinalität explodieren. Deaktivieren Sie es global. Whitelisten Sie minimale, nicht‑PII‑Schlüssel, falls Sie es wirklich brauchen.
5. Attribute‑Allowlist, nicht Denylist. Für Spans und Metriken nur freigegebene Schlüssel schicken. Starten Sie mit: http.method, http.route (vorlagenbasiert), http.status_code, db.system, db.operation, messaging.system, net.peer.name (quantisiert). Alles mit User‑Scope droppen.
6. Head‑Sampling auf ein sinnvolles Maß deckeln. Bis Tail‑basiertes aktiv ist, fahren Sie Head‑Sampling mit 10–20 % auf High‑Traffic‑Services und 100 % auf Low‑Traffic‑ oder Admin‑APIs. Behalten Sie 100 % auf Canaries und internem Staging.
7. Ein Golden‑Path‑Dashboard aufbauen. Instrumentieren Sie 2–3 umsatzrelevante Pfade End‑to‑End. Bauen Sie RED‑Metriken und hängen Sie Exemplare an. Fügen Sie ein „Find Trace“-Panel hinzu, das in Incidents in 2 Klicks funktioniert.

Tage 31–60: Traces müssen Antworten liefern

1. Tail‑basiertes Sampling einschalten. Fügen Sie im Collector Regeln hinzu: behalten, wenn status_code ≥ 500; behalten, wenn latency ≥ p95; behalten, wenn release.version is new; ansonsten probabilistic 5%. Setzen Sie regelbezogene und globale Budgets mit einer Backpressure‑Policy (zuerst normalen Traffic abwerfen).
2. Kontext durch die schwierigen Teile propagieren. Prüfen und reparieren Sie W3C TraceContext über gRPC, Message Buses und Serverless‑Trigger hinweg. Für Messaging: schreiben Sie traceparent in Message‑Header und erstellen Sie Links zwischen Producer‑ und Consumer‑Spans. Für Cron/Batch: starten Sie neue Traces und tragen Sie Korrelations‑IDs in die Logs.
3. Exemplare überall dort, wo es zählt. Konfigurieren Sie span‑to‑metrics so, dass Latenz‑, Fehler‑ und Durchsatz‑Charts Trace‑IDs anhängen. Stellen Sie sicher, dass Ihr Metrik‑Backend das Abfragen von Exemplaren per Klick unterstützt.
4. Kardinalitäts‑SLOs etablieren. Erzwingen Sie: keine Metrik mit einer Label‑Kardinalität über 1.000 eindeutigen Werten/Tag; keine neuen Label‑Keys ohne Design‑Review; keine High‑Card‑Keys auf Hot‑Metriken. Fügen Sie CI‑Checks hinzu, die Ihr Backend auf Series‑Churn abfragen, und lassen Sie PRs fehlschlagen, die Schwellenwerte überschreiten.
5. Logs restrukturieren. Machen Sie request_id zu einem First‑Class‑Feld. Loggen Sie JSON‑Zeilen mit festem Schema. Routen Sie Hot‑Logs (7–14 Tage) in die schnelle Suche; alles andere geht in Objektspeicher mit Query‑Layer. Fügen Sie Log‑Drop‑Regeln für geschwätzige DEBUGs und Health‑Checks auf Collector‑ oder Vector/Fluentd‑Ebene hinzu.
6. Das erste Incident‑Runbook mit OTel bauen. Eine Checkliste, die in einem Metrik‑Dashboard startet, zu Exemplaren springt, den richtigen Trace öffnet und korrelierte Logs per request_id holt. Stoppen Sie die Zeit. Ziel: unter 5 Minuten bis zum „ersten nützlichen Signal“.

Tage 61–90: Kosten fixieren, Ergebnisse belegen und automatisieren

1. Kostengrenzen im Code verankern. Setzen Sie pro Service Budgets für Traces (z. B. max. 2 GB/Tag), Metrik‑Serien (max. N aktive Serien) und Logs (GB/Tag). Verdrahten Sie Autoscaling oder Backpressure im Collector, um nicht‑kritische Daten abzuwerfen, wenn Budgets reißen.
2. Einen Game Day durchführen. Brechen Sie etwas Harmloses (erhöhen Sie die Latenz auf einem Leaf‑Service). Messen Sie die Zeit vom Alert bis zur Root Cause mit und ohne Exemplare. Erwarten Sie eine 2–3× schnellere Diagnose bei korrekter Konfiguration. Wenn nicht, brauchen Sampling oder Exemplare Feintuning.
3. Semantische Konventionen kodifizieren. Dokumentieren Sie, welche OTel semantic conventions Sie befolgen. Stellen Sie sprachspezifische Snippets und Linter bereit. Fügen Sie eine Pre‑Merge‑Checkliste hinzu.
4. Retention richtig dimensionieren. Traces: 7 Tage hot, 30 Tage warm, falls Sie häufig RCA machen. Metriken: 18 Monate mit Downsampling. Logs: 7–14 Tage hot, 90–365 Tage cold. Wenn Sie den zusätzlichen Tag nicht begründen können, zahlen Sie nicht dafür.
5. Vendor vs. Self‑Host für das nächste Jahr entscheiden. Wenn Sie Storage nicht zuverlässig betreiben können, kaufen Sie ihn. Wenn Ihr Volumen vorhersehbar und >200 GB/Tag ist, kann Self‑Hosting von Tempo/Mimir/ClickHouse 20–30 % der Vendor‑Kosten betragen. Der Trade‑off ist SRE‑Headcount. Ein fokussiertes Nearshore‑Pod kann die Lücke schließen – bei 20–30 % geringeren Lohnkosten als US‑Sätze und 6–8 Stunden Zeitzonen‑Überlappung.
6. Den Observability‑Vertrag veröffentlichen. Eine Seite: SLOs, Budgets, genehmigte Attribute, Sampling‑Regeln, Service‑Identitätsregeln und Runbooks. Behandeln Sie Änderungen als ADRs.

Trade‑offs, die Sie annehmen sollten (nicht vermeiden)

• Sampling ist keine Sünde. Sie können sich 100 % Traces im großen Maßstab nicht leisten. Sie brauchen sie auch nicht. Was On‑Call braucht, ist „das Schlechte und das Seltsame behalten“. Tail‑basiertes Sampling mit SLO‑Ausrichtung liefert genau das.
• Logs sind kein Ersatz für Traces – und umgekehrt. Traces zeigen Timing und Kausalität; Logs liefern Fakten. Korrelation über request_id und Exemplare. Wenn Sie nicht vom Spike zum Trace klicken können, ist die Arbeit nicht fertig.
• Jagen Sie keiner perfekten semantischen Abdeckung hinterher. Jetzt 80 % konsistente Konventionen schlagen 100 % theoretische Compliance irgendwann. Keys einfrieren, dann iterieren.
• Self‑gehostete Observability ist nicht kostenlos. Ja, die Speicher‑kosten fallen drastisch. Nein, es läuft nicht von selbst. Planen Sie 0,25–0,5 FTE SRE pro 1 TB/Tag Ingest für Pflege und Betrieb ein, wenn Sie SLOs wollen, auf die Sie eine On‑Call‑Woche verwetten können.

So sieht „gut“ an Tag 90 aus

• On‑Call startet an einem Ort. Ein einziges RED‑Dashboard mit Exemplaren, von denen Sie in Traces und dann in korrelierte Logs klicken können – ohne Tool‑ oder Tab‑Hopping.
• Kosten sind durch Leitplanken begrenzt, nicht durch Hoffnung. Sie kennen die täglichen GB pro Telemetrietyp, wie Sampling sie verändert und wann Budgets Backpressure auslösen.
• Trace‑Abdeckung ist absichtlich gesteuert. 100 % der 5xx behalten; p95‑langsame Traces behalten; normale Requests je nach Kritikalität des Services mit 2–10 % gesamplet. Sie können „was ist passiert“ und „warum jetzt“ beantworten.
• Kardinalität ist gezähmt. Keine Metrik mit >1.000 eindeutigen Label‑Werten/Tag. Keine PII in Attributen. Hochkardinale Daten leben in Logs, nicht auf Hot‑Metriken.
• Propagation funktioniert über die Grenzen hinweg, die früher versagt haben. Sie können eine User Journey über HTTP → Queue → Worker → Serverless verfolgen, ohne dass der Trace auseinanderfällt.

Häufige Fallstricke (und wie man sie umgeht)

• „Sampling fixen wir später.“ Später kommt nie. Bringen Sie Tail‑basiertes Sampling bis Tag 60 in den Collector – mit expliziten Regeln und Budgets.
• Teamautonomie über Service‑Identität stellen. Sie können viel dezentralisieren. Das nicht. Brechen Sie Builds, die service.name nicht korrekt setzen.
• Rohe, nutzerbezogene Labels in Hot‑Metriken mischen. Wenn Sie Per‑User‑Analytik brauchen, ist das ein Data‑Warehouse‑ oder ClickHouse‑Thema. Halten Sie Per‑User‑Daten aus Prometheus/Mimir heraus.
• 100 % Auto‑Instrumentation hinterherjagen. Auto hilft, aber Business‑Spans auf Golden Paths erfordern Handarbeit. Geben Sie Teams ein 1–2‑Stunden‑Rezept für „Span um diesen Use Case legen“.
• Dev/Test‑Rauschen an Prod‑Backends schicken. Routen Sie Non‑Prod in eine separate Pipeline. Besser: Das meiste davon droppen. Observability sollte die Produktionsrealität spiegeln, nicht Unit‑Tests.

Ein Hinweis zu Compliance und Datenschutz

OTel ist ein PII‑Magnet, wenn Sie nachlässig sind. Behandeln Sie Attribut‑Governance als Datenschutz‑Kontrolle:

• User‑Identifiers am Edge droppen. Wenn ein Use Case sie wirklich benötigt, hashen oder bucketen – und die Aufbewahrungs‑ und Zugriffspolitik dokumentieren.
• Geheimnisse im Collector bereinigen. Fügen Sie Prozessoren hinzu, die Bearer‑Tokens, API‑Keys und E‑Mails vor der Speicherung redigieren. Verlassen Sie sich nie darauf, dass App‑Teams sich „erinnern“.
• Auditieren. Monatliche Queries nach PII‑Mustern in Attributen und Logs. Wenn Sie nicht beweisen können, dass das Scrubbing funktioniert hat, hat es nicht funktioniert.

Tooling‑Checkliste, die Sie morgen einsetzen können

• Collector‑Prozessoren: batch, memory_limiter, tail_sampling, attributes (drop/redact), transform (normalize attributes), k8sattributes, spanmetrics, probabilistic_sampler (für Low‑Traffic‑Services), resourcedetection.
• Dashboards: Pro‑Service RED; globaler Service‑Graph; SLOs pro Journey mit Error Budgets; „Find Trace“ mit Filtern für service.name, http.route, status_code und release.version.
• Runbooks: 1) Beim SLO‑Panel starten. 2) Exemplar klicken. 3) Kritischen Pfad im Trace inspizieren. 4) Zu Logs für request_id springen. 5) Timeline erfassen. 6) Über Rollback vs. Mitigation entscheiden.

OpenTelemetry ist die richtige Wette. Die frühen Schmerzen sind kein Urteil; sie signalisieren, dass Sie Rohre installiert haben, ohne zu entscheiden, was dadurch fließen soll. Geben Sie Ihren Teams einen Nordstern, setzen Sie den Collector in den Driver’s Seat und budgetieren Sie nach SLOs, nicht nach Bauchgefühl. In neunzig Tagen haben Sie niedrigere Kosten, schnellere Incident‑Response und ein System, das On‑Call‑Engineers tatsächlich nutzen.

Wichtigste Erkenntnisse

• Entscheiden Sie zuerst Ihre SLOs und Budgets; verknüpfen Sie jede OTel‑Entscheidung damit.
• Setzen Sie den OTel Collector in die Mitte und wechseln Sie bis Tag 60 zu Tail‑basiertem Sampling.
• Identität und Semantik durchsetzen: service.name, service.namespace, service.version sind nicht verhandelbar.
• Verwenden Sie Exemplare, um Metriken und Traces zu verbinden; machen Sie „Find Trace“ zu einem 2‑Klick‑Vorgang.
• Kardinalität deckeln: Attribute erlaubnisbasiert (Allowlist), Baggage by default ausschalten und CI‑Checks hinzufügen.
• Logs in „hot strukturiert“ + „cold günstig“ restrukturieren; Korrelation über request_id.
• Kosten mit pro‑Service Datenbudgets und Collector‑Backpressure fixieren.
• Erwarten Sie 50–70 % Kostensenkung und 2–3× schnellere Diagnose nach dem Tuning.