مرحباً بالجميع
أنا أقوم بتوسيع منصة n8n متعددة المستأجرين وبدأت أدرك أن السجلات الأساسية لم تعد كافية.
Load Balancer
↓
عدة عمال n8n
↓
PostgreSQL + Redis + واجهات برمجية خارجية
مع نمو عدد المستأجرين وسير العمل، أجد صعوبة في الإجابة على أسئلة مثل:
• أي مستأجر ينتج أكبر حمل؟
• لماذا فشل سير عمل محدد؟
• أين نقاط الاختناق في النظام؟
• أي واجهات برمجية خارجية تسبب تأخراً؟
• كيف يمكنني اكتشاف المشاكل قبل أن يلاحظها العملاء؟
أنا أفكر في إضافة:
• تسجيل مركزي
• جمع المقاييس
• تتبع موزع
• لوحات معلومات لكل مستأجر
• التنبيهات واكتشاف الشذوذ
tenant_id
workflow_id
execution_time
error_rate
queue_depth
API_latency
صف المشكلة/الخطأ/السؤال
ما هي مكدس الملاحظة الذي تستخدمه؟ما هي المقاييس الأكثر قيمة؟
ما رسالة الخطأ (إن وجدت)؟
يرجى مشاركة سير العمل الخاص بك
(حدد العقد على لوحتك واستخدم اختصارات لوحة المفاتيح CMD+C/CTRL+C و CMD+V/CTRL+V لنسخ ولصق سير العمل.)
شارك المخرجات التي أرجعتها العقدة الأخيرة
معلومات حول إعداد n8n الخاص بك
- إصدار n8n:
- قاعدة البيانات (الافتراضي: SQLite):
- إعداد n8n EXECUTIONS_PROCESS (الافتراضي: own, main):
- تشغيل n8n عبر (Docker, npm, n8n cloud, سطح المكتب):
- نظام التشغيل:
مرحباً @Selena_Gloria بمجرد أن تبدأ بتوسيع نطاق العمل ليشمل المزيد من المستأجرين وسير العمل، يصبح من الصعب جداً فهم ما يحدث من خلال النظر إلى السجلات وحدها.
يتضمن إعداد الإنتاج الشائع ما يلي:
السجلات المركزية
جمع المقاييس
التنبيهات
تتبع المسار (عند الحاجة)
المقاييس التي أجدها مفيدة جداً هي:
•معرّف المستأجر (tenant_id)
•معرّف سير العمل (workflow_id)
•وقت التنفيذ
•معدل الأخطاء
•عمق الطابور
•وقت استجابة واجهة برمجة التطبيقات الخارجية
وضع علامات على السجلات والمقاييس باستخدام معرّف المستأجر يجعل من الأسهل بكثير استكشاف الأخطاء وإصلاحها لعميل معين دون التأثير على الآخرين.
أوصي أيضاً بإعداد تنبيهات لأشياء مثل معدلات الأخطاء المرتفعة وتراكم الطوابير المتزايدة وأعطال العمال والواجهات البطيئة والارتفاعات المفاجئة في حركة المرور. بهذه الطريقة، يمكنك اكتشاف المشاكل قبل أن يبدأ المستخدمون بالإبلاغ عنها.
الخطأ الذي يجب تجنبه هو الاعتماد على سجلات التطبيق فقط أو مراقبة البنية التحتية فقط. إن الحصول على رؤية شاملة لكل من البنية التحتية وسير العمل الخاص بك يعطيك فهماً أفضل بكثير لما يحدث.
بشكل عام، فإن الجمع بين السجلات المركزية والمقاييس لوحات التحكم والتنبيهات يجعل من الأسهل بكثير الحفاظ على صحة المنصة مع نموها.
نقاط رائعة، وأتفق بشكل خاص على أن وسم البيانات بـ tenant_id و workflow_id يجعل استكشاف الأخطاء أسهل كثيراً. شكراً على المشاركة!
سأضيف مقياسًا واحدًا ليس بالفعل من البنية التحتية: إيصال الإجراء لكل تشغيل.
المستأجر والسير العملي ومعدل الخطأ والكمون يخبرك بمكان المشكلة. يخبر الإيصال العميل بما حدث: التشغيل المتوقع والبيانات المعتمدة/الحساب المستخدم والسجلات التي تم لمسها وواجهة برمجة التطبيقات الخارجية التي تم استدعاؤها ومعرف الكائن/الرسالة النهائي وحالة الإيقاف المؤقت أو إعادة المحاولة.