OpenTelemetry Tail Sampling بالعربي: احتفظ بالتريس المهم

بالظبط، الترتيب مهم. memory_limiter قبل tail_sampling يحمي الـ Collector من الانفجار. وbatch بعده يقلل ضغط التصدير. المصادر الرسمية بتوضح إن تعريف processor لا يفعّله وحده؛ لازم تضيفه داخل pipeline في قسم service.

الأرقام التي تبدأ بها

استخدم معادلة عملية كبداية: num_traces = expected_new_traces_per_sec * decision_wait * 2. لو عندك 1,000 trace في الثانية وقرارك بعد 10 ثواني، ابدأ بـ 20,000. الضرب في 2 هامش أمان لأن traffic مش ثابت.

الـ trade-off هنا واضح: كل ما تزود decision_wait أو num_traces هتقلل احتمال رمي trace قبل قرار sampling، لكن هتزود استهلاك الذاكرة. لو Collector عنده 2GB RAM، لا تبدأ بـ 200,000 trace في الذاكرة. ابدأ صغير، راقب، ثم كبّر.

سيناريو واقعي: موقع SaaS عنده 50K زائر يوميًا، ومتوسط 300 trace في الثانية وقت الذروة. قبل Tail Sampling كان بيخزن 100% من traces. بعد الإعداد السابق، الأخطاء والبطيء اتخزنوا بالكامل، والطبيعي نزل إلى 5%. لو 90% من الطلبات طبيعية، حجم traces المصدرة ممكن ينخفض تقريبًا من 100 وحدة إلى 14.5 وحدة: 10 وحدات مهمة كاملة + 4.5 من الطبيعي. ده تقدير، لكنه كافي لاتخاذ قرار أولي.

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

لا تستخدم Tail Sampling كأول خطوة لو التطبيق نفسه لا يرسل spans صحيحة. أصلح instrumentation الأول. لا تستخدمه أيضًا على edge collector صغير داخل كل pod لو الذاكرة محدودة جدًا، لأن tail sampling يحتاج الاحتفاظ بالـ traces مؤقتًا. ولو عندك متطلبات قانونية أو forensic audit تحتاج 100% من كل request، sampling هنا هيخسرك اكتمال السجل.

بدل ما تبدأ بسياسة معقدة من أول يوم، ابدأ بثلاث سياسات فقط: errors، latency، probabilistic. بعد أسبوع راقب عدد traces المسقطة مبكرًا، ونسبة الأخطاء التي وصلت للBackend، واستهلاك RAM. لو عندك خدمات حرجة مثل payment، أضف attribute مثل service.criticality=critical واحتفظ بها بنسبة أعلى.

مصادر وتحقق

• توثيق OpenTelemetry عن Sampling يشرح الفرق بين head sampling وtail sampling: https://opentelemetry.io/docs/concepts/sampling/
• توثيق Collector Processors يوضح أن Tail Sampling Processor مخصص للـ traces وفي توزيعة contrib/K8s: https://opentelemetry.io/docs/collector/components/processor/
• README الرسمي للـ tailsamplingprocessor يشرح decision_wait وnum_traces وexpected_new_traces_per_sec: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/tailsamplingprocessor/README.md
• توثيق إعدادات Collector يوضح أن processor لا يعمل إلا عند إضافته داخل pipeline: https://opentelemetry.io/docs/collector/configuration/

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

الخطوة التالية: خُد نسخة من إعداد الـ Collector عندك، وضيف tail_sampling بثلاث سياسات فقط: ERROR، latency فوق 2000ms، و5% probabilistic. شغّله يوم واحد في staging، وقارن عدد spans المصدرة واستهلاك RAM قبل ما تلمس الإنتاج.