حدّد أولًا سجل Plex أو الحاوية الذي يزداد حجمه ومدى سرعة ذلك؛ لا تحذف السجلات عشوائيًا بينما تواصل العملية إنتاج الخطأ نفسه.
قد يتسبب امتلاء قرص النظام في أضرار تتجاوز قابلية المراقبة: فقد تحتاج قواعد البيانات وتحديثات الحزم والحاويات أيضًا إلى مساحة خالية. قِس النمو خلال فترة زمنية قصيرة، واحتفظ بعينة تلتقط الحدث المتكرر، ثم أصلح الحالة المسببة للضجيج قبل تشديد سياسة الاحتفاظ. الهدف هو تسجيل محدود الحجم مع إصلاح السبب الجذري، وليس كبت السجلات نهائيًا.
حدّد الكاتب والملف بدقة
يمكن أن تنمو مخرجات الحاوية القياسية، وسجلات تطبيق Plex، وسجلات الوكيل الوسيط، وسجلات المضيف بشكل مستقل. لا يكفي تحديد المجلد الأكبر؛ بل تحتاج إلى معرفة العملية ونمط الرسالة اللذين يفسران هذا النمو.
يمكن لـ Docker التقاط المخرجات القياسية والأخطاء القياسية للحاوية عبر نظام التسجيل الخاص به، بينما يكتب التطبيق أيضًا ملفاته الخاصة، لذا قارن بين المسارين قبل تغيير سياسة الاحتفاظ.
استخدم فحوصات استخدام القرص ونمو الملفات على مدار عشر دقائق، ثم التقط عينة قصيرة من الملف الأسرع نموًا. إذا تكررت رسالة واحدة باستمرار، فأصلح هذه الحالة قبل زيادة وتيرة التدوير.
أصلح الأخطاء المتكررة قبل تقليل مدة الاحتفاظ
يمكن لتركيب غير مضبوط، أو تبعية يتعذر الوصول إليها، أو حلقة تعطل وإعادة تشغيل أن يولّد تسجيلًا يفوق التشغيل الطبيعي بكثير. إذ إن قِصر مدة الاحتفاظ يخفي العَرَض دون تقليل عبء الكتابة.
طبّق فحوصات الأخطاء والتشبع على التبعية المذكورة في الرسالة المتكررة، ثم أعد إنتاج الحالة مرة واحدة بعد الإصلاح المفترض.
إذا انخفض نمو السجلات بعد حل الخطأ الأساسي، فاحتفظ بنافذة تشخيص متوسطة. وإذا لم ينخفض، واصل تتبع الكاتب بدلًا من تقليص مدة الاحتفاظ مرة أخرى.
حدّد نافذة الاحتفاظ وفق الحاجة التشغيلية
لا يعني الاحتفاظ الأطول أنه أكثر أمانًا تلقائيًا عندما نادرًا ما تُستخدم السجلات بعد استكشاف الأعطال الحديثة. ينبغي أن تغطي النافذة المفيدة الفترة اللازمة لاكتشاف الحوادث العادية مع مراعاة سعة قرص النظام.
بالنسبة إلى عمليات النشر الصغيرة، خلصت مفاضلات الاحتفاظ بالسجلات إلى تراجع القيمة التشغيلية للنوافذ الطويلة جدًا في عمليات النشر الصغيرة، مما يدعم وضع سياسة واضحة بدلًا من اعتماد قيمة افتراضية غير محدودة.
قدّر حجم السجلات اليومي بعد إصلاح الخطأ، واضربه في نافذة استكشاف الأعطال المطلوبة، واحتفظ بهامش من المساحة الخالية لحالة Plex والتحديثات. وثّق قيمة الاحتفاظ بجوار تخطيط بيانات التطبيق المستمرة حتى تبقى بعد استبدال الحاوية.
تحقّق من أن القرص لم يعد يمتلئ بلا حدود
لا تنجح قاعدة الاحتفاظ إلا إذا استقرت المساحة المستخدمة أثناء التشغيل العادي وكذلك أثناء إعادة إنتاج خطأ مقصودة. وينبغي للمراقبة أن تؤكد أن آلية التنظيف تعمل فعلًا.
قِس المساحة الخالية، وحجم مجلد السجلات، وعمر أقدم ملف محتفظ به لمدة دورة تدوير كاملة واحدة على الأقل. إذا لم يتحرك الحد الأقدم كما هو متوقع، فأصلح آلية التدوير قبل إعلان إغلاق الحادثة.
احتفظ بالعينة الأصلية ذات النمو المرتفع مع ملاحظات الحادثة، وليس على وحدة تخزين النظام المباشرة. وبذلك تحفظ الأدلة دون السماح لمسار سجلات الإنتاج بالنمو بلا حدود.
الدعم والنصائح
المزيد للقراءة

هل يمكن لـ Jellyfin مشاركة وحدة معالجة رسومات أو مسرّع بأمان مع حاوية أخرى؟
مشاركة وحدة معالجة الرسومات (GPU) مشروطة: تحقّق من ظهور الجهاز ودعم برنامج التشغيل، ثم شغّل كلا الحملين وراقب التحوّل إلى بديل برمجي.

كيفية معرفة ما إذا كان خطأ Jellyfin ناتجًا عن العميل أم الخادم
يكون خطأ Jellyfin من جهة العميل عندما يحدث مع جهاز واحد؛ ويكون من جهة الخادم عندما تفشل عدة عملاء عبر المسار نفسه وتتوافق السجلات.

كيفية تهيئة ذاكرة التخزين المؤقت والتخزين المؤقت في Jellyfin
افصل بين الحالة الدائمة وذاكرة التخزين المؤقت القابلة لإعادة البناء وتخزين التحويل المؤقت، ثم تحقّق من السعة والأذونات باستخدام اختبار تشغيل فعلي.

