مرحباً بالجميع
أنا أقوم بتوسيع منصة n8n متعددة المستأجرين وبدأت أدرك أن السجلات الأساسية لم تعد كافية.
العمارة الحالية: موازن الحمل
↓
عمال n8n متعددون
↓
PostgreSQL + Redis + واجهات برمجية خارجية
مع نمو عدد المستأجرين وسير العمل، أجد صعوبة في الإجابة على أسئلة مثل:
• أي مستأجر يولد أكثر حمل؟
• لماذا فشل سير عمل معين؟
• أين الاختناقات في النظام؟
• أي واجهات برمجية خارجية تسبب تأخيراً؟
• كيف يمكنني اكتشاف المشاكل قبل أن يلاحظها العملاء؟
أنا أفكر في إضافة:
• تسجيل مركزي
• جمع المقاييس
• تتبع موزع
• لوحات تحكم لكل مستأجر
• التنبيهات واكتشاف الشذوذ
مثال على المقاييس: tenant_id
workflow_id
execution_time
error_rate
queue_depth
API_latency
أي مكدس قابلية ملاحظة تستخدم؟
أي المقاييس كانت الأكثر قيمة بالنسبة لك؟
وصف المشكلة/الخطأ/السؤال
ما هي رسالة الخطأ (إن وجدت)؟
يرجى مشاركة سير عملك
(حدد العقد على لوحتك واستخدم اختصارات لوحة المفاتيح CMD+C/CTRL+C و CMD+V/CTRL+V لنسخ ولصق سير العمل.)
Hey @Greg_John مع نمو منصتك، يصبح من الصعب فهم ما يحدث بمجرد النظر إلى السجلات. لذلك فإن وجود قابلية مراقبة جيدة مهم جداً.
يتضمن الإعداد الإنتاجي النموذجي:
تسجيل مركزي
جمع المقاييس
التنبيهات
تتبع العمليات (إذا لزم الأمر)
الأشياء الأكثر فائدة في المراقبة هي:
• tenant_id
• workflow_id
• وقت التنفيذ
• معدل الأخطاء
• عمق الطابور
• وقت استجابة واجهة برمجة التطبيقات الخارجية
إضافة tenant_id و workflow_id إلى السجلات والمقاييس الخاصة بك يجعل من الأسهل بكثير العثور على مشاكل واستكشاف الأخطاء الخاصة بعميل أو سير عمل معين.
من الجيد أيضاً إعداد تنبيهات لـ:
معدلات الخطأ العالية
تراكم أعمال الطابور
أعطال العاملين
واجهات برمجة التطبيقات الخارجية البطيئة
ارتفاعات غير متوقعة في حركة المرور
الخطأ الذي يجب تجنبه هو الاعتماد فقط على سجلات التطبيق أو مراقبة البنية التحتية فقط. تحتاج إلى رؤية شاملة لكل من سير عملك والأنظمة التي تقوم بتشغيلها.
باختصار، تجميع السجلات والمقاييس الخاصة بك بشكل مركزي، وتوسيمها بشكل صحيح، وإعداد لوحات المعلومات والتنبيهات سيساعدك على اكتشاف المشاكل مبكراً والحفاظ على منصتك تعمل بسلاسة مع نموها.
مرحباً @Greg_John
n8n يأتي مع نقطة Prometheus الخاصة به، لذا طبقة التجميع عبارة عن تغيير في الإعدادات وليس شيء تبنيه بنفسك. عيّن هذا على الأجهزة الرئيسية والعمال:
عمق الطابور يأتي من n8n_scaling_mode_queue_jobs_waiting و n8n_scaling_mode_queue_jobs_active. يقرأ n8n هذه من Bull ويعرضها على الأجهزة الرئيسية فقط، لذا وجّه وظيفة المسح إلى الأجهزة الرئيسية لحالة الطابور وإلى العمال لأوقات التنفيذ والعقد. معرّف سير العمل هو أفضل تسمية يصدرها n8n، لا توجد بُعد المستأجر، لذا قم بدمج سير العمل إلى المستأجر في إعادة تسمية Prometheus أو قاعدة التسجيل وبناء عروض المستأجر فوق تلك السلسلة. احتفظ بـ /metrics على الشبكة الداخلية، فهو يعرض التفاصيل التشغيلية عن المثيل.
شكراً، هذا مفيد جداً فعلاً. أنا أحب النقطة بخصوص وضع علامات على كل شيء باستخدام tenant_id و workflow_id—هذا سيجعل استكشاف الأخطاء أسهل بكثير في إعداد متعدد المستأجرين. أتفق أيضاً بأن مراقبة سير العمل مهمة بنفس أهمية مراقبة البنية التحتية. شكراً لك على مشاركة هذا.
معظم هذا الموضوع عبارة عن نصائح عامة حول القابلية للرصد. الأجزاء الخاصة بـ n8n هي المكان الذي تعيش فيه الإجابات على أسئلتك الخمسة بالفعل، لذا:
عمق الطابور وحمل كل مستأجر مكشوفان بالفعل — لا تحتاج إلى بنائهما. يشحن n8n نقطة نهاية Prometheus معطلة بشكل افتراضي: N8N_METRICS=true يعطيك /metrics على الرئيسية. الأعلام التي تهمك في حالتك هي N8N_METRICS_INCLUDE_QUEUE_METRICS (هذا هو queue_depth الخاص بك)، و N8N_METRICS_INCLUDE_WORKFLOW_ID_LABEL و N8N_METRICS_INCLUDE_NODE_TYPE_LABEL (سلسلة لكل سير عمل ولكل نوع عقدة، وهي كيف يصبح “أي مستأجر ينتج الحمل الأكثر” و “أي واجهة برمجية خارجية بطيئة” استعلام PromQL واحد بدلاً من مشروع تسجيل). قم بكشطه في أي شيء تقوم بتشغيله بالفعل. راقب القاعدة إذا كان لديك الكثير من سير العمل — تسمية معرّف سير العمل هي ما يجعلها مفيدة وأيضاً ما يجعلها مكلفة.
مقياس معدل الخطأ الخاص بك سيكذب عليك، وهذا هو الذي يلدغ على نطاق متعدد المستأجرين. ينتهي تنفيذ n8n بحالة success في الكثير من الحالات حيث لم يحدث شيء فعلياً: عقدة تُرجع صفراً عناصر فقط تمرر صفراً عناصر في اتجاه مجرى الأنهار وكل شيء بعده يصمت بدون عمليات؛ IF بدون فرع مطابق؛ إخراج done من Split In Batches الذي لم يقم أحد بتوصيله. التنفيذ أخضر، معدل الخطأ يبقى مسطحاً، وبيانات المستأجر ببساطة لم تتحرك. لذا لا تراقب الأخطاء فقط — أكد على النتائج. أصدر عدد عناصر في نهاية كل سير عمل لمستأجر وتنبيه على processed == 0 عندما لا يكون الصفر نتيجة مشروعة. النجاح الصامت هو وضع الفشل الذي يصل إلى عملائك قبل أن يصل إلى لوحة المعلومات الخاصة بك.
“اكتشف المشاكل قبل أن يلاحظها العملاء” تحتاج إلى مفتاح الرجل الميت، وليس تنبيهاً. مشغل الخطأ / سير عمل الخطأ هو خطاف التنبيه الصحيح لكل مستأجر — قم بتعيينه لكل سير عمل، وضع ما يكفي في الحمل ليكون قابلاً للتنفيذ ($execution.id واسم سير العمل والعقدة الفاشلة وبيانات آخر عقدة؛ تنبيه يقول فقط “فشل سير العمل” يكلفك جلسة تصحيح أخطاء في كل مرة). لكن لاحظ ما لا يمكنه القيام به هيكلياً: مشغل الخطأ لا يُطلق أبداً لتنفيذ لم يبدأ أبداً. مشغل جدول معطل، عامل عالق، سير عمل قام شخص ما بإلغاء تفعيله — كل ذلك ينتج صمتاً، والصمت يبدو تماماً مثل “كل شيء بخير.” الحل معكوس: اجعل كل سير عمل للمستأجر ينطقم برنامج مراقبة في الإكمال، وتنبيه عند فقدان البينج. هذا الفحص الواحد يلتقط فئة الفشل بأكملها التي لا تستطيع السجلات رؤيتها من خلال البناء.
اختناقك هو على الأرجح execution_entity. بحجم متعدد المستأجرين، جدول بيانات التنفيذ هو ما يجعل Postgres بطيئاً، وينمو بهدوء. EXECUTIONS_DATA_PRUNE=true مع EXECUTIONS_DATA_MAX_AGE حقيقي و EXECUTIONS_DATA_PRUNE_MAX_COUNT، وللمستأجرين ذوي الحجم المرتفع فكر في EXECUTIONS_DATA_SAVE_ON_SUCCESS=none — الاحتفاظ بحمولات النجاح الكاملة لكل تشغيل هو تكلفة كبيرة للبيانات التي لن تفتحها أبداً. قم بالتقليم قبل تحسين الاستعلامات؛ الكثير من “n8n بطيء” يتحول إلى هذا.
شيء واحد يستحق القرار مبكراً لأنك متعدد المستأجرين: يحتوي جدول التنفيذ هذا على حمولات المستأجرين الفعلية. إذا كان أي منهم في الاتحاد الأوروبي، فإن قاعدة بيانات التنفيذ هي موقع معالجة، والاحتفاظ هناك هو مسألة امتثال، وليس واحدة فقط على القرص. أرخص بكثير لتعيين السياسة الآن بدلاً من شرحها لاحقاً.