Log stream — bitta manba yoki bir xil label to‘plamiga tegishli log yozuvlarining vaqt bo‘yicha tartiblangan oqimidir. Container stdouti, systemd unit chiqishi yoki Loki dagi {service="api", instance="a"} label seti alohida stream sifatida qaralishi mumkin. Stream yozuvlarni kelib chiqish konteksti bilan guruhlaydi.
Stream identifikatori
Identifikator platformaga qarab fayl pathi, container ID, source handle yoki label to‘plami bo‘ladi. Loki modelida aynan bir xil labelarga ega log entrylar bitta streamni tashkil qiladi. Label qiymati o‘zgarsa yangi stream paydo bo‘ladi.
Request ID, user ID yoki timestampni stream labeliga qo‘yish juda yuqori cardinality yaratadi. Bunday qiymatlar log matni yoki structured fieldda qoladi va query pipeline orqali filterlanadi. Label service, environment, namespace va stable instance kabi cheklangan o‘lchamlar uchun ishlatiladi.
Tartib va vaqt
Bitta process loglari yozilish tartibida kelishi mumkin, ammo collector buffer, network retry va parallel threadlar sabab markaziy tizimda arrival tartibi farqlanadi. Event timestamp log manbasidan, ingestion timestamp collector yoki backenddan olinadi. Ikkalasining farqi pipeline kechikishini ko‘rsatadi.
Distributed request bir nechta streamga tarqaladi. Faqat timestamp bo‘yicha birlashtirish soat siljishi sabab yetarli emas. Trace ID va span ID loglarni request executioni bilan bog‘laydi. Multiline stack trace bitta entry sifatida yig‘ilmasa streamda alohida, ma’nosiz satrlarga bo‘linadi.
Stream lifecycle
Container qayta yaratilganda yangi ID va ko‘pincha yangi stream hosil bo‘ladi. File rotationda agent inode va offsetni kuzatib, eski faylning qolgan qismini yangi fayl bilan adashtirmasligi kerak. Copy-truncate usuli offsetni kutilmaganda ortda qoldirishi mumkin.
Agent o‘qilgan pozitsiyani checkpointda saqlaydi. Crashdan keyin eski checkpoint duplicate yuborishi, juda yangi checkpoint esa buffer diskka yozilmagan bo‘lsa loss keltirishi mumkin. Delivery semantikasi agent va backend konfiguratsiyasiga bog‘liq.
Oqimni qayta ishlash
Pipeline har entryni parse, filter, redact va enrich qiladi. Source labelga cluster yoki tenant metadata qo‘shilishi mumkin. Parsing xatosi yozuvni tashlab yubormasdan alohida error field bilan saqlansa format regressiyasi ko‘rinadi.
Live tail yangi entrylarni real vaqtda ko‘rsatadi, ammo katta production tizimida keng filter backend va clientni bosadi. Tor label selector, qisqa vaqt va rate limit ishlatiladi. Live tail tarixiy queryning o‘rnini bosmaydi, chunki reconnect oralig‘ida yozuv o‘tkazib yuborilishi mumkin.
Loki modeli
Loki stream loglarini vaqt bo‘yicha chunklarga yig‘ib object storagega saqlashi mumkin. Indeks asosan label va vaqt oralig‘ini topadi. LogQL avval stream selector bilan candidate oqimlarni tanlab, keyin matn parseri va filterlarini qo‘llaydi. Tor selector query samaradorligining muhim qismidir.
Out-of-order yozuvlarni qabul qilish chegarasi backend versiyasi va sozlamasiga bog‘liq. Juda eski timestamp replay yoki noto‘g‘ri soat sabab rad etilishi mumkin. Agent rejection metric va yo‘qotilgan entry sonini kuzatadi.
Stream va event farqi
Stream transport va saqlash guruhini, event esa bitta semantik hodisani bildiradi. Bir stream turli event type larni saqlashi mumkin; parser event fieldi orqali ularni ajratadi. Bitta biznes event ham bir nechta streamda log nusxasiga ega bo‘lishi mumkin. Ularni count qilishda duplicate va retry hisobga olinadi.
Stream labelini keyin o‘zgartirish eski va yangi oqimni alohida qoldiradi. Query migratsiya davrida ikkala label conventionini qamrab oladi. Label normalizatsiyasini ingestda bajarish qidiruvni soddalashtiradi, ammo original source metadata kerak bo‘lsa alohida fieldda saqlanadi.
Bog‘liq tushunchalar
Log aggregation, Structured logging, Loki, LogQL, Label, Live tail, Timestamp