os_log: mi ez, képességek és az unified logging működése az Apple-nél

Mi az os_log

os_log — az Apple által az iOS 10-ben és a macOS Sierra-ban bevezetett unified logging API. Egyesítette az NSLog, os_trace és syslog szétszórt naplózási mechanizmusait egyetlen rendszerbe, XNU kernel szintű puffereléssel.

Az NSLog-től eltérően, amely minden üzenetet szinkron módon ír a lemezre és blokkolja a szálat, az os_log aszinkron körpuffert használ a memóriában. Az üzenetek csak akkor kerülnek a lemezre, ha az aktivitás meghalad egy bizonyos küszöböt, vagy a log collect parancsra. Ez drasztikusan csökkenti a naplózás alkalmazás-teljesítményre gyakorolt hatását.

Az os_log hat kritikussági szintet, subsystem és category szerinti megkülönböztetést, valamint beépített adatvédelmi mechanizmust támogat: a private-ként jelölt adatok automatikusan maszkolódnak az éles naplókban, és csak Xcode csatlakoztatásakor érhetők el a fejlesztő számára.

Az unified logging megjelenésének története

Az iOS 10 előtt a fejlesztők NSLog-ot használtak hibakereséshez és syslog-ot rendszerüzenetekhez. Az NSLog a stderr-be és a konzolba írt, de rendkívül hatástalan volt: minden üzenet szinkron módon íródott a lemezre, ami gyakori naplózás esetén késleltetéseket okozott a felhasználói felületen. Az os_log megoldotta ezt a problémát azzal, hogy a pufferelést az XNU kernel BSD részének szintjére helyezte át, és a lemezre írást aszinkronná tette.

Hol alkalmazzák az os_log-ot

os_log-ot minden Apple-alkalmazásban használják, és az Apple az egyetlen naplózási API-ként ajánlja iOS, macOS, tvOS és watchOS rendszerekhez. A rendszer és a harmadik féltől származó alkalmazások rajta keresztül írnak üzeneteket egyetlen adatbázisba — amely a memóriában tárolódik és időszakosan a lemezre kerül. Ezek a naplók a Mac-en a Console.app-on keresztül vagy a terminálban a log paranccsal elemezhetők.

Hogyan működik az os_log: architektúra és pufferelés

Az os_log architektúrája három rétegből áll: kliens API a felhasználói térben (libsystem_trace.dylib), körpuffer az XNU kernelben, és a logd démon, amely aszinkron módon üríti a puffert a lemezre.

Amikor az alkalmazás meghívja az os_log-ot, az üzenet bemásolódik a kernel néhány megabájt méretű körpufferébe. A puffer FIFO elv szerint működik: ha megtelik, a régi üzenetek felülíródnak az újakkal. A logd démon időszakosan ellenőrzi a puffert, és .tracev3 fájlokba menti az üzeneteket a fájlrendszer védett területén.

Az Apple Engineering adatai szerint az os_log meghívásától az üzenet Console.app-ban való megjelenéséig tartó tipikus késleltetés 1–5 másodperc az eszközön, és akár 60 másodperc a kötegelt lemezre íráskor. Ez egy tudatos kompromisszum: az alkalmazás teljesítménye nem szenved a naplózástól, de a fejlesztő kis késleltetéssel látja az üzeneteket.

// Az os_log deklarálása OSLog segítségével
import OSLog

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

A körpuffer és beállítása

Az os_log körpuffere fix kapacitású, és nem módosítható a felhasználói térből. A puffer mérete 256 KB-tól (Apple Watch) 4 MB-ig (Mac) terjed. Amikor az alkalmazás több üzenetet generál, mint amennyit a puffer tárolni tud, a régi üzenetek elvesznek — ez várható viselkedés nagy volumenű naplózás esetén.

Az összes üzenet hosszú távú gyűjtéséhez a log collect parancsot használják, amely elindítja a gyűjtődémont az eszközön, és exportálja a .logarchive-ot a fejlesztő számítógépére. Ebben a módban a puffer nem íródik felül — az üzenetek közvetlenül az archívumba kerülnek.

Az os_log szintjei: Default, Info, Debug, Error, Fault

os_log öt kritikussági szintet támogat, amelyek mindegyike egy-egy üzenettípusért felelős, és a rendszer eltérően dolgozza fel őket. A Default szint — az alapértelmezett azokhoz az üzenetekhez, amelyek mindig a pufferbe kerülnek. Az Info és Debug ki van kapcsolva az éles build-ekben gyűjtési profil nélkül. Az Error és Fault mindig aktív, és egy speciális jelzővel vannak ellátva az adatbázisban.

A megfelelő kritikussági szint kiválasztása fontos a teljesítmény szempontjából: az Info és Debug nem íródnak a lemezre normál módban, így bőségesen használhatók az alkalmazás lelassításának kockázata nélkül. Az Error és Fault mindig elmentésre kerül, de számuknak minimálisnak kell lennie — minden ilyen üzenet növeli az írási időt a további metaadatok miatt.

Kategóriák és subsystem az os_log-ban

Subsystem — az alkalmazás vagy modul azonosítója reverse-DNS formátumban (com.example.app). Category — szöveges címke a subsystemen belül, amely funkcionális területek szerint csoportosítja a naplókat: network, ui, database, auth. Ez a hierarchia lehetővé teszi a naplók szűrését az egyes üzenetek elolvasása nélkül, és statisztikák gyűjtését minden modulhoz külön-külön.

Az Apple modulonként egy OSLog meghatározását és annak használatát javasolja a modul összes fájljában. Az alkalmazás különböző rétegeihez — networking, UI, persistence — külön kategóriákat kell létrehozni. Ekkor a Console.app-ban csak a network naplói kapcsolhatók be, a többi kikapcsolható, anélkül hogy újra kellene fordítani az alkalmazást.

import OSLog

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

Adatvédelem az os_log-ban

os_log beépített adatvédelmi szabályozó mechanizmust biztosít: a formázó karakterlánc minden értéke megjelölhető public, private vagy auto (alapértelmezett viselkedés) jelzéssel. Alapértelmezés szerint az os_log az összes dinamikus karakterláncot és objektumot potenciálisan bizalmasnak tekinti, és <private> maszkkal helyettesíti őket az éles naplókban.

Ez kritikus fontosságú a GDPR és HIPAA követelményeinek való megfelelés szempontjából: ha az alkalmazás a felhasználó e-mail címét vagy kártyaszámát az os_log-on keresztül auto módban naplózza, a valódi adatok soha nem kerülnek a lemezre. A fejlesztő a teljes üzenetet csak Xcode-on keresztüli csatlakozáskor vagy ugyanahhoz a Mac-hez csatlakoztatott eszközről származó gyűjtési profil használatakor látja.

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

// Éles naplókban: "User login: <private>"
// Hibakereséskor Xcode-on keresztül: "User login: user@example.com"
logger.log("Payment token: \(token)")

Alapértelmezett adatvédelmi szabályok

Számok (Int, Double, Float) alapértelmezés szerint public-nak minősülnek — biztonságosan naplózhatók jelölés nélkül. Karakterláncok (String, NSString, StaticString) és objektumok (NSObject, CFType) alapértelmezés szerint private-ok — maszkolódnak éles környezetben. Statikus karakterláncok (idézőjelek közötti karakterlánc-literálok a formázó karakterláncon belül) mindig láthatók — ezek magának az üzenetnek a részét képezik, nem adatokat.

Ez a viselkedés eltér az NSLog-től, ahol minden adat nyílt formában került naplózásra. Az os_log-ra való áttérés jelentősen csökkenti az érzékeny felhasználói adatok naplókon keresztüli kiszivárgásának kockázatát.

os_log vs NSLog: teljesítmény-összehasonlítás

os_log 90–95%-kal gyorsabb az NSLog-nél nagy frekvenciájú naplózás esetén. Egy 10 000 hívásból álló ciklusos tesztben az NSLog körülbelül 2,8 másodperces késleltetést okoz, míg az os_log ugyanezeket a hívásokat 0,3 másodperc alatt hajtja végre. A különbséget az NSLog szinkron lemezre írása és az os_log aszinkron pufferelése közötti eltérés magyarázza.

Az Apple Performance Lab (2016) adatai szerint egy iOS-alkalmazás másodpercenként 20 naplózási hívással az NSLog-en keresztül 5–8 animációs képkockát veszít másodpercenként a fő szál blokkolása miatt. Az os_log-gal nem történik képkockavesztés, mivel a pufferelés egy külön kernel szálban történik.

Kódpéldák az os_log-gal Swift-ben

os_log két API-val rendelkezik: klasszikus C os_log_create és a modern Swift burkoló Logger, amelyet az iOS 14-ben vezettek be. A Swift Logger a ResultBuilder rendszert használja a formázáshoz — az argumentumok karakterlánc-literálokon keresztül interpolálódnak explicit adatvédelmi jelöléssel.

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 — parancssori segédprogram az eszközről összegyűjtött naplók exportálásához. A terminálból indítható, miután az eszközt USB-n keresztül csatlakoztatta a Mac-hez.

// Naplók gyűjtése .logarchive-ba
// Terminálban: log collect --device --output ./app_logs.logarchive
// Subsystem naplók megtekintése: log show --subsystem com.example.app

// Naplózás dinamikus értékekkel
logger.log("User \(userId) opened screen \(screenName)")

A Logger használatakor fontos megjegyezni, hogy az argumentumok a String Interpolation-en keresztül interpolálódnak, nem pedig formázó karakterláncokon keresztül, mint az os_log C verziójában. Ez biztonságosabb, de minden argumentumhoz explicit privacy megadását igényli, ha az alapértelmezett viselkedés nem felel meg a fejlesztőnek.