لم تعد قابلية الملاحظة مسؤولية فرق موثوقية المواقع وحدها؛ فالمطورون مطالبون increasingly بإضافة traces وlogs وmetrics إلى الشيفرة التي يكتبونها، كي يتمكنوا من تشخيص الأعطال وفهم سلوك التطبيقات قبل وصولها إلى الإنتاج وبعده. في تدوينة منشورة على مدونة CNCF في 25 أغسطس 2026، تعرض Adriana Villela، مديرة مجتمع OpenTelemetry وسفيرة CNCF، وDiana Todea، المعتمِدة في توثيق OpenTelemetry وسفيرة CNCF، مساراً عملياً لتقليل عبء هذه المهمة باستخدام OpenTelemetry.
تنطلق الكاتبتان من اعتراض مألوف لدى المطورين: إضافة Instrumentation تعني شيفرة أخرى يجب صيانتها، وتعقيداً إضافياً واحتمالاً لظهور أخطاء أو دين تقني. لكنهما تربطان هذه الكلفة بمكاسب عملية مباشرة، أبرزها تقليل زمن تصحيح الأخطاء، وتسريع إكمال الميزات ونشرها، وكشف المسارات البطيئة وإعادات المحاولة غير الظاهرة والحالات الطرفية، فضلاً عن تحسين فهم الأنظمة الموزعة. وترى الكاتبتان أن قابلية الملاحظة تساعد أيضاً في تفكيك التطبيقات التي تُنتج بمساعدة أدوات الذكاء الاصطناعي عندما تكون جودتها متفاوتة.
ابدأ بالأتمتة ثم أضف ما ينقص
التوصية الأولى هي استخدام Zero-code instrumentation متى كان متاحاً. تضيف هذه الآلية Instrumentation إلى التطبيق من دون تعديل الشيفرة المصدرية، عبر اعتراض استدعاءات أطر العمل والمكتبات الشائعة وقت التشغيل أو أثناء الترجمة. ووفق المادة، يتوافر هذا النوع من الدعم للغات Java و.NET وPython وJavaScript وPHP وGo.
لا تعتبر الكاتبتان الأتمتة حلاً كاملاً؛ فهي لا تعرف بالضرورة ما هو مهم في منطق التطبيق نفسه. لذلك ينبغي استكمالها بـManual instrumentation لإضافة traces وmetrics وlogs ونقل السياق والسمات الخاصة بالشيفرة. كما تقترحان ممارسة Observability-driven development، أي إضافة قابلية الملاحظة أثناء كتابة الشيفرة الجديدة بدلاً من العودة إليها بعد أيام، حين تكون تفاصيل التصميم أقل حضوراً في ذهن المطور.
ما الذي يستحق القياس؟
- الوحدات المهمة من العمل: أضف spans للطلبات الواردة مثل استدعاءات HTTP، والاتصالات الصادرة بقواعد البيانات وذاكرات التخزين المؤقت وواجهات البرمجة وQueues، إضافة إلى العمليات الحساسة للأعمال. وتحذر المادة من إنشاء span لكل استدعاء صغير، لأن ذلك قد ينتج ضوضاء تخفي الإشارات المهمة.
- الأحداث المؤثرة: استخدم السجلات لتفسير سبب حدوث شيء معين، مع التركيز على الأخطاء، وإخفاقات التحقق، ومسارات إعادة المحاولة والبدائل، وأحداث الأمن مثل فشل المصادقة ورفض الصلاحيات.
- زمن الاستجابة: تساعد مقاييس التأخير في تحديد سبب استغراق طلب معين وقتاً أطول من المعتاد، خصوصاً في مسارات متعددة الخطوات مثل إضافة عنصر إلى سلة التسوق ثم إتمام الشراء.
- الأطر والمكتبات الداخلية: إن Instrumentation للأطر والمكتبات التي طوّرها الفريق نفسه قد تمنح تغطية واسعة، لأن أجزاء كبيرة من التطبيق تمر عبرها.
استخدم الذكاء الاصطناعي كمساعد لا كبديل للمراجعة
ترى الكاتبتان أن أدوات البرمجة المدعومة بالذكاء الاصطناعي قد تختصر وقت استكشاف واجهات OpenTelemetry وSDKs المختلفة، كما يمكن أن تساعد في التعامل مع الشيفرة القديمة. لكن الاستفادة منها تتطلب توجيهاً دقيقاً. وتقترحان تحديد دور المساعد، والهدف، وموقع الشيفرة واللغة المستخدمة، والمخرجات المطلوبة، مع إرفاق روابط التوثيق أو أمثلة الشيفرة ذات الصلة.
كما تنصحان بمطالبة الوكيل بشرح قراراته، واستخدام وكيل آخر بوصفه حكماً لتحدي تلك القرارات عند الإمكان، ثم تكرار المحاولة وتحسين النتائج بدلاً من قبول أول تعديل تقترحه الأداة. هذه التوصيات تعكس رأي الكاتبتين وتجربتهما، وليست ضماناً بأن الشيفرة التي ينتجها الذكاء الاصطناعي ستكون صحيحة أو مناسبة للتطبيق.
مسار محلي لفهم بيانات القياس
لا تكتمل Instrumentation من دون وسيلة لقراءة البيانات الناتجة. تشرح المادة أن OpenTelemetry Collector يعمل كوكيل محايد للمورّدين، يستقبل traces وlogs وmetrics من مصادر متعددة، ويعالجها عند الحاجة، ثم يرسلها إلى وجهة واحدة أو أكثر. ويتكون من Receivers لاستقبال البيانات، وProcessors لتعديل السمات أو إخفائها أو أخذ عينات منها، وExporters لإرسالها، وPipelines لتحديد مسار كل نوع من الإشارات، إضافة إلى Connectors لربط مسارين.
لأغراض التطوير، تقترح المادة إعداداً بسيطاً يستقبل البيانات عبر OTLP باستخدام gRPC أو HTTP، ويصدرها إلى وحدة Debug، مع استخدام SpanMetrics Connector لتحويل مدة الـspan إلى بيانات metrics تساعد في رصد مشكلات التأخير. ثم تستعرض ثلاث أدوات مفتوحة المصدر يمكن تشغيلها مع Collector وDocker Compose: OTel Desktop Viewer لعرض traces، وotel-tui لعرض traces وlogs وmetrics وعلاقات الخدمات عبر واجهة طرفية، وOTel Front لعرض الأنواع الثلاثة نفسها مع لوحة معلومات.
القيود التي يجب حسابها
توضح التجربة أن هذه الأدوات ليست خالية من العوائق. فقد كان إعدادها أكثر سهولة للكاتبتين بفضل خبرتهما السابقة بـOpenTelemetry Collector وDocker، بينما قد يواجه المبتدئون صعوبة أكبر. كما تعتمد الأدوات على مشاريع مفتوحة المصدر تابعة لجهات خارجية، وقد لا تواكب دائماً أحدث إصدارات OpenTelemetry API وSDK أو تحقق تكافؤاً كاملاً في الميزات.
وتبرز المادة تحديات أوسع في النظام البيئي، منها تفاوت نشاط مجموعات الاهتمام الخاصة بكل لغة، وغياب الأتمتة لبعض اللغات مثل Rust وElixir، وكثرة الخيارات بين SDKs وeBPF وInstrumentation وقت الترجمة، إلى جانب مشكلات استقرار الواجهات البرمجية وترقية الاعتماديات وارتفاع Cardinality في بعض السمات.
القراءة التحريرية: القيمة العملية هنا ليست في إضافة أداة جديدة، بل في تحويل قابلية الملاحظة من مهمة مؤجلة إلى جزء من دورة تطوير الشيفرة. يحدد الدليل نقطة بداية منخفضة الاحتكاك، ثم يضع حدوداً واضحة لما لا تستطيع الأتمتة معرفته. غير أن المصدر لا يقدم مقارنة أداء كمية بين الأدوات ولا يثبت أن مساراً واحداً يناسب كل اللغات أو البيئات؛ لذلك ينبغي التعامل مع التوصيات كإطار بدء، مع اختبار الإعدادات ومراجعة حجم البيانات وكلفتها وملاءمتها للتطبيق الفعلي.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.