قابلية المراقبة عمليًا باستخدام OpenTelemetry وSLO

1المقدمة

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

2اعتمد OpenTelemetry معيارًا

OpenTelemetry هو معيار CNCF لإنتاج التتبعات والمقاييس والسجلات ونقلها. ويوفر واجهات API وحزم SDK مستقلة عن المورّدين، وأدوات قياس تلقائية للأطر الشائعة، وCollector، وهو مسار يستقبل البيانات ويعالجها ويصدرها. والفائدة العملية واضحة: تضيف القياس إلى كودك مرة واحدة، وتبقى حرًا في تغيير الأنظمة الخلفية دون لمس كود التطبيق.

يفرق تفصيلان بين تتبعات جميلة وتتبعات مفيدة. أولًا، انقل السياق عبر كل خطوة باستخدام ترويسات W3C Trace Context، بما في ذلك عبر قوائم الرسائل حيث يُنسى ذلك غالبًا. ثانيًا، اتبع الاصطلاحات الدلالية لأسماء السمات، ليكون معنى http.response.status_code واحدًا في كل خدمة وكل استعلام.

3خذ العينات عن قصد

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

receivers:
  otlp:
    protocols:
      grpc: {}
      http: {}
processors:
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: keep-errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: keep-slow
        type: latency
        latency: { threshold_ms: 500 }
      - name: sample-the-rest
        type: probabilistic
        probabilistic: { sampling_percentage: 5 }
  batch: {}
exporters:
  otlp:
    endpoint: tracing-backend:4317
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [tail_sampling, batch]
      exporters: [otlp]

يتطلب أخذ العينات في النهاية وصول كل spans التتبع إلى نسخة Collector نفسها. وفي التوسع الأفقي، ضع في المقدمة طبقة أولى من Collectors باستخدام مصدّر موازنة الحمل المعتمد على معرّف التتبع.

4تحكم في تكلفة بيانات المراقبة

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

5دع SLO تحدد ما يهم

يحدد هدف مستوى الخدمة مدى الموثوقية المطلوبة من وجهة نظر المستخدم، مثل “99.9% من طلبات الدفع تنجح في أقل من 800 ms على مدى 28 يومًا”. والمؤشر هو نسبة الأحداث الجيدة إلى الأحداث الصالحة. وتمثل نسبة 0.1% الباقية ميزانية الخطأ، أي نحو 40 دقيقة من الانقطاع الكامل خلال 28 يومًا، وهي تمنح المنتج والهندسة طريقة رقمية مشتركة للموازنة بين عمل الموثوقية والميزات.

نبّه على سرعة استهلاك الميزانية لا على الحدود المجردة. فالنهج متعدد النوافذ ومعدلات الاستهلاك الموصوف في Google SRE Workbook لا يستدعي إنسانًا إلا عندما تختفي الميزانية بسرعة. وفي نافذة 30 يومًا، يستهلك معدل 14.4 لمدة ساعة نسبة 2% من الميزانية، وهذا خطير بما يكفي لإيقاظ أحد. أما الاستهلاك الأبطأ فيفتح طلبًا بدلًا من ذلك.

6من التنبيه إلى السبب الجذري

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

7الخاتمة

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