Airbnb hat seine gewachsene Monitoring-Infrastruktur von Grund auf neu gedacht – und dabei einen Weg beschritten, der für viele Plattformunternehmen als Blaupause dienen könnte: offene Standards statt proprietärer Werkzeuge, klare Abstraktionsschichten statt organisch gewachsenem Chaos.
Airbnb migriert Monitoring-Infrastruktur auf OpenTelemetry und VictoriaMetrics
Ausgangsproblem: Technische Schulden im Monitoring
Wie viele Plattformunternehmen, die über Jahre schnell gewachsen sind, stand Airbnb vor dem typischen Problem einer fragmentierten Observability-Infrastruktur. Verschiedene Teams nutzten unterschiedliche Agenten, Formate und Backends für Metriken, Logs und Traces. Das führte zu redundantem Betriebsaufwand, inkonsistenten Daten und steigenden Kosten – sowohl für Infrastruktur als auch für Ingenieursstunden.
Ohne einheitliches Datenmodell ist die Korrelation von Signalen über Systemgrenzen hinweg fehleranfällig – jede Änderung an einem Teilsystem erfordert Anpassungen an mehreren Stellen.
Das Kernproblem war mangelnde Standardisierung: Jede Änderung an einem Teilsystem erforderte Anpassungen an mehreren Stellen – ein klassisches Symptom gewachsener Systeme ohne architektonischen Gesamtplan.
Migration auf OpenTelemetry als strategische Entscheidung
OpenTelemetry hat sich in den vergangenen Jahren als De-facto-Standard für die Instrumentierung verteilter Systeme etabliert. Das unter dem Dach der Cloud Native Computing Foundation (CNCF) entwickelte Framework bietet herstellerneutrale SDKs und einen Collector, der Telemetriedaten aus unterschiedlichen Quellen aufnehmen, transformieren und weiterleiten kann.
Airbnb nutzt den OpenTelemetry Collector als zentralen Routing-Layer:
- Eingehende Metriken werden dort normalisiert
- Anschließende Weiterleitung per Remote-Write-Protokoll an VictoriaMetrics
- Der vmagent – der schlanke Agent von VictoriaMetrics – scraped Metriken direkt am Erfassungspunkt mit geringer Latenz
VictoriaMetrics ist eine auf Performance und niedrigen Ressourcenverbrauch ausgelegte Zeitreihendatenbank, die als Alternative zu Prometheus bei sehr hohen Datenvolumen klare Vorteile bietet.
Architektonische Lektionen aus der Migration
Der Collector als Abstraktionsschicht
Besonders relevant für andere Teams ist die Entscheidung, den OpenTelemetry Collector als Entkopplungsschicht zu positionieren:
Anwendungen instrumentieren sich einmalig gegen die OTel-API – das Backend kann ausgetauscht oder erweitert werden, ohne Änderungen am Anwendungscode zu erfordern.
Diese Entkopplung reduziert den Migrationsaufwand bei zukünftigen Infrastrukturentscheidungen erheblich.
Skalierbarkeit im Millionen-Zeitreihen-Bereich
Airbnb verarbeitet intern Millionen von Zeitreihen. Die Kombination aus:
- horizontaler Skalierbarkeit des OTel Collectors
- effizientem Speichermodell von VictoriaMetrics
ermöglicht es, dieses Volumen mit überschaubarem operativen Aufwand zu bewältigen.
Schrittweise Migration als Risikomodell
Die Migration verlief bewusst graduell: Altes und neues System liefen parallel, Datenqualität und -konsistenz wurden kontinuierlich validiert, Teams wurden sukzessive umgeschaltet. Dieser Ansatz bedeutete kurzfristig Mehraufwand – minimierte aber das operative Risiko erheblich.
Einordnung für deutsche Unternehmen
Für Unternehmen hierzulande, die ihre Observability-Architektur modernisieren oder neu aufbauen, liefert Airbnbs Vorgehen einen praxisnahen Referenzrahmen:
- OpenTelemetry als Standardschicht ist inzwischen auch in mittelständischen IT-Abteilungen umsetzbar – die CNCF-Ökosystemreife hat deutlich zugenommen
- VictoriaMetrics ist besonders für Umgebungen interessant, in denen Betriebskosten für Cloud-Storage oder Self-Hosted-Lösungen eine Rolle spielen
- Vendor-Lock-in durch proprietäre Agenten sollte konsequent vermieden werden – der architektonische Spielraum offener Standards zahlt sich spätestens beim nächsten Backend-Wechsel aus
Wer heute neue Monitoring-Infrastruktur plant, sollte offene Standards nicht als Option, sondern als Ausgangspunkt betrachten.
Quelle: InfoQ – Airbnb Migrates to OpenTelemetry and vmagent