فازت OpenTelemetry في حروب المراقبة. الآن يأتي الجزء الصعب.

المشكلة التي لا يتحدث عنها أحد بما يكفي

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

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

عصر الاحتكار

كل بائع مراقبة — Datadog، New Relic، Dynatrace، Honeycomb، Jaeger — شحن SDK الخاص به. وكيله الخاص. بروتوكول الأسلاك الخاص به. إذا قمت بقياس خدمة Python الخاصة بك باستخدام متتبع Datadog وقررت لاحقًا تقييم Honeycomb، كنت ستنظر إلى إعادة كتابة طبقة القياس الخاصة بك. ليس لأن البائعين كانوا خبيثين، ولكن لأنه لم يكن هناك معيار. كانت طبقة جمع القياسات هي الخندق.

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

من أين أتت OpenTelemetry

في عام 2019، اندمج مشروعان مفتوحان المصدر متنافسان للمراقبة — OpenCensus (المدعوم من Google) وOpenTracing (مشروع CNCF) — في OpenTelemetry. تجنب الاندماج ما كان سيكون تجزئة ضارة للنظام البيئي. أصبحت OpenTelemetry مشروع CNCF، ونمت بسرعة. من حيث عدد المساهمين، هي الآن ثاني أكثر مشاريع CNCF نشاطًا بعد Kubernetes.

كان عرض القيمة بسيطًا: قس مرة واحدة، صدر في أي مكان. SDK واحد لكل لغة. بروتوكول أسلاك واحد — OTLP (بروتوكول OpenTelemetry). جامع واحد — otel-collector — لاستقبال ومعالجة وتصدير القياسات إلى أي خلفية. يتنافس البائعون على التحليل والتصور، وليس على احتكار القياس.

حالة OTel في 2026

نجح الرهان. OpenTelemetry منشورة في الإنتاج في Google وMicrosoft وShopify وUber وآلاف المؤسسات الأخرى. كل خلفية مراقبة رئيسية — Datadog وGrafana وElastic وHoneycomb وDynatrace وNew Relic وSplunk — تقبل OTLP بشكل أصلي. تذكر CNCF أن OpenTelemetry قيد الاستخدام في 83% من شركات Fortune 500 بشكل ما. لم يعد هذا مشروعًا متخصصًا. هذه بنية تحتية.

SDKs الخاصة بـ Go وJava وPython وJavaScript مستقرة ومُصانة جيدًا. القياس التلقائي للأطر الشائعة — Django وExpress وSpring Boot وRails — يعمل بشكل موثوق. يمكنك إضافة تبعية واحدة، وتعيين بعض متغيرات البيئة، والحصول على تتبعات تتدفق إلى خلفيتك دون لمس كود التطبيق. للمشاريع الجديدة، هذه هي نقطة البداية الواضحة.

ما يعمل بالفعل

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

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

نضج النظام البيئي حول الجامع أيضًا. تغطي أجهزة الاستقبال والمصدرين المساهمة معظم مصادر بيانات المؤسسات. المشغل لـ Kubernetes صلب. توزيعات البائع للجامع (مثل AWS Distro for OpenTelemetry أو Grafana Agent) توفر بنى مبنية مختبرة ومدعومة مع مصدرين خاصين بالبائع مكونين مسبقًا.

ما لا يزال صعبًا

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

اتفاقيات المقاييس الدلالية غير متسقة عبر اللغات. مقياس يُسمى شيئًا في Java SDK يُسمى شيئًا مختلفًا قليلاً في Python SDK. يتم معالجة هذا، لكن ببطء. الفرق التي تبني لوحات معلومات عبر اللغات تواجه هذا الاحتكاك.

تكوين الجامع معقد. تكوين YAML لـ otel-collector — أجهزة الاستقبال، المعالجات، المصدرين، خطوط الأنابيب — مرن لكنه مطول. مع نمو الطوبولوجيا، ينتهي بك الأمر بملفات YAML يصعب حقًا فهمها. لا يوجد حل رائع هنا بعد. بعض الفرق تستخدم jsonnet أو cue لإنشاء تكوينات الجامع. آخرون يكتبون أدوات إدارة التكوين. إنها مشكلة قابلة للحل، لكنها عمل تشغيلي حقيقي.

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

مشكلة الكاردينالية التي لم تحلها OTel

تجعل OpenTelemetry من السهل إضافة سمات إلى قياساتك. هذه ميزة. وهي أيضًا فخ. إضافة سمات عالية الكاردينالية — معرفات المستخدم، معرفات الطلب، رموز الجلسة — إلى المقاييس هو خطأ كلاسيكي يسبب انفجارات في التكلفة في الخلفيات التي تفرض رسومًا لكل سلسلة مقياس (وهي معظمها).

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

الإشارة الرابعة: التنميط

تعمل OpenTelemetry على إشارة مراقبة رابعة: التنميط المستمر. بيانات التنميط — مخططات اللهب لوحدة المعالجة المركزية، تتبعات تخصيص الذاكرة — عاشت تاريخيًا في أدوات منفصلة (pprof، async-profiler، py-spy) بدون تنسيق قياسي أو ارتباط مع الإشارات الثلاث الأخرى.

إشارة تنميط OTel لا تزال تجريبية، لكن Grafana وElastic والعديد من البائعين الآخرين يراهنون عليها بالفعل. الهدف هو نفس الإشارات الأخرى: تنسيق قياسي، بروتوكول أسلاك قياسي، ارتباط بالتتبعات. عندما تستقر، ستغلق الفجوة الرئيسية الأخيرة في قصة مراقبة OTel.

نصائح عملية للفرق التي تتبنى OTel اليوم

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

الحرب انتصرت. العمل لم ينته.

حققت OpenTelemetry شيئًا نادرًا حقًا في برمجيات البنية التحتية: قتلت مشكلة احتكار القياس. يتنافس البائعون على جودة تحليلهم، ولغات استعلامهم، وتنبيهاتهم، وتجربة المستخدم — وليس على حبسك في SDK الخاص بهم. هذا عالم أفضل.

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