مراقبة Heartbeat واكتشاف Crash Loop في عمليات المتصفح

Process قد يكون موجودًا في قائمة النظام لكنه متجمد، لذلك PID وحده لا يثبت الصحة. Heartbeat يثبت أن العملية ما زالت تنفذ جزءًا من منطقها. لكن إعادة التشغيل التلقائي يمكن أن تخفي مشكلة أخرى: Crash Loop حيث تبدأ العملية، تفشل، ويعيدها المشرف بلا نهاية. النظام الجيد يراقب الاثنين معًا.

صمم Heartbeat يعكس صحة حقيقية

لا تجعل Heartbeat Timer منفصلًا تمامًا عن مسار العمل إذا كان يمكنه الاستمرار بينما بقية العملية معلقة. الأفضل أن يحمل timestamp وحالة وعدد Jobs ونسخة التطبيق، وربما Event loop lag بسيط.

استخدم عدة إشارات قبل إعلان الوفاة

تأخر heartbeat واحد قد يكون ضغط CPU. استخدم threshold مثل ثلاث فترات مع مراعاة الحمل. عند الاشتباه، امنع Jobs جديدة ثم حاول فحص العملية قبل قتلها.

Crash Loop يحتاج Circuit breaker

إذا أعيد تشغيل Worker خمس مرات خلال دقائق، لا تستمر بلا نهاية. افتح Circuit، أوقفه مؤقتًا، وأرسل Alert. وإلا سيستهلك CPU وLogs وقد يعيد نفس المهمة عدة مرات.

فرق بين Crash التطبيق وفشل المهمة

Workflow قد يفشل بسبب صفحة أو بيانات، وهذا لا يستحق Restart للمتصفح كله دائمًا. صنف الأخطاء: task-level، profile-level، worker-level. إعادة تشغيل مستوى أكبر من اللازم تزيد الانقطاع وتخفي السبب.

سيناريو تطبيقي قبل الاعتماد

تخيل المهمة تعمل عشرات المرات يوميًا، ويحدث في إحدى المرات timeout بعد خطوة لها أثر خارجي. التصميم الجيد يجب أن يعرف أين توقف وما الذي تم بالفعل. في موضوع «مراقبة Heartbeat واكتشاف Crash Loop في عمليات المتصفح»، نفّذ تجربة صغيرة قبل تعميم القرار. ابدأ بـ1- حدد interval ثابتًا.، 2- سجل آخر heartbeat.، 3- بعد أول تأخر علّم worker degraded.، ثم سجل النتيجة قبل توسيع النطاق. لا تحاول تحسين كل شيء في أول Run؛ المطلوب أولًا إنشاء حالة مرجعية تستطيع العودة إليها ومقارنتها. عندما تنجح التجربة، كررها مرة ثانية بنفس الشروط للتأكد أن النتيجة لم تكن صدفة أو أثر Cache أو حالة مؤقتة.

كيف تقيس نجاح التجربة؟

راقب نسبة النجاح من أول محاولة، عدد retries، زمن كل خطوة، عدد التدخلات اليدوية، وحالات التكرار أو الـloop. هذه المقاييس أهم من مجرد انتهاء Run واحدة بنجاح. حوّل النقاط الموجودة في المقال إلى مؤشرات قابلة للرصد: Heartbeat موجود لا يعني كل الوظائف سليمة.؛ آخر نشاط مفيد بجانب آخر heartbeat.؛ النسخة وWorker ID مهمان أثناء التحديثات.. احتفظ بالقياسات مع timestamp ونسخة التطبيق أو البيئة، لأن مقارنة أرقام من إصدارات أو شروط مختلفة قد تعطي استنتاجًا خاطئًا. وإذا كانت النتيجة رقمية، استخدم أكثر من عينة بدل أفضل أو أسوأ قيمة منفردة.

عند الفشل: ماذا تراجع أولًا؟

عند الفشل، لا تبدأ من أول Workflow تلقائيًا. تحقق من آخر checkpoint والأثر الخارجي، ثم اختر retry أو resume أو manual review وفق حالة مؤكدة. عند التحقيق استخدم هذه القائمة كحد أدنى: عدد restarts في نافذة زمنية محفوظ.؛ Backoff يزداد بين المحاولات.؛ يوجد حد أقصى قبل التوقف.؛ Crash reason محفوظ.. سجل ما الذي جربته وما الذي لم يتغير بعد التجربة. هذه المعلومة تمنع الفريق من إعادة نفس المحاولات وتساعد على تحديد ما إذا كان الخطأ في الإعداد أو الأداة أو الشبكة أو بيانات المهمة.

متى تعتمد القرار على نطاق أوسع؟

قرار الاعتماد لا يجب أن يعتمد على أن التجربة «عملت مرة». في «مراقبة Heartbeat واكتشاف Crash Loop في عمليات المتصفح» اعتبر الحل جاهزًا عندما تستطيع إعادة نفس السيناريو بنتيجة متقاربة، ويفهم شخص آخر خطوات الاختبار وحدود النتيجة، وتعرف ماذا ستفعل لو فشلت الحالة الطبيعية. لو لم تتحقق هذه الشروط، احتفظ بالحل كتجربة أو إعداد مبدئي ولا تحوله إلى Default لكل الحسابات أو المهام.