Das Ende des Vendor-Lock-in

Fünfzehn Jahre lang funktionierte Observability so: Sie wählten einen Anbieter, installierten dessen Agent auf jedem Host, instrumentierten Ihren Code mit dessen SDK und schickten alles an dessen Backend. Es funktionierte – bis das Verlängerungsangebot eintraf, oder die Rechnung den Nutzen überstieg, oder ein besseres Werkzeug erschien, zu dem Sie nicht wechseln konnten, ohne Ihren gesamten Bestand neu zu instrumentieren.

Genau dieser letzte Teil ist die Falle. Die Wechselkosten waren nicht die Daten; es waren der Agent und das SDK. Jeder proprietäre Agent, den Sie ausrollen, und jede proprietäre API, die Sie aufrufen, ist ein Faden, der Sie an einen Anbieter näht. Genug Fäden, und ein Wechsel wird zu einem Projekt über mehrere Quartale, das niemand sponsern will – was genau der Grund ist, warum die Preise sich halten.

OpenTelemetry (OTel) durchbricht die Falle. Nicht, indem es ein günstigeres Backend wäre – es ist überhaupt kein Backend –, sondern indem es jene Teile, die Sie früher gebunden haben, in offene Standards verwandelt, die Ihnen gehören. In diesem Beitrag geht es darum, warum OTel den Vendor-Lock-in lockert, was die beweglichen Teile sind und wie man tatsächlich von einem proprietären Stack zu einem portablen kommt.

Was „Lock-in” tatsächlich ist

Lock-in ist nicht eine Sache; es sind drei Schichten, und ein proprietärer Anbieter besitzt alle drei:

• Instrumentierung – das SDK in Ihrem Anwendungscode, das Spans, Metriken und Logs erzeugt. Ein kompletter Austausch bedeutet, jeden Service zu ändern.
• Collection – der Agent auf jedem Host oder Pod, der Telemetrie scrapt, batcht und weiterleitet. Ein kompletter Austausch bedeutet ein flottenweites Redeploy.
• Das Wire-Format – das proprietäre Protokoll, das der Agent mit dem Backend spricht. Solange Ihre Daten nur in der Form eines Anbieters herauskommen, kann sie nur ein Anbieter lesen.

Wenn alle drei proprietär und fest verschweisst sind, haben Sie keine Datenpipeline – Sie haben eine Einbahnleitung zu einem einzigen Ziel. OpenTelemetry ersetzt jede Schicht durch ein offenes Äquivalent, und in dem Moment, in dem es das tut, wird das Ziel zu einer austauschbaren Wahl statt zu einer lebenslänglichen Strafe.

Die drei Standards, die den Lock-in beenden

OpenTelemetry ist ein CNCF-Projekt – das zweitaktivste nach Kubernetes – und es gibt Ihnen für jede dieser drei Schichten einen offenen Ersatz.

OTLP – das Wire-Format. Das OpenTelemetry Protocol ist ein einziges, anbieterneutrales Format für Logs, Metriken und Traces. Wenn Ihre Telemetrie OTLP ist, kann sie jedes Backend empfangen, das OTLP spricht, und die meisten tun das inzwischen. Ihre Daten sind kein Dialekt eines Anbieters mehr, sondern werden zur Lingua franca.

Der OTel-Collector – Collection. Der Collector ist ein Open-Source-Agent, der Telemetrie von allem empfängt (OTLP, Syslog, Prometheus, Filelog, Kafka, Host-Metriken), sie verarbeitet und an alles exportiert. Er sitzt zwischen Ihren Quellen und Ihren Backends als neutraler Vermittler. Wechseln Sie das Backend, ändern Sie einen Exporter-Block – nicht einen Agent auf jedem Host.

OpAMP – Flottenmanagement. Das Open Agent Management Protocol ist das neueste Teil: ein Standard für das Fernkonfigurieren und -verwalten einer Flotte von Collectors von einer zentralen Control Plane aus. Es ist das, was „ein Collector auf jedem Host” von einem unverwaltbaren Wildwuchs an YAML-Dateien in eine Flotte verwandelt, die Sie von einem Ort aus steuern. (Wir haben eine vollständige Erklärung in OpAMP, erklärt geschrieben.)

Zusammen bedeutet das, dass die teuren, hartnäckigen Teile Ihres Observability-Stacks – Instrumentierung und Collection – Dinge sind, die Ihnen gehören und die Sie überallhin zeigen lassen können. Das Backend wird zum einzigen Ding, das Sie kaufen, und ein Backend zu kaufen, das Sie verlassen können, ist eine ganz andere Verhandlung als eines zu kaufen, das Sie nicht verlassen können.

Sobald Collection neutral ist, ist Routing gratis

Hier ist der Teil, der den Lock-in auf den Kopf stellt. Wenn jede Quelle OTLP in einen neutralen Collector spricht, kann der Collector denselben Stream an mehr als ein Ziel senden – und verschiedene Ausschnitte an verschiedene Orte schicken.

Das ermöglicht die Züge, die proprietäre Agents nicht machen können:

• Eine Migration parallel fahren. Schicken Sie gleichzeitig an Ihr bestehendes und an ein Kandidaten-Backend, vergleichen Sie beide anhand echter Produktionsdaten und stellen Sie erst um, wenn Sie zufrieden sind. Kein Stichtag, kein Vertrauenssprung.
• Nach Wert routen. Schicken Sie die 10 %, die Sie aktiv abfragen, an ein Premium-Backend und den Long Tail an günstigen Objektspeicher – der Kernzug beim Senken von Observability-Kosten.
• Erneuten Lock-in vermeiden. Weil die Pipeline neutral ist, ist ein späterer erneuter Wechsel wieder nur eine Exporter-Änderung, keine weitere Migration. Sie tauschen nicht einen Käfig gegen einen schöneren; Sie werden den Käfig los.

So sieht eine neutrale Pipeline in der Praxis aus – ein Stream hinein, mehrere austauschbare Backends hinaus, jedes bekommt nur, was es soll:

Was OpenTelemetry ersetzt – und was nicht

Das ist der Teil, den die meisten „Verabschieden Sie sich von Ihrem Anbieter”-Beiträge überspringen, und es ist der Teil, der entscheidet, ob Ihre Migration gelingt. OpenTelemetry ist ein Standard zum Erzeugen, Sammeln und Verschicken von Telemetrie. Es ist kein Observability-Backend – es speichert, indiziert, visualisiert und alarmiert nicht. Eine realistische Migration ersetzt also die Collection-Schicht und behält oder baut alles Nachgelagerte neu:

Fähigkeit	Zu OTel wechseln?	Was das tatsächlich bedeutet
Host- und Infrastruktur-Metriken	Meist	Der hostmetrics-Receiver deckt den Standardsatz ab; validieren Sie alle anbieterspezifischen Metriken, auf die Sie sich verlassen.
Anwendungs-Traces	Meist	OTel-SDKs / Auto-Instrumentierung emittieren OTLP; die Abdeckung der Instrumentierung kann von einem proprietären Agent abweichen.
Log-Collection und -Weiterleitung	Häufig	Die filelog- / journald-Receiver sammeln; Parsing- und Routing-Regeln müssen als Prozessoren neu erstellt werden.
PII-Redaction / Data Shaping	Ja	transform- / redaction- / filter-Prozessoren – oft besser als ein geschlossener Agent, und vor dem Egress.
Dashboards	Nein	Kein OTel-Anliegen – im neuen Backend neu aufbauen oder das alte behalten.
Alert-Logik	Nein	Alert-Regeln leben im Backend; sie migrieren separat.
RUM / Session Replay	Meist nicht	Anbieterspezifische Fähigkeit; OTel hat Browser-/Mobile-Signale, aber keine Feature-Parität.
Continuous Profiling	Entstehend	OTel-Profiling ist jung; behandeln Sie Anbieter-Profiler als noch nicht ersetzt.
Service-Topologie / -Maps	Teilweise	Aus OTLP-Traces ableitbar, aber proprietäre Topologie (z. B. autogefundene Maps) überträgt sich womöglich nicht 1:1.
Backend-Storage und Query-Sprache	Nein	OTel ist kein Backend. Hier lebt der Rest-Lock-in – und hier verschafft Ihnen Routing Hebelwirkung.

Das Muster ist klar: OTel entkoppelt die linke Seite der Pipeline (erzeugen, sammeln, routen) und überlässt die rechte Seite (speichern, abfragen, visualisieren, alarmieren) welchem Backend auch immer Sie darauf zeigen. Das ist genau die Schicht, in der Lock-in am teuersten war – die Agents und das Wire-Format –, also verwandelt ihre Entkopplung ein Backend von einer lebenslänglichen Strafe in einen Posten. Der verbleibende Rest-Lock-in (Dashboards, Queries, Analytics) ist real, aber er ist portabler Aufwand, keine technische Wand.

Der ehrliche Haken: OTel gibt Ihnen den Standard, nicht die Flotte

Es gibt eine Lücke, über die Teams stolpern, die von OpenTelemetry erwarten, es sei schlüsselfertig. OTel gibt Ihnen das Protokoll, den Collector und den Management-Standard. Es gibt Ihnen nicht das, was eine grosse Flotte lebbar macht: eine Control Plane, die validierte Konfiguration rendert, sie an die richtigen Nodes pusht, eine Änderung vor dem Ausrollen als Vorschau zeigt und Ihnen den Durchsatz an jeder Kante anzeigt.

Von Haus aus ist eine Flotte von OTel-Collectors ein Satz YAML-Dateien, die Sie von Hand synchron halten – was eine echte operative Last ist und der Grund, warum manche Teams bei einem proprietären Agent bleiben, der wenigstens mit einer Management-UI ausgeliefert wird. Die Antwort ist nicht, den offenen Standard aufzugeben; es ist, eine auf offenem Standard basierende Control Plane darüberzusetzen.

Genau hier passt LinkMesh hinein. Es ist eine selbstgehostete Control Plane für OpenTelemetry Collectors: Zeigen Sie Ihre Collectors – otelcol-contrib unter dem OpAMP Supervisor oder Grafana Alloy über remotecfg – mit einem Konfigurationsblock und einem Token auf LinkMesh und komponieren Sie dann Quellen, Prozessoren, Routen und Ziele in einem visuellen Builder. LinkMesh rendert und validiert die Collector-Konfiguration und liefert sie an die richtigen Nodes; die Telemetrie selbst fliesst niemals durch LinkMesh – sie bleibt auf Ihrer Infrastruktur. Und weil der Preis pro verwaltetem Collector, nicht pro Gigabyte gilt, ist das Werkzeug, das Sie von volumenbasierter Backend-Preisgestaltung befreit, selbst nicht nach Volumen gemessen.

Wo anfangen: einen Anbieter wählen und parallel fahren

Die Migration ist weniger beängstigend, als sie aussieht, denn OTel lässt Sie ohne Urknall umziehen. Das Muster ist dasselbe, egal welchen Anbieter Sie verlassen:

1. OTel-Collectors ausrollen neben Ihren bestehenden Agents – entfernen Sie noch nichts.
2. Parallel schicken: Exportieren Sie weiter an Ihr bestehendes Backend und fügen Sie einen Exporter zu einem Kandidaten hinzu. Vergleichen Sie Dashboards und Alerts anhand von Live-Daten.
3. In der Pipeline verfeinern: Filtern Sie Rauschen, samplen Sie volumenstarke Streams und maskieren Sie PII vor dem Egress – Einsparungen, die Sie aus einem geschlossenen Agent nicht bekommen konnten.
4. Umstellen des bestehenden Exporters, wenn Parität besteht, und die alten Agents ausser Betrieb nehmen.

Lesen Sie, bevor Sie anfangen, was OpenTelemetry ersetzen kann und was nicht, damit Sie die Migration auf die Collection-Schicht zuschneiden und den Neuaufbau von Dashboards/Alerts bewusst planen, statt ihn mitten in der Umstellung zu entdecken. Wählen Sie dann Ihr Anbieter-Playbook:

• Splunk Enterprise zu OpenTelemetry migrieren – Universal Forwarders und den HTTP Event Collector ersetzen.
• Von Dynatrace zu OpenTelemetry migrieren – vom OneAgent entkoppeln und der Host-Unit-/DDU-Preisgestaltung entkommen.
• Von Datadog zu OpenTelemetry migrieren – den Datadog Agent und die Rechnung pro Host + pro GB ersetzen.
• Von New Relic zu OpenTelemetry migrieren – die New-Relic-Agents ersetzen und von der Consumption-Preisgestaltung wegkommen.
• Vom Elastic Agent zu OpenTelemetry migrieren – Beats und Elastic Agent ersetzen und dabei den Elastic Stack behalten (oder verlassen).

Vendor-Lock-in in der Observability war nie eine technische Notwendigkeit – es war ein Geschäftsmodell, das davon abhing, dass Ihre Instrumentierung nicht portabel war. OpenTelemetry macht sie portabel. Sobald Ihre Daten OTLP sprechen und Ihre Collectors auf offenen Standards verwaltet werden, ist Ihr Backend eine Entscheidung, die Sie jederzeit neu treffen dürfen – was der ganze Sinn ist. Es baut Ihnen Ihre Dashboards nicht neu auf, aber es reicht Ihnen das eine, das Sie zuvor nie hatten: Verhandlungsmacht.