لاگ را چند روز نگه داریم؟ مدت نگه‌داری، حجم و هزینه

در بیشتر سازمان‌هایی که دیده‌ام، مدت نگه‌داری لاگ هیچ‌وقت «تصمیم» نبوده؛ نتیجهٔ جانبی اندازهٔ دیسک بوده. کسی یک cron نوشته که فایل‌های قدیمی‌تر از هفت روز را پاک کند، چون دیسک پر شده بود، و آن هفت روز شده سیاست رسمی. بعد یک روز مشتری می‌گوید «سه هفته پیش پولم کم شد» و معلوم می‌شود هیچ ردی از آن روز نمانده.

عکسش را هم دیده‌ام: سازمانی که همه‌چیز را برای همیشه نگه می‌داشت، چون «شاید لازم شود»، و چند سال بعد آرشیو لاگش پر از شماره‌موبایل و نشانی مشتری بود که هیچ‌کس نمی‌دانست کجاست. هر دو اشتباه از یک جا می‌آیند: پرسیدن سؤال غلط.

سؤال درست: چه کسی، چه لاگی را، تا کِی لازم دارد؟

«لاگ را چند روز نگه داریم» یک جواب ندارد، چون «لاگ» یک چیز نیست. لاگ debug برنامه‌نویس، لاگ درخواست‌های HTTP، لاگ خطا و لاگ ممیزی (چه کسی کِی چه چیزی را تغییر داد) مخاطب متفاوت، ارزش متفاوت و ریسک متفاوت دارند. اولین قدم، جدا کردن آن‌هاست — و این فقط وقتی ممکن است که لاگ‌ها ساخت‌یافته باشند و سطح و منبعشان قابل فیلتر باشد. اگر هنوز در انتخاب سطح‌ها تردید دارید، مقالهٔ سطح‌های لاگ پیش‌نیاز همین بحث است.

مدت نگه‌داری بر اساس نوع لاگ

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

نکتهٔ ردیف آخر را جدی بگیرید: میانگین زمان کشف یک نفوذ معمولاً با هفته و ماه سنجیده می‌شود، نه ساعت. اگر لاگ ورود و تغییر دسترسی را هفت روز نگه دارید، روزی که بفهمید کسی سه ماه پیش وارد شده، چیزی برای بررسی ندارید. لاگ ممیزی را هم ترجیحاً جایی نگه دارید که همان کسی که به سرور دسترسی دارد نتواند پاکش کند.

حجم را تخمین بزنید، حدس نزنید

بیشتر تیم‌ها حجم لاگشان را نمی‌دانند، و تخمین ذهنی تقریباً همیشه کمتر از واقعیت است. روش ساده‌ای که خودم به کار می‌برم:

1. یک روز کاری معمولی (نه جمعه) را انتخاب کنید.
2. تعداد خطوط و حجم خام لاگ آن روز را برای هر سرویس بشمارید.
3. از آن، خط در ثانیه و بایت در خط را به‌دست آورید.
4. برای اوج ترافیک (مثلاً روز کمپین) ضریبی در نظر بگیرید.

اگر لاگ روی فایل است، شمارش با چند فرمان ساده ممکن است:

# تعداد خطوط و حجم خام یک روز (فایل فشرده)
zcat /var/log/myapp/app-2026-09-21.log.gz | wc -l
zcat /var/log/myapp/app-2026-09-21.log.gz | wc -c

# سهم هر سطح، اگر لاگ JSON است
zcat /var/log/myapp/app-2026-09-21.log.gz | jq -r '.level' | sort | uniq -c

فرمان سوم معمولاً جالب‌ترین است، چون نشان می‌دهد بیشتر حجم از کجا می‌آید. در سیستم‌هایی که بررسی کرده‌ام، تقریباً همیشه بخش بزرگی از حجم از چند منبع پرسروصدا آمده — مثل لاگ health check یا لاگ هر کوئری ORM — نه از لاگ‌هایی که کسی واقعاً می‌خواند.

یک مثال کار‌شده

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

• میانگین ۲۰۰ خط لاگ در ثانیه، از همهٔ سرویس‌ها روی هم.
• میانگین ۴۰۰ بایت برای هر خط JSON (با زمان، سطح، پیام، trace_id و چند ویژگی).

محاسبه:

• ۲۰۰ × ۴۰۰ = ۸۰٬۰۰۰ بایت در ثانیه، یعنی حدود ۸۰ کیلوبایت در ثانیه.
• در یک روز (۸۶٬۴۰۰ ثانیه): حدود ۶٫۹ گیگابایت.
• در یک ماه: حدود ۲۰۷ گیگابایت خام.
• با نگه‌داری ۳۰ روزه، در هر لحظه حدود ۲۰۷ گیگابایت داده نگه داشته می‌شود؛ با ۹۰ روزه، حدود ۶۲۰ گیگابایت.

حالا فرض کنید فرمان سوم بالا نشان داده که ۶۰ درصد خطوط، لاگ Information خود فریم‌ورک برای هر درخواست و health checkهاست. با حذف همین‌ها از مبدأ، حجم ماهانه از حدود ۲۰۷ به حدود ۸۳ گیگابایت می‌رسد — بدون اینکه یک خط مفید از دست برود. این، ارزان‌ترین صرفه‌جویی ممکن است.

فشرده‌سازی: کمک بزرگ، ولی نه همه‌جا

لاگ متنی و JSON تکرار زیادی دارد — نام فیلدها، نام سرویس، قالب پیام‌ها — و به همین دلیل خیلی خوب فشرده می‌شود. نسبت فشرده‌سازی به محتوا بستگی دارد؛ عدد واقعی را با gzip روی نمونهٔ لاگ خودتان اندازه بگیرید، نه از روی ادعای کسی. سه نکته:

• فشرده‌سازی در انتقال (gzip روی HTTP) پهنای باند را کم می‌کند و تقریباً همیشه ارزشش را دارد.
• فشرده‌سازی در ذخیره به ابزار بستگی دارد. ابزارهای ستونی و Loki داده را فشرده نگه می‌دارند؛ Elasticsearch علاوه بر داده، ایندکس هم می‌سازد و فضای نهایی ممکن است حتی از حجم خام بیشتر شود.
• مبنای قیمت را بپرسید. بیشتر سرویس‌ها حجم را پیش از فشرده‌سازی (یعنی حجم واقعی لاگ) حساب می‌کنند، نه حجمی که روی شبکه آمده. پس محاسبهٔ بالا را با عدد خام انجام دهید.

نمونه‌برداری یا حذف؟

وقتی حجم زیاد است، دو راه دارید: بخشی از لاگ را اصلاً ننویسید (حذف)، یا فقط درصدی از آن را نگه دارید (نمونه‌برداری، sampling). قاعدهٔ من این است:

• چیزی را که هیچ‌وقت نمی‌خوانید، حذف کنید — از مبدأ، نه در مقصد. لاگ هر health check، لاگ Information فریم‌ورک، و dump کامل بدنهٔ درخواست‌ها نامزدهای اول‌اند.
• خطا را هرگز نمونه‌برداری نکنید. یک خطای نادر دقیقاً همان است که با نمونه‌برداری ۱۰ درصدی گم می‌شود.
• اگر نمونه‌برداری می‌کنید، بر اساس درخواست باشد، نه خط. نگه داشتن ۱۰ درصد خطوطِ تصادفی یعنی هیچ درخواستی کامل نمی‌ماند. نگه داشتن همهٔ خطوط ۱۰ درصد درخواست‌ها (بر اساس trace_id) یعنی هر درخواستی که دارید، کامل است.

در ⁦ASP.NET Core⁩، حذف از مبدأ معمولاً یک تنظیم است، نه کد:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "Microsoft.EntityFrameworkCore.Database.Command": "Warning"
    }
  }
}

و اگر با Serilog لاگ درخواست می‌نویسید، می‌توانید health checkها را به سطحی بفرستید که نوشته نشود:

app.UseSerilogRequestLogging(options =>
{
    options.GetLevel = (httpContext, elapsedMs, ex) =>
        ex is not null || httpContext.Response.StatusCode >= 500
            ? LogEventLevel.Error
            : httpContext.Request.Path.StartsWithSegments("/health")
                ? LogEventLevel.Verbose
                : LogEventLevel.Information;
});

هزینه فقط دیسک نیست

وقتی دربارهٔ هزینهٔ نگه‌داری فکر می‌کنید، سه بخش را جدا ببینید:

• ذخیره: با حجم × روز رشد می‌کند. ارزان‌ترین بخش است، به شرطی که داده روی ذخیره‌ساز ارزان باشد.
• ایندکس و جستجو: دادهٔ قابل جستجوی سریع، حافظه و دیسک سریع می‌خواهد. اینجاست که هزینه در ابزارهای خودمیزبان منفجر می‌شود. (مقایسهٔ ابزارها از این زاویه را در مقایسهٔ ابزارهای مدیریت لاگ آورده‌ام.)
• آدم: کسی که سیاست حذف را اجرا و پایش کند و مطمئن شود واقعاً اجرا می‌شود.

الگوی رایج این است که لاگ را دو لایه کنید: چند هفتهٔ اخیر در ابزار جستجو، و برای لاگ‌هایی که مدت طولانی لازم‌اند (مثل ممیزی)، آرشیو فشرده روی ذخیره‌ساز ارزان که فقط در صورت نیاز بازگردانده شود. Elasticsearch با ILM و Loki با تنظیم retention این را پشتیبانی می‌کنند؛ در ساده‌ترین حالت هم یک اسکریپت شبانه که فایل‌های روز قبل را فشرده و به جای دیگری منتقل کند، کار را می‌کند.

ملاحظات حقوقی و سازمانی

اینجا عمداً کلی صحبت می‌کنم، چون الزامات به صنعت، قرارداد و قوانین حاکم بر شما بستگی دارد و باید آن را با مشاور حقوقی یا واحد حراست سازمانتان روشن کنید. چند اصل که تقریباً همه‌جا صدق می‌کند:

• حداقل و حداکثر هر دو وجود دارند. برخی صنایع و قراردادها نگه داشتن لاگ‌های مشخصی را برای مدت مشخصی الزامی می‌کنند. از آن طرف، اصل «کمینه‌سازی داده» می‌گوید دادهٔ شخصی را بیش از نیاز نگه ندارید.
• نگه‌داری طولانی، ریسک را بیشتر می‌کند. هر روز اضافه یعنی دادهٔ بیشتری که در صورت نشت، بیرون می‌رود. به همین دلیل، پیش از تصمیم دربارهٔ مدت، تصمیم بگیرید چه چیزی اصلاً نباید در لاگ باشد.
• سیاست را بنویسید. یک جدول یک‌صفحه‌ای مثل جدول بالا، با امضای کسی که مسئولش است، از ده جلسه بحث مفیدتر است — و وقتی کسی پرسید «چرا لاگ آن روز نیست؟»، جواب روشنی دارید.
• حذف را ثابت کنید. سیاستی که می‌گوید «۹۰ روز» ولی کسی بررسی نکرده که واقعاً پس از ۹۰ روز پاک می‌شود، سیاست نیست.

جمع‌بندی

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

اگر از LogMug استفاده می‌کنید، مدت نگه‌داری به پلن بستگی دارد (از ۷ روز در پلن رایگان تا ۳۶۵ روز در پلن سازمانی) و حجم، مثل همان توصیهٔ بالا، پس از باز شدن فشرده‌سازی شمرده می‌شود؛ جزئیات در صفحهٔ سهمیه و مدت نگه‌داری آمده است.

منابع و مطالعهٔ بیشتر

• NIST SP 800-92: راهنمای مدیریت لاگ امنیت رایانه — مرجع کلاسیک برای برنامه‌ریزی نگه‌داری، چرخش و آرشیو لاگ در سازمان.
• برگهٔ تقلب لاگ‌نویسی OWASP — چه رویدادهایی را ثبت کنیم، چه چیزی را نه، و حفاظت از لاگ در طول نگه‌داری.
• تنظیم retention در Grafana Loki — نمونهٔ عملی سیاست نگه‌داری متفاوت برای جریان‌های مختلف لاگ.
• مدیریت چرخهٔ عمر ایندکس (ILM) در Elasticsearch — لایه‌بندی داغ و سرد و حذف خودکار داده بر اساس سن.