Loki

Loki — log yozuvlarini markaziy yig‘ish, saqlash va query qilishga mo‘ljallangan log aggregation tizimi. U logning to‘liq matnini keng indekslash o‘rniga asosan label metadata’sini indekslashga urg‘u beradi.

Loki ko‘pincha application va container loglarini agent orqali qabul qiladi, siqilgan chunklarda saqlaydi va LogQL yordamida qidiradi.

Log stream

Loki’da loglar streamlarga ajratiladi.

Stream label to‘plami bilan aniqlanadi.

Misol:

{service="api", environment="prod"}

Shu label kombinatsiyasiga tegishli barcha log qatorlari bitta mantiqiy stream hisoblanadi.

Label

Label logni topish uchun indekslanadigan metadata.

Yaxshi label:

• service;
• environment;
• namespace;
• cluster;
• log level;
• region.

Yuqori cardinality label:

• request ID;
• user ID;
• order ID;
• tasodifiy path;
• timestamp

indeks va stream sonini keskin oshiradi.

Bunday qiymatlar log matnida field sifatida qoladi.

Cardinality

Har noyob label kombinatsiyasi yangi stream yaratadi.

Juda ko‘p stream:

• memory;
• index;
• ingestion;
• query;
• storage metadata

yukini oshiradi.

Label dizayni Prometheus metriclariga o‘xshash ehtiyotkorlik talab qiladi.

Log agent

Agent host yoki container platformadan loglarni o‘qib Lokiga yuboradi.

Agent vazifalari:

• file tail;
• container log discovery;
• label qo‘shish;
• parsing;
• multiline birlashtirish;
• buffering;
• retry;
• backpressure.

Agent pozitsiyani saqlab, restartdan keyin qayerdan davom etishni bilishi kerak.

Push modeli

Prometheus odatda targetni scrape qiladi.

Log tizimida agent loglarni Loki endpointiga push qiladi.

Network uzilganda agent:

• disk buffer;
• memory queue;
• retry;
• drop policy

bilan ishlaydi.

Cheksiz buffer host diskini to‘ldirishi mumkin.

Chunk

Bir stream loglari vaqt va hajm bo‘yicha chunklarga guruhlanadi.

Chunk:

• compression;
• object storage;
• cache;
• retention

uchun qulay birlik.

Juda mayda streamlar kichik chunklar sonini ko‘paytirib samaradorlikni pasaytiradi.

Index

Loki label va vaqt oralig‘i bo‘yicha kerakli chunklarni topadi.

Log matnidagi har bir so‘z odatda global full-text indexga kiritilmaydi.

Shu sababli query avval label bilan streamlarni toraytirib, keyin matnni filter qilishi kerak.

LogQL

LogQL log streamlarni tanlash va qayta ishlash uchun query tili.

Oddiy selector:

{service="api", environment="prod"}

Matn filter:

|= "error"

Parser bosqichi JSON yoki logfmt fieldlarni ajratishi mumkin.

Metric query loglardan rate va count hisoblaydi.

Structured log

JSON yoki key-value log parsingni yengillashtiradi.

Misol fieldlar:

• timestamp;
• level;
• message;
• trace_id;
• user_action;
• duration.

Har fieldni labelga aylantirish shart emas.

Query vaqtida kerakli field parse qilinishi mumkin.

Multiline log

Stack trace bir nechta qatordan iborat.

Agent ularni bitta eventga birlashtirmasa har qator alohida log bo‘lib ketadi.

Multiline qoida:

• boshlanish patterni;
• timeout;
• maksimal qator;
• maksimal hajm

bilan cheklanadi.

Timestamp

Log event vaqti agent qabul qilgan vaqt yoki log ichidagi timestampdan olinadi.

Noto‘g‘ri parsing:

• kelajakdagi vaqt;
• juda eski vaqt;
• tartibsiz stream;
• queryda yo‘qolgan log

keltirishi mumkin.

Barcha hostlarda vaqt sinxronizatsiyasi muhim.

Out-of-order log

Distributed tizimda loglar kechikib yoki tartibsiz kelishi mumkin.

Storage ma’lum out-of-order oynaga ruxsat berishi mumkin.

Juda kech event rad etilishi yoki alohida qayta ishlanishi mumkin.

Retention

Loglar vaqt yoki tenant siyosati bo‘yicha o‘chiriladi.

Retention:

• compliance;
• incident tahlili;
• storage xarajati;
• maxfiy data

bilan muvozanatlanadi.

Faqat object storage lifecycle va Loki index retention bir-biriga mos bo‘lishi kerak.

Multi-tenancy

Bir cluster bir nechta tenant logini ajratishi mumkin.

Tenant ID request orqali beriladi.

Gateway authentication qilib, foydalanuvchi o‘z tenantini o‘zgartira olmasligini ta’minlaydi.

Storage darajasidagi mantiqiy isolation access policy bilan birga ishlaydi.

Query performance

Yaxshi query:

1. tor vaqt oralig‘i;
2. aniq label selector;
3. keyin matn filter;
4. kerakli parser;
5. minimal result.

Faqat error so‘zini barcha service va uzoq vaqt bo‘yicha qidirish qimmat.

Trace correlation

Structured log ichida trace_id saqlansa Grafana yoki boshqa UI logdan trace’ga o‘tishi mumkin.

Trace ID label bo‘lmasdan parsed field sifatida qidirilishi mumkin.

Metric, log va trace umumiy service va environment label conventioniga ega bo‘lsa correlation osonlashadi.

Maxfiy ma’lumot

Logga quyidagilar yozilmaydi:

• parol;
• access token;
• private key;
• to‘liq payment data;
• maxfiy personal data.

Agentda redaction bo‘lishi mumkin, ammo eng yaxshi joy applicationning o‘zidir.

Distributor va ingester

Scale qilingan arxitekturada distributor incoming streamlarni tekshiradi va ingesterlarga tarqatadi. Ingester loglarni memoryda yig‘ib, chunklar hosil qiladi va barqaror storage’ga yozadi.

Query frontend

Query frontend uzun querylarni bo‘lishi, cache ishlatishi va workerlar orasida taqsimlashi mumkin. Bu katta vaqt oralig‘idagi so‘rovlarni boshqarishga yordam beradi.

Compactor

Index va retention bilan bog‘liq background ishlar compactor orqali bajarilishi mumkin. Delete request va retention storage lifecycle bilan mos bo‘lishi kerak.

Ruler

LogQL asosidagi recording va alert qoidalari davriy ishlaydi. Rule query’lari ham cardinality va vaqt oralig‘i bo‘yicha optimallashtiriladi.

Rate limit

Tenant bo‘yicha ingestion rate, stream soni va query limitlari bir foydalanuvchining butun cluster resource’ini egallashini cheklaydi.

Bog‘liq tushunchalar

Log aggregation, Log stream, Label, LogQL, Structured logging, Log agent, Chunk, Cardinality, Grafana, Trace correlation