مراقبة ما يهم
تُقاس فائدة المراقبة بالقرارات التي تساعد عليها. تفيد لوحات المعلومات في التحقيق في الأعطال وتخطيط السعة، بينما تلفت التنبيهات الانتباه إلى ما يحتاج إلى إجراء. وكثرة الإشعارات التي لا تستدعي عملًا تجعل هذا الدور أصعب. الهدف هو ملاحظة التغيّر المهم، وإيصاله إلى الشخص المناسب، وتوضيح الخطوة التالية.
ابدأ بالسؤال لا بالمقياس
قبل إضافة مقياس، اسأل: أي قرار سيساعدنا عليه؟ إذا لم تتضح الإجابة، فقد لا يصلح للتنبيه. مثال ذلك تنبيه استخدام المعالج عند 80 بالمئة؛ فقد يكون الارتفاع طبيعيًا ومؤقتًا ولا يدل على مشكلة. أما توقف خدمة محددة عن الاستجابة فيشير عادةً إلى إجراء أوضح.
فكّر في النتيجة المطلوبة: استمرار إتاحة الخدمة، أو نجاح النسخ الاحتياطي، أو سلامة النسخ المتماثل لخدمة الدليل، أو استمرار وصول أحداث من مصدر سجلات مهم. المقاييس التي لا ترتبط بنتيجة قد تفيد الاستكشاف، لكنها ليست بالضرورة مناسبة للإشعارات.
نبّه عند تغيّر يستدعي إجراءً
التغيّر المهم هو ما يحتاج إلى تدخل. انتقال امتلاء قرص من 40 إلى 45 بالمئة لا يستدعي غالبًا تنبيهًا، بينما انتقاله من 85 إلى 92 بالمئة خلال يوم قد يستدعي ذلك. اختر العتبات وفق المشكلة الفعلية، لا وفق سهولة اختيار رقم دائري.
استخدم معدل التغيّر عندما يكون الانحراف المفاجئ هو الإشارة المهمة. توقف خدمة عن إرسال السجلات يختلف عن خدمة لم ترسلها أصلًا. وإعادة تشغيل غير متوقعة تختلف عن إعادة تشغيل ضمن نافذة صيانة. في Prometheus، تحسب changes() عدد تغيّرات القيمة خلال فترة، بينما تحسب rate() متوسط الزيادة في العداد لكل ثانية، وتوصي الوثائق باستخدامها للتنبيه بدلًا من المعدل اللحظي المتقلب (دوال استعلام Prometheus).
إزالة التكرار وتجميع التنبيهات
قد يتسبب عطل واحد في أعراض كثيرة. فتعطّل قاعدة بيانات قد يظهر كأخطاء في التطبيقات، وشكاوى مستخدمين، وانقطاع في بيانات المراقبة. تمنع إزالة التكرار تكرار إشعار التنبيه نفسه، ويجمع التجميع التنبيهات المرتبطة في إشعار واحد. لكن معرفة السبب الأساسي تظل بحاجة إلى تسميات مفيدة وقواعد كبت عند الحاجة.
يوفر Alertmanager هذه الآليات. تُجمَّع التنبيهات وفق تسميات تختارها، وتتحكم ثلاثة إعدادات في التوقيت: group_wait قبل أول إشعار لمجموعة جديدة، وgroup_interval قبل إشعارات التغييرات اللاحقة للمجموعة، وrepeat_interval قبل إعادة الإشعار نفسه. أما الكبت فيمنع إشعار تنبيه مستهدف عند وجود تنبيه آخر يطابق شروطًا تحددها؛ مثل كبت أخطاء التطبيقات المرتبطة بعطل معروف في قاعدة البيانات (إعداد Alertmanager).
حدّد متى يُعدّ العطل متعافيًا، وهل ينبغي إرسال إشعار بالتعافي. إشعار التعافي المفيد يؤكد نجاح التدخل، بينما التذبذب المتكرر بين حالتي العطل والتعافي هو الضوضاء التي ينبغي تقليلها. في Prometheus، تُبقي keep_firing_for التنبيه في حالة الإطلاق مدةً تحددها بعد زوال شرطه، لتقليل التذبذب والتعافي الكاذب. وبدونها يتوقف التنبيه في أول تقييم لا يتحقق فيه الشرط. أما for فتؤخر إطلاق التنبيه حتى يستمر الشرط المدة المطلوبة، ويبقى التنبيه خلالها معلّقًا (قواعد التنبيه).
تجنّب إرهاق التنبيهات
عندما تتكرر تنبيهات لا تحتاج إلى إجراء، يبدأ الناس تجاهلها؛ وعندئذ قد يفوتهم التنبيه الذي يستحق الانتباه.
راجع التنبيهات بانتظام. إذا تكرر تنبيه وكان يُتجاهَل غالبًا، فأصلح السبب، أو عدّل العتبة، أو احذفه إن لم تكن له فائدة. ينبغي أن يبرر كل تنبيه وجوده بإجراء يساعد عليه.
مجموعة صغيرة من التنبيهات المختارة بعناية أنفع من مئة تنبيه يومي. المطلوب هو ملاحظة ما يهم، لا تحويل كل مقياس إلى إشعار.
المراجعة بعد الحوادث
بعد كل حادثة، راجع التنبيهات التي أُطلقت: هل كانت مفيدة؟ هل أشارت إلى المشكلة الصحيحة؟ وهل غابت تنبيهات كان ينبغي أن تظهر؟ استخدم الإجابات لتعديل العتبات وإضافة القواعد اللازمة وحذف غير المفيد. تتطور المراقبة مع البيئة التي تصفها.
قائمة تحقق
- حدّد القرار الذي يدعمه كل مقياس قبل إنشاء تنبيه له.
- ركّز على النتائج وصحة الخدمة، لا الأرقام الخام وحدها.
- اختر العتبات وفق المشكلة الحقيقية.
- استخدم معدل التغيّر عندما يكون الانحراف المفاجئ هو الإشارة المطلوبة.
- أزل التكرار، واجمع التنبيهات المرتبطة، وحدّد شروط التعافي.
- راجع القواعد بعد الحوادث واحذف ما لا يؤدي إلى عمل.
- اجعل الإشعارات قابلة للتنفيذ، مع الاحتفاظ بالمقاييس والسجلات اللازمة للتحقيق.