OpenTelemetry und Prometheus: Ergänzung statt Ersatz

„Brauchen wir OpenTelemetry eigentlich noch, wenn wir schon Prometheus haben?” — das ist die klassische Frage, die in fast jedem Observability-Gespräch irgendwann fällt. Die kurze Antwort lautet: Oft ja, aber definitiv nicht als reinen Ersatz.

Prometheus bleibt unangefochten stark für Metriken und Alerts. OpenTelemetry (OTel) kommt dann ins Spiel, wenn du saubere Traces brauchst, deine Instrumentierung vereinheitlichen willst und dich weniger an einen spezifischen Vendor binden möchtest.

Was Prometheus fantastisch macht — und wo die Grenzen liegen

Lass uns ehrlich sein: Für pull-basierte Metriken, PromQL, den Alertmanager und den gesamten kube-prometheus-stack gibt es aktuell kaum etwas Besseres. Das Ökosystem ist ausgereift. Wenn es um RED-Metriken (Rate, Errors, Duration) oder die Umsetzung von SLOs und Recording Rules geht, fährt die überwiegende Mehrheit der Platform-Teams mit Prometheus jahrelang extrem gut.

Schwierig wird es allerdings, wenn du den exakten Request-Flow über 15 Microservices hinweg nachvollziehen musst. Eine Error-Rate von 2 % auf dem Checkout-Service sagt dir, dass etwas brennt — aber nicht, dass die eigentliche Ursache drei Hops weiter hinten ein überlasteter Redis ist. Auch Push-Szenarien (kurzlebige Batch-Jobs, Serverless) oder der Versuch, Logs und Traces nahtlos mit Metriken zu verknüpfen, sind nicht die Kernkompetenz von Prometheus. Da hilft auch keine Magie.

Was bringt OpenTelemetry auf den Tisch?

Drei Dinge, die man sauber auseinanderhalten sollte, weil sie oft in einen Topf geworfen werden:

Erstens die Instrumentierung: SDKs für alle relevanten Sprachen plus Auto-Instrumentation, die in Java, Python oder Node.js ohne Codeänderung HTTP-Clients, Datenbank-Treiber und Frameworks abdeckt. Zweitens OTLP als herstellerneutrales Wire-Format — deine Apps sprechen ein Protokoll, egal ob dahinter Tempo, Jaeger oder ein kommerzieller Vendor sitzt. Drittens der Collector als zentrale Pipeline, in der du Daten anreicherst, filterst, samplest und routest, ohne App-Deployments anzufassen.

Der unterschätzte Punkt für Plattform-Teams ist der dritte: Wenn der Vendor-Vertrag ausläuft oder die Kosten explodieren, änderst du einen Exporter im Collector — nicht die Instrumentierung von achtzig Services.

Aber Vorsicht: Ohne saubere Context Propagation (W3C traceparent-Header) sind deine Traces wertlos — jeder Service-Hop ohne weitergereichten Header zerreißt den Trace in unverbundene Fragmente. Das bedeutet, dass auch dein Ingress und dein Service Mesh mitspielen müssen. Und vergiss das Sampling nicht: Wer 100 % aller Traces aufhebt, zahlt bei nennenswertem Traffic schnell vierstellige Beträge pro Monat nur für Trace-Storage. Error-biased Sampling (100 % der Fehler und langsamen Requests, 5 % des Rests) ist der Kompromiss, der in den meisten Setups gewinnt — technisch heißt das Tail-based Sampling, mehr dazu im Artikel zum Collector in Produktion.

So sieht das Zusammenspiel konkret aus

Das Setup, das sich in vielen Plattformen etabliert hat: Apps senden OTLP an den Collector. Der Collector exportiert Metriken an Prometheus (per prometheusremotewrite-Exporter oder als Scrape-Endpoint), Traces an Tempo, Logs an Loki. Grafana sitzt obendrauf — und hier zahlt sich die Integration aus: über Exemplars springst du von einem Latenz-Spike im Prometheus-Histogramm direkt zum zugehörigen Trace in Tempo, über die trace_id im Log-Eintrag von Loki ebenfalls. Das ist der Moment, in dem aus drei getrennten Datentöpfen Observability wird.

Euer Platform-Team stellt dabei den OTLP-Endpoint als Shared Service bereit, definiert verbindliche Resource-Attribute (service.name, deployment.environment) und kümmert sich um Sampling- und Retention-Policies — damit nicht jedes App-Team seine eigene Pipeline bastelt und die Kosten dreimal anfallen.

Migration: Bloß kein Big Bang

Niemand wirft Prometheus von heute auf morgen raus — und das ist auch nicht das Ziel. Eine Reihenfolge, die funktioniert: Collector als Gateway deployen, während Prometheus unverändert weiterläuft. Auto-Instrumentation am Ingress und bei zwei kritischen Services aktivieren, Trace-Qualität prüfen (sind die Traces vollständig? Stimmt die Propagation?). Dann Service für Service ausweiten. Bestehende Prometheus-Exporter und ServiceMonitors bleiben, wie sie sind — es gibt keinen Grund, funktionierende Metrik-Pipelines anzufassen. Den alten Jaeger oder Promtail schaltet ihr erst ab, wenn wirklich niemand mehr auf die alten Dashboards schaut.

Im Interview reicht oft ein prägnanter Satz: „Wir behalten Prometheus für unsere SLOs, nutzen aber OTel für Traces und als einheitlichen, vendor-neutralen Export. Wir migrieren schrittweise und haben die Kosten durch error-biased Sampling im Griff.”

Behaupte bloß nicht, OTel würde Prometheus vollständig ersetzen — das wirkt schnell so, als hättest du es noch nie in Produktion betrieben.

Tiefergreifende Infos findest du in unseren Lernpfaden zu OpenTelemetry, Prometheus und dem Grafana Stack.