Log Rotation: یہ کیسے کام کرتا ہے، روٹیشن حکمت عملیاں اور موبائل پروجیکٹس کے لیے کنفیگریشن

Log Rotation کیا ہے

Log Rotation فعال لاگ فائل کو وقتاً فوقتاً نئی فائل سے تبدیل کرنے کا عمل ہے جس کے ساتھ پرانی فائل کو آرکائیو، کمپریس یا حذف کیا جاتا ہے۔ روٹیشن کے بغیر، ایک واحد لاگ فائل غیر معینہ مدت تک بڑھتی رہتی ہے جب تک کہ وہ پوری ڈسک پارٹیشن کو بھر نہ دے، جس سے ایپلیکیشن فیل اور ڈیٹا ضائع ہوتا ہے۔

عام منظر نامہ: ایک ایپلیکیشن app.log فائل میں لاگ لکھتی ہے۔ جب app.log 100 MB تک پہنچتی ہے، سسٹم اسے app.log.1 کا نام دیتا ہے، app.log.1.gz میں کمپریس کرتا ہے اور ایک نئی خالی app.log بناتا ہے۔ اگلی بھرائی پر، app.log.1 app.log.2 بن جاتی ہے، app.log.1.gz app.log.2.gz بن جاتی ہے، اور پرانی app.log.2.gz حذف ہو جاتی ہے۔ اس میکانزم کو کیپ کاؤنٹ کے ساتھ روٹیشن کہا جاتا ہے — آرکائیو کاپیوں کی تعداد مقرر ہے۔

Splunk (2023) کے مطابق، غلط روٹیشن کنفیگریشن ایپلیکیشن سرورز پر ڈسک اسپیس ختم ہونے سے متعلق 40% واقعات کی وجہ ہے۔ موبائل ڈیوائسز کے لیے، روٹیشن اور بھی اہم ہے کیونکہ صارف دستی طور پر لاگز کا انتظام نہیں کر سکتا اور نہ ہی کرنا چاہیے۔

لاگ روٹیشن حکمت عملیاں

Log Rotation تین بنیادی حکمت عملیوں کو سپورٹ کرتا ہے جنہیں ملایا جا سکتا ہے۔ حکمت عملی کا انتخاب ایپلیکیشن کی قسم پر منحصر ہے: سرور سسٹم اکثر وقت پر مبنی روٹیشن استعمال کرتے ہیں، موبائل — سائز پر مبنی، ایمبیڈڈ — فائل گنتی پر مبنی۔

سائز پر مبنی روٹیشن — سب سے عام

سائز پر مبنی روٹیشن یقینی بناتا ہے کہ کوئی بھی لاگ فائل مقررہ حد سے تجاوز نہ کرے۔ حد کا انتخاب دستیاب ڈسک اسپیس اور لاگنگ فریکوئنسی کی بنیاد پر کیا جاتا ہے۔ سرور کے لیے، عام حد 100–500 MB فی فائل ہے، موبائل ڈیوائس کے لیے — 1–10 MB۔ اگر ایپلیکیشن زیادہ لاگ کرتی ہے تو حد کم کی جانی چاہیے، ورنہ روٹیشن ہر چند منٹوں میں ہوگی۔

وقت پر مبنی روٹیشن — تعمیل کے لیے

وقت پر مبنی روٹیشن لاگ حجم سے آزاد ہے — فائل کو مقررہ شیڈول کے مطابق تبدیل کیا جاتا ہے۔ ان سسٹمز کے لیے آسان جہاں لاگز کو مقررہ دنوں تک محفوظ کرنا ضروری ہے: کیپ کاؤنٹ = 30 کے ساتھ روزانہ روٹیشن کا مطلب 30 دن کا ذخیرہ ہے۔ منفی پہلو — ایک فائل زیادہ بوجھ کے تحت روزانہ ایک گیگابائٹ تک بڑھ سکتی ہے۔

Linux میں logrotate: کنفیگریشن اور مثالیں

logrotate خودکار لاگ روٹیشن کے لیے معیاری Linux یوٹیلیٹی ہے۔ یہ cron کے ذریعے چلتی ہے اور /etc/logrotate.d/ سے کنفیگریشن فائلیں پروسیس کرتی ہے۔ ہر سروس (nginx، postgresql، ایپلیکیشن) لاگ پاتھ، روٹیشن حکمت عملی اور روٹیشن کے بعد کی کارروائیوں کی وضاحت کرتے ہوئے اپنی کنفیگ بناتی ہے۔

# /etc/logrotate.d/myapp — ایپلیکیشن لاگ روٹیشن
/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
    postrotate
        kill -HUP $(cat /var/run/myapp.pid)
    endscript
}

یہ کنفیگ لاگز کو روزانہ روٹیٹ کرتی ہے، 7 آرکائیو کاپیاں رکھتی ہے، پرانی فائلوں کو gzip سے کمپریس کرتی ہے (آخری کو چھوڑ کر — delaycompress)، لاگز غائب ہونے پر غلطی نہیں دیتی (missingok)، خالی فائلوں کو روٹیٹ نہیں کرتی (notifempty)، اور 0640 اجازتوں کے ساتھ فائل کو دوبارہ بناتی ہے۔ روٹیشن کے بعد، یہ postrotate اسکرپٹ کے ذریعے ایپلیکیشن پروسیس کو HUP سگنل بھیجتی ہے۔

logrotate پیرامیٹرز

size — ایک سائز تک پہنچنے پر روٹیشن (size 100M)۔ rotate — آرکائیو کاپیوں کی تعداد (rotate 7)۔ compress — gzip کمپریشن۔ dateext — ترتیب وار نمبر کے بجائے فائل نام میں تاریخ شامل کرتا ہے۔ sharedscripts — ہر فائل کے لیے الگ الگ نہیں بلکہ تمام فائلوں کے لیے ایک بار postrotate چلاتا ہے۔ maxage — N دن سے پرانے آرکائیوز کو حذف کرتا ہے۔

موبائل ایپلیکیشنز میں Log Rotation

موبائل ڈیوائسز پر، Log Rotation اہم ہے کیونکہ صارف فائل سسٹم کا انتظام نہیں کرتا اور توقع نہیں کرتا کہ ایپلیکیشن لاگز کے ساتھ گیگابائٹس لے گی۔ iOS اور Android میں بلٹ ان میکانزم ہیں: iOS پر os_log ایک مقررہ سائز کی رنگ بفر (اوور رائٹ کے ذریعے روٹیشن) استعمال کرتی ہے، Android Logcat میں کرنل میں محدود بفر ہے۔

iOS پر کسٹم فائل لاگز کے لیے CocoaLumberjack DDFileLogger کلاس کے ساتھ استعمال ہوتا ہے، جو سائز اور وقت پر مبنی روٹیشن کو سپورٹ کرتا ہے۔ Android پر — Logback یا RollingFileAppender کے ذریعے کسٹم نفاذ۔ دونوں ٹولز زیادہ سے زیادہ فائل سائز اور آرکائیو کی تعداد مقرر کرنے کی اجازت دیتے ہیں۔

// CocoaLumberjack — iOS پر فائل روٹیشن
import CocoaLumberjack

let fileLogger = DDFileLogger()
fileLogger.maximumFileSize = 1024 * 1024 // 1 MB
fileLogger.logFileManager.maximumNumberOfLogFiles = 5
DDLog.add(fileLogger)

iOS: os_log کو روٹیشن کی ضرورت نہیں — پیغامات رنگ بفر میں اوور رائٹ ہو جاتے ہیں۔ لیکن اگر ایپلیکیشن کسٹم فائل لاگز لکھتی ہے (ڈیبگنگ یا سرور پر بھیجنے کے لیے)، تو روٹیشن کو دستی طور پر کنفیگر کرنا ضروری ہے۔ CocoaLumberjack iOS ٹیموں کے لیے معیاری انتخاب ہے — یہ خود بخود آرکائیوز کو .gz میں کمپریس کرتا ہے اور حد سے تجاوز کرنے پر پرانی فائلیں حذف کر دیتا ہے۔

Android پر روٹیشن کیوں اہم ہے

Android ایپلیکیشنز کو اپنی ڈائریکٹری میں لاگ لکھنے سے محدود نہیں کرتا۔ اگر ڈویلپر روٹیشن کے بغیر فائل میں ڈیبگ لاگز لکھتا ہے، تو فعال استعمال کے ایک مہینے میں وہ 500 MB سے 1 GB تک لے سکتے ہیں۔ صارف کو مسئلہ تب پتہ چلے گا جب سسٹم کم اسٹوریج کی وارننگ دکھائے گا اور وہ ایپلیکیشن کو حذف کر دے گا۔ RollingFileAppender کے ساتھ Logback اس مسئلے کو حل کرتا ہے: 3 آرکائیوز کے ساتھ 5 MB کی حد اس بات کی ضمانت دیتی ہے کہ لاگز کبھی 20 MB سے تجاوز نہیں کریں گے۔

iOS اور Android پر روٹیشن نفاذ کی مثالیں

ذیل میں دونوں پلیٹ فارمز پر لاگ روٹیشن کنفیگریشن کی مثالیں دی گئی ہیں۔ iOS پر CocoaLumberjack استعمال ہوتا ہے، Android پر — XML کنفیگریشن کے ساتھ Logback۔

// Android پر Logback — logback.xml میں روٹیشن کنفیگریشن
// فائل سائز 5MB، 3 آرکائیو کاپیاں
@file:Suppress("unused")

// logback.xml میں:
// <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
//   <file>${DATA_DIR}/logs/app.log</file>
//   <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
//     <fileNamePattern>app.%i.log.gz</fileNamePattern>
//     <minIndex>1</minIndex>
//     <maxIndex>3</maxIndex>
//   </rollingPolicy>
//   <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
//     <maxFileSize>5MB</maxFileSize>
//   </triggeringPolicy>
// </appender>

iOS پر CocoaLumberjack نہ صرف سائز پر مبنی روٹیشن بلکہ logFileManager.maximumLogFiles استعمال کرکے تاریخ کے مطابق پرانے لاگز کو حذف کرنے کی بھی حمایت کرتا ہے۔ اگر maximumLogFiles = 0 سیٹ کیا جائے تو حد ہٹا دی جاتی ہے — لاگز غیر معینہ مدت تک جمع ہوتے رہیں گے، جو پروڈکشن کے لیے خطرناک ہے۔

// کل حجم کی جانچ کے ساتھ کسٹم روٹیشن
class SizeAwareLogger {
    let maxTotalSize: Int64 = 20 * 1024 * 1024

    func enforceQuota(at logDirectory: URL) {
        let files = (try? FileManager.default
            .contentsOfDirectory(
                at: logDirectory,
                includingPropertiesForKeys: [.fileSize]
            )) ?? []
        let total = files.reduce(0) {
            $0 + (try? $1.resourceValues(forKeys: [.fileSize])
                .fileSize).map(Int64.init) ?? 0
        }
        if total > maxTotalSize {
            // سب سے پرانی فائل حذف کریں
            files.sorted { $0.path < $1.path }.first.map {
                try? FileManager.default.removeItem(at: $0)
            }
        }
    }
}

روٹیشن میں نگرانی اور الرٹ

Log Rotation نہ صرف خودکار آرکائیونگ ہے بلکہ سسٹم کی صحت کا اشارہ بھی ہے۔ اگر لاگز بہت بار روٹیٹ ہوتے ہیں (ہر چند منٹ)، تو یہ ضرورت سے زیادہ لاگنگ یا ایرر لاگ لوپ کا اشارہ ہے۔ روٹیشن فریکوئنسی پر الرٹ سیٹ کریں: فی گھنٹہ 10 سے زیادہ روٹیشن جانچ کا سبب ہے۔

نگرانی کے نظام (Prometheus، Grafana، Datadog) فائل سسٹم ایکسپورٹرز کے ذریعے روٹیشن میٹرکس ٹریک کر سکتے ہیں۔ Prometheus node_exporter فائل سائز اور تبدیلی کے وقت کے میٹرکس فراہم کرتا ہے۔ موبائل ڈیوائسز پر، روٹیشن نگرانی عام طور پر SDK میں بلٹ ان ہوتی ہے: CocoaLumberjack DDLog کے ذریعے روٹیشن ایونٹ لاگ کرتا ہے، اور Logback appender کے ذریعے اسٹیٹس بھیجتا ہے۔

الرٹ: اگر توقع سے زیادہ آرکائیوز ہوں (روٹیشن کاؤنٹ حد سے تجاوز کر گیا) یا کل لاگ حجم کوٹہ سے تجاوز کر گیا — سسٹم کو ایڈمنسٹریٹر کو مطلع کرنا چاہیے۔ سرورز کے لیے معیاری حد پارٹیشن سائز کا 80% ہے؛ موبائل ڈیوائسز کے لیے — فی ایپلیکیشن 50 MB سے تجاوز پر الرٹ۔