2025-11-17T13:07:13.610318

Interoperability From OpenTelemetry to Kieker: Demonstrated as Export from the Astronomy Shop

Reichelt, Yang, Hasselbring
The observability framework Kieker provides a range of analysis capabilities, but it is currently only able to instrument a smaller selection of languages and technologies, including Java, C, Fortran, and Python. The OpenTelemetry standard aims for providing reference implementations for most programming languages, including C# and JavaScript, that are currently not supported by Kieker. In this work, we describe how to transform OpenTelemetry tracing data into the Kieker framework. Thereby, it becomes possible to create for example call trees from OpenTelemetry instrumentations. We demonstrate the usability of our approach by visualizing trace data of the Astronomy Shop, which is an OpenTelemetry demo application.
academic

OpenTelemetryからKiekerへの相互運用性：Astronomy Shopからのエクスポートとして実証

基本情報

  • 論文ID: 2510.11179
  • タイトル: Interoperability From OpenTelemetry to Kieker: Demonstrated as Export from the Astronomy Shop
  • 著者: David Georg Reichelt (Lancaster University Leipzig)、Shinhyung Yang (Kiel University)、Wilhelm Hasselbring (Kiel University)
  • 分類: cs.SE (ソフトウェアエンジニアリング)、astro-ph.IM (天文学計測・方法論)
  • 発表日: 2025年10月13日
  • 論文リンク: https://arxiv.org/abs/2510.11179

要旨

本論文は、可観測性フレームワークKiekerとOpenTelemetry標準間の相互運用性の問題に対処している。Kiekerは豊富な分析能力を備えているが、Java、C、Fortran、Pythonに限定されたプログラミング言語のみをサポートしている一方、OpenTelemetry標準はKiekerがサポートしていないC#やJavaScriptを含む大多数のプログラミング言語に対して参照実装を提供している。本論文は、OpenTelemetryトレースデータをKiekerフレームワーク形式に変換する方法を説明し、OpenTelemetryインストルメンテーションに基づいてコールツリーなどの分析結果を生成できるようにしている。Astronomy Shop（OpenTelemetryデモアプリケーション）のトレースデータ可視化を通じて、本手法の有用性が検証されている。

研究背景と動機

問題定義

  1. 言語サポートの制限：Kiekerフレームワークは強力な分析能力と低オーバーヘッド特性を提供しているが、Java、C、Fortran、Pythonなどの限定されたプログラミング言語のみをサポートしている
  2. 標準化の必要性：OpenTelemetryは事実上の標準として、複数のプログラミング言語にエージェント実装を提供しているが、Kiekerの分析能力を直接活用することができない
  3. 相互運用性の欠如：両フレームワーク間に効果的なデータ変換メカニズムが存在せず、各々の利点の組み合わせ使用が制限されている

研究の重要性

  • 現代的なマイクロサービスアーキテクチャは通常、複数言語の技術スタックを採用しており、統一された可観測性ソリューションが必要である
  • Kiekerの低オーバーヘッド利点とOpenTelemetryの広範な言語サポートは相補的である
  • 相互運用性の実装により、両フレームワークの各々の利点を最大限に活用できる

既存手法の制限

  • OpenTelemetryからKiekerへのデータ変換スキームが存在しない
  • 非同期トレースと同期トレースの概念的な根本的差異が互換性の課題をもたらしている
  • 既存ツールはKiekerの分析能力を維持しながらOpenTelemetryの複数言語サポートを利用することができない

核心的貢献

  1. OpenTelemetryからKiekerへのデータ形式変換を実装し、Kiekerの分析フレームワークでOpenTelemetryの豊富なエージェントエコシステムを使用できるようにした
  2. 非同期トレースと同期トレースの概念的差異を解決し、非互換な制御フロー表現を処理するための非同期マーキングメカニズムを導入した
  3. 完全なフィールドマッピングスキームを提供し、両データ形式間の対応関係を確立した
  4. Astronomy Shopケーススタディを通じて手法の実行可能性を検証し、複数言語マイクロサービスアプリケーションのトレースデータ分析能力を実証した

方法論の詳細

タスク定義

OpenTelemetry形式のトレースデータ（gRPCを通じて受信）をKiekerモニタリングログ形式に変換し、Kiekerの分析パイプラインで処理でき、コールツリーやコンポーネント図などの分析結果を生成できるようにする。

データ形式分析

Kiekerデータ形式

  • インストルメンテーション記録言語(IRL)を使用してデータ形式を定義
  • Xtextに基づいてレコード構造を定義
  • 同期トレースをサポートし、一度に1つの呼び出し実行のみが可能
  • 実行順序インデックス(eoi)と実行スタックサイズ(ess)を使用して制御フローを表現

OpenTelemetryデータ形式

  • protobufシリアライゼーションに基づく標準形式
  • ログ、メトリクス、トレースの3つの可観測性の柱をサポート
  • トレースはスパンで構成され、各スパンには名前、タイムスタンプ、属性などが含まれる
  • 非同期トレースをサポートし、親子関係を通じて制御フローを表現

変換方法

基本フィールドマッピング

直接的なフィールド対応関係を確立：

  • startEpochNanos → tin
  • endEpochNanos → tout
  • name → signature
  • ホスト名はOpenTelemetryセマンティック規約の属性組み合わせから生成

制御フロー変換戦略

非同期トレースと同期トレースの根本的差異に直面して、4つのソリューション案を提案：

  1. トレースの線形化：呼び出しを呼び出し元で配列するが、リソース使用量が大幅に増加
  2. 直接変換：モニタリングログをスキップしてExecutionTraceに直接変換するが、Kiekerのアーキテクチャ分離を破壊
  3. 新しい非同期レコードタイプの追加：多数の分析パイプラインの書き直しが必要
  4. 非同期マーキング方案：トレースに非同期マーキングを追加し、分析時に特別処理

最終的に方案4を選択し、kieker-trace-analysisで--asynchronousTraceフラグを通じて非同期トレースを処理。

技術的革新点

  1. 非同期互換性処理：マーキングメカニズムを通じて2つの異なるトレースモデルの互換性問題を革新的に解決
  2. セマンティックマッピング戦略：OpenTelemetryセマンティック規約とKiekerフィールド間のインテリジェントなマッピング関係を確立
  3. アーキテクチャ保持性：Kiekerの既存アーキテクチャを破壊することなく相互運用性を実現

実験設定

テストアプリケーション

Astronomy Shopをデモンストレーションアプリケーションとして使用：

  • OpenTelemetryのデフォルトデモアプリケーション
  • 14個のサービスを含み、11種類の異なるプログラミング言語を使用
  • Kiekerが直接サポートできない.NETおよびTypeScriptサービスを含む

実験環境

  • OpenTelemetryインストルメンテーションが有効なAstronomy Shop
  • Kieker-otel-transformerを起動してデータ変換を実行
  • Kiekerトレース分析ツールを使用して可視化

評価方法

  • コールツリー生成を通じて変換の正確性を検証
  • 複数サービス間の呼び出し関係可視化効果を分析
  • クロス言語トレースデータの完全性を検証

実験結果

主要な結果

OpenTelemetryからKiekerへのデータ変換を正常に実装し、完全なコールツリー可視化を生成した。図3は製品サービスと推奨サービス間の呼び出し関係を示し、変換方法の有効性を証明している。

ケース分析

Astronomy Shopの実際の実行を通じて：

  • 複数言語サービス間の呼び出し関係を正常に捕捉
  • 生成されたコールツリーはサービス間の依存関係を明確に表示
  • 非同期トレースマーキングメカニズムの実用性を検証

実験的発見

  1. 構造的差異の影響：OpenTelemetryの非同期トレースモデルとKiekerの同期モデルには根本的な差異が存在
  2. マーキングメカニズムの有効性：非同期マーキング方案はマイクロサービスアプリケーションの複雑な呼び出しパターンを効果的に処理可能
  3. クロス言語サポート：Kiekerの言語サポート範囲を正常に拡張

関連研究

主要な研究方向

  1. OpenTelemetryデータ処理：Weberら等はOpenTelemetryとPalladioの相互運用性を研究し、性能予測に使用
  2. トレースデータ圧縮：TraceZipはOpenTelemetryデータの圧縮ストレージスキームを提案し、メモリ需要を33.8%削減
  3. モデル変換：Gronerら等は開発者のデータモデル変換に対する見方を研究

本論文の利点

  • OpenTelemetryからKiekerへの変換を実装した最初の研究
  • 完全なKieker分析フローを実行可能
  • Kiekerの低オーバーヘッド利点を維持

結論と考察

主要な結論

  1. OpenTelemetryトレースデータからKieker形式への変換を正常に実装
  2. 非同期マーキングメカニズムを通じて2つのトレースモデルの互換性問題を解決
  3. Kiekerの言語サポート能力を拡張し、複数言語マイクロサービスアプリケーションの分析を可能にした

制限事項

  1. 非同期処理の複雑性：非同期マーキングを手動で指定する必要があり、使用の複雑性が増加
  2. 概念的差異：2つのトレースモデルの根本的差異が完全な互換性を制限
  3. 性能考慮：論文は変換プロセスの性能オーバーヘッドの深い分析を行っていない

今後の方向

  1. 完全なネイティブサポート：KiekerでOpenTelemetryデータ形式を直接サポート
  2. ハイブリッドトレース：Kiekerの低オーバーヘッドとOpenTelemetryの広範な適用性を組み合わせ
  3. 性能最適化：異なる変換実装の性能表現を研究

深層的評価

利点

  1. 実用価値が高い：2つの重要な可観測性フレームワーク間の相互運用性問題を解決
  2. 方法の革新性：非同期マーキングメカニズムはトレースモデルの差異を革新的に解決
  3. 検証が十分：実際の複数言語アプリケーションを通じて手法の実行可能性を検証
  4. アーキテクチャ親和性：既存アーキテクチャを破壊することなく拡張を実現

不足点

  1. 理論分析の不足：変換の正確性と完全性に関する理論的保証が欠如
  2. 性能評価の欠落：変換プロセスの性能オーバーヘッド分析が提供されていない
  3. エッジケース処理：複雑な非同期シナリオへの処理能力が限定的
  4. ユーザー体験：手動マーキングが必要で使用の複雑性が増加

影響力

  1. 技術的貢献：可観測性ツール相互運用性に重要な参考を提供
  2. 実用価値：既存のマイクロサービス監視シナリオに直接適用可能
  3. エコシステム意義：異なる可観測性ツール間の協力を促進

適用シナリオ

  • 複数言語マイクロサービスアーキテクチャの性能監視
  • OpenTelemetryの広範なサポートとKiekerの分析能力を組み合わせる必要があるシナリオ
  • 既存Kiekerユーザーが言語サポートを拡張したい場合
  • 可観測性ツール相互運用性を研究する学術シナリオ

参考文献

論文は可観測性フレームワーク、マイクロサービスアプリケーション、モデル変換などの関連分野の重要な研究を網羅する9篇の関連文献を引用しており、研究に堅実な理論的基礎を提供している。

総合評価：これは実用性が非常に高いシステムソフトウェア論文であり、2つの重要な可観測性フレームワーク間の相互運用性問題を解決している。理論分析と性能評価の面で不足がある一方で、提案されたソリューションは重要な実用価値を持ち、マイクロサービス監視分野に価値あるツールと方法を提供している。