Observability: Zuverlässigkeit und Konsistenz mit OpenTelemetry Weaver
«Gute Erkenntnisse entstehen nur aus guten Daten»
opensight.ch - roman hüsler
OpenTelemetry: Semantic Conventions
In letzter Zeit bin ich bei der Governance von Observability-Daten auf erhebliche Probleme gestossen. Beim Onboarding von Telemetriedaten aus verschiedenen Systemen führt uneinheitliche Benennung und Labelung oft zu einem fragmentierten, chaotischen Durcheinander in der Observability-Plattform, aus dem sich kaum noch aussagekräftige Erkenntnisse gewinnen lassen.
Probleme, die durch inkonsistente Telemetriedaten entstehen können:
- Kaputte Alerts und Dashboards, weil sich Metriknamen geändert haben
- Schwer lesbare Queries wegen uneinheitlicher Benennung
- Undokumentierte Telemetrie, die für Verwirrung sorgt
- Fehlende Instrumentierung, die erst in Produktion auffällt
Bei der Recherche habe ich festgestellt, dass die Observability-Branche das Problem aktiv mit gemeinsamen Standardisierungsbemühungen angeht. Eine herausragende Initiative sind die OpenTelemetry Semantic Conventions, Teil des übergreifenden OpenTelemetry-Projekts der Cloud Native Computing Foundation (CNCF).
OpenTelemetry bringt grosse Anbieter wie Dynatrace, Datadog, Elastic und andere zusammen, um einen einheitlichen Standard für Telemetriedaten zu schaffen, über Metrics, Logs und Traces hinweg. Indem sie Benennung, Struktur und Metadaten einheitlich festlegen, ermöglichen die Semantic Conventions Interoperabilität zwischen Observability-Tools, verringern die Fragmentierung und verbessern die Portabilität der Daten. Dieser branchenweite Schritt zur Standardisierung verspricht schlankere Observability-Workflows, weniger Vendor Lock-in und packt die Herausforderungen der Daten-Governance direkt an. OpenTelemetry ist kein Allheilmittel, aber ein wichtiger Schritt hin zu einem kohärenteren und effizienteren Observability-Ökosystem.
Wie viel die OpenTelemetry Semantic Conventions zur Standardisierung von Telemetriedaten beitragen, zeigt die Metrik http.server.request.duration, die die Dauer von HTTP-Server-Requests in Millisekunden misst. Gemäss den OpenTelemetry Semantic Conventions für HTTP-Metriken (nachzulesen in der OpenTelemetry-Spezifikation) muss diese Metrik Pflichtattribute wie http.request.method (z. B. "GET" oder "POST") und http.response.status_code (z. B. 200 oder 404) enthalten, damit Tools wie Dynatrace oder Grafana Alloy sie einheitlich interpretieren. Eine konforme Metrik könnte etwa so aussehen: {name: "http.server.request.duration", value: 120.5, unit: "ms", attributes: {"http.request.method": "GET", "http.response.status_code": 200, "service.name": "my-web-app"}}. Diese Attribute folgen den strengen Benennungs- und Typregeln der Conventions, sodass sich Request-Dauern über verteilte Systeme hinweg nahtlos korrelieren lassen. Weil OpenTelemetry solche Standards durchsetzt, können Tools wie Weaver diese Metrik in CI/CD-Pipelines validieren, während Collectors wie Grafana Alloy nicht konforme Daten herausfiltern. So bleibt die Observability-Pipeline sauber und kontrollierbar.
OpenTelemetry Weaver
open-telemetry
Mit OpenTelemetry Weaver gibt es nun ein neues Tool (2025 vorgestellt), das auf Validierung zur Design-Zeit ausgerichtet ist und sich direkt in einer CI/CD-Pipeline ausführen lässt, um die Qualität der Observability-Daten zu prüfen.
Das Prinzip heisst «Observability by Design»: Observability wird von Anfang an ins Produkt eingeplant und eingebaut. Weil Weaver sich an den Semantic Conventions von OpenTelemetry orientiert, hilft es, Observability-Daten zu standardisieren, und ebnet so den Weg zu einem kohärenteren Ökosystem. Weaver ist als CLI v0.X versioniert, gilt aber als produktionsreif und wird aktiv weiterentwickelt (v0.16.1, Stand 4. Juli 2025).
Weaver ist im Grunde ein Kommandozeilen-Tool mit mehreren Funktionen:
- Schema-Definition
Telemetrie-Schemas über Semantic Conventions definieren - Validierung
Telemetrie manuell oder in der CI gegen die definierten Schemas validieren - Typsichere Code-Generierung
Idiomatische Client-SDKs (Go, Rust usw.) aus diesen Schemas generieren - Dokumentations-Generierung
Markdown-Dokumentation für die eigenen Signale automatisch erzeugen - Live Checking (Schwerpunkt dieses Beitrags)
In die CI oder zur Laufzeit einbinden, um sicherzustellen, dass die ausgegebene Telemetrie konform ist
In der CI/CD-Pipeline kann man die Applikation hochfahren und ihre Telemetrie an Weaver senden. Weaver validiert sie dann gegen die Semantic Conventions und gibt einen Report aus. Eine ausführlichere Architekturzeichnung von Weaver finden Sie hier.
Beispiel-App
Um Weaver auszuprobieren, habe ich eine Test-App gebaut, die in einem Docker-Container läuft. Sie startet einen OpenTelemetry Collector und Weaver direkt im eigenen Container und schickt ihnen Telemetrie. (Der Code liegt auf meinem GitHub.)
# start testapp on docker http://localhost:3000
docker-compose up -d --build
Sobald die Test-App läuft, können wir mit dem Button «send non-compliant metrics» Telemetrie an Weaver schicken, die nicht den OpenTelemetry Semantic Conventions entspricht. Die App startet dann einen OpenTelemetry Collector, startet Weaver und sendet fehlerhafte Telemetriedaten.
Als Beispiel sendet sie die Metrik my_custom_counter_123{bad_label="test_value_1760100097079"}. Diesen Metriknamen gibt es in den OpenTelemetry Semantic Conventions nicht. Auch das Label-Attribut bad_label ist gemäss den Semantic Conventions nicht erlaubt. Schauen wir uns also die Ausgabe von Weaver an:
Im Ergebnis sehen wir, dass Weaver die Verstösse in den schlecht formatierten Telemetriedaten erkannt hat. Hier die vollständige Rohausgabe von Weaver: GitHub: Weaver-Beispielausgabe
Das Tool ist noch recht jung, aber ich bin gespannt, was es bringen wird. Das Wertversprechen überzeugt: Weaver behandelt Telemetrie-Schemas (abgeleitet aus den Semantic Conventions) als versionierte, durchsetzbare «Public APIs» und generiert daraus Code, Tests und Dokumentation, um Inkonsistenzen früh im SDLC abzufangen. Die Architektur von Weaver sieht ausdrücklich ein WASM-Plugin-System vor, um die Plattform zu erweitern. Das könnte eine direkte Integration zur Laufzeit mit Collectors (z. B. Grafana Alloy) ermöglichen, für Schema Injection, Validierung oder sogar eine dynamische Weiterentwicklung.
opensight.ch - roman hüsler