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 पार होने पर अलर्ट।