Взаимодействие между 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 (Software Engineering), astro-ph.IM (Instrumentation and Methods for Astrophysics)
• Дата публикации: 13 октября 2025 г.
• Ссылка на статью: https://arxiv.org/abs/2510.11179

Аннотация

В данной статье рассматривается проблема взаимодействия между фреймворком наблюдаемости Kieker и стандартом OpenTelemetry. Kieker обладает богатыми аналитическими возможностями, но поддерживает только ограниченное количество языков программирования (Java, C, Fortran, Python), в то время как OpenTelemetry предоставляет эталонные реализации для большинства языков программирования, включая C# и JavaScript, которые не поддерживаются Kieker. В статье описывается метод преобразования данных трассировки OpenTelemetry в формат фреймворка Kieker, что позволяет создавать результаты анализа, такие как деревья вызовов, на основе инструментирования OpenTelemetry. Применимость метода подтверждена визуализацией данных трассировки демонстрационного приложения Astronomy Shop.

Исследовательский контекст и мотивация

Определение проблемы

1. Ограничения поддержки языков: Фреймворк Kieker, несмотря на мощные аналитические возможности и низкие накладные расходы, поддерживает только ограниченное количество языков, таких как Java, C, Fortran и Python
2. Требование стандартизации: OpenTelemetry как де-факто стандарт предоставляет реализации агентов для множества языков программирования, но не может напрямую использовать аналитические возможности Kieker
3. Отсутствие взаимодействия: Между двумя фреймворками отсутствует эффективный механизм преобразования данных, что ограничивает возможность комбинированного использования их преимуществ

Значимость исследования

• Современные архитектуры микросервисов обычно используют многоязычные технологические стеки, требующие единого решения для наблюдаемости
• Преимущества низких накладных расходов Kieker и широкой поддержки языков OpenTelemetry являются взаимодополняющими
• Реализация взаимодействия позволит в полной мере использовать преимущества обоих фреймворков

Ограничения существующих подходов

• Отсутствуют решения для преобразования данных из OpenTelemetry в Kieker
• Фундаментальные различия между концепциями асинхронной и синхронной трассировки создают проблемы совместимости
• Существующие инструменты не могут одновременно использовать аналитические возможности Kieker и многоязычную поддержку OpenTelemetry

Основные вклады

1. Реализовано преобразование формата данных из OpenTelemetry в Kieker, позволяющее использовать богатую экосистему агентов OpenTelemetry в аналитическом фреймворке Kieker
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, при котором асинхронные трассировки обрабатываются в kieker-trace-analysis с использованием флага --asynchronousTrace.

Технические инновации

1. Обработка асинхронной совместимости: инновационное решение проблемы совместимости двух различных моделей трассировки с использованием механизма маркировки
2. Стратегия семантического сопоставления: установление интеллектуального соответствия между семантическими соглашениями OpenTelemetry и полями Kieker
3. Сохранение архитектуры: реализация взаимодействия без нарушения исходной архитектуры Kieker

Экспериментальная установка

Тестовое приложение

Использовано Astronomy Shop в качестве демонстрационного приложения:

• Демонстрационное приложение OpenTelemetry по умолчанию
• Содержит 14 сервисов, использующих 11 различных языков программирования
• Включает сервисы на .NET и TypeScript, которые не поддерживаются Kieker напрямую

Экспериментальная среда

• Astronomy Shop с включённым инструментированием OpenTelemetry
• Активированный 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. Полная встроенная поддержка: прямая поддержка формата данных OpenTelemetry в Kieker
2. Гибридная трассировка: комбинирование низких накладных расходов Kieker и широкой применимости OpenTelemetry
3. Оптимизация производительности: исследование производительности различных реализаций преобразования

Глубокая оценка

Преимущества

1. Высокая практическая ценность: решает проблему взаимодействия между двумя важными фреймворками наблюдаемости
2. Методологическая инновативность: механизм асинхронной маркировки инновационно решает проблему различий моделей трассировки
3. Достаточная верификация: применимость метода подтверждена на примере реального многоязычного приложения
4. Архитектурная совместимость: расширение реализовано без нарушения исходной архитектуры

Недостатки

1. Недостаточный теоретический анализ: отсутствуют теоретические гарантии корректности и полноты преобразования
2. Отсутствие оценки производительности: не предоставлен анализ накладных расходов процесса преобразования
3. Ограниченная обработка граничных случаев: ограниченные возможности обработки сложных асинхронных сценариев
4. Пользовательский опыт: необходимость ручной маркировки усложняет использование

Влияние

1. Технический вклад: предоставляет важный ориентир для взаимодействия инструментов наблюдаемости
2. Практическая ценность: может быть непосредственно применено в существующих сценариях мониторинга микросервисов
3. Значение для экосистемы: способствует сотрудничеству между различными инструментами наблюдаемости

Применимые сценарии

• Мониторинг производительности многоязычных архитектур микросервисов
• Сценарии, требующие комбинирования широкой поддержки OpenTelemetry и аналитических возможностей Kieker
• Ситуации, когда существующие пользователи Kieker хотят расширить поддержку языков
• Академические исследования взаимодействия инструментов наблюдаемости

Список литературы

Статья цитирует 9 связанных работ, охватывающих важные исследования в области фреймворков наблюдаемости, приложений микросервисов, преобразования моделей и других смежных областей, обеспечивая прочную теоретическую основу для исследования.

Общая оценка: Это практически ценная статья в области системного программного обеспечения, решающая проблему взаимодействия между двумя важными фреймворками наблюдаемости. Несмотря на недостатки в теоретическом анализе и оценке производительности, предложенное решение имеет значительную практическую ценность и предоставляет ценные инструменты и методы для области мониторинга микросервисов.