Warum ich native Prometheus-Instrumentierung gegenüber OpenTelemetry empfehle - und warum dieser Titel für Streit gesorgt hat
Es gibt wenige Debatten in der modernen Observability, die so emotional aufgeladen sind wie diese:
Prometheus-Instrumentierung… oder OpenTelemetry?
Ein aktueller Blogbeitrag mit dem Titel "Why I recommend native Prometheus instrumentation over OpenTelemetry" brachte die Prometheus-Community genau aus diesem Grund in Aufruhr.
Nicht, weil er OpenTelemetry frontal angriff.
Sondern weil er eine konkrete, meinungsstarke Empfehlung in einer Welt aussprach, die zunehmend von "einem Standard, der sie alle beherrscht" besessen ist.
Und fast sofort wies jemand auf die fehlende Nuance hin:
Das sollte wohl "für Metriken" heißen.
Diese kleine Klarstellung offenbart die gesamte Spannung, die unter der Debatte liegt.
Der Titel war der Funke
Der erste größere Widerstand richtete sich nicht gegen die fachliche Korrektheit.
Es ging um den Umfang.
Ein Kommentator schlug vor, der Beitrag sollte heißen:
Why I recommend native Prometheus instrumentation over OpenTelemetry for metrics
Weil moderne Instrumentierung nicht mehr nur Metriken bedeutet.
Wir haben:
- Metriken
- Traces
- Logs
- Profile
- Events
Und OpenTelemetry existiert genau dafür, diese zu vereinheitlichen.
Der Autor antwortete schlicht: ja, aber der Titel war schon lang, und in einem Prometheus-Kontext sollte offensichtlich sein, dass diese Diskussion sich um Metriken dreht.
Dieser Austausch ist wichtig.
Weil er das Argument richtig einordnet.
Das ist nicht Prometheus gegen OpenTelemetry insgesamt.
Es geht speziell um Metrik-Instrumentierung.
Prometheus wurde für Metriken gebaut — Punkt
Prometheus macht eine Sache.
Metriken.
Diese Beschränkung ist ein Feature.
Native Prometheus-Client-Bibliotheken sind ausgelegt auf:
- Counter
- Gauges
- Histogramme
- Summaries
- Pull-basierte Exposition
Sie passen zum Storage-Modell.
Sie passen zur Query-Sprache.
Sie passen zur Scraping-Philosophie.
Wenn Sie nativ instrumentieren, gibt es keine Übersetzungsschicht.
Keine semantische Konvertierung.
Keine "Brücke".
Keinen Exporter dazwischen.
Es ist direkt.
Und direkt bedeutet meist einfacher.
Das OpenTelemetry-Versprechen
OpenTelemetry dagegen verspricht etwas Größeres:
Ein einheitliches Instrumentierungs-Framework für Metriken, Traces und Logs.
Ein SDK.
Mehrere Signaltypen.
Vendor-neutral.
Für verteilte Systeme mit mehrstufigen Architekturen ist das überzeugend.
Wie ein Kommentator anmerkte: Sobald man mehrstufige Anwendungen hat, will man Traces und Logs, um die Root-Cause-Analyse-Zeit zu verkürzen.
Das ist nicht falsch.
Metriken sagen Ihnen, dass etwas nicht stimmt.
Traces helfen Ihnen zu verstehen, warum.
Die Frage ist nicht, ob Traces wertvoll sind.
Die Frage ist, ob OpenTelemetry-Metriken der beste Weg sind, wenn Prometheus Ihr Backend ist.
Wo die Reibung wirklich entsteht
Die Reibung zeigt sich oft in der Architektur.
Ein Kommentator beschrieb, wie er viele unterschiedliche öffentliche Internet-Projekte betreibt und Push-basierte Statistikerfassung bevorzugt, weil man dadurch keine Firewall-Regeln für einen zentralen Collector öffnen muss.
Das ist eine sehr reale Einschränkung.
Prometheus ist Pull-basiert.
OpenTelemetry arbeitet oft in Push-Pipelines.
Wenn Ihre Topologie Push bevorzugt, können sich OpenTelemetry-Collectors wie der einfachere Weg anfühlen.
Aber jetzt führen Sie ein:
- Collectors
- Pipelines
- Prozessoren
- Möglicherweise Alloy oder andere Agenten
Ein anderer Kommentator beschrieb Alloy im Grunde als Prometheus plus Exporter plus Data Sinks in einem — und sorgte sich, dass es zu Bloatware werden könnte.
Es gibt auch einen Seitenhieb, dass HCL-Konfiguration im Vergleich zu strukturierten Config-Dateien "irrsinnig" sei.
Das ist nicht nur Nörgelei.
Es spiegelt eine tiefere Sorge wider:
Wenn man universelle Agenten einführt, führt man Komplexität ein.
Und Komplexität bleibt selten klein.
Native Instrumentierung ist langweilig — und genau das ist der Punkt
Native Prometheus-Instrumentierung ist:
- Sprachspezifisch.
- Stabil.
- Direkt.
- Nur auf Metriken fokussiert.
Sie versucht nicht, Tracing zu lösen.
Sie versucht nicht, Logs zu exportieren.
Sie baut keine Cross-Signal-Pipelines.
Sie stellt /metrics bereit.
Prometheus scrapt es.
Fertig.
Wenn Sie einen Metrik-first-Stack betreiben und Prometheus die Source of Truth ist, ist diese Einfachheit mächtig.
Sie vermeiden:
- Semantische Mismatches.
- Feature-Lücken.
- Übersetzungs-Randfälle.
- Überraschungen im Aggregationsverhalten.
Und vor allem reduzieren Sie bewegliche Teile.
Das versteckte Risiko "universeller" Instrumentierung
Universelle Instrumentierungs-Frameworks altern anders als Single-Purpose-Frameworks.
Sie wachsen.
Sie fügen Schichten hinzu.
Sie fügen Konfigurationsregler hinzu.
Sie fügen Kompatibilitätsmodi hinzu.
Und irgendwann fangen sie an, Probleme zu lösen, die Sie gar nicht haben.
Genau hier trifft der "Bloatware"-Kommentar ins Schwarze.
Es ist nicht so, dass OpenTelemetry von Natur aus aufgebläht ist.
Es ist, dass universelle Agenten dazu neigen, Verantwortlichkeiten anzuhäufen.
Wenn Sie nur Metriken brauchen, fühlen sich native Prometheus-Bibliotheken schlanker an.
Aber Metriken sind nicht die ganze Geschichte
Das Gegenargument liegt auf der Hand.
Metriken allein reichen in komplexen Systemen nicht aus.
Traces verkürzen die RCA-Zeit.
Logs liefern Kontext.
Korrelation über Signale hinweg ist mächtig.
Wenn Sie OpenTelemetry bereits für Tracing einsetzen, kann es sich redundant anfühlen, für Metriken eine separate Instrumentierung zu nutzen.
Das ist die architektonische Weggabelung:
- Jedes Signal für sein natives Ökosystem optimieren.
- Oder Signale unter einem Instrumentierungs-Framework vereinheitlichen.
Es gibt hier keine universell richtige Antwort.
Die Zielgruppe zählt
Der Autor stellte klar, dass der Blogbeitrag für ein Prometheus-Publikum geschrieben wurde.
Dieser Kontext ist wichtig.
Wenn Ihr Backend Prometheus ist.
Wenn Ihre Queries PromQL sind.
Wenn Ihr Alerting auf Prometheus-nativer Semantik basiert.
Dann ist native Instrumentierung standardmäßig aligned.
Sie kämpfen nicht gegen Übersetzungsschichten.
Sie sind nicht darauf angewiesen, dass Brücken-Komponenten perfekt funktionieren.
Sie nutzen das System so, wie es entworfen wurde.
Architektur ist constraint-driven
Schauen Sie sich noch einmal den Push-vs-Pull-Kommentar an.
Wenn Firewall-Regeln Pull-basiertes Scraping unpraktikabel machen, drängt Ihre Architektur Sie zu Collectors.
Wenn Sie breit über öffentliche Netzwerke verteilt sind, akzeptieren Sie vielleicht zusätzlichen Overhead für zentralisierte Ingestion.
Constraints treiben Design.
Und die Instrumentierungsstrategie sollte Constraints widerspiegeln, nicht Ideologie.
Das eigentliche Fazit
Diese Debatte handelt nicht davon, welches Projekt "besser" ist.
Es geht um Alignment.
Native Prometheus-Instrumentierung passt perfekt zu Prometheus.
OpenTelemetry passt perfekt zu Multi-Signal-Observability-Strategien.
Wenn sich diese Ziele überschneiden, entsteht Reibung.
Der Blogbeitrag löste die Diskussion aus, weil er meinungsstark war.
Und in der Observability ist meinungsstarke Anleitung selten.
Die meisten Inhalte hedgen.
Die meisten Tools versprechen alles.
Manchmal ist es erfrischend zu hören:
"Wenn Sie Prometheus für Metriken nutzen, instrumentieren Sie einfach für Prometheus."
Das negiert Traces nicht.
Es verwirft Logs nicht.
Es greift OpenTelemetry nicht an.
Es argumentiert nur dafür, unnötige Abstraktionsschichten zu reduzieren, wenn Ihr Stack bereits feststeht.
Und in der Infrastruktur bedeuten weniger Schichten meist weniger Überraschungen.
Was, um 3 Uhr nachts, oft das ist, was am meisten zählt.