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 اور کنسول پر لکھتا تھا، لیکن انتہائی غیر موثر تھا: ہر پیغام ہم وقت سازی سے ڈسک پر لکھا جاتا تھا، جس سے بار بار لاگنگ پر یوزر انٹرفیس میں تاخیر ہوتی تھی۔ 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 ورژن میں ہوتا ہے۔ یہ زیادہ محفوظ ہے، لیکن ہر آرگیومنٹ کے لیے واضح رازداری کے نشان کی ضرورت ہوتی ہے اگر ڈیفالٹ رویہ ڈویلپر کے لیے موزوں نہ ہو۔