مراقبة المهام المتوازية: ما الذي يجب تسجيله بجانب Success و Failed

لو انتهت 90 مهمة Success و 10 Failed قد تبدو النتيجة جيدة، لكن ربما استغرقت الناجحة ثلاثة أضعاف الزمن بسبب ضغط CPU، أو أن الفاشلة كلها بدأت عند قمة التزامن. مراقبة parallel workflows تحتاج مقاييس زمنية وسعة تربط المهمة بال worker والبروفايل.

سجل دورة حياة كاملة

لكل job احفظ enqueuedAt و startedAt و finishedAt. الفرق الأول queue wait والثاني run duration. هذان الرقمان يكشفان هل المشكلة نقص workers أم بطء داخل المهمة.

أضف attempt و error taxonomy

سجل رقم المحاولة و error code ثابت و step. رسالة نصية فقط صعبة التجميع. فرّق network و selector و auth و resource و validation. هذا يسمح بمقارنة failure rate مع concurrency.

راقب الموارد عند البداية والنهاية

لا تحتاج profiling كامل لكل job، لكن snapshots ل ـCPU/RAM و open browsers وعدد active tasks تساعد. إذا ارتفع P95 duration عند activeTasks فوق 6، لديك دليل على saturation.

استخدم traces للعينات لا لكل شيء

Screenshots و DOM dumps مكلفة وحساسة. فعّل trace مفصلًا لل ـfailed jobs أو نسبة صغيرة sampled. احتفظ بال metadata للجميع. هذا يوازن التشخيص والتكلفة.

راقب fairness

Priority queues قد تجوع jobs منخفضة الأولوية. راقب oldest age حسب priority/profile. مهمة لا تبدأ لساعات رغم نجاح النظام العام مشكلة يجب أن تظهر.

ابنِ لوحة Saturation تربط التزامن بالنتيجة

اعرض concurrency الفعلية مع P50/P95 duration و CPU و RAM و failure rate في نفس الرسم. ارفع الحد تدريجيًا في اختبار مضبوط. النقطة التي يتوقف فيها throughput عن الزيادة بينما P95 أو failures ترتفع هي saturation العملية. احتفظ بنتيجة حسب نوع workload؛ browsing خفيف ليس مثل video أو automation كثيف. عند الإنتاج، إذا اقتربت المؤشرات من هذه النقطة، قلل قبول jobs أو concurrency قبل أن يتحول النظام إلى crash storm.

ميّز Saturation من Memory Leak

كلاهما قد يرفع RAM ويبطئ المهام، لكن saturation تتحسن عادة عند خفض concurrency بينما leak تستمر الذاكرة في الصعود عبر الزمن حتى مع حمل ثابت. نفذ اختبار step-load: ارفع concurrency ثم اخفضها وراقب هل RSS تعود قريبًا من baseline بعد GC ودورة هدوء. شغّل soak طويل بحمل ثابت لاكتشاف slope. إذا بقيت الذاكرة مرتفعة بسبب cache مقصود، وثق upper bound. هذا يمنع خفض concurrency لمعالجة leak أو مطاردة leak بينما المشكلة مجرد ضغط مؤقت.

حوّل الفكرة إلى سيناريو قابل للإعادة

لتقييم «مراقبة المهام المتوازية: ما الذي يجب تسجيله بجانب Success و Failed» اكتب workflow صغيرًا له بداية معروفة ونهاية قابلة للقياس، ثم اختبر happy path وحالة timeout وحالة إعادة التشغيل. يجب أن يكون واضحًا ما إذا كانت الخطوة قابلة للتكرار بأمان، وما الذي يحدث إذا نُفذت مرتين، وأين تحفظ حالة التقدم. بعد ذلك شغّل السيناريو على بيانات اختبار لا على حساب إنتاجي، وسجّل سبب كل retry والوقت المستغرق. هذه التفاصيل تمنع نجاحًا ظاهريًا في أول تشغيل ثم فشلًا صعب التفسير عندما تعمل المهام بالتوازي أو تستأنف بعد crash.