OpenTelemetry Collector: اعزل الـ telemetry قبل ما تكسر التطبيق
لو كل microservice عندك بيبعت traces وmetrics مباشرة لأداة المراقبة، فأنت رابط استقرار التطبيق باستقرار مسار المراقبة. الحل العملي هنا: حط OpenTelemetry Collector في النص، وخليه يجمع، يضغط، ويقرر إيه يتبعت وإيه يتساب.
مستوى القارئ: محترف
المشكلة باختصار
اللي بيحصل فعلاً في فرق كتير إن كل خدمة فيها OTLP exporter يبعث مباشرة إلى SaaS monitoring أو Jaeger أو backend خارجي. الطريقة دي بسيطة في البداية، لكنها بتفشل لما عدد الخدمات يكبر. لو عندك 40 خدمة، وكل خدمة بتطلع 300 request telemetry في الدقيقة، فأنت بتعمل حوالي 12,000 طلب تصدير في الدقيقة قبل ما المستخدم نفسه يضغط على النظام.
الافتراض إن عندك تطبيق موزع بحجم متوسط: 20 إلى 60 خدمة، وtraffic ثابت، وأنت عايز traces للأخطاء والطلبات البطيئة أكثر من traces لكل طلب طبيعي. في الحالة دي، إرسال كل شيء مباشرة مكلف ومزعج. بتكسب بساطة الإعداد، لكن بتخسر التحكم في التكلفة والضغط والفلترة.
مثال بسيط قبل التعريف العلمي
ركز في المثال ده: عندك فرع شركة فيه 40 موظف، وكل موظف يرسل تقريرًا منفصلًا للإدارة كل 5 دقائق. الإدارة هتستلم مئات الرسائل الصغيرة. الأفضل إن فيه مسؤول في الفرع يجمع التقارير، يحذف التكرار، ويرسل ملخصًا واضحًا. OpenTelemetry Collector بيعمل نفس الدور تقريبًا، لكن مع traces وmetrics وlogs.
علميًا، الـ Collector هو خدمة مستقلة تستقبل telemetry غالبًا عبر OTLP، تمررها على processors مثل memory_limiter وbatch وtail_sampling، ثم تصدرها إلى exporters مثل OTLP, Prometheus, Jaeger, أو أي backend مدعوم. التطبيق يظل ينتج نفس الإشارات، لكن قرار التجميع والتصفية ينتقل لخارج التطبيق.
إعداد عملي قابل للنسخ
أفضل طريقة كبداية: شغّل Collector قريب من الخدمات، سواء كـ sidecar في حالات خاصة أو كخدمة مستقلة داخل نفس الشبكة. المثال التالي config مختصر يشتغل كفكرة أساسية. عدّل endpoint النهائي حسب backend عندك.
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
memory_limiter:
check_interval: 1s
limit_mib: 512
spike_limit_mib: 128
batch:
timeout: 5s
send_batch_size: 1024
tail_sampling:
decision_wait: 10s
num_traces: 50000
policies:
- name: keep-errors
type: status_code
status_code:
status_codes: [ERROR]
- name: keep-slow-requests
type: latency
latency:
threshold_ms: 750
exporters:
otlp:
endpoint: monitoring.example.com:4317
tls:
insecure: false
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, tail_sampling, batch]
exporters: [otlp]
metrics:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp]