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 সংস্করণে হয়। এটি আরও নিরাপদ, তবে প্রতিটি আর্গুমেন্টের জন্য স্পষ্ট গোপনীয়তা চিহ্নিতকরণ প্রয়োজন যদি ডিফল্ট আচরণ ডেভেলপারের জন্য উপযুক্ত না হয়।