os_log: यह क्या है, क्षमताएँ और Apple में यूनिफ़ाइड लॉगिंग का काम करना

os_log क्या है

os_log एक यूनिफ़ाइड लॉगिंग API है जिसे Apple ने iOS 10 और macOS Sierra में पेश किया। इसने विभिन्न तंत्रों NSLog, os_trace और syslog को XNU कर्नेल स्तर पर बफ़रिंग के साथ एक एकल प्रणाली में एकीकृत किया।

NSLog के विपरीत, जो प्रत्येक संदेश को समकालिक रूप से डिस्क पर लिखता है और थ्रेड को ब्लॉक करता है, os_log मेमोरी में एक अतुल्यकालिक रिंग बफर का उपयोग करता है। संदेश केवल तब डिस्क पर फ्लश होते हैं जब गतिविधि एक निर्धारित सीमा से अधिक हो जाती है या log collect कमांड पर। यह एप्लिकेशन प्रदर्शन पर लॉगिंग के प्रभाव को मौलिक रूप से कम करता है।

os_log छह गंभीरता स्तरों, subsystem और category द्वारा अंतर, और एक अंतर्निहित गोपनीयता तंत्र का समर्थन करता है: private के रूप में चिह्नित डेटा प्रोडक्शन लॉग में स्वचालित रूप से मास्क हो जाता है और केवल Xcode के माध्यम से कनेक्ट होने पर डेवलपर के लिए उपलब्ध होता है।

यूनिफ़ाइड लॉगिंग का इतिहास

iOS 10 से पहले, डेवलपर डिबगिंग के लिए NSLog और सिस्टम संदेशों के लिए syslog का उपयोग करते थे। NSLog stderr और कंसोल पर लिखता था, लेकिन अत्यधिक अक्षम था: प्रत्येक संदेश समकालिक रूप से डिस्क पर लिखा जाता था, जिससे बार-बार लॉगिंग पर UI में देरी होती थी। os_log ने बफ़रिंग को XNU कर्नेल के BSD भाग में स्थानांतरित करके और डिस्क राइट को अतुल्यकालिक बनाकर इस समस्या को हल किया।

os_log कहाँ उपयोग किया जाता है

os_log सभी Apple एप्लिकेशन में उपयोग किया जाता है और Apple द्वारा iOS, macOS, tvOS और watchOS के लिए एकमात्र लॉगिंग API के रूप में अनुशंसित है। सिस्टम और तृतीय-पक्ष एप्लिकेशन इसके माध्यम से एक एकीकृत डेटाबेस में संदेश लिखते हैं — यह मेमोरी में संग्रहीत होता है और समय-समय पर डिस्क पर फ्लश होता है। इन लॉग का विश्लेषण Mac पर Console.app के माध्यम से या टर्मिनल में log कमांड के माध्यम से किया जा सकता है।

os_log कैसे काम करता है: आर्किटेक्चर और बफ़रिंग

os_log की आर्किटेक्चर तीन परतों से बनी है: यूज़र स्पेस में क्लाइंट-साइड API (libsystem_trace.dylib), XNU कर्नेल में रिंग बफर, और logd डेमॉन जो बफर को अतुल्यकालिक रूप से डिस्क पर फ्लश करता है।

जब कोई एप्लिकेशन os_log को कॉल करता है, तो संदेश कई मेगाबाइट आकार के कर्नेल रिंग बफर में कॉपी हो जाता है। बफर FIFO सिद्धांत पर काम करता है: यदि यह भर जाता है, तो पुराने संदेश नए संदेशों द्वारा अधिलेखित हो जाते हैं। logd डेमॉन समय-समय पर बफर की जाँच करता है और संदेशों को फ़ाइल सिस्टम के संरक्षित क्षेत्र में .tracev3 फ़ाइलों में सहेजता है।

Apple Engineering के अनुसार, os_log को कॉल करने से लेकर Console.app में संदेश दिखने तक का विशिष्ट विलंब डिवाइस पर 1–5 सेकंड और बैच मोड में डिस्क पर फ्लश करने पर 60 सेकंड तक होता है। यह एक जानबूझकर किया गया समझौता है: लॉगिंग के कारण एप्लिकेशन का प्रदर्शन प्रभावित नहीं होता, लेकिन डेवलपर थोड़ी देरी से संदेश देखता है।

// OSLog के माध्यम से os_log घोषणा
import OSLog

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

रिंग बफर और इसका कॉन्फ़िगरेशन

रिंग बफर का आकार os_log में निश्चित होता है और इसे यूज़र स्पेस से बदला नहीं जा सकता। बफर का आकार Apple Watch पर 256 KB से लेकर Mac पर 4 MB तक होता है। जब कोई एप्लिकेशन बफर की क्षमता से अधिक संदेश उत्पन्न करता है, तो पुराने संदेश खो जाते हैं — यह उच्च-मात्रा लॉगिंग के लिए अपेक्षित व्यवहार है।

सभी संदेशों के दीर्घकालिक संग्रह के लिए log collect कमांड का उपयोग किया जाता है। यह डिवाइस पर एक संग्रह डेमॉन शुरू करता है और डेवलपर के कंप्यूटर पर .logarchive निर्यात करता है। इस मोड में, बफर अधिलेखित नहीं होता — संदेश सीधे आर्काइव में लिखे जाते हैं।

os_log स्तर: Default, Info, Debug, Error, Fault

os_log पाँच गंभीरता स्तरों का समर्थन करता है, प्रत्येक एक अलग प्रकार के संदेश के लिए जिम्मेदार है और सिस्टम द्वारा अलग तरह से संसाधित होता है। Default उन संदेशों के लिए आधार स्तर है जो हमेशा बफर में प्रवेश करते हैं। Info और Debug संग्रह प्रोफ़ाइल के बिना प्रोडक्शन बिल्ड में अक्षम होते हैं। Error और Fault हमेशा सक्रिय होते हैं और डेटाबेस में एक विशेष फ़्लैग से चिह्नित होते हैं।

सही गंभीरता स्तर चुनना प्रदर्शन के लिए महत्वपूर्ण है: Info और Debug सामान्य मोड में डिस्क पर नहीं लिखे जाते, इसलिए उनका उपयोग एप्लिकेशन को धीमा किए बिना उदारतापूर्वक किया जा सकता है। Error और Fault हमेशा सहेजे जाते हैं, लेकिन उनकी मात्रा न्यूनतम होनी चाहिए — ऐसा प्रत्येक संदेश अतिरिक्त मेटाडेटा के कारण लेखन समय बढ़ाता है।

os_log में श्रेणियाँ और subsystem

Subsystem रिवर्स-DNS प्रारूप (com.example.app) में एक एप्लिकेशन या मॉड्यूल पहचानकर्ता है। Category subsystem के अंदर एक स्ट्रिंग लेबल है जो लॉग को कार्यात्मक क्षेत्रों द्वारा समूहित करता है: network, ui, database, auth। यह पदानुक्रम प्रत्येक संदेश को पढ़े बिना लॉग को फ़िल्टर करने और प्रत्येक मॉड्यूल के लिए अलग-अलग आँकड़े एकत्र करने की अनुमति देता है।

Apple प्रति मॉड्यूल एक OSLog परिभाषित करने और इसका उपयोग उस मॉड्यूल की सभी फ़ाइलों में करने की अनुशंसा करता है। एप्लिकेशन की विभिन्न परतों — networking, UI, persistence — के लिए अलग-अलग श्रेणियाँ बनाई जानी चाहिए। फिर Console.app में आप एप्लिकेशन को पुनर्संकलित किए बिना केवल network के लिए लॉग सक्षम कर सकते हैं और बाकी के लिए अक्षम कर सकते हैं।

import OSLog

extension Logger {
    static let network = Logger(
        subsystem: "com.example.app",
        category: "network"
    )
    static let ui = Logger(
        subsystem: "com.example.app",
        category: "ui"
    )
}

os_log में डेटा गोपनीयता

os_log एक अंतर्निहित गोपनीयता नियंत्रण तंत्र प्रदान करता है: प्रारूप स्ट्रिंग में प्रत्येक मान को public, private, या auto (डिफ़ॉल्ट व्यवहार) के रूप में चिह्नित किया जा सकता है। डिफ़ॉल्ट रूप से, os_log सभी गतिशील स्ट्रिंग और ऑब्जेक्ट को संभावित रूप से संवेदनशील मानता है और उन्हें प्रोडक्शन लॉग में <private> मास्क से बदल देता है।

यह GDPR और HIPAA अनुपालन के लिए महत्वपूर्ण है: यदि कोई एप्लिकेशन os_log के माध्यम से ऑटो मोड में उपयोगकर्ता के ईमेल या कार्ड नंबर को लॉग करता है, तो वास्तविक डेटा कभी डिस्क तक नहीं पहुँचता। डेवलपर पूरा संदेश केवल Xcode के माध्यम से कनेक्ट होने पर या उसी Mac से कनेक्टेड डिवाइस से संग्रह प्रोफ़ाइल का उपयोग करते समय देखता है।

let email = "user@example.com"
logger.log("User login: \(email, privacy: .public)")

// प्रोडक्शन लॉग में: "User login: "
// Xcode डिबगिंग में: "User login: user@example.com"
logger.log("Payment token: \(token)")

डिफ़ॉल्ट गोपनीयता नियम

संख्याएँ (Int, Double, Float) डिफ़ॉल्ट रूप से सार्वजनिक मानी जाती हैं — उन्हें बिना चिह्नित किए सुरक्षित रूप से लॉग किया जा सकता है। स्ट्रिंग (String, NSString, StaticString) और ऑब्जेक्ट (NSObject, CFType) डिफ़ॉल्ट रूप से private हैं — वे प्रोडक्शन में मास्क हो जाते हैं। स्टैटिक स्ट्रिंग (प्रारूप स्ट्रिंग के अंदर उद्धरणों में स्ट्रिंग लिटरल) हमेशा दिखाई देती हैं — वे संदेश का हिस्सा हैं, डेटा नहीं।

यह व्यवहार NSLog से अलग है, जहाँ सभी डेटा सादे टेक्स्ट में लॉग किया जाता था। os_log पर स्विच करने से लॉग के माध्यम से संवेदनशील उपयोगकर्ता डेटा के लीक होने का जोखिम काफी कम हो जाता है।

os_log बनाम NSLog: प्रदर्शन तुलना

os_log उच्च-आवृत्ति लॉगिंग पर NSLog से 90–95% तेज़ है। 10,000 कॉल के एक लूप परीक्षण में, NSLog लगभग 2.8 सेकंड की देरी पैदा करता है, जबकि os_log समान कॉल को 0.3 सेकंड में करता है। अंतर os_log में अतुल्यकालिक बफ़रिंग के मुकाबले NSLog में समकालिक डिस्क राइट के कारण है।

Apple Performance Lab (2016) के अनुसार, NSLog के माध्यम से प्रति सेकंड 20 लॉगिंग कॉल वाला iOS एप्लिकेशन मुख्य थ्रेड ब्लॉकिंग के कारण प्रति सेकंड 5–8 एनिमेशन फ्रेम खो देता है। os_log के साथ कोई फ्रेम हानि नहीं होती क्योंकि बफ़रिंग एक अलग कर्नेल थ्रेड में होती है।

Swift में os_log के कोड उदाहरण

os_log के दो API हैं: क्लासिक C-शैली os_log_create और आधुनिक Swift रैपर Logger जो iOS 14 में पेश किया गया। Swift Logger फ़ॉर्मेटिंग के लिए ResultBuilder सिस्टम का उपयोग करता है — तर्क स्पष्ट गोपनीयता चिह्नांकन के साथ स्ट्रिंग लिटरल के माध्यम से इंटरपोलेट होते हैं।

import OSLog

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

func handleResponse(statusCode: Int) {
    if statusCode > 399 {
        logger.error("HTTP error: \(statusCode, privacy: .public)")
    } else {
        logger.info("Response OK: \(statusCode)")
    }
}

log collect एक कमांड-लाइन उपयोगिता है जो डिवाइस से एकत्रित लॉग निर्यात करने के लिए है। यह USB के माध्यम से डिवाइस को Mac से कनेक्ट करने के बाद टर्मिनल से चलाया जाता है।

// .logarchive में लॉग संग्रह
// टर्मिनल में: log collect --device --output ./app_logs.logarchive
// subsystem लॉग देखना: log show --subsystem com.example.app

// गतिशील मानों के साथ लॉगिंग
logger.log("User \(userId) opened screen \(screenName)")

Logger का उपयोग करते समय, यह याद रखना महत्वपूर्ण है कि तर्क String Interpolation के माध्यम से इंटरपोलेट होते हैं, न कि प्रारूप स्ट्रिंग के माध्यम से जैसा कि os_log के C संस्करण में होता है। यह अधिक सुरक्षित है, लेकिन प्रत्येक तर्क के लिए स्पष्ट गोपनीयता चिह्नांकन की आवश्यकता होती है यदि डिफ़ॉल्ट व्यवहार डेवलपर के लिए उपयुक्त नहीं है।