Docker: التسجيل والمراقبة

آخر تحديث: 2026-08-26

حاوية تتعطل في الثالثة صباحًا — السجلات والمراقبة هما أدواتك الوحيدة لتحديد السبب الجذري بسرعة.

1. ما ستتعلمه



2. قصة حقيقية لمهندس عمليات

(1) نقطة الألم: لا أدلة حول تنبيه OOM في الثالثة صباحًا

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

(2) حلول تصفية السجلات ومراقبة الموارد

استخدم تشارلي مزيجًا من docker logs --since و grep للعثور على الطلب غير الطبيعي في 30 ثانية.

BASH
# العثور على سجلات متعلقة بـ OOM في آخر ساعتين
docker logs --since 2h --tail 500 app 2>&1 | grep -i "oom\|memory\|error"

# التحقق من سجل استخدام الموارد
docker stats --no-stream

(3) الفائدة: تحديد السبب الجذري في 30 ثانية

من 2 جيجابايت من السجلات، حدد حدث OOM والطلب غير الطبيعي في 30 ثانية. ثم قام تشارلي بتكوين تدوير السجلات وتنبيهات Prometheus بحيث تتضمن التنبيهات المستقبلية في الصباح الباكر السبب الجذري تلقائيًا.



3. محركات سجلات Docker

(1) أربعة أنواع من محركات السجلات

100%
graph LR
    CTN["الحاوية<br/>stdout/stderr"] --> DRV["محرك السجلات"]
    DRV --> JSON["json-file<br/>افتراضي، ملفات محلية"]
    DRV --> JRN["journald<br/>سجل systemd"]
    DRV --> SYS["syslog<br/>خادم سجلات بعيد"]
    DRV --> GELF["gelf<br/>ELK/Loki"]
المحرك موقع التخزين تدوير السجلات مركزي حالات الاستخدام
json-file (افتراضي) /var/lib/docker/containers/ يتطلب تكوينًا يدويًا تطوير مستقل
journald systemd journal ✅ تلقائي systemd
syslog خادم syslog بعيد ✅ الخادم نظام تسجيل تقليدي
gelf ELK/Loki ✅ جانب الخادم منصة تسجيل مركزية
local ملفات محلية (صيغة محسنة) ✅ تلقائي سجلات محلية خفيفة
none لا تسجيل - - أداء عالي/بيانات حساسة

(2) تكوين محرك السجلات

BASH
# لكل حاوية: تحديد محرك السجلات عند التشغيل
docker run -d \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  --name app myapp:1.0
JSON
// شامل: /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}


4. الاستخدام المتقدم لـ docker logs

▶ مثال: مرشح الوقت --since (الصعوبة: ⭐⭐)

BASH
# عرض سجلات آخر ساعتين
docker logs --since 2h app

# عرض سجلات من وقت محدد
docker logs --since "2024-01-15T03:00:00" app

# عرض سجلات بين طابعين زمنيين
docker logs --since "2024-01-15T03:00:00" --until "2024-01-15T04:00:00" app

▶ مثال: حد الأسطر --tail (الصعوبة: ⭐)

BASH
# عرض آخر 100 سطر
docker logs --tail 100 app

# متابعة آخر 100 سطر في الوقت الفعلي
docker logs -f --tail 100 app

▶ مثال: المراقبة في الوقت الفعلي مع docker stats (الصعوبة: ⭐⭐)

BASH
# إحصائيات الموارد في الوقت الفعلي لجميع الحاويات
docker stats

# لقطة واحدة (بدون بث)
docker stats --no-stream

# إحصائيات لحاويات محددة
docker stats app db --no-stream

# تنسيق مخصص
docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"
💻 المخرجات:

TEXT 📖 للعرض فقط
NAME   CPU %   MEM USAGE / LIMIT
app    2.35%   150MiB / 512MiB
db     0.50%   85MiB / 256MiB

▶ مثال: تتبع الأحداث مع Docker Events (الصعوبة: ⭐⭐)

BASH
# بث أحداث Docker daemon
docker events

# تصفية حسب نوع الحدث
docker events --filter type=container

# تصفية حسب حدث محدد
docker events --filter event=oom --filter event=die

# تصفية حسب النطاق الزمني
docker events --since "2024-01-15T03:00:00" --until "2024-01-15T04:00:00"
💻 المخرجات:

TEXT 📖 للعرض فقط
2024-01-15T03:24:15Z container oom 67890... (name=app, image=myapp)
2024-01-15T03:24:15Z container die 67890... (exitCode=137, name=app)
2024-01-15T03:24:25Z container start 67890... (name=app, image=myapp)


5. استراتيجية تدوير السجلات

(1) تدوير سجلات ملفات JSON

المعامل الوظيفة القيمة الموصى بها
max-size الحجم الأقصى لملف سجل واحد 10m
max-file الحد الأقصى لعدد ملفات السجل للاحتفاظ بها 3
labels علامات النشر -
tag قالب علامة السجل -

▶ مثال: تكوين تدوير السجلات (الصعوبة: ⭐⭐)

BASH
# تكوين تدوير السجلات عند بدء الحاوية
docker run -d \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  --name app myapp:1.0
💡 نصيحة: الحاويات بدون تدوير السجلات هي "قنابل موقوتة" — ستنمو ملفات السجل إلى ما لا نهاية حتى تملأ القرص. في بيئات الإنتاج، يجب تكوين max-size و max-file، أو استخدام محرك السجلات local (الذي يتضمن تدويرًا مدمجًا).

(1) تكوين التسجيل في Compose

YAML
services:
  api:
    image: myapp:1.0
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"


6. حل التجميع المركزي للسجلات

(1) مقارنة الخيارات الثلاثة

الحل المكونات التعقيد النطاق المناسب
docker logs مدمج جهاز واحد/تطوير
ELK Stack Elasticsearch + Logstash + Kibana ⭐⭐⭐ مستوى المؤسسات
Loki + Grafana Loki + Promtail + Grafana ⭐⭐ صغير/متوسط/سحابي أصلي


7. مثال كامل: تكوين تدوير السجلات والمراقبة

BASH
# ============================================
# شرح كامل: تدوير السجلات + المراقبة
# يغطي: تدوير السجلات، الإحصائيات، الأحداث، تشخيص OOM
# ============================================

# 1. بدء التطبيق مع تدوير السجلات
docker run -d \
  --name app \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  --memory=256m \
  --restart=on-failure:5 \
  -p 5000:5000 \
  myapp:1.0

# 2. مراقبة استخدام الموارد
docker stats app --no-stream

# 3. محاكاة: تفعيل OOM بتجاوز الذاكرة
docker exec app python -c "
import numpy as np
x = np.zeros((50000, 50000))  # محاولة تخصيص ~20GB
"

# 4. التقاط حدث OOM
docker events --filter event=oom --since 1m

# 5. العثور على OOM في السجلات مع الطابع الزمني
docker logs --since 5m --tail 200 app 2>&1 | grep -i "oom\|memory\|killed"

# 6. التحقق من كود الخروج
docker inspect app --format='ExitCode: {{.State.ExitCode}}, OOMKilled: {{.State.OOMKilled}}'

# 7. تصدير آخر 1000 سطر للتحليل
docker logs --tail 1000 app > app-debug.log 2>&1

# 8. التحقق من عمل تدوير السجلات
ls -la /var/lib/docker/containers/$(docker inspect app --format='{{.Id}}')/

❓ أسئلة شائعة

س هل يمكن لملف سجل كبير جدًا أن يؤثر على القرص؟
ج نعم. افتراضيًا، محرك json-file لا يقوم بتدوير السجلات، لذا ينمو ملف السجل إلى ما لا نهاية. رأيت حالات في بيئات الإنتاج حيث وصل ملف سجل حاوية واحدة إلى 50 جيجابايت. يجب تكوين --log-opt max-size=10m --log-opt max-file=3 عند البدء أو تعيين التدوير الافتراضي شاملاً في daemon.json.
س كيف أقوم بتكوين تدوير السجلات؟
ج هناك طريقتان: ① استخدم --log-opt max-size=10m --log-opt max-file=3 عند بدء الحاوية؛ ② قم بتكوين "log-opts": {"max-size": "10m", "max-file": "3"} في التكوين الشامل /etc/docker/daemon.json. نوصي باستخدام التكوين الشامل في بيئة الإنتاج لتجنب الإغفال.
س كيف يمكنني تجميع سجلات حاويات متعددة مركزيًا؟
ج استخدم محرك سجلات gelf أو syslog لإرسال جميع سجلات الحاويات إلى منصة ELK/Loki مركزية. نهج أكثر تفضيلاً: حافظ على محرك json-file واستخدم Filebeat/Promtail لجمع ملفات السجل؛ بهذه الطريقة، سيظل docker logs يعمل.
س هل لا تزال السجلات موجودة بعد إعادة تشغيل الحاوية؟
ج نعم. إعادة تشغيل الحاوية لا تحذف ملفات السجل. ومع ذلك، docker rm يحذف السجلات عند حذف الحاوية. لاستمرار السجلات: ① اكتبها في ملفات التطبيق وركبها كوحدة تخزين؛ ② استخدم منصة تسجيل مركزية للتجميع في الوقت الفعلي.
س هل الذاكرة المعروضة بواسطة docker stats تشير إلى الحاوية أم العملية؟
ج إلى الحاوية. docker stats يعرض إجمالي استخدام الذاكرة لجميع العمليات داخل cgroup الحاوية. LIMIT هو الحد الأعلى المحدد بواسطة --memory. إذا لم يتم تعيين --memory، يعرض LIMIT إجمالي ذاكرة المضيف.

📖 ملخص


📝 تمارين

  1. تمرين أساسي (الصعوبة: ⭐): ابدأ الحاوية وعدل --log-opt max-size=5m --log-opt max-file=2، ثم استخدم docker logs لعرض السجلات وتحقق من أن التدوير دخل حيز التنفيذ.
  2. تمرين متقدم (الصعوبة: ⭐⭐): استخدم docker stats لمراقبة حاوية أثناء اختبار حمل وسجل ذروة استخدام CPU والذاكرة.
  3. تحدٍ (الصعوبة: ⭐⭐⭐): استخدم docker events لالتقاط حدث OOM لحاوية، وادمجه مع docker logs --since لتحديد الطلب أو العملية التي تسببت في OOM.
Web-Tutorial.com

فريق Web-Tutorial التقني

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

100%