Vendor-Lock-in bezeichnet eine Lage, in der ein Wechsel zu einem anderen Anbieter so teuer, riskant oder langwierig ist, dass Kunden faktisch nicht wechseln können. In der Observability entsteht Lock-in meist durch proprietäre Agents und Instrumentierung, geschlossene Datenformate, herstellerspezifische Abfragesprachen und Dashboards, nicht exportierbare Daten sowie Vertragsbedingungen.
Was ist Vendor-Lock-in?
Vendor-Lock-in beschreibt eine Abhängigkeit von einem einzelnen Anbieter, die sich nur mit hohem Aufwand auflösen lässt. Zu den Wechselkosten gehören Engineering-Aufwand, Migrationsrisiko, verlorene Historie, Schulungen und Vertragsstrafen. Lock-in ist nicht per se schlecht, denn tiefe Integration kann echte Vorteile bringen. Problematisch wird er, wenn er Ihre Verhandlungsposition schwächt, bessere Technologie blockiert oder Sie regulatorische Anforderungen wie Datenresidenz oder Exit-Pläne nicht mehr erfüllen können.
Observability ist besonders anfällig für Lock-in, weil Telemetrie jeden Service berührt. Instrumentierung steckt in Anwendungscode und Deployment-Manifesten, Alarme enthalten jahrelanges Betriebswissen, und Dashboards prägen, wie Teams über ihre Systeme denken.
Wo Lock-in in der Observability steckt
| Ebene | Typischer Lock-in | Offene Alternative |
|---|---|---|
| Instrumentierung | Proprietäre SDKs und Agents mit herstellerspezifischen APIs im Code | OpenTelemetry-APIs, -SDKs und Zero-Code-Agents |
| Transport | Geschlossene Protokolle und Ingest-Endpunkte | OTLP, Prometheus Remote Write |
| Erfassungspipeline | Herstellereigene Forwarder und Verarbeitungsregeln | OpenTelemetry Collector |
| Datenmodell | Eigene Attributnamen und Metrik-Typen | Semantic Conventions |
| Abfragen und Alarme | Ausschließlich proprietäre Abfragesprachen | PromQL, SQL |
| Gespeicherte Daten | Kein Massenexport oder nur in proprietären Formaten | Export in offenen Formaten, eigenes Cloud-Konto |
| Vertrag | Mehrjährige Bindung, Strafzahlungen bei Mehrverbrauch, Paketpreise | Nutzungsbasierte Konditionen, klare Exit-Klauseln |
Warum das wichtig ist
- Kostenkontrolle: Ohne glaubwürdige Alternative lassen sich Preiserhöhungen oder Änderungen am Preismodell kaum abwehren.
- Technologiewahl: Ist die Instrumentierung an einen Anbieter gebunden, bedeutet ein besseres Tool für ein einzelnes Signal, etwa Profiling oder LLM-Monitoring, doppelte Instrumentierung.
- Regulierung: Finanzregulierung wie DORA verlangt Exit-Strategien für kritische IKT-Drittdienstleister, und DSGVO-Pflichten können erfordern, Daten in eine andere Region oder zu einem anderen Anbieter zu verlagern.
- Resilienz: Fällt ein Anbieter aus oder ändert er seine Strategie, brauchen Sie einen Weg, die Sichtbarkeit zu erhalten.
Datengravitation
Je länger Sie eine Plattform nutzen, desto mehr Historie sammelt sich darin: Monate an Metriken für die Kapazitätsplanung, Logs für Audits, Traces zu vergangenen Incidents. Diese Datengravitation ist eine leise Form von Lock-in. Selbst wenn die Instrumentierung portabel ist, bedeutet ein Wechsel entweder den Verlust der Historie, den Parallelbetrieb zweier Systeme, bis alte Daten auslaufen, oder einen kostenpflichtigen Massenexport. Planen Sie das früh: Legen Sie fest, welche Daten Sie wirklich behalten müssen, in welchem Format und wie lange, idealerweise abgestimmt mit Ihrer Richtlinie zur Datenaufbewahrung.
Wie OpenTelemetry Lock-in verringert
OpenTelemetry ist der wirksamste Hebel gegen Lock-in in der Observability, weil es die am schwersten änderbare Ebene standardisiert: die Instrumentierung. Der Code nutzt herstellerneutrale APIs, die Daten fließen über OTLP, und der Collector entscheidet, wohin sie gehen. Ein Backend zu wechseln oder hinzuzufügen wird so zur Konfigurationsänderung statt zur Codeänderung:
exporters:
otlphttp/current:
endpoint: https://otlp.current-vendor.example
otlphttp/candidate:
endpoint: https://otlp.candidate.example
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlphttp/current, otlphttp/candidate]Mit dieser beispielhaften Konfiguration fließen dieselben Traces parallel an zwei Backends. Eine Evaluierung oder Migration wird dadurch risikoarm. Beachten Sie aber: OpenTelemetry beseitigt nicht jede Form von Lock-in. Dashboards, Alarmregeln und gespeicherte Historie brauchen weiterhin einen eigenen Plan.
Portable Dashboards und Alarme
In Dashboards und Alarmregeln steckt viel Betriebswissen, und genau diesen Teil unterschätzen Teams bei Migrationen am häufigsten. Verwalten Sie beides als Code in der Versionskontrolle, nutzen Sie für Alarme, die Menschen wecken, breit unterstützte Abfragesprachen, und dokumentieren Sie die Absicht jedes Alarms, nicht nur seinen Ausdruck. Ein Alarm mit der Beschreibung „alarmieren, wenn zehn Minuten lang mehr als 1 Prozent der Checkout-Requests fehlschlagen“ lässt sich auf jeder Plattform nachbauen, eine 40-zeilige proprietäre Abfrage ohne Erklärung nicht. Es gibt offene Initiativen für Dashboard-Definitionen, aber noch keinen universellen Standard. Die dokumentierte Absicht bleibt daher Ihre beste Absicherung.
Best Practices
- Mit OpenTelemetry instrumentieren, auch bei neuen Services und auch dann, wenn Ihr aktueller Anbieter einen eigenen Agent anbietet.
- Eine Collector-Schicht dazwischenschalten, damit Routing, Filterung und Anreicherung in Ihrer Hand liegen.
- Offene Abfragesprachen bevorzugen für wichtige Alarme, und Alarm- und Dashboard-Definitionen als Code in Git verwalten.
- Datenexport vor Vertragsabschluss prüfen: Format, Vollständigkeit, Geschwindigkeit und Kosten eines Massenexports.
- Einen Exit-Plan schreiben mit Verantwortlichen, Schritten und Zeitrahmen, und Teile davon testen, etwa durch paralleles Senden für einige Services.
- Vertragsbedingungen prüfen: Laufzeiten, Verlängerungsklauseln und Datenlöschung nach Vertragsende.
Typische Fehler
- Annehmen, dass „unterstützt OpenTelemetry“ keinen Lock-in bedeutet, während Dashboards und Alarme nur in einer proprietären Sprache existieren.
- Aufrufe eines Hersteller-SDKs in die Geschäftslogik mischen, sodass eine spätere Migration zum Refactoring-Projekt wird.
- Die gespeicherte Historie vergessen: Lassen sich Daten nicht exportieren, gehen beim Wechsel Monate an Trends verloren.
Wie Obseria hilft
Obseria ist OpenTelemetry-nativ: Es nimmt OTLP an und arbeitet mit Standard-SDKs und -Collectoren, proprietäre Instrumentierung ist nicht nötig. Sie können Ihre Daten jederzeit per OTLP exportieren, neben OQL auch mit PromQL und SQL abfragen und die Datenresidenz in der EU, im Vereinigten Königreich oder im eigenen Cloud-Konto (BYOC) wählen. Abgerechnet wird nutzungsbasiert pro Signal, ohne Host- oder Nutzerlizenzen. Mehr dazu unter OpenTelemetry in Obseria.
