كيف تمنع سجلات Docker من ملء قرص إقلاع المضيف؟

أوقف منتج السجل الذي ينمو فورًا، وحدد وجهة السجلات النشطة، ثم طبّق تدويرًا محدودًا وأصلح الخطأ أو حلقة إعادة التشغيل التي تُنشئ هذا التدفق.

على خادم NAS أو خادم منزلي قائم على Docker، قد يمتلئ قرص الإقلاع حتى عندما تكون ملفات الوسائط وقواعد البيانات موجودة في مجموعة أخرى، لأن مخرجات stdout وstderr للحاويات، وبيانات سجل systemd، وملفات التطبيقات الأصلية قد تظل مخزنة ضمن نظام الملفات الخاص بالنظام. يتمثل التسلسل الآمن في الاحتفاظ بما يكفي من الأدلة الحديثة، وإيقاف النمو غير المنضبط، وتصنيف طبقة التسجيل المسؤولة عن استهلاك المساحة، وتهيئة الاحتفاظ للخدمات الحالية والمستقبلية، والتحقق من أن التطبيق الأساسي لم يعد يُصدر الحجم نفسه من السجلات.

حدد مخزن السجلات الذي ينمو فعليًا

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

أظهرت حالة تتعلق بمساحة القرص في Docker أن الملخصات العادية لـ Docker لم تكشف المستهلك الرئيسي، لأن ملف السجل الافتراضي كان ينمو بشكل منفصل. وكان الدليل الحاسم هو سجل حاوية متزايد باستمرار ضمن مسار تخزين Docker المحلي.

افحص برنامج تشغيل السجل المكوَّن ومسار السجل لكل حاوية قيد التشغيل، ثم طابق أكبر ملف مع اسم الحاوية والرسائل الحديثة. إذا لم يفسر أي سجل للحاويات الاستخدام، فتابع فحص journald ومجلدات التطبيقات الأصلية بدل افتراض أن كل مشكلة مساحة مرتبطة بـ Docker تعود إلى json-file.

أوقف الحاوية المسببة للضوضاء قبل التنظيف الطارئ

عندما يقترب قرص الإقلاع من الامتلاء، أوقف مؤقتًا أو أوقف الحاوية التي تسجل أسرع نمو. احفظ ذيلًا محدودًا من السجل، وعدد مرات إعادة التشغيل، وحالة الخروج، وإصدار الصورة، والبيئة، والوصلات، وأول خطأ متكرر قبل استعادة المساحة.

يكتشف المسؤولون عادةً أن سجلات JSON الخاصة بالحاويات قد تستهلك المساحة المتبقية على القرص عند عدم تهيئة حد للحجم. وتحدد مناقشة طويلة على Stack Overflow نمو سجلات JSON غير المحدود باعتباره خطرًا منفصلًا على السعة عن بيانات الصور ووحدات التخزين.

لا تحذف ملف سجل نشطًا بشكل عشوائي بينما لا يزال Docker يحتفظ به مفتوحًا، ولا تزل أدلة عشوائية من شجرة البيانات الوصفية لـ Docker. استخدم إجراء التدوير أو الاقتطاع المدعوم من المنصة فقط بعد إيقاف المنتج، ثم أكد ظهور الكتل المستعادة قبل إعادة تشغيل أي خدمة متأثرة.

طبّق تدويرًا محدودًا لكل خدمة طويلة التشغيل

عيّن برنامج تشغيل سجل صريحًا وحدود تدوير محدودة في خدمة Compose أو إعدادات الحاوية. بالنسبة إلى برنامج التشغيل الشائع JSON، فإن عنصري التحكم المهمين هما الحد الأقصى لحجم الملف وعدد الملفات المحتفظ بها.

توضح مناقشة مجتمعية حول تدوير Docker أن خيارات مثل max-size وmax-file تحدد مقدار السجل المحلي الذي تحتفظ به كل حاوية. والمتطلب التشغيلي هو سياسة تدوير محدودة، وليس ملفًا واحدًا يستمر في النمو بلا نهاية.

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

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

عيّن الإعدادات الافتراضية للحاويات المستقبلية من دون افتراض أنها ستغيّر الحالية

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

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

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

أصلح الحدث الذي ينتج تدفق السجلات

تحدّ حدود التدوير من الضرر، لكنها لا تصلح حاوية تعيد التشغيل كل بضع ثوانٍ، أو تعيد محاولة الاتصال بقاعدة بيانات يتعذر الوصول إليها، أو تسجل كل فحص للصحة، أو تتعرض لهجوم أو سيل من الطلبات، أو تُركت في وضع التصحيح بعد انتهاء استكشاف الأخطاء.

تتبع أحد مستخدمي Docker سجل JSON بحجم يقارب 80 غيغابايت إلى إخراج تصحيح مفرط، ما يوضح كيف يمكن أن يؤدي الإخراج بمستوى التصحيح إلى إغراق قرص الإقلاع حتى عندما يكون التدوير هو الإجراء الوقائي الفوري.

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

تتبّع سجلات Docker وJournald وسجلات التطبيقات الأصلية بشكل منفصل

يمكن للحاوية إرسال stdout إلى Docker مع كتابة ملفاتها الخاصة أيضًا إلى وصلة ربط، كما قد ترسل خدمة Docker نفسها أحداث البرنامج الخفي إلى journald. ولكل وجهة مالك احتفاظ مختلف، وقد تملأ نظام ملفات قرص الإقلاع نفسه بشكل مستقل.

أفاد مشغلو الخوادم المنزلية بنمو مجلدات سجلات التطبيقات رغم توقعهم أن يؤدي التدوير على مستوى Docker إلى احتوائها. وتبرز حالة في مجتمع TrueNAS ضرورة تحديد طبقة التسجيل المسؤولة عن الاحتفاظ قبل تعديل الحدود.

سجّل خط أساس بعد الإصلاح لاستخدام قرص الإقلاع، وأكبر ملفات السجلات، وحجم journal، وعدد مرات إعادة تشغيل الحاويات، والنمو اليومي. ولا يكتمل الإصلاح إلا عندما تكون لكل وجهة نشطة سياسة محدودة، وتظل الخدمة المسببة للضوضاء مستقرة أثناء حملها المعتاد، ولا تؤدي إعادة تشغيل متعمدة إلى إنشاء ملفات غير محدودة من جديد.