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: عرض توضيحي كتصدير من متجر الفلك

المعلومات الأساسية

  • معرّف الورقة: 2510.11179
  • العنوان: التشغيل البيني من OpenTelemetry إلى Kieker: عرض توضيحي كتصدير من متجر الفلك
  • المؤلفون: David Georg Reichelt (جامعة لانكستر لايبزيغ)، Shinhyung Yang (جامعة كيل)، Wilhelm Hasselbring (جامعة كيل)
  • التصنيف: cs.SE (هندسة البرمجيات)، astro-ph.IM (الأدوات والطرق الفيزيائية الفلكية)
  • تاريخ النشر: 13 أكتوبر 2025
  • رابط الورقة: https://arxiv.org/abs/2510.11179

الملخص

تتناول هذه الورقة مشكلة التشغيل البيني بين إطار العمل القابل للمراقبة Kieker والمعيار OpenTelemetry. يتمتع Kieker بقدرات تحليلية غنية لكنه يدعم فقط لغات برمجية محدودة (Java و C و Fortran و Python)، بينما يوفر معيار OpenTelemetry تطبيقات مرجعية لمعظم لغات البرمجة، بما في ذلك C# و JavaScript التي لا يدعمها Kieker. تصف الورقة كيفية تحويل بيانات التتبع من OpenTelemetry إلى صيغة إطار عمل Kieker، مما يتيح إنشاء نتائج تحليلية مثل أشجار الاستدعاء بناءً على الأجهزة المثبتة في OpenTelemetry. تم التحقق من قابلية الطريقة من خلال تصور بيانات التتبع من Astronomy Shop (تطبيق العرض التوضيحي لـ OpenTelemetry).

الخلفية البحثية والدافع

تعريف المشكلة

  1. قيود دعم اللغات: يوفر إطار عمل Kieker قدرات تحليلية قوية وخصائص منخفضة التكلفة، لكنه يدعم فقط لغات محدودة مثل Java و C و Fortran و Python
  2. متطلبات التوحيد القياسي: يعمل OpenTelemetry كمعيار فعلي، ويوفر تطبيقات وكيل لعدة لغات برمجية، لكن لا يمكنه الاستفادة المباشرة من قدرات تحليل Kieker
  3. غياب التشغيل البيني: يفتقد الإطاران إلى آلية تحويل بيانات فعالة، مما يحد من الجمع بين مزايا كل منهما

أهمية البحث

  • تعتمد معمارية الخدمات الدقيقة الحديثة عادة على مكدسات تكنولوجية متعددة اللغات، وتتطلب حلاً موحداً للمراقبة
  • تتمتع مزايا Kieker منخفضة التكلفة ودعم OpenTelemetry الواسع للغات بطبيعة متكاملة
  • يمكن لتحقيق التشغيل البيني أن يستفيد بالكامل من مزايا كل إطار عمل

قيود الطرق الموجودة

  • غياب حل تحويل البيانات من OpenTelemetry إلى Kieker
  • الاختلافات الأساسية بين مفاهيم التتبع غير المتزامن والمتزامن تؤدي إلى تحديات التوافقية
  • لا يمكن للأدوات الموجودة الاستفادة من دعم OpenTelemetry متعدد اللغات مع الحفاظ على قدرات تحليل Kieker

المساهمات الأساسية

  1. تطبيق تحويل صيغة البيانات من OpenTelemetry إلى Kieker، مما يتيح استخدام النظام البيئي الغني للوكلاء في إطار عمل تحليل 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 مراجع ذات صلة، تغطي أعمالاً مهمة في مجالات إطارات العمل القابلة للمراقبة والتطبيقات الدقيقة وتحويل النماذج وغيرها، مما يوفر أساساً نظرياً متيناً للبحث.

التقييم الشامل: هذه ورقة عملية جداً في مجال برمجيات الأنظمة، تحل مشكلة التشغيل البيني بين إطاري عمل مراقبة مهمين. على الرغم من وجود نقاط ضعف في التحليل النظري وتقييم الأداء، فإن الحل المقترح له قيمة عملية مهمة، ويوفر أدوات وطرقاً قيمة لمجال مراقبة الخدمات الدقيقة.