فناوری / تحلیل و راهنمای کاربردی

قبل از پرشدن دیسک، سقف لاگ Docker را مشخص کنیم

یک بررسی کوتاه برای رشد لاگ کانتینر: تشخیص مصرف، تعیین چرخش و آزمون تنظیم؛ بدون حذف کورکورانه فایل‌ها یا ازبین‌بردن شواهد.

ADاردشیر دریانی··۲ دقیقه مطالعه
تصویر مفهومی برگه بررسی عملیات در کنار یک سرور
تصویر مفهومی اختصاصی، ساخته‌شده با هوش مصنوعی؛ بازنمایی دقیق یک محصول یا معماری تجاری نیست.

منبع فنی: درایور json-file در مستندات Docker. چک‌لیست زیر پیشنهاد مستقل این یادداشت است.

وقتی دیسک پر می‌شود، پاک‌کردن سریع لاگ ممکن است علامت را پنهان کند و شواهد خطا را از بین ببرد. پیشنهاد من این است که پیش از بحران، مالک و سقف نگهداری لاگ هر سرویس مشخص باشد.

اول مصرف را بشناسیم

  • فضای مصرف‌شده دیسک میزبان را از اندازه داده برنامه جدا بررسی کنید.
  • نوع درایور لاگ و تنظیم مؤثر همان کانتینر را ببینید.
  • علت تکرار پیام را با زمان شروع رشد تطبیق دهید.

در استفاده از json-file می‌توان سقف اندازه و تعداد فایل را تعیین کرد. مثال آموزشی زیر فقط بخش تنظیم لاگ یک سرویس Compose است؛ اندازه مناسب هر سازمان باید جدا انتخاب شود:

logging:
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

تنظیم نوشته‌شده با تنظیم فعال فرق دارد

تغییر پیش‌فرض daemon به‌صورت خودکار کانتینرهای موجود را به‌روز نمی‌کند. اعمال تنظیم باید مطابق روش استقرار، با برنامه تغییر و بررسی پس از آن انجام شود. فایل‌های داخلی لاگ را مستقیم دست‌کاری نکنید؛ Docker آن‌ها را مدیریت می‌کند.

پایان کار فقط خالی‌شدن دیسک نیست

در یک مثال فرضی، خطای اتصال باعث تولید پیوسته پیام شده است. چرخش لاگ رشد را محدود می‌کند، ولی خطای اتصال را حل نمی‌کند. بعد از اصلاح، نرخ تولید پیام و امکان بررسی رخداد را دوباره بسنجید.

مالک نگهداری، مدت موردنیاز و هشدار ظرفیت را ثبت کنید. سقف کوچک بدون مسیر نگهداری شواهد نیز می‌تواند مسئله‌ساز شود.

بررسی منبع: 2 نوامبر 2026. مثال، تنظیم پیشنهادی برای همه سرورها یا دستور حذف داده نیست.

تحلیل فناوری برای تصمیم‌های آگاهانه‌تر.همه نوشته‌ها →