تسجيل OpenTelemetry: المقدمة

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

فبفضل نموذج البيانات المهيكل والمستقل عن الموردين، يمكن لأدوات قابلية الملاحظة تحليل السجلات بسهولة وموثوقية أكبر وإرفاق البيانات الوصفية وربط السجلات بالمقاييس والتتبعات لتحقيق رؤية شاملة وعميقة.

يتيح تسجيل OTel للمؤسسات إمكانية التبديل بين منصات قابلية الملاحظة أو الجمع بينها دون الحاجة إلى إعادة تهيئة البنية التحتية بالكامل، ولهذا السبب أصبح هو المعيار الصناعي المعتمد في الأنظمة السحابية الأصلية الحديثة. تساعد هذه القدرات فرق تكنولوجيا المعلومات ومهندسي موثوقية الموقع (SREs) على تجنب فجوات قابلية الملاحظة ومشكلات تشتت البيانات التي تحدث عندما يمتلك كل مورد أو تقنية مخطط تسجيل وبروتوكولات نقل خاصة به.

كما يُسهِّل تسجيل OTel الربط التلقائي بين الإشارات المختلفة، ما يحسن بشكل كبير من عمليات تصحيح الأخطاء ويقلل من الاحتكار لمنتج معين في قابلية الملاحظة.

تُعد سجلات OpenTelemetry عنصرًا حيويًا من OpenTelemetry. OpenTelemetry هو إطار عمل مفتوح المصدر لقابلية الملاحظة، ويتضمن مجموعة من أدوات تطوير البرمجيات (SDKs) وواجهات برمجة التطبيقات (APIs) المستقلة عن الموردين، وأدوات أخرى لتهيئة التطبيقات والأنظمة والأجهزة.

سابقًا، كان رمز التهيئة يختلف بشكل كبير من نظام لآخر، ولم يكن هناك مورد تجاري واحد يقدم أداة قادرة على جمع البيانات من كل تطبيق وخدمة على الشبكة. هذه الفجوة الوظيفية جعلت من الصعب (بل ومن المستحيل غالبًا) على الفرق جمع البيانات من لغات برمجة وتنسيقات وبيئات أوقات تشغيل مختلفة.

كما جعلت أساليب قابلية الملاحظة التقليدية من عملية تغيير البنية التحتية والمكونات الخلفية عملية مستهلكة للوقت والجهد.

فعلى سبيل المثال، إذا أراد فريق تطوير استبدال الأدوات الخلفية، كان يتعين عليه إعادة تهيئة التعليمات البرمجية بالكامل وتكوين وكلاء جدد (وهي مكونات برمجية تنفذ مهام البناء والإصدار الآلية) لإرسال بيانات القياس عن بُعد إلى الخوادم الجديدة. وقد أدت هذه الأساليب المجزأة إلى خلق صوامع بيانات وحالة من الارتباك، ما جعل حل مشكلات الأداء بفعالية أمرًا معقدًا.

مثَّل OpenTelemetry تقدُّمًا كبيرًا في أدوات قابلية الملاحظة؛ لأنه قام بتوحيد الطريقة التي يتم بها جمع بيانات القياس عن بُعد إلى الأنظمة الخلفية وتحليلها ونقلها. فقد قدم حلاً مفتوح المصدر—قائمًا على معايير يقودها المجتمع—لجمع البيانات حول سلوك النظام وأمنه، ما ساعد الفرق على تبسيط عمليات المراقبة وقابلية الملاحظة في المنظومات الموزعة.

يعتمد تسجيل OpenTelemetry على مجموعة من المكونات المتكاملة التي تعمل معًا لإنشاء سجلات الأحداث وهيكلتها ونقلها وتسليمها ضمن مسار موحد لقابلية الملاحظة. وتتضمن ما يلي:

يُعد السجل بنية بيانات مركزية تمثل حدثًا واحدًا في OpenTelemetry. وهو يتبع نموذج بيانات قياسيًا يحدد الحقول والدلالات، بحيث يمكن تفسير السجلات من لغات وأنظمة مختلفة بشكل متسق من خلال الواجهات الخلفية.

وتظهر هذه السجلات كصفوف مهيكلة في جدول بيانات تصف حدثًا معينًا وتجيب عن أسئلة جوهرية مثل: "ماذا حدث" "متى حدث" "ما مدى أهمية الحدث" و"ما مصدره."

يُعد نموذج بيانات السجل القالب الشائع الذي يتبعه كل سجل، عبر اللغات والأنظمة. وهو يحدد الحقول الأساسية ومعنى كل منها.

ويتطلب هذا النموذج عادةً أن تتضمن السجلات ما يلي:

• الطابع الزمني والطابع الزمني المرصود (وقت وقوع الحدث ومتى تمت رؤيته)

• أرقام الخطورة ونص الخطورة (يسمى أيضًا مستوى السجل)، الذي يصف مستوى خطورة الحدث

• النص الأساسي (رسالة السجل الرئيسية، غالبًا ما تكون سلسلة قصيرة أو كائن JSON)

• السمات، التي تضيف تفاصيل أدق حول كل حدث (مثل تفاصيل المستخدم أو HTTP)

• معلومات الموارد التي تحدد الخدمة المنبعثة وبيئة النشر

• معرفات التتبع ومعرفات النطاق التي تربط الحدث بطلب محدد (تبسط ربط البيانات)

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

ونظرًا إلى أن نموذج السجلات هذا مفتوح ويقوده المجتمع، فإن أدوات التهيئة ومسارات السجلات في OTel تتميز بقابليتها للنقل (أي أنها غير مرتبطة بمنتج برمجي معين كخدمة (SaaS) أو وكيل خاص). فهي تعمل عبر مختلف أطر العمل والمنصات، وهو أمر ذو قيمة خاصة في بيئات الخدمات المصغرة التي تستخدم لغات برمجة متعددة.

المُسجِّل هو الكائن المسؤول عن كتابة سجلات الأحداث، وهو مشابه لمثيلات المسجلات في أطر العمل الأخرى (مثل Java وPython). عندما تصدر منصة قابلية الملاحظة أمرًا مثل "سجل هذا الخطأ" أو "سجل رسالة المعلومات هذه"، فإنها ترسل الرسالة فعليًا إلى المُسجِّل.

يمكن للأجزاء المختلفة من التطبيق أو النظام أن تطلب مُسجِّلات خاصة بها (على سبيل المثال: مُسجِّل خاص بعمليات "الدفع" وآخر لعمليات "تسجيل الخروج")، ومع ذلك، تتبع جميع هذه المُسجِّلات القواعد نفسها لتوليد السجلات.

يتم الحصول على المُسجِّلات من مزود المُسجِّلات، وهو المسؤول عن إنشاء المُسجِّلات وتهيئتها بالسمات والمصدرين والمسار الصحيح.​ فعندما تطلب التعليمات البرمجية "مُسجِّلاً"، يقوم المزود بتقديم مُسجِّل مهيأ مسبقًا بشكل مناسب.

يتيح هذا التصميم للأجزاء المختلفة من النظام استخدام مُسجِّلات متنوعة، لكنها تظل تشترك في تكوين موحد وتدار جميعًا بشكل مركزي من قبل مزود المُسجِّلات. كما يُسهل هذا التصميم على فرق تكنولوجيا المعلومات استبدال آليات التنفيذ وتعديل سلوك تسجيل البيانات بشكل شامل دون الحاجة إلى التعديل في كل موضع يتم فيه استدعاء المُسجِّل.

تُعَد OTel Collector خدمة منفصلة تستقبل بيانات القياس عن بُعد وتعالجها وتصدرها—بما في ذلك سجلات الأحداث—من العديد من المصادر. ترسل التطبيقات سجلاتها (وتتبعاتها ومقاييسها) إلى Collector، الذي يمكنه استقبال البيانات بصيغ مختلفة وتوحيدها، ثم إرسالها إلى واجهة خلفية أو أكثر.

تدعم خدمات Collector مسارات السجلات المخصصة المبنية حول ثلاثة مكونات فرعية رئيسية: أجهزة الاستقبال والمعالجات والمصدرين.

تتولى أجهزة الاستقبال مهمة استيعاب السجلات من مدخلات متنوعة، مثل تدفقات OpenTelemtetry Protocol (OTLP) وملفات السجلات التي يتم تتبعها عبر أجهزة استقبال مراقبة الملفات. وتجري المعالجات عمليات تقنية حيوية على تلك السجلات، مثل التجميع وتعديل السمات وإثراء السياق (مثل إضافة البيانات الوصفية الخاصة بحجيرات Kubernetes)، فضلاً عن تصفية السجلات وأخذ العينات منها. وفي المرحلة الأخيرة، يوجه المُصدّرن داخل Collector السجلات المُعالَجة إلى وجهة نهائية واحدة أو أكثر.

يوجد مُصدّرو سجلات الأحداث ضمن مجمّع OTel Collector أو مجموعة تطوير البرمجيات (SDK) الخاصة بالتطبيق، ويحددون وجهة بيانات القياس عن بُعد وكيفية تسليمها إلى الأنظمة الخلفية.

فبمجرد قيام مجموعة تطوير برمجيات السجلات (SDK) بإنشاء السجل ومعالجته، يقوم المُصدّر بتشفير نموذج بيانات السجل وتحويله إلى بروتوكول أو تنسيق محدد، ثم يرسله إلى "مستهلك" (Consumer) في المراحل النهائية. قد يشمل هؤلاء المستهلكون OTel Collectors أو حلول قابلية الملاحظة أو مخازن البيانات مفتوحة المصدر على سبيل المثال.

يمكن أن يعمل المُصدّرون وفق آلية الدفع أو السحب، كما يمكن استبدالهم أو الجمع بينهم لإرسال سجلات الأحداث نفسها في آن واحد إلى أنظمة خلفية مختلفة من دون تعديل التعليمات البرمجية للتطبيق. وهذه المرونة التي يوفرها المُصدّرون تسهل على المؤسسات تطوير بنية قابلية الملاحظة لديها مع تغير المتطلبات.

تعمل واجهة برمجة تطبيقات السجلات ومجموعة تطوير برمجيات السجلات (SDK) تمامًا مثل المقبس في وصلة الكهرباء: تمثل واجهة برمجة تطبيقات نوع المقبس، بينما تمثل مجموعة تطوير البرمجيات (SDK) الوصلة الكهربائية التي تنقل الكهرباء فعليًا.

تتكون واجهات برمجة تطبيقات OpenTelemetry من مجموعة من الوظائف التي تستدعيها مكتبات التعليمات البرمجية والتسجيل لإنشاء إدخالات سجلات موحدة. بشكل أساسي، تحدد واجهة برمجة تطبيقات السجلات "الشكل" الذي يجب أن يتخذه السجل لكي "يتم توصيله" بـ OTel. تساعد واجهة برمجة تطبيقات السجلات في ضمان بقاء استدعاءات واجهة برمجة التطبيقات نفسها فعالة وناجحة بغض النظر عن النظام الخلفي لقابلية الملاحظة أو المورد الذي قد يختاره فريق تكنولوجيا المعلومات لاحقًا.

ومع ذلك، فإن واجهة برمجة التطبيقات هي مجرد واجهة. لا يمكنها تحديد مكان إرسال السجلات أو كيفية إرسالها. وهنا يأتي دور مجموعة تطوير برمجيات (SDK) OpenTelemetry - أو مجموعة تطوير برمجيات السجلات (SDK).

تأخذ مجموعة تطوير برمجيات السجلات السجلات من نقطة نهاية واجهة برمجة التطبيقات وتتولى القيام بالعمل الحقيقي. فهي تتلقى سجلات الأحداث، وتثريها (بإضافة اسم الخدمة أو البيئة مثلاً)، وتجمعها وتجهزها للشحن. بعد ذلك، تستخدم المُصدّرين لإرسال السجلات المُعالجة إلى Collector أو منصة السجلات.

تربط مُلحقات السجلات—والتي تُعرف أيضًا بجسور السجلات—مكتبات التسجيل الحالية (مثل Log4j أو SLF4J أو أطر العمل المشابهة) بنموذج بيانات سجلات OpenTelemetry.

وبدلاً من استدعاء مطوري البرامج لواجهة برمجة تطبيقات السجلات مباشرةً، يمكنهم تهيئة إطار عمل السجلات الحالي لديهم لاستخدام مُلحق يحول كل حدث سجل تقليدي إلى سجل أحداث OTel.

ويمكن لجسور السجلات أيضًا إدخال سياق الامتداد والتتبع في سجلات الأحداث، ما يتيح الارتباط بين السجلات والتتبعات حتى عندما يكون رمز التطبيق نفسه غير مدرك لتفاصيل تتبع الأثر.

تُعد آليات انتشار السياق والارتباط من المكونات الأساسية لتسجيل OpenTelemetry. عندما يكون نطاق التتبع نشطًا، يمكن لجسر السجلات أو مجموعة تطوير البرمجيات (SDK) إرفاق معرف التتبع الحالي ومعرف النطاق تلقائيًا بكل سجل أحداث يتم إصداره.

يساعد الارتباط منصات قابلية الملاحظة الخلفية على توصيل السجلات بالتتبعات الموزعة التي تمثل الطلب نفسه أو سير العمل ذاته. وتمكّن هذه الروابط الفرق من الانتقال مباشرة من إدخال سجل إشكالي إلى تتبع يعرض المسار الكامل للطلب. كما تسهل عملية تحليل الإشارات المتقاطعة للمقاييس والتتبعات والسجلات التي تشترك في حقول الموارد والسياق.

تتحدث OTel عن "أنواع" السجلات بعدة طرق مختلفة: حسب البنية وحسب المصدر وحسب الترميز أو بروتوكول الإرسال.

تتمتع السجلات المنظمة بمخطط ثابت—أي الحقول نفسها بأسماء وأنواع بيانات مستقرة—ما يتيح لأدوات قابلية الملاحظة إمكانية تحليلها والاستعلام عنها بشكل موثوق. وقد يتم ترميز هذه السجلات بتنسيق JSON أو أي تنسيق آخر، ولكن ما يجعلها مهيكلة هو تلك المجموعة المتوقعة من حقول البيانات.

تحتوي السجلات شبه المنظمة على بعض الهياكل القابلة للتمييز (مثل أزواج المفتاح والقيمة أو كتل تشبه تنسيق JSON)، ولكن المخطط الخاص بها لا يكون ثابتًا بمرور الوقت. هذه السجلات أكثر قابلية للقراءة آليًا من النصوص الحرة، لكنها تتطلب عمليات تحليل وتوحيد إضافية قبل أن تتمكن الفرق من تحليلها بفعالية.

السجلات غير المنظمة هي رسائل نصية حرة تفتقر إلى مخطط ثابت (مثل جمل الطباعة العشوائية أو سجلات الخادم النصية البسيطة). يسهل على البشر كتابتها وقراءتها، ولكن يصعب على الأنظمة الآلية البحث فيها أو ربطها أو تجميعها دون إجراء عمليات تحليل إضافية مجهدة. 

يتم إنتاج سجلات النظام والبنية التحتية بواسطة أنظمة التشغيل وأجهزة الشبكة وخدمات البنية التحتية السحابية وغيرها من مكونات المنصة، بدلاً من التعليمات البرمجية للتطبيق. فهي تلتقط الأحداث—مثل أخطاء نظام التشغيل ومشكلات الشبكة وحالة البنية التحتية—لمساعدة الفرق على فهم الأداء والسلامة البيئية الأساسية

تأتي سجلات تطبيقات الطرف الأول من الخدمات والتطبيقات الداخلية، عادةً من خلال مجموعة تطوير برمجيات (SDK) OTel أو مكتبة تسجيل أو حاوية جانبية (حاوية تطبيق ثانية تعمل جنبًا إلى جنب مع الحاوية الأساسية وتستخدم الموارد نفسها) أو وكيل. تصف هذه السجلات أحداث العمل ومعالجة الطلبات وإجراءات المستخدم والأخطاء الداخلية. ويمكن إثراؤها بخصائص الموارد ونطاق التهيئة (الذي يصف أصل السجل داخل الكيان الذي أنشأه) لتوفير صورة أكثر اكتمالاً لسلوك التطبيق.

تصدر سجلات الطرف الثالث من الخدمات الخارجية والمكونات المدارة ومنتجات البرمجيات كخدمة التي تعتمد عليها العديد من بيئات تكنولوجيا المعلومات في المؤسسات (مثل واجهات برمجة التطبيقات الخارجية وقواعد البيانات). يمكن لـ OTel استيعاب هذه السجلات إلى جانب السجلات الداخلية حتى تتمكن فرق تكنولوجيا المعلومات من رؤية كيفية تأثير الاعتماديات الخارجية على المنظومة.

يتم تمثيل سجلات OTLP في نموذج بيانات OTLP الأصلي وإرسالها عبر OTLP gRPC أو HTTP. يتم توحيد كل سجل لضمان الحيادية تجاه الموردين والارتباط السريع بالتتبعات والمقاييس.

تُكتب السجلات المستندة إلى الملفات في ملفات (ملفات سجلات التطبيقات أو سجلات الوصول إلى خادم الويب)، أما سجلات نمط syslog فهي رسائل يتم إصدارها باستخدام بروتوكول syslog. يجمع OTel عادةً هذه السجلات باستخدام أجهزة استقبال تقوم بتتبع الملفات أو الاستماع إلى رسائل syslog ثم تحويلها إلى سجلات أحداث OTel لتتم معالجتها بشكل موحد.

يتم تسليم سجلات HTTP وJSON عبر HTTP في JSON. يدعم OpenTelemetry CSV وتنسيق السجلات المشترك (CLF) وLTSV وأزواج المفتاح والقيمة أيضًا. يتم تحليل هذه التنسيقات بواسطة المُجمِّع في نموذج بيانات سجلات OTel الشائع، بحيث يمكن الاستعلام عنها وربطها بالطريقة نفسها التي يتم بها ربط سجلات OTLP الأصلية.

تخيل أن مهندسي موثوقية المواقع يلاحظون زيادة في أخطاء "فشل إتمام الشراء" على لوحات معلومات قابلية الملاحظة الخاصة بخدمة مصغرة لعمليات الدفع. قد يبدؤون عملية استكشاف الأخطاء وإصلاحها بفحص سجلات OTel، والتي تكون موحدة بالفعل وتتضمن سمات مهيكلة (تشمل قيمة الطلب وعدد العناصر ومعرف التتبع) لكل سجل من سجلات "تم تقديم الطلب".

يستطيع المهندسون التحقق سريعًا مما إذا كانت حالات الفشل ترتبط بأحجام طلبات مرتفعة أو بطريقة شحن معينة، أو بمنطقة جغرافية محددة، وذلك بمجرد الاستعلام عن سمات السجل. يمكنهم أيضًا مواءمة النافذة الزمنية عبر السجلات والتتبعات والمقاييس، لأن OTel تستخدم طوابع زمنية وبيانات وصفية متسقة للموارد عبر جميع إشارات القياس عن بُعد.

يؤكد المهندسون أن الطلبات الموجهة إلى مزود دفع معين هي فقط التي تتعرض للفشل. فيقومون بتتبع المسار وصولاً إلى جميع السجلات التي تشترك في سمة ذلك المزود، حيث يجدون حالات زمن توقف جلسة متكررة. وبناءً على ذلك الدليل، يمكن لفريق تكنولوجيا المعلومات توجيه الحادثة بسرعة إلى المسؤول الصحيح وتنفيذ إستراتيجية تخفيف، (مثل تحويل العمليات إلى مزود آخر مثلاً).

يختلف تسجيل OTel بشكل كبير عن التسجيل التقليدي في عمليات الجمع والتوحيد والارتباط ونقل السجلات.  

تركز أنظمة التسجيل التقليدية على تجميع السجلات وفهرستها والبحث فيها والتنبيه بناءً على أنماط السجلات. فهي أدوات قوية للبحث عن النصوص والتحليل التاريخي، ولكنها عادةً ما تفحص السجلات بمعزل عن بيانات القياس عن بُعد الأخرى.

تعتمد أساليب التسجيل التقليدية بشكل أساسي على تسجيل الرسائل النصية محليًا، حتى يتمكن المطورون من تصحيح الأخطاء في تطبيق واحد أو مضيف واحد. فهي تفترض أن المستخدمين سيقرؤون الملفات ويصفونها وربما يرسلونها إلى مجمع السجلات في وقت لاحق. كما أنها تستخدم عادةً تنسيقات مخصصة، مثل الخطوط النصية البسيطة أو JSON ضعيفة التنظيم أو الأنماط الخاصة بأطر العمل التي تفتقر إلى معيار مشترك عبر الخدمات.

ونظرًا إلى أن كل فريق تطوير يمكنه اختيار الحقول والتسمية الخاصة به، فإن التحليل عبر الأنظمة عملية مرهقة.

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

يُعدّ تسجيل OpenTelemetry جزءًا من إطار عمل موحّد لقابلية الملاحظة، والذي يتعامل مع السجلات والمقاييس والتتبعات بصفتها إشارات من الدرجة الأولى قابلة للتشغيل البيني تحكمها اصطلاحات دلالية مشتركة. منذ البداية، تسجل السجلات ليتم ربطها وتحليلها عبر الأنظمة الموزعة، لأن الهدف هو فهم سلوك النظام بشكل شامل.

بينما يقتصر التسجيل التقليدي على مجموعات أو جهات خلفية محددة، فإن تسجيل OTel يتسم بالاستقلال التام. يوفر جسورًا ومُلحقات بحيث يمكن لأطر عمل التسجيل الحالية إصدار البيانات بصيغة OTel دون الحاجة إلى إعادة كتابة كل استدعاء سجل.

يمكّن هذا النطاق والنهج الموحد فرق تكنولوجيا المعلومات من إنشاء مسارات عمل شاملة لاستكشاف الأخطاء وإصلاحها، حيث يمكنهم التنقل بسلاسة بين لوحات المعلومات وأنواع البيانات لفهم الأعطال المعقدة والموزعة.

يوفر تسجيل OTel سجلات موحدة وغنية بالسياق تتكامل بإحكام مع التتبعات والمقاييس، ما يجعل استكشاف الأخطاء وإصلاحها وتحليلها أكثر فعالية بكثير من الأساليب التقليدية. وتتضمن هذه الفوائد ما يلي: