التتبّع الموزّع بـ OpenTelemetry: حدّد الخدمة اللي بتبطّئ نظامك

pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install

OTEL_SERVICE_NAME=order-service \
OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4317 \
opentelemetry-instrument python app.py

للأجزاء الحرجة زوّد span يدوي بسمات (attributes) بتفرّق وقت التشخيص. ركز على إنك تسجّل القيم اللي هتدوّر بيها بعدين:

في السيناريو اللي فوق، لما تفتح الـ waterfall هتلاقي span اسمه payment.charge أخد 528 مللي من أصل 742، يعني حوالي 74% من زمن الطلب الكلي، وكله مستنّي رد الـ bank-api الخارجي. هنا القرار واضح: المشكلة مش في كودك، هي في الاعتماد الخارجي، والحل timeout أقصر مع retry محسوب أو نداء غير متزامن.

المعاينة (sampling): الـ trade-off الأهم في الإنتاج

تسجيل 100% من الـ traces في خدمة بتستقبل عشرات آلاف الطلبات في الثانية بيغرق الشبكة والتخزين. الحل هو المعاينة. وهنا الفرق الجوهري:

• Head sampling: بتقرّر تسجّل الطلب من عند أول خدمة (مثلًا 10% عشوائي). رخيص، لكن ممكن يرمي الطلب اللي فيه الخطأ.
• Tail sampling: بتستنى الـ trace يكتمل، وبعدين تقرّر تحتفظ بيه لو فيه خطأ أو بطء. بيضمن إنك تشوف كل المشاكل، مقابل إنه محتاج ذاكرة في الـ Collector عشان يجمّع الـ spans.

إعداد tail sampling في الـ OpenTelemetry Collector بيحتفظ بكل الأخطاء وكل طلب أبطأ من 500 مللي، ويعاين 10% من الباقي:

الافتراض هنا إن عندك Collector مستقل (مش agent جوّه كل pod) عشان الـ tail sampling محتاج يشوف كل spans الـ trace في مكان واحد. لو الـ Collector متعدّد النسخ من غير load balancing على أساس الـ trace_id، هتفقد أجزاء من الـ traces.

التكلفة الحقيقية وما يجب الانتباه له

الـ overhead بتاع الـ auto-instrumentation في معظم الخدمات بيكون أقل من 5% على الـ CPU (رقم تقديري بيختلف حسب عدد الـ spans وحجم السمات). لكن في فخّين بيوجعوا:

• Cardinality: لو حطّيت قيمة عالية التغيّر كسمة (زي user_id أو order_id) على metric، هتفجّر تكلفة التخزين. خلّي القيم دي على الـ spans مش على الـ metrics.
• حجم الـ attributes: تسجيل body كامل لكل request بيكبّر كل span ويرفع تكلفة الشبكة. سجّل المفيد بس.
• الـ context propagation الناقص: لو خدمة واحدة في السلسلة مش بتمرّر هيدر traceparent، الـ trace هيتقطع عندها وهتشوف رحلتين منفصلتين بدل واحدة.

متى لا تستخدم هذه الطريقة

لو نظامك monolith واحد من غير نداءات شبكة بين مكوّنات، الـ distributed tracing بيبقى overhead بلا فايدة، والـ profiler العادي أنسب وأرخص. وكمان لو عندك خدمتين بس بتتكلموا مرة في الطلب، الـ structured logging بـ correlation id ممكن يكفّي من غير ما تركّب stack كامل. الـ tracing بيستحق التعب لما يبقى عندك 4 خدمات فأكثر في مسار الطلب الواحد.

الخطوة التالية

اختار أبطأ endpoint عندك دلوقتي، شغّل عليه opentelemetry-instrument وابعت الـ traces لـ Jaeger محلي عبر Docker. افتح أول waterfall وشوف أنهي span واخد أطول وقت. الأغلب إنك هتلاقي السبب في نداء خارجي أو استعلام DB مش متوقّع، مش في الكود اللي بتشكّ فيه.

المصادر

• OpenTelemetry — التوثيق الرسمي ومفاهيم الـ traces والـ instrumentation: opentelemetry.io/docs
• W3C Trace Context — مواصفة هيدر traceparent (W3C Recommendation): w3.org/TR/trace-context
• OpenTelemetry Collector — موثّق الـ tailsamplingprocessor على GitHub: github.com/open-telemetry/opentelemetry-collector-contrib
• Dapper, a Large-Scale Distributed Systems Tracing Infrastructure — Sigelman et al., Google, 2010 (الورقة الأصل لمفهوم الـ span وانتشار السياق)
• CNCF — OpenTelemetry كمشروع graduated: cncf.io