Prometheus Alerts بالعربي: قلل التنبيهات الكاذبة قبل ما تصحي الفريق
هتخرج من المقال ده بإعداد Alert Rules عملي يقلل التنبيهات الكاذبة، ويخلي التنبيه اللي بيوصلك قابل للتصرف بدل ما يكون صوت مزعج.
مستوى القارئ: متوسط
المشكلة باختصار
الطريقة الشائعة الغلط إنك تعمل alert على أي spike لحظي. مثلًا: لو latency عدّى 500ms لمدة دقيقة، ابعت تنبيه. الطريقة دي بتفشل لأن الإنتاج الطبيعي فيه spikes قصيرة وقت restart، deploy، أو GC pause. النتيجة إن الفريق يتعود يتجاهل التنبيهات، وده أخطر من عدم وجود monitoring.
الافتراض إن عندك خدمة Web عليها حوالي 50K زائر يوميًا، وبتستخدم Prometheus مع Alertmanager. لو عندك 3 instances وكل instance بيعمل restart مرة يوميًا، ممكن تشوف 6 إلى 10 تنبيهات كاذبة في الأسبوع لو القاعدة حساسة زيادة.
الفكرة الأساسية: التنبيه لازم يقيس استمرار المشكلة
ركز: الـ monitoring مش مطلوب منه يثبت إن كل ثانية مثالية. المطلوب يقولك إمتى المستخدمين بيتأثروا بشكل مستمر. الفرق هنا مهم. spike لمدة 30 ثانية ممكن يكون مقبول. latency عالية لمدة 10 دقائق معناها إن في مشكلة تستحق فتح incident.
Prometheus بيدعم ده من خلال حقل for داخل alerting rules. حسب توثيق Prometheus الرسمي، القاعدة لا تعتبر firing إلا بعد استمرار الشرط طول المدة المحددة. المصدر: Prometheus Alerting Rules.
مثال قريب: اعتبر التنبيه زي إنذار حريق في مطبخ. دخان بسيط لمدة 5 ثواني أثناء الطبخ مش حادث. دخان مستمر 5 دقائق محتاج تدخل. نفس المعنى بالظبط ينطبق على latency وerror rate.
إعداد عملي لقاعدة تنبيه أقل إزعاجًا
بدل ما تنبه على request واحد بطيء، استخدم percentile من histogram. Prometheus يوفر دالة histogram_quantile لحساب قيم مثل P95 من buckets. المصدر: Prometheus histogram_quantile.
القاعدة التالية تنبه لما P95 latency يتعدى 700ms لمدة 10 دقائق. الرقم 700ms هنا مناسب كبداية لتطبيق CRUD داخلي. لو المنتج public-facing وحساس، ممكن تبدأ بـ 400ms.
groups:
- name: api-latency.rules
rules:
- alert: HighApiLatencyP95
expr: |
histogram_quantile(
0.95,
sum(rate(http_request_duration_seconds_bucket{job="api"}[5m])) by (le)
) > 0.7
for: 10m
labels:
severity: warning
team: backend
annotations:
summary: "API P95 latency is above 700ms"
description: "P95 latency stayed above 700ms for 10 minutes. Check recent deploys, DB latency, and queue depth."
runbook_url: "https://example.com/runbooks/high-api-latency"
