Interoperabilität von OpenTelemetry zu Kieker: Demonstriert als Export aus dem Astronomy Shop

Grundinformationen

• Paper-ID: 2510.11179
• Titel: Interoperability From OpenTelemetry to Kieker: Demonstrated as Export from the Astronomy Shop
• Autoren: David Georg Reichelt (Lancaster University Leipzig), Shinhyung Yang (Kiel University), Wilhelm Hasselbring (Kiel University)
• Klassifizierung: cs.SE (Softwaretechnik), astro-ph.IM (Instrumentierung und Methoden für Astrophysik)
• Veröffentlichungsdatum: 13. Oktober 2025
• Paper-Link: https://arxiv.org/abs/2510.11179

Zusammenfassung

Dieses Paper behandelt das Interoperabilitätsproblem zwischen dem Observability-Framework Kieker und dem OpenTelemetry-Standard. Kieker verfügt über umfangreiche Analysefähigkeiten, unterstützt aber nur begrenzte Programmiersprachen (Java, C, Fortran, Python), während OpenTelemetry-Standard Referenzimplementierungen für die meisten Programmiersprachen bietet, einschließlich C# und JavaScript, die Kieker nicht unterstützt. Das Paper beschreibt, wie OpenTelemetry-Tracing-Daten in das Kieker-Framework-Format konvertiert werden, um Analyseergebnisse wie Aufrufbäume basierend auf OpenTelemetry-Instrumentierung zu erstellen. Die Machbarkeit der Methode wurde durch die Visualisierung von Tracing-Daten der Astronomy Shop (OpenTelemetry-Demo-Anwendung) validiert.

Forschungshintergrund und Motivation

Problemdefinition

1. Einschränkungen der Sprachunterstützung: Das Kieker-Framework bietet zwar starke Analysefähigkeiten und niedrige Overhead-Eigenschaften, unterstützt aber nur begrenzte Sprachen wie Java, C, Fortran und Python
2. Standardisierungsbedarf: OpenTelemetry als De-facto-Standard bietet Agent-Implementierungen für verschiedene Programmiersprachen, kann aber nicht direkt die Analysefähigkeiten von Kieker nutzen
3. Fehlende Interoperabilität: Es fehlt ein effektiver Datentransformationsmechanismus zwischen den beiden Frameworks, was die kombinierte Nutzung ihrer jeweiligen Vorteile einschränkt

Forschungsrelevanz

• Moderne Microservice-Architekturen verwenden typischerweise mehrsprachige Technologie-Stacks und benötigen eine einheitliche Observability-Lösung
• Die Niedrig-Overhead-Vorteile von Kieker und die breite Sprachunterstützung von OpenTelemetry sind komplementär
• Die Realisierung von Interoperabilität kann die jeweiligen Vorteile beider Frameworks vollständig nutzen

Einschränkungen bestehender Methoden

• Fehlende Datentransformationslösung von OpenTelemetry zu Kieker
• Grundlegende Unterschiede zwischen asynchronem und synchronem Tracing-Konzept führen zu Kompatibilitätsproblemen
• Bestehende Tools können nicht gleichzeitig die Analysefähigkeiten von Kieker mit der Mehrsprachunterstützung von OpenTelemetry nutzen

Kernbeiträge

1. Implementierung der Datentransformation von OpenTelemetry zu Kieker, die es ermöglicht, das umfangreiche Agent-Ökosystem von OpenTelemetry im Kieker-Analyse-Framework zu nutzen
2. Lösung der konzeptionellen Unterschiede zwischen asynchronem und synchronem Tracing durch Einführung eines asynchronen Markierungsmechanismus zur Behandlung inkompatibler Kontrollflussdarstellungen
3. Bereitstellung eines vollständigen Feldmapping-Schemas, das die Entsprechung zwischen den beiden Datenformaten etabliert
4. Validierung der Methodenmachbarkeit durch den Astronomy Shop-Anwendungsfall, der die Tracing-Datenanalysefähigkeit mehrsprachiger Microservice-Anwendungen demonstriert

Methodische Details

Aufgabendefinition

Konvertierung von OpenTelemetry-Format-Tracing-Daten (empfangen über gRPC) in das Kieker-Monitoring-Log-Format, damit diese von der Kieker-Analyse-Pipeline verarbeitet werden können und Analyseergebnisse wie Aufrufbäume und Komponentendiagramme generiert werden.

Datenformatanalyse

Kieker-Datenformat

• Verwendung der Instrumentation Record Language (IRL) zur Datenformatdefinition
• Auf Xtext basierende Recordstruktur-Definition
• Unterstützt synchrones Tracing, wobei jeweils nur ein Aufruf ausgeführt werden kann
• Verwendung von Execution Order Index (eoi) und Execution Stack Size (ess) zur Darstellung des Kontrollflusses

OpenTelemetry-Datenformat

• Auf Protobuf-Serialisierung basierendes Standardformat
• Unterstützt die drei Säulen der Observability: Logs, Metriken und Traces
• Traces bestehen aus Spans, wobei jeder Span Namen, Zeitstempel, Attribute usw. enthält
• Unterstützt asynchrones Tracing durch Parent-Child-Beziehungen zur Darstellung des Kontrollflusses

Transformationsmethode

Grundlegende Feldmapping

Etablierung direkter Feldkorrespondenzen:

• startEpochNanos → tin
• endEpochNanos → tout
• name → signature
• Hostname wird durch Attributkombination aus OpenTelemetry-Semantikkonventionen generiert

Kontrollfluss-Transformationsstrategie

Angesichts der grundlegenden Unterschiede zwischen asynchronem und synchronem Tracing wurden vier Lösungsansätze vorgeschlagen:

1. Linearisierung von Traces: Anordnung von Aufrufen nach Aufrufer, führt aber zu erheblich erhöhtem Ressourcenverbrauch
2. Direkte Konvertierung: Umgehung des Monitoring-Logs mit direkter Konvertierung zu ExecutionTrace, zerstört aber die Architektur-Trennung von Kieker
3. Neue asynchrone Record-Typen: Erfordert Umschreiben großer Teile der Analyse-Pipeline
4. Asynchrone Markierungslösung: Hinzufügen von asynchronen Markierungen zu Traces mit spezieller Behandlung während der Analyse

Letztendlich wurde Ansatz 4 gewählt, wobei asynchrone Traces durch das Flag --asynchronousTrace in kieker-trace-analysis behandelt werden.

Technische Innovationen

1. Asynchrone Kompatibilitätsbehandlung: Innovative Lösung der Kompatibilitätsprobleme zwischen zwei verschiedenen Tracing-Modellen durch einen Markierungsmechanismus
2. Semantische Mapping-Strategie: Etablierung intelligenter Mapping-Beziehungen zwischen OpenTelemetry-Semantikkonventionen und Kieker-Feldern
3. Architektur-Erhaltung: Realisierung von Interoperabilität ohne Zerstörung der ursprünglichen Kieker-Architektur

Experimentelle Einrichtung

Test-Anwendung

Verwendung der Astronomy Shop als Demo-Anwendung:

• Standard-Demo-Anwendung von OpenTelemetry
• Enthält 14 Services mit 11 verschiedenen Programmiersprachen
• Enthält .NET- und TypeScript-Services, die Kieker nicht direkt unterstützen kann

Experimentelle Umgebung

• Astronomy Shop mit aktivierter OpenTelemetry-Instrumentierung
• Aktivierung des Kieker-otel-Transformers für Datentransformation
• Verwendung von Kieker-Trace-Analyse-Tools für Visualisierung

Bewertungsmethode

• Validierung der Transformationskorrektheit durch Aufrufbaum-Generierung
• Analyse der Visualisierungseffektivität von Service-übergreifenden Aufrufen
• Validierung der Vollständigkeit von sprachübergreifenden Tracing-Daten

Experimentelle Ergebnisse

Hauptergebnisse

Erfolgreiche Realisierung der Datentransformation von OpenTelemetry zu Kieker mit Generierung einer vollständigen Aufrufbaum-Visualisierung. Abbildung 3 zeigt die Aufrufsbeziehungen zwischen Product Service und Recommendation Service und beweist die Effektivität der Transformationsmethode.

Fallstudie

Durch die tatsächliche Ausführung der Astronomy Shop:

• Erfolgreiche Erfassung von Aufrufsbeziehungen zwischen mehrsprachigen Services
• Der generierte Aufrufbaum zeigt deutlich die Abhängigkeitsbeziehungen zwischen Services
• Validierung der Praktikabilität des asynchronen Tracing-Markierungsmechanismus

Experimentelle Erkenntnisse

1. Auswirkungen struktureller Unterschiede: Das asynchrone Tracing-Modell von OpenTelemetry und das synchrone Modell von Kieker unterscheiden sich grundlegend
2. Effektivität des Markierungsmechanismus: Der asynchrone Markierungsansatz kann komplexe Aufrusmuster von Microservice-Anwendungen effektiv behandeln
3. Sprachübergreifende Unterstützung: Erfolgreiche Erweiterung der Sprachunterstützung von Kieker

Verwandte Arbeiten

Hauptforschungsrichtungen

1. OpenTelemetry-Datenverarbeitung: Weber et al. untersuchten die Interoperabilität zwischen OpenTelemetry und Palladio für Leistungsvorhersage
2. Tracing-Datenkompression: TraceZip schlug ein Kompressionsschema für OpenTelemetry-Daten vor und reduzierte den Speicherbedarf um 33,8%
3. Modelltransformation: Groner et al. untersuchten die Perspektiven von Entwicklern auf Datentransformationen

Vorteile dieses Papers

• Erste Arbeit, die die Transformation von OpenTelemetry zu Kieker realisiert
• Kann vollständige Kieker-Analyse-Prozesse ausführen
• Behält die Niedrig-Overhead-Vorteile von Kieker bei

Schlussfolgerungen und Diskussion

Hauptschlussfolgerungen

1. Erfolgreiche Realisierung der Transformation von OpenTelemetry-Tracing-Daten in das Kieker-Format
2. Lösung der Kompatibilitätsprobleme zwischen den beiden Tracing-Modellen durch den asynchronen Markierungsmechanismus
3. Erweiterung der Sprachunterstützung von Kieker, um die Analyse mehrsprachiger Microservice-Anwendungen zu ermöglichen

Einschränkungen

1. Komplexität der asynchronen Verarbeitung: Manuelle Angabe von asynchronen Markierungen erhöht die Nutzungskomplexität
2. Konzeptionelle Unterschiede: Grundlegende Unterschiede zwischen den beiden Tracing-Modellen begrenzen die vollständige Kompatibilität
3. Leistungsüberlegungen: Das Paper analysiert die Leistungsausgaben des Transformationsprozesses nicht tiefgreifend

Zukünftige Richtungen

1. Vollständige native Unterstützung: Direkte Unterstützung des OpenTelemetry-Datenformats in Kieker
2. Hybrid-Tracing: Kombination der Niedrig-Overhead-Eigenschaften von Kieker mit der breiten Anwendbarkeit von OpenTelemetry
3. Leistungsoptimierung: Untersuchung der Leistungsmerkmale verschiedener Transformationsimplementierungen

Tiefgreifende Bewertung

Stärken

1. Hoher praktischer Wert: Löst das Interoperabilitätsproblem zwischen zwei wichtigen Observability-Frameworks
2. Methodische Innovation: Der asynchrone Markierungsmechanismus löst innovativ die Unterschiede zwischen Tracing-Modellen
3. Ausreichende Validierung: Validierung der Methodenmachbarkeit durch tatsächliche mehrsprachige Anwendungen
4. Architektur-freundlich: Realisierung von Erweiterungen ohne Zerstörung der ursprünglichen Architektur

Schwächen

1. Unzureichende theoretische Analyse: Fehlende theoretische Garantien für Transformationskorrektheit und Vollständigkeit
2. Fehlende Leistungsbewertung: Keine Analyse der Leistungsausgaben des Transformationsprozesses
3. Behandlung von Grenzfällen: Begrenzte Fähigkeit zur Behandlung komplexer asynchroner Szenarien
4. Benutzererfahrung: Manuelle Markierung erhöht die Nutzungskomplexität

Einflussfähigkeit

1. Technischer Beitrag: Bietet wichtige Referenzen für die Interoperabilität von Observability-Tools
2. Praktischer Wert: Kann direkt auf bestehende Microservice-Monitoring-Szenarien angewendet werden
3. Ökosystem-Bedeutung: Fördert die Zusammenarbeit zwischen verschiedenen Observability-Tools

Anwendungsszenarien

• Leistungsüberwachung mehrsprachiger Microservice-Architekturen
• Szenarien, die die breite Unterstützung von OpenTelemetry und die Analysefähigkeiten von Kieker kombinieren müssen
• Fälle, in denen bestehende Kieker-Benutzer die Sprachunterstützung erweitern möchten
• Akademische Szenarien zur Erforschung der Interoperabilität von Observability-Tools

Literaturverzeichnis

Das Paper zitiert 9 verwandte Arbeiten, die wichtige Arbeiten in den Bereichen Observability-Frameworks, Microservice-Anwendungen und Modelltransformation abdecken und eine solide theoretische Grundlage für die Forschung bieten.

Gesamtbewertung: Dies ist ein äußerst praktisches Systemsoftware-Paper, das das Interoperabilitätsproblem zwischen zwei wichtigen Observability-Frameworks löst. Obwohl es Mängel in der theoretischen Analyse und Leistungsbewertung gibt, hat die vorgeschlagene Lösung einen wichtigen praktischen Wert und bietet wertvolle Tools und Methoden für das Microservice-Monitoring-Feld.