أفضل الممارسات للاحتفاظ بسجلات التنفيذ لمدة 30+ يوماً في مثيل n8n موزع ذاتياً بحجم كبير

أسئلة
1

مرحبا بالجميع،

نحن نشغل مثيل n8n موزع ذاتيا (v2.32.7) على خادم Hostinger VPS في بيئة الإنتاج.

يقوم مثيلنا بتنفيذ أكثر من 1000 سير عمل يوميا (حوالي 100 ألف عملية تنفيذ في الإنتاج وفقا للوحة معلومات Insights)، ونود الاحتفاظ بسجل تنفيذ لمدة 30 يوما على الأقل لأغراض التدقيق واستكشاف الأخطاء، بما في ذلك بيانات التنفيذ (المدخلات والمخرجات والأخطاء).

نحن على دراية بإعدادات تقليم التنفيذ:

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=720
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000
EXECUTIONS_DATA_PRUNE_INTERVAL=3600

كان هدفنا الاحتفاظ ببيانات التنفيذ لحوالي شهر واحد، لذلك زدنا إعدادات الاحتفاظ وفقا لذلك. ومع ذلك، بعد إجراء هذه التغييرات، بدأ مثيل n8n في التعطل بشكل متكرر (4 أعطال في أقل من ساعة واحدة). عدنا إلى الإعدادات السابقة لاستعادة الاستقرار.

بعض السياق الإضافي:

  • موزع ذاتيا على Hostinger VPS
  • ذاكرة وصول عشوائي بسعة 16 جيجابايت
  • n8n v2.32.7
  • قاعدة بيانات PostgreSQL
  • بيئة إنتاج تحتوي على العديد من سير العمل النشطة
  • نحتاج إلى بيانات التنفيذ الكاملة للمراقبة والتدقيق (التنفيذات الناجحة والفاشلة).

أسئلتي هي:

  1. كيف تقوم الشركات التي تشغل مثيلات n8n بحجم كبير عادة بالاحتفاظ بسجلات التنفيذ لمدة 30 يوما أو أكثر؟
  2. هل تحتفظون ببيانات التنفيذ مباشرة في PostgreSQL، أم تقومون بتصديرها إلى منصة مراقبة أو تسجيل أخرى؟
  3. هل هناك معمارية موصى بها للاحتفاظ طويل الأجل بسجل التنفيذ؟
  4. هل هناك متغيرات بيئية أو تحسينات قاعدة البيانات التي يجب أخذها في الاعتبار قبل زيادة احتفاظ التنفيذ؟
  5. هل واجه أي شخص أعطالا بعد زيادة احتفاظ التنفيذ؟ إن كان الأمر كذلك، ما السبب الجذري؟
  6. هل يعتبر تخزين بيانات تنفيذ كاملة لمدة شهر واحد في PostgreSQL ممارسة سيئة بالنسبة إلى n8n بهذا الحجم، أم أنها إعداد إنتاج شائع؟

هدفنا هو توفير قابلية تدقيق كاملة دون المساس باستقرار المثيل.

سنكون ممتنين لأي توصيات أو أمثلة على إعدادات الإنتاج.

شكرا لكم!

2

مرحباً @mellkadvescalavel

تخزين 30 يوماً من payload التنفيذ الكاملة في قاعدة بيانات PostgreSQL التشغيلية الخاصة بـ n8n بحجم التنفيذ الخاص بك يسبب انتفاخاً حاداً في الجداول واستنزاف الذاكرة (OOM) أثناء استعلامات واجهة المستخدم/API، وهذا هو السبب في تعطل مثيلك؛ والحل الذي يتوافق مع معايير الإنتاج هو فصل الاحتفاظ التشغيلي قصير الأجل عن تسجيل التدقيق طويل الأجل.

3

مرحباً @mellkadvescalavel! هذا إعداد ضخم لديك! عدد الحذف الخاص بك مضبوط على 10000، لذلك حتى مع ضبط 30 يوماً، سيتم قطعك حول 10 أيام بحوالي 1000 تشغيل يومياً! قبل رفع أو تغيير أي إعداد، عندما تعطل، هل كان حاوية n8n تعاني من نقص الذاكرة أم postgres يعاني من نقص مساحة القرص؟

بناءً على أسئلتك، إليك توصياتي، وأيضاً أن يكون لديك فقط 16 غيغابايت من الذاكرة لـ 1000 تنفيذ يومياً يبدو ضيقاً جداً.

  1. أنا لست شركة، لذا لست متأكداً، لكنني أرى الكثير من الأشخاص يستخدمون عقد الحذف والحلقة للتعامل مع القيود. لا تبقيها في n8n، يمكن لـ Postgres الاحتفاظ بنافذة من 7-14 يوماً للتصحيح ولكن أي شيء أطول من ذلك يجب أن يذهب إلى مسجل أو موقع آخر

  2. يجب عليك تصدير وإرسال البيانات التي تحتاجها إلى مصدر آخر.

  3. يجب عليك استخدام طبقتين، postgres مع حذف كبير، وثم النتائج إلى متجر أو موقع منفصل خاص بك. ربما webhook أو شيء يمكنه الاستقبال.
    شيء مثل N8N_EXECUTION_DATA_STORAGE_MODE=s3 للحفاظ على postgres صغير

  4. نعم، هذه تعمل - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none - يحتفظ بالأخطاء فقط

  5. بالنسبة للأعطال، إنها إما postgres أو أخطاء OOM.

  6. على نطاقك، من المحتمل أن تكون مضادة للنمط، إنها ما سيحطم قاعدة بيانات ur ويسبب المزيد من المشاكل.

4

هذان الإعدادان للاحتفاظ متناقضان. EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000 يحد من التنفيذات المحتفظ بها عند 10,000 حتى لو كان EXECUTIONS_DATA_MAX_AGE=720. بمعدل حوالي 1,000 عملية تشغيل يومياً، يفوز حد العدد بعد حوالي عشرة أيام تقريباً.

لن أسمي امتلاء جدول الأعطال أو فشل الذاكرة العشوائية حتى الآن. تحقق من سبب خروج الحاوية وسجلات PostgreSQL بشكل منفصل. تحقق أيضاً من مساحة القرص الحرة. كل منها يشير إلى فشل مختلف وإصلاح مختلف.

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

قس يوماً عادياً واحداً من بيانات التنفيذ المحتفظ بها، ثم وسّعها عبر 30 يوماً. عدد التنفيذات وحده لا يخبرك ما إذا كانت هذه نسخة Postgres والقرص قادرة على حمل النافذة.