مراقبة أخطاء n8n: تنبيهات تلقائية، تشخيص، استعادة

التفاصيل البرمجية والتهيئة

مقدمة حول سير العمل

سير عمل يراقب كل executions في n8n، يلتقط الفشل فوراً، يصنّف الأخطاء، يرسل تنبيهات مع تشخيص، ويعيد المحاولة تلقائياً للأخطاء العابرة. ضروري لأي n8n في الإنتاج.

الهدف من سير العمل

تقليل MTTR (Mean Time To Resolution) للـ workflows المعطّلة من ساعات (اكتشاف عرضي) إلى دقائق (تنبيه فوري). والاستعادة التلقائية للأخطاء العابرة دون تدخل بشري.

الأدوات والتقنيات المستخدمة

تم استخدام الأدوات التالية: n8n و telegram و apitable

تفاصيل تنفيذ سير العمل

• مستوى الصعوبة: متوسط
• الوقت المتوقع للإعداد:
• محفز التشغيل (Trigger):

خطوات العمل (الآلية)

1. أنشئ workflow جديد باسم ‘Error Monitor’. ابدأ بـ Error Trigger.
2. في كل workflow حرج، Settings → Error Workflow → اختر ‘Error Monitor’.
3. Error Trigger يستلم: workflow name، execution_id، error.message، error.stack، last_node.
4. Code Node لتصنيف: regex على error.message للكشف عن transient (timeout, ECONNRESET, 502/503/504) vs critical.
5. Switch: للـ transient → Wait 30s → HTTP Request لإعادة تشغيل الـ execution عبر n8n API.
6. إذا الإعادة نجحت: log في APITable كـ ‘recovered’.
7. إذا فشلت أو الخطأ critical: Telegram alert مع: اسم الـ workflow، الـ node المعطّل، رسالة الخطأ، رابط الـ execution.
8. APITable insert: timestamp، workflow، error_type، message، resolution_status.
9. Schedule جانبي: تقرير أسبوعي يلخّص الأخطاء — أكثر workflows فشلاً، أكثر الأسباب.

وصف مفصل

## المشكلة n8n في الإنتاج يفشل بصمت أحياناً: API خارجي يتوقف، rate limit، خطأ syntax بعد تعديل. اكتشاف العطل عادة عبر شكوى من فريق أو ملاحظة فقدان بيانات. مكلف. ## المُدخلات – n8n instance (Error Trigger مدعومة) – Telegram bot للتنبيهات – Discord webhook (اختياري، مماثل) – APITable لتسجيل الأخطاء ## المُخرجات – تنبيه فوري لكل failed execution – تصنيف الخطأ (transient, configuration, code) – إعادة محاولة تلقائية للـ transient – أرشيف أخطاء للتحليل ## مخطط Mermaid “`mermaid graph TD A[Any workflow fails] –>|Error Trigger| B[Error Workflow] B –> C[Extract error details] C –> D{Classify error} D –>|Transient: timeout, 5xx| E[Wait + Retry] D –>|Configuration: 401, 404| F[Telegram critical alert] D –>|Code: syntax, ReferenceError| F E –> G{Retry succeeded?} G –>|Yes| H[Log to APITable as recovered] G –>|No| F F –> I[APITable insert] I –> J[Add to weekly report] “` ## نقاط الفشل – Error workflow نفسه يفشل: لا يُلتَقط (paradox). الحل: webhook خارجي بسيط (UptimeRobot) يفحص n8n نفسه دورياً – Telegram bot معطّل: تنبيه لا يصل. الحل: قناة بديلة (Discord) كـ fallback – إعادة المحاولة قد تخلق effects (إرسال إيميل مزدوج). فعّل فقط لـ workflows idempotent – rate limit من Telegram إذا كثرت الأخطاء: bunch alerts بدلاً من رسالة لكل خطأ ## نقاط المراجعة البشرية – كل تنبيه يُقرأ بشرياً — لا قرارات تلقائية بناء على نوع الخطأ – إعادة المحاولة محصورة في scenarios آمنة (idempotent) – تقرير أسبوعي يُراجع، الـ patterns تستخدم لتحسين الـ workflows الأصلية ## اعتبارات الخصوصية Stack traces قد تحوي بيانات حساسة (مثلاً: نص رسالة كان يُعالَج). فلتر المحتوى قبل التسجيل. لا تضع stack الكامل في Telegram alert — رابط لـ APITable فقط. ## ملاحظات الصيانة تحديث regex التصنيف عند ظهور أخطاء جديدة. اختبار الـ Error Workflow شهرياً بإحداث فشل متعمد.