os_log: bu nədir, imkanları və Apple-da unified logging-in işləməsi

os_log nədir

os_log — Apple tərəfindən iOS 10 və macOS Sierra-da təqdim edilmiş unified logging API-dir. O, NSLog, os_trace və syslog-un səpələnmiş loqinq mexanizmlərini XNU nüvəsi səviyyəsində buferləşdirmə ilə vahid sistemdə birləşdirmişdir.

Hər mesajı sinxron şəkildə diskə yazan və thread-i bloklayan NSLog-dan fərqli olaraq, os_log yaddaşda asinxron halqa buferindən istifadə edir. Mesajlar yalnız aktivlik müəyyən edilmiş həddi aşdıqda və ya log collect əmri ilə diskə atılır. Bu, loqinqin tətbiq performansına təsirini kəskin şəkildə azaldır.

os_log altı kritiklik səviyyəsini, subsystem və category üzrə diferensiasiyanı, həmçinin daxili məxfilik mexanizmini dəstəkləyir: private kimi qeyd edilmiş məlumatlar istehsal loqlarında avtomatik maskalanır və yalnız Xcode qoşulduqda tərtibatçı üçün əlçatan olur.

Unified logging-in yaranma tarixi

iOS 10-dan əvvəl tərtibatçılar debug üçün NSLog və sistem mesajları üçün syslog istifadə edirdilər. NSLog stderr-ə və konsola yazırdı, lakin son dərəcə səmərəsiz idi: hər mesaj sinxron şəkildə diskə yazılır, tez-tez loqinq zamanı UI-də gecikmələrə səbəb olurdu. os_log bu problemi buferləşdirməni XNU nüvəsinin BSD hissəsi səviyyəsinə köçürərək və diskə yazmanı asinxron edərək həll etdi.

os_log harada tətbiq olunur

os_log bütün Apple tətbiqlərində istifadə olunur və Apple tərəfindən iOS, macOS, tvOS və watchOS üçün yeganə loqinq API-si kimi tövsiyə edilir. Sistem və üçüncü tərəf tətbiqləri onun vasitəsilə vahid verilənlər bazasına mesajlar yazır — bu baza yaddaşda saxlanılır və vaxtaşırı diskə atılır. Bu loqları Mac-da Console.app vasitəsilə və ya terminalda log əmri ilə analiz etmək olar.

os_log necə işləyir: arxitektura və buferləşdirmə

os_log-un arxitekturası üç təbəqədən ibarətdir: istifadəçi məkanında müştəri API-si (libsystem_trace.dylib), XNU nüvəsində halqa buferi və buferi asinxron şəkildə diskə atan logd demonu.

Tətbiq os_log-u çağırdıqda, mesaj bir neçə meqabayt ölçüsündə nüvə halqa buferinə kopyalanır. Bufer FIFO prinsipi ilə işləyir: dolduqda köhnə mesajlar yeniləri ilə əvəz olunur. logd demonu vaxtaşırı buferi yoxlayır və mesajları fayl sisteminin qorunan sahəsində .tracev3 fayllarına yazır.

Apple Engineering məlumatlarına görə, os_log çağırışından Console.app-da mesajın görünməsinə qədər tipik gecikmə cihazda 1–5 saniyə, paket rejimində diskə atmada isə 60 saniyəyə qədərdir. Bu şüurlu kompromisdir: tətbiq performansı loqinqdən əziyyət çəkmir, lakin tərtibatçı mesajları kiçik gecikmə ilə görür.

// os_log-un OSLog vasitəsilə elan edilməsi
import OSLog

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

Halqa buferi və onun konfiqurasiyası

Halqa buferi os_log-un sabit həcmi var və onu istifadəçi məkanından dəyişmək mümkün deyil. Buferin ölçüsü Apple Watch-da 256 KB-dan Mac-da 4 MB-a qədər dəyişir. Tətbiq buferin tutduğundan çox mesaj yaratdıqda, köhnə mesajlar itir — bu, yüksək həcmli loqinq üçün gözlənilən davranışdır.

Bütün mesajların uzunmüddətli toplanması üçün log collect əmrindən istifadə olunur, o cihazda toplama demonunu işə salır və .logarchive-ı tərtibatçının kompüterinə ixrac edir. Bu rejimdə bufer üzərinə yazılmır — mesajlar birbaşa arxivə yazılır.

os_log səviyyələri: Default, Info, Debug, Error, Fault

os_log beş kritiklik səviyyəsini dəstəkləyir, hər biri ayrıca mesaj növünə cavabdehdir və sistem tərəfindən fərqli işlənir. Default səviyyəsi — həmişə buferə düşən mesajlar üçün əsas səviyyədir. Info və Debug toplama profili olmadan istehsal qurğularında söndürülür. Error və Fault həmişə aktivdir və verilənlər bazasında xüsusi bayraqla qeyd olunur.

Düzgün kritiklik səviyyəsinin seçilməsi performans üçün vacibdir: Info və Debug adi rejimdə yazılmır diskə, buna görə də tətbiqi yavaşlatmaq riski olmadan bolca istifadə edilə bilər. Error və Fault həmişə saxlanılır, lakin onların sayı minimal olmalıdır — hər belə mesaj əlavə metadata səbəbindən yazma müddətini artırır.

os_log-da kateqoriyalar və subsystem

Subsystem — tətbiqin və ya modulun reverse-DNS formatında identifikatorudur (com.example.app). Category — subsystem daxilində mətn etiketi, loqları funksional sahələr üzrə qruplaşdırır: network, ui, database, auth. Belə iyerarxiya hər mesajı oxumadan loqları filtrləməyə və hər modul üçün ayrıca statistika toplamağa imkan verir.

Apple hər modul üçün bir OSLog təyin etməyi və onu bu modulun bütün fayllarında istifadə etməyi tövsiyə edir. Tətbiqin müxtəlif təbəqələri üçün — networking, UI, persistence — ayrı-ayrı kateqoriyalar yaradılmalıdır. Onda Console.app-da yalnız network üçün loqları açmaq və qalanlarını söndürmək olar, tətbiqi yenidən kompilyasiya etmədən.

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-da məlumatların məxfiliyi

os_log daxili məxfilik nəzarəti mexanizmi təmin edir: formatlama sətirindəki hər bir dəyər public, private və ya auto (defolt davranış) kimi qeyd edilə bilər. Defolt olaraq os_log bütün dinamik sətirləri və obyektləri potensial məxfi hesab edir və onları istehsal loqlarında <private> maskası ilə əvəz edir.

Bu, GDPR və HIPAA tələblərinə uyğunluq üçün kritik əhəmiyyət daşıyır: əgər tətbiq istifadəçinin e-poçtunu və ya kart nömrəsini os_log vasitəsilə auto rejimində loq edirsə, real məlumatlar heç vaxt diskə düşmür. Tərtibatçı tam mesajı yalnız Xcode vasitəsilə qoşulduqda və ya eyni Mac-a qoşulmuş cihazdan toplama profilindən istifadə etdikdə görür.

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

// İstehsal loqlarında: "User login: <private>"
// Xcode vasitəsilə debugda: "User login: user@example.com"
logger.log("Payment token: \(token)")

Defolt məxfilik qaydaları

Rəqəmlər (Int, Double, Float) defolt olaraq public hesab olunur — onları işarələmədən təhlükəsiz loq etmək olar. Sətirlər (String, NSString, StaticString) və obyektlər (NSObject, CFType) defolt olaraq private-dir — istehsalda maskalanır. Statik sətirlər (format sətirində dırnaq içərisindəki sətir literalları) həmişə görünür — bu mesajın özünün bir hissəsidir, məlumat deyil.

Bu davranış bütün məlumatların açıq şəkildə loq edildiyi NSLog-dan fərqlənir. os_log-a keçid loqlar vasitəsilə həssas istifadəçi məlumatlarının sızması riskini əhəmiyyətli dərəcədə azaldır.

os_log vs NSLog: performans müqayisəsi

os_log yüksək tezlikli loqinqdə NSLog-dan 90–95% daha sürətlidir. Dövrədə 10 000 çağırış testində NSLog təxminən 2.8 saniyə gecikmə yaradır, os_log isə eyni çağırışları 0.3 saniyədə yerinə yetirir. Fərq NSLog-da sinxron diskə yazma ilə os_log-da asinxron buferləşdirmə arasındakı fərqlə izah olunur.

Apple Performance Lab (2016) məlumatlarına görə, saniyədə 20 loqinq çağırışı olan iOS tətbiqi NSLog vasitəsilə əsas thread-in bloklanması səbəbindən saniyədə 5–8 animasiya kadrını itirir. os_log ilə kadr itkisi baş vermir, çünki buferləşdirmə ayrıca nüvə thread-ində aparılır.

Swift-də os_log ilə kod nümunələri

os_log iki API-yə malikdir: klassik C os_log_create və iOS 14-də təqdim edilmiş müasir Swift sarğısı Logger. Swift Logger formatlaşdırma üçün ResultBuilder sistemindən istifadə edir — arqumentlər aşkar məxfilik qeydi ilə sətir literalları vasitəsilə interpolasiya olunur.

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 — cihazdan toplanmış loqları ixrac etmək üçün komanda sətri utiliti. USB vasitəsilə cihazı Mac-a qoşduqdan sonra Terminaldan işə salınır.

// .logarchive-da loqların toplanması
// Terminalda: log collect --device --output ./app_logs.logarchive
// Subsystem loqlarına baxış: log show --subsystem com.example.app

// Dinamik dəyərlərlə loqinq
logger.log("User \(userId) opened screen \(screenName)")

Logger istifadə edərkən yadda saxlamaq lazımdır ki, arqumentlər C versiyasındakı kimi format sətirləri ilə deyil, String Interpolation vasitəsilə interpolasiya olunur. Bu daha təhlükəsizdir, lakin defolt davranış tərtibatçını qane etmirsə, hər arqument üçün aşkar privacy göstərilməsini tələb edir.