Structured logging — log hodisasini erkin matn sifatida emas, nomlangan maydonlardan iborat mashina o‘qiydigan yozuv ko‘rinishida chiqarish usulidir. JSON, logfmt yoki binary schema ishlatilishi mumkin. Timestamp, level, service, event, trace ID va domen atributlari alohida saqlangani uchun qidirish, agregatsiya va routing aniqroq bo‘ladi.
Hodisa modeli
Yaxshi yozuv “xato yuz berdi” matnidan tashqari qayerda va nima bilan sodir bo‘lganini beradi. Masalan, event=payment_declined, order_id, provider, reason_code va duration fieldlari hodisani tavsiflaydi. Field nomlari xizmatlar orasida barqaror conventionga ega bo‘ladi.
Log message inson o‘qishi uchun qolishi mumkin, lekin automation message matnini regex bilan parchalashga tayanmaydi. Matn tarjima yoki imlo o‘zgarganda query buzilmasligi uchun event va reason kabi identifikatorlar alohida fielddir.
Turlar va schema
Raqam satr sifatida yozilsa range va aggregation noto‘g‘ri ishlaydi. Boolean, integer, duration va timestamp aniq turda chiqariladi. Duration birligi field nomi yoki schema bilan belgilanadi, masalan duration_ms. Bir service sekund, boshqasi millisekund yuborsa umumiy dashboard noto‘g‘ri bo‘ladi.
Schema registry majburiy bo‘lmasa ham field katalogi va versionlash foydali. Mavjud field ma’nosini o‘zgartirish tarixiy queryni buzadi. Yangi optional field odatda mos, fieldni boshqa turga aylantirish esa yangi nom yoki migratsiya talab qiladi.
Context qo‘shish
Request middleware correlation ID, trace ID, route va authenticated subject kabi umumiy contextni loggerga bog‘laydi. Har log chaqiruviga qo‘lda uzatish unutishga olib keladi. Context propagation async task va message consumer chegarasidan ham o‘tishi kerak.
High-cardinality field log ichida bo‘lishi mumkin, ammo storage uni avtomatik indekslamasligi kerak. Qaysi field indeks yoki stream label bo‘lishi query chastotasi va cardinalityga qarab belgilanadi.
Xato va stack trace
Exception turi, message, stack trace va cause chain alohida fieldlarda berilishi mumkin. Multiline stack trace collector parserini buzmasligi uchun JSON ichida escaped satr yoki array sifatida saqlanadi. Bir exception uchun o‘nlab bir xil log yozish signalni ko‘paytiradi; xato ownershipi qatlam bo‘yicha belgilanadi.
Error log foydalanuvchi kiritmasini to‘liq qaytarmaydi. SQL, token yoki request body stack contextiga tasodifan tushishi mumkin. Sanitization field darajasida amalga oshiriladi.
Ishonchlilik va narx
Log serialization application latencyga ta’sir qilishi mumkin. Asinxron sink throughputni oshiradi, lekin process crashida buffer yo‘qolishi ehtimol. Audit log uchun durability talabi debug logdan kuchliroq bo‘ladi.
Har requestning katta obyektini loglash storage va networkni ko‘paytiradi. Level, sampling va eventga xos field tanlovi qo‘llanadi. Dynamic objectni nazoratsiz serialize qilish circular reference yoki maxfiy field tarqalishiga olib kelishi mumkin.
Field naming
Nested JSON domen guruhini saqlaydi, ammo ayrim backendlar uni flatten qiladi. http.request.method kabi nomlar OpenTelemetry semantic convention bilan moslashishi mumkin. Bir xil tushuncha uchun userId, user_id va uid aralashsa umumiy query murakkablashadi. Naming convention casing, namespace va reserved fieldlarni belgilaydi.
Loggerga berilgan obyekt keyin o‘zgartirilsa asinxron serializer yangi holatni yozishi mumkin. Kutubxona qiymatni chaqiruv vaqtida snapshot qilishi yoki immutable data qabul qilishi kerak. Lazy evaluation performance beradi, lekin lifecycle tushunarli bo‘ladi.
Bog‘liq tushunchalar
JSON logging, Log aggregation, Correlation ID, Trace context, Log schema, Log level, OpenTelemetry