Interoperability From OpenTelemetry to Kieker: Demonstrated as Export from the 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 (Software Engineering), astro-ph.IM (Instrumentation and Methods for Astrophysics)
• 发表时间: 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定义记录结构
• 支持同步追踪，每次只能有一个调用执行
• 使用执行顺序索引(eoi)和执行栈大小(ess)表示控制流

OpenTelemetry数据格式

• 基于protobuf序列化的标准格式
• 支持日志、指标和追踪三大可观测性支柱
• 追踪由spans组成，每个span包含名称、时间戳、属性等
• 支持异步追踪，通过父子关系表示控制流

转换方法

基础字段映射

建立了直接的字段对应关系：

• startEpochNanos → tin
• endEpochNanos → tout
• name → signature
• 主机名通过OpenTelemetry语义约定中的属性组合生成

控制流转换策略

面对异步追踪与同步追踪的根本差异，提出了四种解决方案：

1. 线性化追踪：将调用按调用者排列，但会大幅增加资源使用
2. 直接转换：跳过监控日志直接转换为ExecutionTrace，但破坏了Kieker的架构分离
3. 新增异步记录类型：需要重写大量分析管道
4. 异步标记方案：为追踪添加异步标记，在分析时特殊处理

最终选择方案4，通过--asynchronousTrace标志在kieker-trace-analysis中处理异步追踪。

技术创新点

1. 异步兼容性处理：创新性地通过标记机制解决了两种不同追踪模型的兼容性问题
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. 通过异步标记机制解决了两种追踪模型的兼容性问题
3. 扩展了Kieker的语言支持能力，使其能够分析多语言微服务应用

局限性

1. 异步处理复杂性：需要手动指定异步标记，增加了使用复杂度
2. 概念差异：两种追踪模型的根本差异限制了完全兼容性
3. 性能考量：论文未深入分析转换过程的性能开销

未来方向

1. 完全原生支持：在Kieker中直接支持OpenTelemetry数据格式
2. 混合追踪：结合Kieker的低开销和OpenTelemetry的广泛适用性
3. 性能优化：研究不同转换实现的性能表现

深度评价

优点

1. 实用价值高：解决了两个重要可观测性框架间的互操作性问题
2. 方法创新性：异步标记机制创新性地解决了追踪模型差异
3. 验证充分：通过实际的多语言应用验证了方法可行性
4. 架构友好：在不破坏原有架构的前提下实现了扩展

不足

1. 理论分析不足：缺乏对转换正确性和完整性的理论保证
2. 性能评估缺失：未提供转换过程的性能开销分析
3. 边界案例处理：对复杂异步场景的处理能力有限
4. 用户体验：需要手动标记增加了使用复杂度

影响力

1. 技术贡献：为可观测性工具互操作性提供了重要参考
2. 实用价值：能够直接应用于现有的微服务监控场景
3. 生态意义：促进了不同可观测性工具间的协作

适用场景

• 多语言微服务架构的性能监控
• 需要结合OpenTelemetry广泛支持和Kieker分析能力的场景
• 现有Kieker用户希望扩展语言支持的情况
• 研究可观测性工具互操作性的学术场景

参考文献

论文引用了9篇相关文献，涵盖了可观测性框架、微服务应用、模型转换等相关领域的重要工作，为研究提供了坚实的理论基础。

总体评价：这是一篇实用性很强的系统软件论文，解决了两个重要可观测性框架间的互操作性问题。虽然在理论分析和性能评估方面存在不足，但其提出的解决方案具有重要的实用价值，为微服务监控领域提供了有价值的工具和方法。