// HEISE ONLINE — LINUX & OPEN SOURCE
OpenTelemetry friert seine Transformationssprache ein
Schluss mit kaputten Collector-Pipelines nach Updates: Die OpenTelemetry Transformation Language (OTTL) ist in Version 1.0 stabil und rückwärtskompatibel.
Die OpenTelemetry Transformation Language (OTTL) liegt ab sofort in Version 1.0 vor. Ab dem Release v0.164.0 der Collector-Contrib-Distribution gilt die Sprache für die Signaltypen Traces, Metriken und Logs offiziell als stabil. Damit einher geht ein Kompatibilitätsversprechen für alle kommenden Versionen der 1.x-Reihe, das sowohl die Syntax und die Standardfunktionen als auch die Go-API abdeckt.
OpenTelemetry (OTel) hat sich unter dem Dach der Cloud Native Computing Foundation (CNCF) als herstellerneutraler Standard etabliert, um Telemetriedaten in verteilten Systemen zu erfassen und weiterzuleiten. Eine zentrale Rolle in der Architektur spielt der OpenTelemetry Collector, der Datenströme entgegennimmt, verarbeitet und an Analyse-Backends wie Prometheus, Jaeger oder Grafana Loki exportiert. OTTL dient innerhalb dieses Collectors als domänenspezifische Sprache, mit der Plattformteams und Administratoren eingehende Daten direkt in der Pipeline manipulieren. So lassen sich etwa sensible Daten aus Logs maskieren, Kubernetes-Metadaten anreichern oder ungenutzte Metriken vor dem Weiterleiten verwerfen, um Speicher- und Ingest-Kosten im Backend zu senken.
Vor dem Schritt auf Version 1.0 stand das Entwicklerteam vor einem Dilemma: Da mit dem Stabilitätsversprechen keine Breaking Changes mehr erlaubt sind, wird jede Funktion im Standardumfang zu einer dauerhaften Verpflichtung. In der Vergangenheit kam es bei Collector-Upgrades immer wieder vor, dass sich Funktionssignaturen änderten oder das Verhalten bestehender OTTL-Ausdrücke abwich, was manuelle Anpassungen an den Pipeline-Konfigurationen erzwang. Wie das Team in der Ankündigung zu OTTL v1 im OpenTelemetry-Blog erklärt, hat es daher vorab die gesamte Grammatik überprüft und für den 1.x-Lebenszyklus eingefroren. Das umfasst Pfade, Literale, Operatoren, Funktionsaufrufe und where-Bedingungen. Ein Ausdruck wie set(span.attributes["env"], "prod") where span.attributes["env"] == nil wird in allen künftigen 1.x-Releases exakt gleich geparst und ausgeführt.
Um die Sprache dennoch weiterentwickeln zu können, ohne Altlasten durch vorschnell aufgenommene Features anzuhäufen, führt das Projekt einen neuen Reifeprozess ein. Neue Funktionen starten ab sofort grundsätzlich als experimentell in einem separaten Modul namens xottl (versioniert unter 0.x), in dem sich Signaturen jederzeit ändern können. Standardkomponenten wie der Transform- oder Filter-Prozessor liefern diese Funktionen zwar direkt mit, schalten sie aber standardmäßig ab. Wer sie nutzen möchte, muss sie explizit via --feature-gates=pkg.ottl.functions.enableExperimental aktivieren. Erst wenn eine Funktion über mindestens zwei Minor-Releases hinweg erprobt ist, vollständige Tests und Dokumentationen aufweist, keine offenen Änderungsvorschläge mehr hat und messbaren Bedarf bei Nutzern deckt, wandert sie dauerhaft in den stabilen Standardumfang.
Ausgenommen von der aktuellen v1-Garantie sind noch einige neuere Bereiche. Dazu zählen die mächtigen Lambda-Funktionen (Filter, MapEach, MapKeys, Any, All, Find, Reduce und WHen), die weiterhin das Feature-Gate ottl.functions.enableLambda erfordern. Auch die Unterstützung für kontinuierliches Profiling befindet sich noch in der Entwicklung. Die zugehörigen Funktionen liegen im separat unter 0.x geführten Modul xprofile. Experimentelle Go-APIs wie SliceGetter verbleiben ebenfalls in xottl.
Für das Upgrade auf opentelemetry-collector-contrib v0.164.0 müssen Administratoren bestehende Startparameter prüfen. Im Vorfeld des Releases haben die Maintainer lange als veraltet markierte Funktionen wie Base64Decode sowie alte Profiling-Funktionen endgültig entfernt. Zudem sind diverse Feature-Gates weggefallen, deren Funktionen bereits in den stabilen Zustand übergegangen sind. Hierzu zählen ottl.PanicDuplicateName, ottl.contexts.enableOTelColCo