Interopérabilité d'OpenTelemetry à Kieker : Démonstration par Export depuis l'Astronomy Shop

Informations Fondamentales

• ID de l'article : 2510.11179
• Titre : Interopérabilité d'OpenTelemetry à Kieker : Démonstration par Export depuis l'Astronomy Shop
• Auteurs : David Georg Reichelt (Université de Lancaster Leipzig), Shinhyung Yang (Université de Kiel), Wilhelm Hasselbring (Université de Kiel)
• Classification : cs.SE (Génie Logiciel), astro-ph.IM (Instrumentation et Méthodes pour l'Astrophysique)
• Date de publication : 13 octobre 2025
• Lien de l'article : https://arxiv.org/abs/2510.11179

Résumé

Cet article aborde le problème d'interopérabilité entre le cadre d'observabilité Kieker et la norme OpenTelemetry. Bien que Kieker possède des capacités d'analyse riches, il ne supporte qu'un nombre limité de langages de programmation (Java, C, Fortran, Python), tandis que la norme OpenTelemetry fournit des implémentations de référence pour la plupart des langages de programmation, y compris C# et JavaScript, non supportés par Kieker. Cet article décrit comment convertir les données de traçage OpenTelemetry au format du cadre Kieker, permettant ainsi de créer des résultats d'analyse tels que des arbres d'appels basés sur l'instrumentation OpenTelemetry. La viabilité de la méthode a été validée par la visualisation des données de traçage de l'Astronomy Shop (application de démonstration OpenTelemetry).

Contexte et Motivation de la Recherche

Définition du Problème

1. Limitations du support linguistique : Bien que le cadre Kieker offre des capacités d'analyse puissantes et des caractéristiques de faible surcharge, il ne supporte que des langages limités tels que Java, C, Fortran et Python
2. Besoin de normalisation : OpenTelemetry, en tant que norme de facto, fournit des implémentations d'agents pour de nombreux langages de programmation, mais ne peut pas exploiter directement les capacités d'analyse de Kieker
3. Absence d'interopérabilité : L'absence de mécanisme efficace de conversion de données entre les deux cadres limite la combinaison de leurs avantages respectifs

Importance de la Recherche

• Les architectures de microservices modernes adoptent généralement des piles technologiques multilingues, nécessitant une solution d'observabilité unifiée
• L'avantage de faible surcharge de Kieker et le support linguistique étendu d'OpenTelemetry sont complémentaires
• La réalisation de l'interopérabilité peut exploiter pleinement les avantages respectifs des deux cadres

Limitations des Approches Existantes

• Absence de solution de conversion de données d'OpenTelemetry vers Kieker
• Les différences fondamentales entre les concepts de traçage asynchrone et synchrone créent des défis de compatibilité
• Les outils existants ne peuvent pas exploiter le support multilingue d'OpenTelemetry tout en conservant les capacités d'analyse de Kieker

Contributions Principales

1. Implémentation de la conversion de format de données d'OpenTelemetry vers Kieker, permettant l'utilisation du riche écosystème d'agents d'OpenTelemetry dans le cadre d'analyse Kieker
2. Résolution des différences conceptuelles entre traçage asynchrone et synchrone, par l'introduction d'un mécanisme de marquage asynchrone pour gérer les représentations de flux de contrôle incompatibles
3. Fourniture d'un schéma complet de mappage de champs, établissant les correspondances entre les deux formats de données
4. Validation de la viabilité de la méthode via le cas d'étude Astronomy Shop, démontrant les capacités d'analyse des données de traçage d'applications de microservices multilingues

Explication Détaillée de la Méthode

Définition de la Tâche

Convertir les données de traçage au format OpenTelemetry (reçues via gRPC) au format de journal de surveillance Kieker, de sorte qu'elles puissent être traitées par le pipeline d'analyse Kieker et générer des résultats d'analyse tels que des arbres d'appels et des diagrammes de composants.

Analyse du Format de Données

Format de Données Kieker

• Utilise le langage de définition d'enregistrements (IRL) pour définir le format des données
• Structure d'enregistrement définie basée sur Xtext
• Supporte le traçage synchrone, avec une seule exécution d'appel à la fois
• Utilise l'indice d'ordre d'exécution (eoi) et la taille de la pile d'exécution (ess) pour représenter le flux de contrôle

Format de Données OpenTelemetry

• Format standard basé sur la sérialisation protobuf
• Supporte les trois piliers de l'observabilité : journaux, métriques et traçage
• Le traçage est composé de spans, chaque span contenant un nom, des horodatages, des attributs, etc.
• Supporte le traçage asynchrone, avec le flux de contrôle représenté par les relations parent-enfant

Méthode de Conversion

Mappage de Champs Fondamental

Établit les correspondances de champs directs :

• startEpochNanos → tin
• endEpochNanos → tout
• name → signature
• Le nom d'hôte est généré par la combinaison d'attributs des conventions sémantiques d'OpenTelemetry

Stratégie de Conversion du Flux de Contrôle

Face aux différences fondamentales entre traçage asynchrone et synchrone, quatre solutions ont été proposées :

1. Linéarisation du traçage : Arrange les appels selon l'appelant, mais augmente considérablement l'utilisation des ressources
2. Conversion directe : Contourne le journal de surveillance pour convertir directement en ExecutionTrace, mais rompt la séparation architecturale de Kieker
3. Ajout de nouveaux types d'enregistrements asynchrones : Nécessite la réécriture d'une grande partie du pipeline d'analyse
4. Schéma de marquage asynchrone : Ajoute un marquage asynchrone au traçage, traité spécialement lors de l'analyse

La solution 4 a finalement été choisie, avec le traitement du traçage asynchrone via le drapeau --asynchronousTrace dans kieker-trace-analysis.

Points d'Innovation Technique

1. Traitement de la compatibilité asynchrone : Résout de manière innovante les problèmes de compatibilité entre deux modèles de traçage différents par un mécanisme de marquage
2. Stratégie de mappage sémantique : Établit une relation de mappage intelligente entre les conventions sémantiques d'OpenTelemetry et les champs de Kieker
3. Préservation architecturale : Réalise l'interopérabilité sans compromettre l'architecture existante de Kieker

Configuration Expérimentale

Application de Test

Utilise Astronomy Shop comme application de démonstration :

• Application de démonstration par défaut d'OpenTelemetry
• Contient 14 services utilisant 11 langages de programmation différents
• Inclut des services .NET et TypeScript non directement supportés par Kieker

Environnement Expérimental

• Astronomy Shop avec instrumentation OpenTelemetry activée
• Activation du transformateur Kieker-otel pour la conversion de données
• Utilisation des outils d'analyse de traçage Kieker pour la visualisation

Méthode d'Évaluation

• Vérification de la correction de la conversion par la génération d'arbres d'appels
• Analyse de l'efficacité de la visualisation des relations d'appels entre services
• Vérification de l'intégrité des données de traçage multilingues

Résultats Expérimentaux

Résultats Principaux

La conversion réussie des données d'OpenTelemetry vers Kieker a été réalisée, générant une visualisation complète de l'arbre d'appels. La Figure 3 montre les relations d'appels entre le service de produits et le service de recommandations, prouvant l'efficacité de la méthode de conversion.

Analyse de Cas

Par l'exécution réelle d'Astronomy Shop :

• Capture réussie des relations d'appels entre services multilingues
• L'arbre d'appels généré affiche clairement les dépendances entre services
• Validation de l'utilité pratique du mécanisme de marquage de traçage asynchrone

Découvertes Expérimentales

1. Impact des différences structurelles : Le modèle de traçage asynchrone d'OpenTelemetry et le modèle synchrone de Kieker présentent des différences fondamentales
2. Efficacité du mécanisme de marquage : Le schéma de marquage asynchrone gère efficacement les modèles d'appels complexes des applications de microservices
3. Support multilingue : Extension réussie du support linguistique de Kieker

Travaux Connexes

Directions de Recherche Principales

1. Traitement des données OpenTelemetry : Weber et al. ont étudié l'interopérabilité entre OpenTelemetry et Palladio pour la prédiction de performance
2. Compression des données de traçage : TraceZip propose un schéma de stockage compressé pour les données OpenTelemetry, réduisant les besoins en mémoire de 33,8 %
3. Transformation de modèles : Groner et al. ont étudié les perspectives des développeurs sur la transformation de modèles de données

Avantages de Cet Article

• Premier travail implémentant la conversion d'OpenTelemetry vers Kieker
• Capable d'exécuter le pipeline d'analyse Kieker complet
• Préserve l'avantage de faible surcharge de Kieker

Conclusion et Discussion

Conclusions Principales

1. Conversion réussie des données de traçage OpenTelemetry au format Kieker
2. Résolution des problèmes de compatibilité entre les deux modèles de traçage par un mécanisme de marquage asynchrone
3. Extension des capacités de support linguistique de Kieker, permettant l'analyse d'applications de microservices multilingues

Limitations

1. Complexité du traitement asynchrone : Nécessite la spécification manuelle du marquage asynchrone, augmentant la complexité d'utilisation
2. Différences conceptuelles : Les différences fondamentales entre les deux modèles de traçage limitent la compatibilité complète
3. Considérations de performance : L'article n'analyse pas en profondeur la surcharge de performance du processus de conversion

Directions Futures

1. Support natif complet : Support direct du format de données OpenTelemetry dans Kieker
2. Traçage hybride : Combinaison de la faible surcharge de Kieker et de l'applicabilité étendue d'OpenTelemetry
3. Optimisation de performance : Étude des performances de différentes implémentations de conversion

Évaluation Approfondie

Points Forts

1. Valeur pratique élevée : Résout le problème d'interopérabilité entre deux cadres d'observabilité importants
2. Innovation méthodologique : Le mécanisme de marquage asynchrone résout de manière innovante les différences de modèles de traçage
3. Validation suffisante : La viabilité de la méthode est validée par une application multilingue réelle
4. Convivialité architecturale : L'extension est réalisée sans compromettre l'architecture existante

Insuffisances

1. Analyse théorique insuffisante : Manque de garanties théoriques sur la correction et l'exhaustivité de la conversion
2. Évaluation de performance absente : Aucune analyse fournie de la surcharge de performance du processus de conversion
3. Traitement des cas limites : Capacités limitées dans le traitement de scénarios asynchrones complexes
4. Expérience utilisateur : Le marquage manuel augmente la complexité d'utilisation

Impact

1. Contribution technique : Fournit une référence importante pour l'interopérabilité des outils d'observabilité
2. Valeur pratique : Peut être directement appliqué aux scénarios de surveillance de microservices existants
3. Signification écosystémique : Favorise la collaboration entre différents outils d'observabilité

Scénarios Applicables

• Surveillance de performance d'architectures de microservices multilingues
• Scénarios nécessitant de combiner le support étendu d'OpenTelemetry et les capacités d'analyse de Kieker
• Cas où les utilisateurs existants de Kieker souhaitent étendre le support linguistique
• Contextes académiques étudiant l'interopérabilité des outils d'observabilité

Références

L'article cite 9 références pertinentes, couvrant des travaux importants dans les domaines des cadres d'observabilité, des applications de microservices et de la transformation de modèles, fournissant une base théorique solide pour la recherche.

Évaluation Globale : Cet article est un travail de génie logiciel très pratique qui résout le problème d'interopérabilité entre deux cadres d'observabilité importants. Bien qu'il présente des insuffisances en analyse théorique et évaluation de performance, la solution proposée possède une valeur pratique importante et fournit des outils et des méthodes précieuses pour le domaine de la surveillance des microservices.