Structured Logging — mohiyati, ma'lumot formatlari va ilovalarda ishlash prinsipi

Structured Logging nima

Structured Logging — har bir xabar tipli qiymatlar bilan nomlangan maydonlarni o'z ichiga olgan log yozish usulidir. User 42 logged in from device ABC kabi satr o'rniga tuzilgan log maydonlar to'plami sifatida ko'rinadi: user_id=42, event=login, device_id=ABC, timestamp=2026-07-04T10:30:00Z.

Tuzilgan loglarning matnli loglardan asosiy ustunligi — dasturiy qayta ishlash imkoniyati. Matnli loglarni pars qilish muntazam ifodalar va satr formati haqidagi taxminlarni talab qiladi. Tuzilgan loglar yo'qotishlarsiz pars qilinadi: har bir maydon ma'lum tur va nomga ega, bu qo'shimcha qayta ishlashsiz oxirgi soat ichida foydalanuvchi 42 uchun barcha avtorizatsiya xatolarini top darajasidagi so'rovlarni qurish imkonini beradi.

Honeycomb.io (2023) ma'lumotlariga ko'ra, ishlab chiqarishda structured logging ishlatadigan jamoalar hodisalarni matnli loglar va grep-ga tayanadigan jamoalarga nisbatan o'rtacha 4 marta tezroq aniqlaydi.

Tuzilgan log formatlari

Structured Logging bir nechta serializatsiya formatlarini qo'llab-quvvatlaydi. Formatni tanlash infratuzilmaga bog'liq: JSON Elasticsearch va bulut tizimlari bilan integratsiya uchun qulay, logfmt — tail va grep orqali konsol ko'rinishi uchun, Protocol Buffers — yuqori unumli, o'tkazish qobiliyati cheklangan tizimlar uchun.

JSON — universal format

JSON tuzilgan loglar uchun eng keng tarqalgan formatdir. Barcha yig'ish tizimlari tomonidan mahalliy qo'llab-quvvatlanadi: Logstash, Fluentd, Amazon CloudWatch, Google Cloud Logging. JSON loglari odam tomonidan oson o'qiladi va qo'shimcha kutubxonalarsiz har qanday dasturlash tili bilan pars qilinadi. Asosiy kamchilik — ortiqchalik: har bir kalit-qiymat juftligi qo'shtirnoq va ikki nuqtani talab qiladi, bu saqlanadigan ma'lumotlar hajmini logfmt-ga nisbatan 30–50% oshiradi.

Logfmt — ixcham format

Logfmt Heroku-da konsol ko'rinishi uchun ishlab chiqilgan. JSON-dan ixchamroq, odam o'qish qobiliyatini saqlaydi va cut va awk bilan oson kesiladi. Misol: ts=2026-07-04T10:30:00Z level=error module=api status=500. Logfmt ko'pchilik belgilarni ekranlashtirishni talab qilmaydi va konteynerlarda stdout-loglash uchun yaxshi mos keladi.

Nega Structured Logging mobil ishlanmada kerak

Mobil ilovalarda Structured Logging uchta asosiy vazifani hal qiladi: qurilmada takrorlanmasdan nosozlik sabablarini topish, foydalanuvchi sessiyalarini kuzatish va ilova versiyalari bo'yicha unumdorlikni tahlil qilish.

Mobil qurilmalarda matnli loglar deyarli foydasiz — dasturchi foydalanuvchi qurilmasida loglarni grep qila olmaydi. Tuzilgan loglar bulut tizimlariga (Firebase, Sentry, Datadog) yuboriladi va u erda indekslanadi. So'rov qurish mumkin: iOS 17.4 dagi barcha crash-larni ko'rsat, ilova versiyasi 3.2, checkouts modulida — va bir necha soniya ichida aniq tanlovni olish.

Sentry (2024) ma'lumotlariga ko'ra, structured breadcrumbs ishlatadigan ilovalar faqat xato matnini loglaydigan ilovalarga nisbatan har bir crash hisobotida 60% ko'proq kontekstga ega. Bu to'g'ridan-to'g'ri xatoni tuzatish tezligiga ta'sir qiladi.

Yig'ish va tahlil vositalari

ELK Stack — Elasticsearch, Logstash, Kibana — tuzilgan loglar bilan ishlash uchun standart infratuzilma bo'lib qolmoqda. Logstash loglarni JSON-da qabul qiladi, o'zgartiradi va indekslash uchun Elasticsearch-ga yuboradi, Kibana so'rovlar va dashboardlar uchun vizual interfeysni taqdim etadi.

Mobil ilovalar uchun bulutli yechimlar mashhur: Firebase Crashlytics maxsus loglar bilan, Sentry breadcrumbs bilan, Datadog APM kuzatuvi bilan. Ular tuzilgan loglarni to'g'ridan-to'g'ri mobil SDK-dan qabul qiladi va o'z backend-ni joylashtirishni talab qilmaydi. Firebase crash hisobotlari uchun bepul paketni taklif qiladi, Sentry distributed tracing qo'shadi, Datadog esa bir vaqtning o'zida mijoz va serverda so'rov unumdorligini kuzatish uchun APM bilan integratsiyalanadi.

Grafana Loki — loglar uchun optimallashtirilgan Elasticsearch alternativi. Loki sukut bo'yicha xabarlar mazmunini indekslamaydi, filtrlash uchun teglardan (labels) foydalanadi. Bu saqlashda ancha arzon va belgilangan maydonlar to'plami bo'yicha so'rovlarda tezroq.

// Structured logging Swift Logger orqali JSON-da
struct StructuredLog {
    let event: String
    let attributes: [String: Any]
    let level: String

    func serialize() -> String {
        var base = "event=\(event) level=\(level)"
        for (key, value) in attributes {
            base += " \(key)=\(value)"
        }
        return base
    }
}

Structured Logging eng yaxshi amaliyotlari

Tuzilgan loglashning birinchi qoidasi: har bir xabar so'rov yoki sessiya identifikatorini o'z ichiga olishi kerak. Kontekstsiz, yagona log foydasiz — qaysi foydalanuvchi yoki so'rovga tegishli ekanligini tushunish mumkin emas. Sessiya boshida correlation ID qo'shing va uni ilovaning barcha qatlamlari orqali o'tkazing.

Ikkinchi qoida: maydonlarni tiplash. Raqamli maydonlar (duration_ms, status_code, retry_count) satr sifatida emas, raqam sifatida uzatilishi kerak. Elasticsearch va shunga o'xshash tizimlar raqamlar va satrlarni turlicha indekslaydi: raqamlarga agregatsiyalar (o'rtacha, mediana, persentil) qo'llanilishi mumkin, satrlarga — to'liq matnli qidiruv. Soxta tiplash analitik dashboardlar qurish imkoniyatini yo'qotadi.

Uchinchi qoida: ichma-ich obyektlardan saqlaning. 2 darajadan chuqur ichma-ich JSON loglarini filtrlash va vizuallashtirish qiyin. {"user": {"name": "Alice", "role": "admin"}} o'rniga yassi kalitlardan foydalaning: user_name=Alice user_role=admin.

// Structured logging Android-da Timber + logfmt orqali
class StructuredTree : Timber.Tree() {
    override fun log(priority: Int, tag: String?,
                  message: String?, t: Throwable?) {
        val level = priorityToLevel(priority)
        val logfmt = "level=$level tag=$tag message=$message"
        sendToRemote(logfmt)
    }
}

Qaysi maydonlar majburiy

Har bir tuzilgan xabar uchun minimal maydonlar to'plami: timestamp ISO 8601 formatida, level (debug/info/warn/error/fatal), logger (modul yoki sinf nomi), message (hodisaning odam o'qiy oladigan tavsifi). Qo'shimcha: correlation_id, user_id (agar ma'lum bo'lsa), version (ilova versiyasi), platform (iOS/Android), environment (dev/staging/prod).

Correlation ID bo'lmasa tuzilgan loglar bir foydalanuvchi ssenariysida birlashtirib bo'lmaydigan tarqoq yozuvlar to'plamiga aylanadi. Har bir ilova ishga tushirilganda UUID yarating va uni barcha sessiya loglariga qo'shing. Amalda correlation ID barcha qatlamlardan o'tkazilishi kerak: UI hodisalaridan tarmoq so'rovlari va fon vazifalarigacha — aks holda loglarning bir qismi kontekstsiz qoladi va analitikada ishtirok etmaydi. Uchidan-uchiga kuzatishda bitta UUID foydalanuvchi yo'lining to'liq rasmini to'plash imkonini beradi.

Swift va Kotlin-da tuzilgan loglash misollari

iOS-da tuzilgan loglash os_log ustidagi maydonlarni logfmt formatiga seriyalashtiradigan o'rash orqali amalga oshirilishi mumkin. Android-da — serverga yuborishdan oldin xabarlarni JSON yoki logfmt-ga aylantiradigan maxsus Tree bilan Timber orqali.

import OSLog

struct StructuredLogger {
    let subsystem: String
    let category: String

    func log(level: OSLogType,
              event: String,
              context: [String: Any]) {
        let oslogger = Logger(
            subsystem: subsystem,
            category: category
        )
        let fields = context.map {
            "\($0.key)=\($0.value)"
        }.joined(separator: " ")
        oslogger.log(level: level,
                     "\(event) \(fields)")
    }
}

Structured vs Unstructured: yondashuvlarni taqqoslash

Tuzilgan va matnli loglar o'rtasidagi tanlov loyiha bosqichiga bog'liq. Dastlabki rivojlanish bosqichlarida matnli loglar sodda va tezroq — dasturchi xabarni to'g'ridan-to'g'ri qo'shimcha o'rashlarsiz yozadi. Ammo loyiha bir jamoa yoki bir server chegarasidan chiqishi bilan tuzilgan loglar majburiy bo'ladi.