أحتاج إلى البدء في مراقبة سير العمل بشكل أفضل.
كيف تقومون بذلك يا جماعة؟
@patriciaLee الإجابة الأصلية التي يفتقدها معظم الناس هي Error Workflow، قم بتعيين واحد عموميًا في Settings وسيتم تشغيله عند أي تنفيذ فاشل حتى تتمكن من إرسال الخطأ إلى Slack أو البريد الإلكتروني أو أي مكان آخر دون الحاجة إلى الاستقصاء. للتصفح والتدقيق يوجد عرض Executions مع مرشحات الحالة. وإذا كنت تستخدم النسخة ذاتية الاستضافة، قم بتعيين N8N_METRICS=true لكشف نقطة نهاية /metrics في Prometheus يمكنك جلبها إلى Grafana للحصول على لوحات تحكم وتنبيهات. Error Workflow + Metrics يغطي معظم إعدادات الإنتاج.
هناك فئتان أقيّمهما. الفئة الأولى هي صحة التنفيذ. أريد معرفة ما إذا كان التنفيذ قد بدأ أو اكتمل أو واجه خطأ. أما الفئة الأخرى فهي النتيجة التجارية. يجب أن أحدد ما إذا كان التنفيذ قد فعل ما كان مفروضاً عليه أن يفعله. هذه الفئة أصعب في التقييم. على سبيل المثال، إذا تسبب التنفيذ في تخطي أحد المرشحات لجميع السجلات، فإن التنفيذ سيكون ناجحاً مع أنه عديم الفائدة تماماً.
إذا كان سير العمل مهماً بما يكفي، فسأسجل تفاصيل أكثر تحديداً تشمل عدد السجلات المعالجة والحالة النهائية لسير العمل وسبب فشل سير العمل ومالك سير العمل والخطوة التالية المقترحة.
بالإضافة إلى الأخطاء، أراقب بعض الأعراض الأخرى. على سبيل المثال، إذا لم تكتمل سير العمل بنجاح، أو إذا انخفض عدد السجلات المعالجة إلى 0، أو إذا كان هناك عدد متزايد من محاولات إعادة المحاولة، فسأصدر تنبيهاً. أسعى دائماً لجعل التنبيهات قابلة للتنفيذ.
@patriciaLee أحسن التغطية للأساسيات (Error Workflow + عرض Executions + Prometheus/Grafana) — هذا هو الأساس الصحيح. هناك شيئان أود أن أضيفهما يغطيان ما قد يفتقده الآخرون:
-
اجعل Error Workflow قابلاً للتنفيذ فعلياً. تنبيه مجرد “فشل سير العمل” ليس كافياً. في Error Workflow العام، أرسل رسالة تتضمن اسم سير العمل، رابط التنفيذ، العقدة التي فشلت، ورسالة الخطأ — هذا يحول بحثاً لمدة 20 دقيقة إلى نقرة واحدة للانتقال إلى التشغيل المعطل. كما قم بتعيين EXECUTIONS_DATA_SAVE_ON_ERROR=all (وقم بتنظيف عمليات التشغيل الناجحة باستخدام إعدادات data-prune) حتى تحافظ على عمليات التشغيل الفاشلة للتصحيح دون إثقال قاعدة البيانات.
-
انتبه للفشل الصامت — المشكلة الفعلية التي يتم التغاضي عنها. Error Workflow والمقاييس تعمل فقط عندما يعمل سير العمل ويرمي خطأ. لكنها لا تمسك بسير عمل توقف بصمت — مشغّل توقف عن العمل، webhook تم إلغاء تسجيله، cron توقف بهدوء. هذا هو الفشل الذي يؤلم فعلاً، لأنك تكتشفه بعد أيام من العميل. الحل هو Dead-man’s switch: مشغّل Schedule يرسل ping إلى خدمة heartbeat (Healthchecks، Better Stack، أو Uptime Kuma ذاتية الاستضافة) كل بضع دقائق. إذا توقف الـ ping عن الوصول، فسيتم تنبيهك — لذلك تمسك “توقف عن العمل تماماً،” وليس فقط “عمل وأرمى خطأ.”
إذا كنت تستخدم self-hosted، أود أيضاً وضع مراقب uptime أساسي على instance/حاوية n8n نفسها، حتى تعرف ما إذا كان الكل معطلاً مقابل سير عمل واحد فقط.
إعداد متعدد الطبقات أود أن أشغله: Error Workflow مع سياق غني لفشل وقت التشغيل → Prometheus/Grafana للصحة الكلية → heartbeat/dead-man’s switch للتوقف الصامت → مراقب uptime على instance. معظم الناس يقومون بإعداد الاثنين الأولين؛ heartbeat هو الشيء الذي يتناساه الجميع تقريباً حتى يعضهم.
نقطة جيدة من @ShawnWilliams حول التمييز بين سلامة التنفيذ مقابل النتيجة التجارية. مثال من الفئة الثانية قد يساعد: لقد بنيت سير عمل يومي لا يراقب الأخطاء، بل يراقب فرص المحتوى، فهو يبحث في منشورات المنتديات ويقيّم عبر نموذج لغة كبير (LLM) ما إذا كانت ذات صلة بي، ثم يرسل ملخصًا عبر البريد الإلكتروني.
النقطة هي: “المراقبة” لا يجب أن تعني الأخطاء فقط. يمكنك استخدام نفس آلية سير عمل الخطأ للتعرف أيضًا على محفزات إيجابية، سواء كانت عملاء محتملين جدد أو محتوى أو أسئلة مفتوحة يمكنك الإجابة عليها. البنية التحتية التقنية (إعداد Achamm) تبقى كما هي، فقط الشرط الذي يُطلق التنبيه يتغير من “حدث خطأ” إلى “تم التعرف على حدث مهم”.
@patriciaLee وآخرون غطّوا الأجزاء الأساسية (Error Workflow، عرض الـ Executions، Prometheus/Grafana، والفرق بين صحة التنفيذ مقابل النتائج التجارية). سأضيف طبقة إضافية واحدة سببت لي مشاكل في بيئة الإنتاج: الأعطال الصامتة.
Error Workflows والمقاييس تساعد فقط عندما يتم تنفيذ شيء فعلي ويرمي خطأ. لا تكتشف مُشغّل توقف عن الاستجابة، أو اشتراك webhook ينتهي بهدوء (Gmail watches مثال كلاسيكي)، أو وظيفة cron لا تعمل أبداً. لا يتم تنفيذ شيء، لذا لا يتم ملاحظة أي شيء. في تجربتي، تلك غالباً ما تكون أكثر الأعطال مؤلمة لأنك تكتشفها من عميل بدلاً من المراقبة.
المنهج الذي استقررت عليه هو dead-man’s switch: سير عمل مجدول يرسل ping لخدمة heartbeat (Healthchecks.io، Better Stack، أو Uptime Kuma المستضاف ذاتياً). إذا توقف وصول heartbeat، هذا هو التنبيه. يكمل Error Workflows بكشف “توقف التشغيل تماماً”، وليس فقط “تم التشغيل وفشل”.
أنا أيضاً أحب نقطة Shawn حول النتائج التجارية. بالنسبة لسير العمل المهم، أتابع أشياء مثل السجلات المعالجة، عدد المحاولات مجدداً، أحجام الحد الأدنى المتوقعة، والملكية. سير عمل يعالج بنجاح صفر سجل قد يكون سليماً من الناحية التقنية لكنه عديم الفائدة من الناحية التشغيلية، لذا تلك المقاييس تستحق تنبيهات أيضاً.
النموذج المتعدد الطبقات الذي أثبت نجاحه معي هو:
- Error Workflow → سياق غني (سير العمل، العقدة، execution URL، تفاصيل الخطأ)
- Prometheus/Grafana → المقاييس الإجمالية والاتجاهات
- مقاييس الأعمال → السجلات المعالجة، المحاولات مجدداً، النتائج المتوقعة
- Heartbeat/dead-man’s switch → الأعطال الصامتة
- مراقبة التوفر → صحة المثيل/الحاوية
معظم الناس ينفذون الطبقتين الأوليين. طبقات heartbeat والنتائج التجارية هي التي تميل لإنقاذك من المفاجآت غير السارة لاحقاً.
الفصل الذي سأستخدمه هو الفصل الخاص بـ Shawn: حالة التنفيذ مقابل النتيجة التجارية.
بالنسبة لسير عمل العميل، سأضيف إيصالاً صغيراً للتشغيل إلى التنبيه: النافذة المتوقعة، والسجلات التي تم لمسها، والحساب/بيانات الاعتماد المستخدمة، والإجراء اللاحق الذي تم محاولته، معرّف السجل/الرسالة النهائي، ومن يمتلك الخطوة التالية. التنفيذ الأخضر أقل فائدة من إثبات ما تغيّر.
هذا الموضوع يغطي بالفعل الفصل المهم بشكل جيد — صحة التنفيذ مقابل ما إذا حدثت النتيجة الفعلية، بالإضافة إلى فكرة نبض القلب للتشغيل الذي لا ينطلق أبداً، لذا سأضيف فقط الخطأ الواحد الذي لا يزال يتسلل عبر كل ذلك. حتى مع وجود فحص لعدد السجلات وآلية إيقاف جديدة (dead-man switch)، الحالة التي تربك الناس هي التشغيل الذي يكتمل ويعالج العدد المعتاد من الصفوف ولا يرمي أي استثناء، وهو لا يزال خاطئاً، لأن بيانات الاعتماد انتهت بصمت أو تحديث مصدر ما، وعادت الواجهة برد صحيح لكنه فارغ أو استجابة افتراضية. العدد يبدو طبيعياً، الحالة خضراء، لا شيء يخطئ، لذا لا تُرفع أي من الطبقات العليا أي علم.
السبب في أن مُشغِّل الخطأ المعياري أعمى تجاه هذا هو أنه لم يكن هناك خطأ. التوكن لم يفشل بصوت عالٍ، بل أعاد 200 نظيف مع لا شيء مفيد بداخله، وسارت سير العمل بسعادة إلى الأمام. تنبيه عدد السجلات يفتقده أيضاً، لأن العدد يمكن أن يكون طبيعياً بينما المحتويات قديمة أو فارغة.
ما يمسكها دون جهد كبير هو التحقق من المحتوى وليس فقط الحضور. بعد أي استدعاء حساس للمصادقة، تأكد من حقل لا يظهر إلا عندما ينجح الاستدعاء فعلاً، بدلاً من التحقق فقط من أن الرد غير فارغ، وأضِف فحص الحداثة، هل السجل الأحدث حالياً حديث فعلاً أم أنني أنظر إلى بيانات أمس التي يتم إرجاعها إليّ. من زاوية بيانات الاعتماد تحديداً، يساعد التعامل مع النتيجة الفارغة غير المتوقعة من مصدر عادة ما يكون مشغولاً كحالة فشل بدلاً من نجاح صامت.
العقلية التي تربط كل هذا الموضوع معاً: التشغيل الأخضر مع عدد صفوف عادي ليس دليلاً على أن البيانات حقيقية، فقط أن شيئاً ما عاد. الفحص الذي يستحق الإضافة هو ما إذا كانت النتيجة حديثة وصحيحة، وليس فقط موجودة. ماذا تفعلون أنتم بخصوص حالة القدم-لكن-أخضر، أم أنها لم تؤذكم بعد؟
هذا الموضوع يغطي الطبقات الأساسية بشكل جيد: سير عمل الأخطاء مع السياق، Prometheus/Grafana، نبض القلب للأعطال الصامتة، وحالة البطء مع الحالة الخضراء التي أثارها أحدهم. هناك فجوة واحدة أود إضافتها، خاصة إذا كنت لا تشغل n8n بمعزل عن غيره:
كل ما تم ذكره حتى الآن هو أصلي من n8n. سير عمل الأخطاء، N8N_METRICS، عرض التنفيذات. هذا الخيار الصحيح إذا كان n8n هو سطح الأتمتة الوحيد لديك. لكن الكثير من الفرق ليست خالصة n8n. لديهم سيناريوهات Make، وعدد قليل من zaps في Zapier، وربما وظيفة cron، وربما نصوص برمجية أو اثنين، كلها تقوم بعمل إنتاجي حقيقي. لكل واحد لوحة تحكم خاصة به، لذا فإن “هل كل شيء سليم” يعني التحقق من ثلاثة أو أربعة أماكن مختلفة، وينبغي إعادة بناء نمط نبض القلب الذي وصفه الأشخاص هنا بشكل منفصل لكل أداة.
النمط الذي نجح معي: التعامل مع “هل تم تشغيله، هل نجح، هل فشل” كحدث بسيط واحد تطلقه من أي مكان تعيش فيه الأتمتة. استدعاء HTTP واحد من مسارات النجاح والخطأ في n8n، نفس الشيء من webhook في Make أو webhook في Zapier أو try/except في نص برمجي، كلها تهبط في مكان واحد لا يهتم بأي أداة أرسلتها. نفس فكرة نبض القلب كما هو مذكور أعلاه، فقط غير مرتبط بمنصة واحدة.
إخلاء المسؤولية حيث يجب أن أقولها بصراحة: لقد بنيت أداة لهذا الغرض تماماً (FlowPulse) بعد واجهة نفس مشكلة “أربع لوحات تحكم، لا عرض موحد” بنفسي. لا أحاول إلقاء عرض توضيحي في منتصف موضوع جيد، فقط أشير إلى أنه موجود هناك في حالة كون الجزء متعدد المنصات مفيداً لأي شخص. سعيد بالحديث عن نسخة DIY أيضاً إذا كان هذا هو أسلوبك أكثر.