Wie YAML die Observability in OpenTelemetry-Pipelines erschwert

Der Tag, an dem YAML aufhört, „nur Konfiguration" zu sein

YAML wirkte früher harmlos. Es begann als freundliche Konfigurationssprache mit einfacher Einrückung, lesbarer Syntax und dem Ruf, einfacher zu sein als JSON. Infrastruktur-Ingenieure übernahmen es schnell: Kubernetes nutzt es, CI/CD-Pipelines verlassen sich darauf, und Monitoring-Systeme speichern ihre Konfigurationen darin.

Irgendwann ist YAML dann, ohne dass es groß jemand bemerkt hätte, zum Rückgrat einiger der komplexesten Systeme in der modernen Infrastruktur geworden. OpenTelemetry ist eines davon, und für viele Ingenieure werden genau dort die Risse sichtbar.

Ein Team beschrieb den Moment, in dem YAML zur Last wurde. Die Konfiguration ihres OpenTelemetry Collectors war über eine Handvoll Pipelines hinausgewachsen, und plötzlich umfasste das Setup mehrere Receiver, Prozessoren, Exporter und Routing-Regeln, die alle miteinander interagierten. Die Konfigurationsdatei zu lesen fühlte sich eher an wie das Reverse-Engineering eines Systemdiagramms.

Ab diesem Punkt wird YAML zu Infrastruktur-Code ohne Landkarte.

Wie eine OpenTelemetry-Pipeline tatsächlich aussieht

Auf den ersten Blick ist die Architektur des OpenTelemetry Collectors elegant. Daten kommen über Receiver herein, Prozessoren transformieren oder filtern sie, und Exporter senden die Telemetriedaten an Storage- oder Monitoring-Plattformen. Das ist einfach genug.

Reale Deployments bleiben aber selten so einfach. Eine einzelne Collector-Konfiguration kann fünf verschiedene Receiver umfassen, etwa OTLP, Prometheus-Metriken, dateibasierte Logs und mehrere andere Quellen. Diese Signale durchlaufen dann Schichten von Prozessoren, die Batching, Filterung oder Transformationen übernehmen.

Jeder Prozessor kann Telemetriedaten je nach Attributen oder Inhalt unterschiedlich verzweigen. Manche Pipelines leiten Logs an ein Backend und Metriken an ein anderes. Andere verteilen Traces je nach Service-Zugehörigkeit oder Datenklassifizierung auf mehrere Exporter.

Schon bald bildet eine einzige Konfigurationsdatei eine gesamte Observability-Architektur ab, und dargestellt wird diese Architektur ausschließlich durch … Einrückung.

Das eigentliche Problem ist die fehlende Visualisierung

Schwierig wird es, weil man die Struktur der Pipeline nicht sieht. Mit wachsendem Umfang von OpenTelemetry-Deployments wird der Collector immer mehr zu einem Datenverarbeitungsgraphen. Signale bewegen sich durch Pipelines, verzweigen sich zu verschiedenen Exportern und durchlaufen manchmal mehrere Verarbeitungsstufen in Schleifen. Das Konfigurationsformat stellt diese Architektur trotzdem weiterhin als reinen Text dar.

Ingenieure müssen die Pipeline-Struktur im Kopf rekonstruieren, indem sie YAML Zeile für Zeile lesen. Bei zwei oder drei Komponenten geht das noch, bei Dutzenden wird es schmerzhaft.

Ein Ingenieur beschrieb, wann es kippt: Sobald Collector-Konfigurationen drei oder vier Pipelines überschreiten und mehrere Prozessoren und Exporter einschließen, lässt sich allein durch das Lesen von YAML kaum noch verstehen, wie Daten durch das System fließen. Ab da liest man keine Konfiguration mehr, man löst ein Puzzle.

Warum Teams anfingen, visuelle Tools zu bauen

Angesichts dieser Komplexität begannen manche Teams, interne Tools zu bauen, nur um ihre eigenen Telemetrie-Pipelines zu verstehen.

Ein Beispiel ist ein Projekt namens OteFlow, ein visueller Editor speziell für Konfigurationen des OpenTelemetry Collectors. Ingenieure bauen Pipelines dort über eine grafische Oberfläche auf, statt YAML direkt zu schreiben. Receiver, Prozessoren und Exporter erscheinen als Knoten, und das System zeigt visuell, wie Telemetriedaten durch den Collector fließen.

Das Konzept ist unkompliziert. Ingenieure müssen keine Einrückungen mehr von Hand interpretieren und sehen die Pipeline-Struktur sofort: Receiver speisen Prozessoren, Prozessoren verbinden sich mit Exportern, und Verzweigungen und Routing-Regeln stehen im Bild, statt in der Konfigurationssyntax vergraben zu sein. Die Collector-Pipeline wird so zu dem, was sie eigentlich ist, einem Dataflow-Diagramm.

Warum das für Teams wichtig ist

Visuelle Tools sind bequem, vor allem aber machen sie das Thema für mehr Leute zugänglich.

Nicht jeder, der mit Observability-Systemen arbeitet, kennt die internen Abläufe von OpenTelemetry genau. Manche Teammitglieder verstehen Monitoring-Konzepte, aber keine YAML-Syntax, andere kennen sich eher mit Infrastruktur aus als mit Telemetrie-Pipelines. Mit visuellen Editoren können sich auch diese Personen an der Konfiguration beteiligen, weil sie die Architektur direkt sehen, statt Konfigurationsdateien entziffern zu müssen.

Besonders wichtig wird das, wenn Teams Observability-Pipelines Kunden oder Stakeholdern erklären. Einen Graphen der Telemetrieflüsse zu zeigen ist wesentlich einfacher, als jemanden durch Dutzende Konfigurationszeilen zu führen. Ein Ingenieur fand die Visualisierungsfunktion genau dann besonders nützlich, wenn er Collector-Setups Kunden erklärte, die verstehen wollten, wie ihre Telemetriedaten verarbeitet werden. Diagramme kommunizieren eben schneller als Text.

Konkurrierende Ansätze im Observability-Tooling

Tools wie OteFlow sind übrigens nicht die einzigen Versuche, dieses Problem zu lösen. Im OpenTelemetry-Ökosystem gibt es bereits mehrere Visualisierungstools. Manche Projekte wandeln YAML-Konfigurationen in Diagramme um, andere bieten teilweise grafische Oberflächen zur Bearbeitung von Collector-Pipelines.

Die Ansätze unterscheiden sich allerdings deutlich. Manche Tools beschränken sich auf Visualisierung, nehmen also eine bestehende Konfiguration und stellen sie als Graph dar. Andere wollen die YAML-Bearbeitung vollständig durch GUI-basierte Pipeline-Builder ersetzen. Visualisierungstools helfen Ingenieuren, bestehende Systeme zu verstehen, während Editoren verändern, wie diese Systeme überhaupt erst entstehen.

Beide Ansätze setzen am selben Problem an: Observability-Pipelines sind zu komplex geworden, um sie rein über Text zu erfassen.

Die versteckte Hürde bei der OpenTelemetry-Einführung

Visuelle Tools helfen noch aus einem weiteren Grund. OpenTelemetry verbreitet sich branchenweit rasant, aber seine Komplexität kann das Onboarding neuer Teams verlangsamen.

Die Architektur des Collectors ist extrem flexibel und dadurch leistungsfähig, doch Flexibilität bringt oft Komplexität mit sich. Neue Nutzer müssen Receiver, Prozessoren, Exporter, Extensions und Pipeline-Definitionen lernen und dann verstehen, wie diese Komponenten in den Konfigurationsdateien zusammenspielen. Erfahrenen Observability-Ingenieuren leuchtet dieses Modell irgendwann ein, Neueinsteiger kann es überwältigen.

Ein Entwickler wies darauf hin, dass visuelle Tools beim Onboarding von Personen helfen, die OpenTelemetry oder YAML nicht gut kennen. Wer die Komponenten sichtbar verbunden sieht, versteht leichter, wie Telemetriedaten durch das System fließen. Das zählt, weil Observability-Systeme am meisten bringen, wenn ganze Teams sie verstehen und nicht nur eine kleine Gruppe von Spezialisten.

Der größere Trend: Infrastruktur braucht bessere Interfaces

Die Geschichte von YAML in OpenTelemetry passt zu einem breiteren Muster im Infrastruktur-Tooling.

Viele moderne Systeme begannen als Technologien für Entwickler. Konfigurationsdateien waren akzeptabel, weil die ursprünglichen Nutzer Ingenieure waren, die mit codeähnlicher Syntax umgehen konnten. Als sich diese Systeme in Organisationen ausbreiteten, wuchs jedoch die Zielgruppe: Operations-Teams, Platform-Engineers, Security-Analysten und Data-Engineers, und manchmal kommen sogar Produktteams mit Observability-Tools in Berührung. Nicht alle von ihnen wollen komplexe Konfigurationsdateien lesen.

Deshalb bewegt sich Infrastruktur-Tooling langsam in Richtung besserer Interfaces, mit visuellen Pipelines, grafischen Editoren und schema-bewussten Konfigurationstools. Text soll dabei nicht vollständig verschwinden, komplexe Systeme sollen sich aber leichter verstehen lassen.

Was YAML in der Observability lehrt

Bei YAML in der Observability liegt das Problem letztlich in der Komplexität.

OpenTelemetry-Collectors sind heute Telemetrie-Router, Transformatoren, Filter und Exporter in einem System. Sie verarbeiten enorme Mengen an Signalen, die sich durch verteilte Infrastruktur bewegen. Diese Komplexität als reinen Text darzustellen funktioniert bis zu einem gewissen Punkt, danach brauchen Ingenieure bessere Wege, um zu sehen, was passiert.

Visuelle Tools wie Pipeline-Editoren sind deshalb der nächste Schritt, um Observability-Systeme verständlich zu machen. Wenn Ihre Monitoring-Infrastruktur so komplex geworden ist, dass sie Diagramme braucht, hat sie diese wahrscheinlich auch verdient.