Warum ich native Prometheus-Instrumentierung gegenüber OpenTelemetry empfehle, und warum dieser Titel für Streit gesorgt hat

Wenige Debatten in der modernen Observability sind so emotional aufgeladen wie diese: Prometheus-Instrumentierung oder OpenTelemetry?

Ein aktueller Blogbeitrag mit dem Titel "Why I recommend native Prometheus instrumentation over OpenTelemetry" hat die Prometheus-Community genau deshalb in Aufruhr gebracht. Nicht, weil er OpenTelemetry frontal angriff, sondern weil er eine konkrete, meinungsstarke Empfehlung aussprach, während sich die Welt zunehmend nach "einem Standard, der sie alle beherrscht" sehnt.

Fast sofort wies jemand auf die fehlende Nuance hin:

Das sollte wohl "für Metriken" heißen.

In dieser kleinen Klarstellung steckt die ganze Spannung, die unter der Debatte liegt.

Der Titel war der Funke

Der erste größere Widerstand richtete sich nicht gegen die fachliche Korrektheit, sondern gegen den Umfang. Ein Kommentator schlug vor, der Beitrag sollte heißen:

Why I recommend native Prometheus instrumentation over OpenTelemetry for metrics

Denn moderne Instrumentierung umfasst mehr als Metriken. 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 klar sein, dass es um Metriken geht.

Dieser Austausch ordnet das Argument richtig ein. Gemeint ist speziell die Metrik-Instrumentierung und nicht das gesamte Verhältnis von Prometheus zu OpenTelemetry.

Prometheus wurde für Metriken gebaut

Prometheus macht eine Sache, nämlich Metriken, und 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, zur Query-Sprache und zur Scraping-Philosophie. Wer nativ instrumentiert, hat keine Übersetzungsschicht, keine semantische Konvertierung, keine "Brücke" und keinen Exporter dazwischen. Der Weg ist direkt, und direkt heißt meist einfacher.

Das OpenTelemetry-Versprechen

OpenTelemetry verspricht etwas Größeres: ein einheitliches Instrumentierungs-Framework für Metriken, Traces und Logs, mit einem SDK, mehreren Signaltypen und ohne Vendor-Bindung. Für verteilte Systeme mit mehrstufigen Architekturen ist das überzeugend.

Ein Kommentator merkte an, sobald man mehrstufige Anwendungen betreibe, wolle man Traces und Logs, um die Zeit für die Root-Cause-Analyse zu verkürzen. Das ist nicht falsch. Metriken sagen Ihnen, dass etwas nicht stimmt, Traces helfen beim Verstehen, warum.

Die Frage ist nicht, ob Traces wertvoll sind, sondern 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 verschiedene Projekte im öffentlichen Internet betreibt und Push-basierte Statistikerfassung bevorzugt, weil er dann keine Firewall-Regeln für einen zentralen Collector öffnen muss. Das ist eine sehr reale Einschränkung.

Prometheus arbeitet pull-basiert, OpenTelemetry läuft oft in Push-Pipelines. Wenn Ihre Topologie Push bevorzugt, wirken OpenTelemetry-Collectors wie der einfachere Weg. Nur führen Sie damit auch Collectors, Pipelines, Prozessoren und möglicherweise Alloy oder andere Agenten ein.

Ein anderer Kommentator beschrieb Alloy als Prometheus plus Exporter plus Data Sinks in einem und sorgte sich, dass daraus Bloatware werden könnte. Dazu kam ein Seitenhieb, HCL-Konfiguration sei im Vergleich zu strukturierten Config-Dateien "irrsinnig".

Hinter dem Seitenhieb steckt eine ernstere Sorge: Universelle Agenten bringen Komplexität mit, und Komplexität bleibt selten klein.

Native Instrumentierung ist langweilig, und genau darum geht es

Native Prometheus-Instrumentierung ist sprachspezifisch, stabil, direkt und allein auf Metriken fokussiert. Sie versucht nicht, Tracing zu lösen, exportiert keine Logs und baut keine Cross-Signal-Pipelines. Sie stellt /metrics bereit, Prometheus scrapt es, und damit ist die Sache erledigt.

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, Randfälle bei der Übersetzung und Überraschungen im Aggregationsverhalten. Vor allem reduzieren Sie die Zahl der beweglichen Teile.

Das versteckte Risiko "universeller" Instrumentierung

Universelle Instrumentierungs-Frameworks altern anders als solche mit einem einzigen Zweck. Sie wachsen, kommen mit weiteren Schichten, weiteren Konfigurationsreglern und weiteren Kompatibilitätsmodi, und irgendwann lösen sie Probleme, die Sie nie hatten.

Genau hier trifft der Kommentar zur Bloatware einen Punkt. OpenTelemetry ist nicht von Natur aus aufgebläht, aber universelle Agenten neigen dazu, Verantwortlichkeiten anzuhäufen. Wer nur Metriken braucht, empfindet native Prometheus-Bibliotheken als schlanker.

Aber Metriken sind nicht die ganze Geschichte

Das Gegenargument liegt auf der Hand: In komplexen Systemen reichen Metriken allein nicht. Traces verkürzen die RCA-Zeit, Logs liefern Kontext, und die Korrelation über Signale hinweg ist mächtig. Wenn Sie OpenTelemetry schon für Tracing nutzen, kann eine separate Instrumentierung für Metriken redundant wirken.

Damit steht man an einer architektonischen Weggabelung:

• Jedes Signal für sein natives Ökosystem optimieren.
• Oder alle Signale unter einem Instrumentierungs-Framework vereinheitlichen.

Eine universell richtige Antwort gibt es hier nicht.

Die Zielgruppe zählt

Der Autor stellte klar, dass der Blogbeitrag für ein Prometheus-Publikum geschrieben wurde, und dieser Kontext ist wichtig. Wenn Ihr Backend Prometheus ist, Ihre Queries in PromQL geschrieben sind und Ihr Alerting auf Prometheus-nativer Semantik basiert, passt native Instrumentierung von vornherein dazu. Sie kämpfen nicht gegen Übersetzungsschichten und hängen nicht davon ab, dass Brücken-Komponenten perfekt funktionieren, sondern nutzen das System so, wie es entworfen wurde.

Architektur folgt den Constraints

Ein Blick zurück auf den Kommentar zu Push und Pull lohnt sich. Machen Firewall-Regeln pull-basiertes Scraping unpraktikabel, drängt die Architektur Sie zu Collectors. Wer breit über öffentliche Netzwerke verteilt ist, nimmt für zentralisierte Ingestion vielleicht zusätzlichen Overhead in Kauf.

Constraints treiben das Design, und die Instrumentierungsstrategie sollte diese Constraints widerspiegeln und nicht eine Ideologie.

Das eigentliche Fazit

In dieser Debatte zählt vor allem die Passung, weniger die Frage, welches Projekt "besser" ist. Native Prometheus-Instrumentierung passt perfekt zu Prometheus, OpenTelemetry passt perfekt zu Multi-Signal-Strategien. Überschneiden sich diese Ziele, entsteht Reibung.

Der Blogbeitrag löste die Diskussion aus, weil er meinungsstark war, und meinungsstarke Anleitung ist in der Observability selten. Die meisten Inhalte sichern sich nach allen Seiten ab, 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."

Traces werden damit nicht negiert, Logs nicht verworfen und OpenTelemetry nicht angegriffen. Das Argument lautet nur, unnötige Abstraktionsschichten zu reduzieren, wenn der Stack schon feststeht. In der Infrastruktur bedeuten weniger Schichten meist weniger Überraschungen, und um 3 Uhr nachts zählt genau das am meisten.