سجلات الحاويات وكيف لا تفقدها

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

كيفية القراءة

docker logs -f --tail 100 <container>
docker compose logs -f app
docker compose logs --since 30m --timestamps app
docker logs <container> 2>&1 | grep -i error | tail -50

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

docker compose exec app ls -la /var/log

تحديد الحجم الآن

الإعداد العام لجميع الحاويات هو /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "20m", "max-file": "3" }
}

sudo systemctl restart docker

يسري الإعداد على الحاويات المنشأة بعد إعادة التشغيل. أما الحاويات قيد التشغيل فيجب إعادة إنشائها. لخدمة واحدة، يوضع الإعداد نفسه في Compose:

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "3"

النتيجة: لا يزيد عن 60 ميغابايت لكل خدمة بدلًا من نمو غير محدود.

تحقق من الحجم الحالي قبل أن يفاجئك: sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail. لا يمكنك تقليص ملف قيد التشغيل باستخدام rm — لا تُحرَّر المساحة طالما يحتفظ Docker بوصف الملف. الطريقة الصحيحة: إعادة إنشاء الحاوية أو sudo truncate -s 0 <file>.

اجعل السجلات تنجو من الحاوية

يُحذف ملف السجل مع الحاوية. إذا كان السجل مهمًا، فسلّمه إلى سجل النظام:

logging:
  driver: journald
  options:
    tag: "myapp"

journalctl -t myapp -n 200 --since today
journalctl -t myapp -p err --since "2 days ago"

يدوّر journald السجلات من تلقاء نفسه، ويحدّه إعداد SystemMaxUse في /etc/systemd/journald.conf. للتحقق من المساحة التي يشغلها: journalctl --disk-usage.

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

ما الذي تبحث عنه عند تصحيح انقطاع الخدمة

1. آخر 200 سطر قبل الانهيار: docker logs --tail 200 <container>.
2. رمز الخروج: docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>. الرمز 137 وtrue في OOMKilled يعنيان أن النواة قتلت العملية بسبب نفاد الذاكرة — راجع حدود الموارد.
3. سجل نظام الجهاز: sudo dmesg -T | tail -50 سيعرض عمليات القتل بسبب نفاد الذاكرة وأخطاء القرص.

أخطاء شائعة

• امتلأ القرص بالسجلات وتعطلت كل الخدمة. تحديد الحجم أمر لا بد منه مباشرة بعد تثبيت Docker.
• النظر في سجل حاوية محذوفة بالفعل. بعد docker compose down يكون قد اختفى. اجمع السجلات في journald مسبقًا.
• الأسرار في السجل. تحب التطبيقات طباعة سلاسل الاتصال مع كلمات المرور. يمكن لأي شخص لديه وصول إلى الجهاز قراءة السجل.
• البحث عن الخطأ في وحدة التحكم النصية. فهي دائمًا 80×24 وتُقطع الأسطر الطويلة. لقراءة السجلات، يكون SSH أو وحدة تحكم “Screen” أكثر ملاءمة.