Standard oder Last?

Über OpenTelemetry werden zwei Dinge gesagt, meist von verschiedenen Leuten in derselben Sitzung. Das erste: Es sei das Ende proprietärer Agents — ein Standard, einmal instrumentieren, überallhin schicken. Das zweite: Es habe den Agenten eines Anbieters durch eine YAML-Datei, eine Contrib-Distribution mit dreihundert Komponenten und eine Flotte ersetzt, für deren Betrieb sich niemand gemeldet hat.

Beides stimmt. Die interessante Frage ist nicht, welche Seite die Diskussion gewinnt, sondern woraus die Last genau besteht — denn ungefähr die Hälfte davon liegt im Standard selbst, und die andere Hälfte ist ein Flottenbetriebs-Problem, das älter ist als OpenTelemetry und bekannte Antworten hat.

Was Sie tatsächlich gewinnen

Der Klarheit halber zuerst, denn der Rest dieses Beitrags handelt von Kosten:

• Instrumentierung gehört nicht mehr dem Anbieter. Das SDK in Ihrer Anwendung und das Wire-Format auf dem Netz sind offen. Ein Backend-Wechsel bedeutet nicht mehr, tausend Services neu zu instrumentieren — die mit Abstand teuerste Eigenschaft eines Observability-Anbieterwechsels.
• Ein Agent statt mehrerer. Die meisten Bestände, die OTel einführen, konsolidieren drei oder vier Anbieter-Agents in einen Collector. Das ist eine echte Reduktion der Komplexität, kein blosser Tausch.
• Die Verarbeitungsschicht wird Ihre. Filterung, Redaction, Sampling und Routing finden in einer Komponente statt, die Sie konfigurieren — vor dem Egress. Das ist es, was Kosten und Compliance überhaupt steuerbar macht.

Nichts davon ist Marketing. Gratis ist es auch nicht.

Woraus die Last tatsächlich besteht

Fünf verschiedene Kosten, und sie sind nicht gleich schwer:

• Sie betreiben jetzt eine Flotte. Der Collector ist ein Prozess auf jedem Host, der installiert, konfiguriert, aktualisiert und überwacht werden will. Fünfzig davon sind ein Inventarproblem; fünftausend sind eine Betriebsdisziplin. Das ist der grösste und am meisten unterschätzte Posten, eigenständig behandelt in ein Collector-Fleet aktuell halten.
• Konfigurationswildwuchs. YAML pro Host driftet. Jemand bearbeitet während eines Vorfalls eine Config von Hand und nimmt es nie zurück; ein Rollout kommt nur halb an. Das Ergebnis ist eine Flotte, bei der Sie nicht sagen können, was läuft, ohne nachzusehen — Config-Drift ist der konkrete Fehlermodus.
• Komponenten-Fluktuation. Die Contrib-Distribution bewegt sich schnell. Komponenten wechseln die Stabilitätsstufe, semantische Konventionen entwickeln sich weiter, und ein Upgrade kann ein Attribut umbenennen, von dem Ihre Dashboards abhängen. Das ist der Preis eines jungen, schnellen Standards und bei jedem Upgrade echte Arbeit.
• Kardinalität und Volumen sind jetzt Ihr Problem. Ein Anbieter-Agent lieferte einen meinungsstarken, vorabgestimmten Satz Metriken. Ein Collector emittiert bereitwillig, was Sie konfigurieren — inklusive eines Label-Satzes pro Container, der Ihre Serienzahl still vervielfacht.
• Nichts ist fertig mitgeliefert. OpenTelemetry gibt Ihnen Erfassung und Transport. Dashboards, Alert-Regeln und die kuratierten Inhalte, die ein kommerzieller Agent mitbrachte, liegen nicht bei. Diese Lücke ist das Thema von was OpenTelemetry ersetzen kann und was nicht.

Welche Hälfte im Standard liegt — und welche nicht

Das ist der nützliche Schnitt. Von den fünf:

Dem Standard inhärent: Komponenten-Fluktuation und die fehlenden kuratierten Inhalte. Beides folgt daraus, dass OpenTelemetry eine Spezifikation und eine Implementierung ist und kein Produkt. Man kann es einplanen — Versionen pinnen, Upgrades health-gaten, Budget für den Neubau von Dashboards — aber nicht wegkonstruieren.

Nicht inhärent — das sind Flottenbetriebs-Probleme: Konfigurationswildwuchs, Drift, Upgrade-Risiko und Volumenkontrolle. Jedes davon gab es mit Anbieter-Agents ebenso; die Konsole des Anbieters hat es nur verdeckt. Dreihundert Splunk-Forwarder per Puppet zu verwalten hatte dasselbe Drift-Problem und dasselbe Rollback um 3 Uhr nachts.

Diese Unterscheidung zählt, weil die zweite Gruppe eine strukturelle Antwort hat statt einer, die auf Disziplin beruht. Ist die laufende Konfiguration autoritativ, von einer Stelle ausgerollt, versioniert, vor dem Ausliefern in der Vorschau geprüft und beim Rollout health-gated, dann ist Drift nichts, was Sie erkennen — sondern etwas, das grösstenteils gar nicht passieren kann. Das ist das Argument in Governance und Durchsetzung, und es verwandelt eine Flotte von einer Verbindlichkeit in einen Aktivposten.

Der Fehlermodus, den es zu vermeiden gilt

Es gibt einen bestimmten Weg, auf dem OpenTelemetry-Einführungen schiefgehen, und er verdient einen Namen: Das Team führt den Collector als Drop-in-Ersatz für den Agenten ein, verwaltet ihn mit demselben Config-Management wie den alten Agenten — und baut die Steuerungsschicht nie.

Sechs Monate später haben sie die ganze Last und keinen Hebel. Der Collector ist einfach ein anderer Agent, mit einem ungewohnteren Config-Format und ohne Support-Hotline des Anbieters. Der Grund, OTel einzuführen — dass die Verarbeitungsschicht nun Ihnen zur Verfügung steht —, ist genau der Teil, der nie genutzt wird, weil niemand eine Pipeline über dreihundert Hosts hinweg sicher ändern kann.

Der Test ist einfach: Wenn das Ändern einer Verarbeitungsregel über die Flotte hinweg ein Change-Management-Ticket ist statt eines Nachmittags, wurde der Hebel nie realisiert.

Eine ehrliche Empfehlung

• Den Standard für die Instrumentierung sofort einführen. Das Lock-in-Argument ist real, und die Kosten des Zuwartens summieren sich mit jedem Service, den Sie gegen ein Anbieter-SDK instrumentieren.
• Den Collector nicht einführen, ohne zu entscheiden, wer ihn betreibt. Eine Flotte ohne Eigentümer driftet in den obigen Fehlermodus. Das ist eine organisatorische Entscheidung, keine technische.
• Die Flotte vom ersten Tag an als Flotte behandeln. Zentrale Konfiguration, versioniert, bewusst ausgerollt. Das nach zwei Jahren handgepflegtem YAML nachzurüsten ist selbst eine Migration.
• Budget für die Inhaltslücke einplanen. Dashboards und Alerts müssen von irgendwoher kommen. Etwas anderes zu behaupten ist der Weg, auf dem eine technisch erfolgreiche Migration von denen als Fehlschlag beurteilt wird, die ihre Dashboards verloren haben.

Also: offener Standard und neue Betriebslast. Die Last ist kleiner als das Lock-in, das sie ersetzt — aber nur, wenn die Flotte betrieben und nicht bloss ausgerollt wird.