تنبيه خدمة النموذج: هل الشرط المرتفع أطلقه فورا؟

الخلاصة السريعة

ليس بالضرورة؛ مع for نحتاج استمرار الشرط عند التقييمات خلال المدة المحددة. حالة القاعدة منفصلة عن وصول إشعار أو إصلاح خدمة.

• for في Prometheus مدة انتظار من أول نشاط للعنصر، وpending نشاط لم يصبح firing؛ يلزم استمرار النشاط عند كل تقييم. ^[1]
• نعلن الشرط أكبر من 10 ومدة دقيقتين: القيم 12 ثم 13 ثم 9 عند الدقائق 0 و 1 و 2 لا تكمل انتظار النشاط الأول. هذه تقييمات منفصلة لا تثبت الاستمرار بين القراءات.
• مع القيم 12 و 13 و 12 عند 3 و 4 و 5 تبدأ مدة جديدة عند 3 وتكتمل عند 5؛ ومن دون keep_firing_for يزول النشاط عند تقييم 6 ذي القيمة 9 في مثالنا.
• keep_firing_for إعداد منفصل للاحتفاظ بحالة firing بعد زوال الشرط، والإشعارات لها طبقة أخرى مثل Alertmanager. ^[1] لا نساوي حالة القاعدة بوصول رسالة أو تحديد سبب المشكلة.

ما الفرق بين نشاط الشرط وحالة الإطلاق؟

ينتظر Prometheus مدة for بين أول نشاط عنصر التعبير واحتساب التنبيه firing، ويتحقق من بقاء النشاط عند كل تقييم؛ ما ينتظر يبقى pending. ^[1]

نختار في الورقة مؤشرا لخدمة استدلال، بوحدة عددية تعليمية ثابتة، وليس عدد طلبات أو متوسط زمن قسناه. نربط جميع التقييمات بعنصر واحد ثابت التسميات كي لا نجمع حالة خدمة أ مع خدمة ب.

الحد ومدة الانتظار قراران مختلفان. عبارة «تجاوز عشرة» تصف المقارنة العددية، بينما «استمر دقيقتين» تحتاج بداية وتسلسل تقييمات. لا نقرأ التقييم الأول كما لو أنه حفظ تلقائيا تاريخا سابقا لم نقدمه.

لماذا لا يكتمل الانتظار الأول؟

نعلن المقارنة الصارمة: القيمة أكبر من 10، وfor تساوي دقيقتين. التقييمات عند 0 و 1 و 2 دقيقة، والقيم بالترتيب 12 و 13 و 9. نبدأ بلا نشاط سابق. هذه سجلات مؤلفة لا قراءات نظام.

عند صفر يبدأ نشاط مع انتظار. وعند واحد يبقى الشرط متحققا، لكن مضت دقيقة واحدة فقط. وعند اثنين يفشل الشرط لأن 9 ليست أكبر من 10؛ لا تكتمل دقيقتان من نشاط مستمر في تقييمات هذه القائمة.

ولا نحول ذلك إلى دليل أن القيمة لم ترتفع بين القراءات أو أن الجهاز تعافى فعليا. ما أعلنّاه كاف لترتيب تقييمات المثال، ولا يقدم تسجيلا مستمرا لكل ما حدث في الخدمة.

كيف يبدأ انتظار جديد وينتهي نشاطه؟

نضيف تقييمات عند 3 و 4 و 5 دقائق بقيم 12 و 13 و 12. بعد زوال النشاط السابق نبدأ عند 3؛ يبقى الشرط متحققا عند 4 وعند 5، وعندها مضت دقيقتان. تتوافق الورقة مع الانتقال إلى firing عند تقييم 5.

عند 6 نعطي القيمة 9، ونعلن غياب إعداد keep_firing_for من هذه القاعدة. لا نستعمل بداية صفر لنحسب ست دقائق من نشاط متصل، لأن تقييم اثنين قطع الفترة الأولى.

إبقاء هوية العنصر وقاعدة المقارنة ومواعيد التقييم ثابتة مهم للحساب. لو تبدلت التسميات أو ضاع تقييم، يحتاج تفسير مدة النشاط إلى وصف جديد؛ لا نملأ فجوة السجل بنشاط لم نعرفه.

هل الاحتفاظ بالحالة يعني إيصال الرسالة؟

keep_firing_for يحفظ firing مدة بعد آخر تحقق للشرط؛ وغيابه يزيل النشاط عند أول تقييم لا يحققه. وتفصل الصفحة ذلك عن إدارة الإشعارات عبر طبقة أخرى مثل Alertmanager. ^[1]

لذلك نحفظ خانة حالة القاعدة وخانة ما عرف عن إرسال الرسالة واستقبالها مستقلتين. لم ننفذ أي إرسال في مقالنا، ولا نعلن أن شخصا تلقى إنذارا عند الدقيقة الخامسة أو أن عملا تصحيحيا بدأ.

راجع الشرط والمدة والتسميات ومواعيد التقييم وخيار الاحتفاظ قبل تفسير التنبيه. الرسم يظهر فترة أولى انقطعت وفترة ثانية اكتمل انتظارها. لا يثبت سبب ارتفاع المؤشر أو أن ضبط الانتظار اختار أفضل توازن بين سرعة الإنذار وتكراره.