ऐप डेवलपमेंट में Log Level: यह क्या है, स्तरों के प्रकार और कॉन्फ़िगरेशन

Log Level क्या है?

Log Level प्रत्येक लॉग संदेश की एक विशेषता है जो इसके महत्व और प्रसंस्करण की तात्कालिकता को निर्धारित करती है। आधुनिक iOS और Android प्लेटफ़ॉर्म 6–7 स्तरों का एकीकृत पैमाना समर्थन करते हैं: सबसे विस्तृत (Verbose/Trace) से लेकर महत्वपूर्ण (Error/Assert) तक। स्तर का चुनाव यह निर्धारित करता है कि वर्तमान एप्लिकेशन कॉन्फ़िगरेशन के तहत संदेश लॉग में लिखा जाएगा या नहीं।

Log Level अवधारणा गंभीरता पिरामिड सिद्धांत पर आधारित है: स्तर जितना ऊँचा होगा, उस पर उतने ही कम संदेश आउटपुट होंगे। Semaphore CI, 2024 के अनुसार, प्रोडक्शन एप्लिकेशन में वितरण इस प्रकार है: Info — 60% संदेश, Warn — 25%, Error — 10%, Debug — 5%. Verbose संदेश प्रोडक्शन में पूरी तरह से अक्षम होने चाहिए।

प्रत्येक प्लेटफ़ॉर्म Log Level को अपने API के माध्यम से लागू करता है। Android v(), d(), i(), w(), e() विधियों के साथ android.util.Log का उपयोग करता है। Apple default, info, debug, error, fault स्तरों के साथ OSLog का उपयोग करता है। Timber और CocoaLumberjack जैसी लाइब्रेरीज़ इन मानक API के ऊपर अतिरिक्त कार्यक्षमता जोड़ती हैं।

Google I/O 2023 के अनुसार, गलत Log Level चुनाव प्रोडक्शन में 40% प्रदर्शन समस्याओं का कारण है। डेवलपर्स रिलीज़ बिल्ड में Debug लॉग छोड़ देते हैं, जिससे डिस्क पर अत्यधिक लेखन और त्वरित बैटरी डिस्चार्ज होता है।

लॉगिंग स्तरों के प्रकार: Verbose से Assert तक

Verbose (TRACE) — सबसे विस्तृत स्तर, विशेष रूप से डेवलपमेंट के लिए। इस स्तर पर सभी मध्यवर्ती गणनाएँ, लूप पुनरावृत्तियाँ और एल्गोरिदम के प्रत्येक चरण के परिणाम आउटपुट होते हैं। Android पर, यह स्तर Log.v() से मेल खाता है, iOS पर — OSLog प्रकार debug (iOS 14 से पहले os_trace उपयोग किया जाता था)।

Debug — डेवलपमेंट और परीक्षण के दौरान उपयोगी डीबगिंग संदेश। इनमें मुख्य ऑब्जेक्ट्स की स्थिति, SQL क्वेरी परिणाम और API कॉल पैरामीटर के बारे में जानकारी होती है। Verbose के विपरीत, Debug संदेश संरचित और अर्थपूर्ण होते हैं। iOS पर, यह स्तर OSLogType.debug से मेल खाता है।

Info — एप्लिकेशन की सामान्य घटनाओं के बारे में सूचनात्मक संदेश: SDK आरंभीकरण, सफल प्रमाणीकरण, स्क्रीन खोलना, सर्वर से डेटा प्राप्त करना। Info संदेशों में उपयोगकर्ताओं का व्यक्तिगत डेटा नहीं होना चाहिए और प्रोडक्शन विश्लेषण के लिए सुरक्षित होना चाहिए। iOS पर OSLogType.info उपयोग किया जाता है, Android पर — Log.i().

Warn — संभावित समस्याओं के बारे में चेतावनी। एप्लिकेशन काम करना जारी रखता है, लेकिन स्थिति पर ध्यान देने की आवश्यकता है: कैश आकार सीमा के करीब, API का पुराना संस्करण, धीमी नेटवर्क प्रतिक्रिया, कनेक्शन का पुनः प्रयास। Android पर — Log.w(), iOS पर — OSLogType.default (चेतावनियों के लिए)।

Error — महत्वपूर्ण त्रुटियाँ जहाँ एप्लिकेशन अनुरोधित ऑपरेशन नहीं कर सकता लेकिन काम करना जारी रखता है: असफल API अनुरोध, कनेक्शन खोना, DB लेखन त्रुटि, अनुमतियों की कमी। iOS पर त्रुटियों के लिए OSLogType.error उपयोग किया जाता है, Android पर — Log.e().

Assert (WTF) — उच्चतम स्तर, “यह हो नहीं सकता” स्थिति को दर्शाता है। उन बग्स को लॉग करने के लिए उपयोग किया जाता है जो सिस्टम के मूलभूत अपरिवर्तनीय नियमों का उल्लंघन करते हैं। Android पर, Assert संदेश डिफ़ॉल्ट रूप से रिलीज़ बिल्ड में प्रदर्शित नहीं होते हैं। iOS पर, WTF (What a Terrible Failure) को OSLogType.fault के माध्यम से संभाला जाता है।

Android पर Log Level का उपयोग

Android Log API — android.util.Log पैकेज से अंतर्निहित लॉगिंग तंत्र। यह 6 स्थैतिक विधियाँ प्रदान करता है: Log.v(), Log.d(), Log.i(), Log.w(), Log.e() और Log.wtf(). प्रत्येक विधि tag (स्रोत पहचानकर्ता स्ट्रिंग) और msg (संदेश पाठ) लेती है।

class UserRepository {
    companion object {
        private val TAG = "UserRepo"
    }

    suspend fun loadUser(id: String): User {
        Log.d(TAG, "$id के साथ उपयोगकर्ता लोड हो रहा है")

        return try {
            val response = api.fetchUser(id)
            Log.i(TAG, "उपयोगकर्ता सफलतापूर्वक लोड हुआ")
            response.toUser()
        } catch (e: Exception) {
            Log.e(TAG, "उपयोगकर्ता लोड करने में विफल: ${e.message}")
            throw e
        }
    }
}

स्तरों के अनुसार फ़िल्टरिंग Android Logcat में ADB के माध्यम से की जाती है: adb logcat *:E केवल Error संदेश दिखाएगा। प्रोडक्शन बिल्ड में, जब मिनिफिकेशन सक्षम होता है तो ProGuard/R8 द्वारा सभी Log.v() और Log.d() कॉल हटा दिए जाते हैं। Log.i(), Log.w() और Log.e() रहते हैं, इसलिए इन विधियों के माध्यम से संवेदनशील डेटा आउटपुट न करना महत्वपूर्ण है।

रनटाइम पर कस्टम फ़िल्टरिंग के लिए, Android Log.isLoggable(tag, level) प्रदान करता है — एक विधि जो जाँचती है कि दिए गए tag के लिए निर्दिष्ट स्तर सक्षम है या नहीं। यह एप्लिकेशन को पुनर्निर्माण किए बिना किसी विशिष्ट मॉड्यूल के लिए विस्तृत लॉगिंग को गतिशील रूप से सक्षम करने की अनुमति देता है।

iOS और macOS पर Log Level का उपयोग

OSLog — Apple की एकीकृत लॉगिंग प्रणाली, जिसने पदावनत NSLog को बदल दिया। OSLog 5 स्तर प्रदान करता है: debug, info, default (notice), error और fault। मुख्य लाभ संरचित लॉगिंग है जिसमें फ़ॉर्मेटेड स्ट्रिंग्स और कंसोल के माध्यम से गतिशील फ़िल्टरिंग का समर्थन है।

import OSLog

let logger = Logger(
    subsystem: "com.example.app",
    category: "network"
)

func fetchData(from url: URL) {
    logger.debug("Starting request to \(url.absoluteString)")

    do {
        let data = try Data(contentsOf: url)
        logger.info("Received \(data.count) bytes")
    } catch {
        logger.error("Request failed: \(error.localizedDescription)")
    }
}

OSLog फ़िल्टरिंग प्रणाली ऑपरेटिंग सिस्टम स्तर पर काम करती है। Debug संदेश केवल तभी लिखे जाते हैं जब डीबगर संलग्न हो या -com.apple.CoreData.Logging.debug 1 तर्क सक्षम हो। Info संदेश डिवाइस मेमोरी (512 KB तक) में एकत्र किए जाते हैं और Console.app के माध्यम से सुलभ होते हैं। Error और fault संदेश लगातार लिखे जाते हैं और क्रैश-रिपोर्टिंग सिस्टम के माध्यम से संग्रह के लिए उपलब्ध होते हैं।

OSLog की एक महत्वपूर्ण विशेषता: प्लेसहोल्डर्स के साथ फ़ॉर्मेटेड स्ट्रिंग्स। Swift स्ट्रिंग इंटरपोलेशन (जो स्तर की परवाह किए बिना हमेशा मूल्यांकित होता है) के बजाय, OSLog संवेदनशील डेटा को अलग करने के लिए %{public}@ और %{private}@ के साथ os_log प्रारूप का उपयोग करता है। प्रोडक्शन लॉग में निजी पैरामीटर मास्क किए जाते हैं।

Production vs Debug: स्तर फ़िल्टरिंग कैसे कॉन्फ़िगर करें

मुख्य नियम — प्रोडक्शन में स्तरों का न्यूनतम सेट: Info, Warn, Error, Assert। Debug और Verbose अक्षम होने चाहिए। कारण सुरक्षा जितना प्रदर्शन नहीं है: प्रत्येक लॉग कॉल स्ट्रिंग को फ़ॉर्मेट करने में CPU समय लेता है, भले ही संदेश आउटपुट न हो।

आलसी स्ट्रिंग फ़ॉर्मेटिंग

महत्वपूर्ण अनुकूलन — लॉग कॉल में कभी भी स्ट्रिंग इंटरपोलेशन का उपयोग न करें। यदि log() कॉल से पहले स्ट्रिंग बनाई जाती है, तो स्तर अक्षम होने पर भी CPU समय बर्बाद होता है। लैम्ब्डा या गार्ड शर्तों के माध्यम से आलसी फ़ॉर्मेटिंग का उपयोग करें।

Android पर, Log.isLoggable() विधि इस उद्देश्य को पूरा करती है; OSLog पर, प्लेसहोल्डर्स के साथ मूल फ़ॉर्मेटेड स्ट्रिंग्स समर्थित हैं। Android के लिए Timber timber.log.Tree के माध्यम से पेड़ के अंदर स्तर जाँच के साथ समस्या का समाधान करता है।

चलते-फिरते गतिशील स्तर परिवर्तन

Remote Log Level — एक अभ्यास जहाँ लॉगिंग स्तर Firebase Remote Config या समान सेवा के माध्यम से सर्वर से नियंत्रित किया जाता है। यदि प्रोडक्शन में कोई जटिल त्रुटि होती है, तो डेवलपर चयनित उपयोगकर्ता समूह के उपकरणों पर किसी विशिष्ट मॉड्यूल के लिए दूरस्थ रूप से Debug लॉगिंग सक्षम कर सकता है।

Firebase, 2024 के अनुसार, यह अभ्यास दुर्लभ बग्स के निदान के समय को 60% तक कम करता है और डीबग बिल्ड स्थापित किए बिना समस्या की पूरी तस्वीर प्राप्त करने की अनुमति देता है। मुख्य सीमा — कॉन्फ़िगरेशन प्राप्त करने के बाद लॉगिंग केवल एप्लिकेशन के अगले लॉन्च पर सक्षम होती है।

बिल्ड प्रकार के अनुसार स्वचालित फ़िल्टरिंग

Android पर BuildConfig.DEBUG और Swift पर #if DEBUG मानक सशर्त संकलन तंत्र हैं जो रिलीज़ बिल्ड में डीबग स्तरों को अक्षम करते हैं। स्वच्छ आर्किटेक्चर के लिए, सशर्त निर्देशों के साथ व्यावसायिक तर्क को अव्यवस्थित न करने के लिए Log Level चयन को DI-कंटेनर या लॉगर फ़ैक्टरी में स्थानांतरित करने की अनुशंसा की जाती है।

लॉगिंग स्तर चुनने के सर्वोत्तम अभ्यास

पहला नियम — प्रत्येक लॉग कॉल को “कौन, क्या, कब” प्रश्न का उत्तर देना चाहिए। कौन — घटक या मॉड्यूल (Android पर tag, iOS पर category)। क्या — विशिष्ट घटना या स्थिति परिवर्तन। कब — टाइमस्टैम्प, जो लॉगिंग सिस्टम द्वारा स्वचालित रूप से जोड़ा जाता है।

दूसरा नियम — Info और उससे ऊपर के माध्यम से संवेदनशील डेटा लॉग न करें। पासवर्ड, टोकन, ईमेल, फ़ोन नंबर, सटीक भौगोलिक निर्देशांक — किसी भी लॉग में सख्त वर्जित हैं जो प्रोडक्शन में जाता है। आवश्यकता होने पर मास्किंग का उपयोग करें: “email: us***@example.com.”

तीसरा नियम — Warn स्तर डेवलपर की जिम्मेदारी है, Error — टीम की। Warn का अर्थ है “यहाँ संभावित समस्या है, इस पर नज़र रखें।” Error का अर्थ है “यहाँ समस्या है, इसे ठीक करें।” उन स्थितियों के लिए Error का उपयोग न करें जो अपेक्षित और संभाली गई हैं (जैसे, 404 API त्रुटि)।

चौथा नियम — स्थिरता। पूरे प्रोजेक्ट को tag और श्रेणियों के नामकरण के लिए एकीकृत सम्मेलनों का उपयोग करना चाहिए। Android tag के लिए ClassName.methodName और iOS category के लिए module.subsystem अनुशंसित है। यह घटक द्वारा लॉग को तुरंत फ़िल्टर करने की अनुमति देता है।

पाँचवाँ नियम — अपने लॉग का परीक्षण करें। यूनिट परीक्षणों में जाँच करें कि विशिष्ट परिदृश्यों में सही Log Level कॉल किया गया है। इस उद्देश्य के लिए मॉक लॉगिंग लाइब्रेरीज़ मौजूद हैं: Android के लिए Mockito, iOS के लिए Cuckoo। परीक्षणों में स्तरों की जाँচ प्रोडक्शन में डीबग संदेशों के रिसाव को रोकती है।