بمساهمة من Dan Gomez Blanco (New Relic). إذا كنت تبني برمجيات مستضافة ذاتيًا أو منتج SaaS، فسيطلب المستخدمون عاجلًا أو آجلًا إرسال السجلات والتتبعات والمقاييس إلى منظومة المراقبة الخاصة بهم. إن تقييدهم بلوحات المعلومات المدمجة أو حصر عمليات التصدير بمزوّدين معينين يخلق احتكاكًا غير ضروري. وفي المقابل، فإن دعم التصدير إلى أي نظام خلفي متوافق مع Open Telemetry (OTel) ممارسة محايدة تجاه المزوّدين ومستقبلية، تمنح المستخدمين حرية اختيار منظومة المراقبة التي يريدونها.
توضح هذه المقالة كيفية تصميم منتجك بحيث يتمكن المستخدمون من تصدير السجلات والتتبعات والمقاييس إلى نظام خلفي متوافق مع OTel متى أرادوا ذلك. يحدد Open Telemetry أربعة أنواع من الإشارات تُنقل عبر بروتوكول Open Telemetry القياسي (OTLP): السجلات (سجلات الأحداث وسجلات الطلبات والوصول وسجلات التطبيقات مع الطوابع الزمنية والبيانات الوصفية)، والتتبعات (التتبعات الموزعة والفترات الزمنية التي تتيح للمستخدمين رؤية تدفق الطلبات عبر الخدمات وربطها بالسجلات)، والمقاييس (العدادات والمقاييس اللحظية والمدرجات التكرارية، مثل معدلات الطلبات وزمن الاستجابة ومعدلات الأخطاء)، والملفات الشخصية (عينات توضح أين تستهلك التطبيقات الموارد أثناء التنفيذ). تنطبق قصة التصدير نفسها على الإشارات الثلاث: يتيح للمستخدمين تهيئة نقطة نهاية OTLP ودفع بيانات القياس إليها. يمكنك دعم إشارة واحدة أو اثنتين أو الثلاث جميعًا بحسب ما ينتجه منتجك. تدعم كثير من المنصات التي تتيح تصدير OTel التتبعات والسجلات على الأقل، وبات عدد متزايد منها يوفّر دعم المقاييس أيضًا. إن التصميم للإشارات الثلاث منذ البداية يتجنب الحاجة إلى إعادة الهيكلة لاحقًا.
تتميز استراتيجية التصدير الجيدة بعدة خصائص واضحة لكل إشارة تدعمها: الحياد تجاه المزوّد، وعدم الحاجة إلى تطوير مخصص معقد، والحفاظ على السياق الغني، ودعم الاصطلاحات الدلالية. وهناك سياقان يجب مراعاتهما: أين يعمل منتجك؟ بالنسبة إلى البرمجيات المستضافة ذاتيًا، قم بتزويد منتجك بأدوات قياس باستخدام Open Telemetry، ودع العملاء يهيئون نقطة النهاية عبر متغيرات البيئة أو ملف الإعدادات. أما بالنسبة إلى المنصات السحابية، فأضف ميزة منصة لإدارة عمليات التصدير. ومن الأمثلة على ذلك Keycloak وKuma.
المصدر: Hacker News · لخّصه HeadlinesBriefing