Kuzatilganlik: loglar, metriklar, trastirovkalar
Kuzatilganlik: loglar, metriklar, trastirovkalar
1) Nima uchun bu zarur?
Kuzatish - tizimning o’z holati to’g "risida rejalashtirilmagan savollarga javob berish qobiliyati. U uchta asosiy signalga tayanadi:- Metriklar - simptomlar bo’yicha SLI/SLO va alerting uchun ixcham agregatlar.
- Izlanishlar - so’rovlarning sababiy-oqibatli zanjirlari (end-to-end).
- Logi - tekshiruv va audit uchun batafsil voqealar.
Maqsad: tezkor RCA, preventiv alertlar va error budget doirasida boshqariladigan ishonchlilik.
2) Arxitektura prinsiplari
Yagona kontekst:’trace _ id’,’span _ id’,’tenant _ id’,’request _ id’,’user _ agent’,’client _ ip _ hash’.
Standartlar: SDK/agentlar uchun OpenTelemetry (OTel), JSON-log formati (kanonik, sxemali).
Simptomlar> sabablar: CPU emas, foydalanuvchi simptomlari (yashirin/xato) bo’yicha alertim.
Signallar aloqasi: metrikadan spanga (exemplars) → aniq loglarga’trace _ id’.
Xavfsizlik va maxfiylik: PIIni log’larda yashirish, in transit/at rest shifrlash, audit uchun o’zgarmas jurnallar.
Koʻp ijara: nomlar/kalitlar/siyosatlar boʻshliqlarini ajratish.
3) Signallar taksonomiyasi va sxemalar
3. 1 Metrika
Xizmatlar uchun RED (Rate, Errors, Duration) va infratuzilma uchun USE (Utilization, Saturation, Errors).
Типы: counter, gauge, histogram/summary. Latentlik uchun - bucket’lar o’rnatilgan histogram.
Exemplars: gistogrammaning «issiq» bandlaridagi’trace _ id’ga havola.
name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id
3. 2 Trassalar
Span =’name’,’start/end’,’attributes’,’events’,’status’bilan operatsiya.
Chidamlilik uchun W3C Trace Context.
Semplash: asosiy (head) + dinamik (tail) + «muhimlik» qoidalari (xatolar, yuqori p95).
3. 3 Logi
Faqat strukturalangan JSON; darajalar: DEBUG/INFO/WARN/ERROR.
Majburiy maydonlar:’ts _ utc’,’level’,’message’,’trace _ id’,’span _ id’,’tenant _ id’,’env’,’service’,’region’,’host’,’labels {}’.
Taqiqlangan: sirlar, tokenlar, PAN, parollar. PII - faqat tokenlashtirilgan/niqoblangan.
json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}
4) Yig’ish va transport
Agentlar/eksportchilar (daemonset/sidecar) → uzeldagi bufer → shina/ingest (TLS/mTLS) → signallar ombori.
Talablar: back-pressure, retrajlar, deduplikatsiya, kardinallikni cheklash (labels!), «log storms» dan himoya qilish.
Metriklar: pull (Prometheus-mos) yoki OTLP orqali push.
OTLP/HTTP (gRPC), kollektordagi tail-samplerlar.
Logi: lokal yigʻish (journald/docker/stdout) → parser → normalizator.
5) Saqlash va retensiya (tiered)
Metriklar: issiq TSDB 7-30 kun (downsample bilan), agregatlar uzoqroq muddatga (90-365 kun).
Yo’nalishlar: 1-7 kun to’liq, so’ngra «muhim» servislarning agregatlari/spanlari; indekslarni’service’,’status’,’error’bo’yicha saqlash.
Logi: issiq indeks 7-14 kun, issiq 3-6 oy, arxiv 1-7 yilgacha (komplayens). Audit - WORM.
Xarajatlarni optimallashtirish: downsampling, DEBUGni proda filtrlash, leybllar uchun kvotalar, trassalar uchun sampling.
6) SLI/SLO, alerting va navbatchilik
SLI: foydalanish imkoniyati (% muvaffaqiyatli so’rovlar), yashirin (p95/p99), 5xx ulushi, ma’lumotlarning yangiligi, muvaffaqiyatli job ulushi.
SLO: SLIdagi maqsad (masalan, 99. 9% muvaffaqiyatli ≤ 400 ms).
Error budget: 0. 1% xato huquqi → fichfriz/tajriba qoidalari.
- `ALERT HighLatency` если `p99(http_server_duration_seconds{route="/pay"}) > 1s` 5мин.
- `ALERT ErrorRate` если `rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0. 02`.
- Silos-alertlar (CPU/Disk) - faqat yordamchi sifatida, pagingsiz.
7) Signallarning korrelyatsiyasi
"Qizil" metrikasi → exemplar’ga bosish → aniq’trace _ id’→ "sekin’span’ga qarash → xuddi shu’trace _ id’bo’yicha loglarni ochish.
Relizlar bilan bogʻlanish:’version’,’image _ sha’,’feature _ flag’atributlari.
Maʼlumotlar/ETL uchun:’dataset _ urn’,’run _ id’, lineage bilan aloqa (tegishli maqolaga qarang).
8) Semplash va kardinallik
Metriklar: yorliqlarni cheklaymiz (’user _ id’,’session _ id’); ro’yxatdan o’tkazishda kvotalar/validatsiya.
Trastirovki: head-sample (kirish joyida) va tail-sample (kollektorda) «hammasi 5xx, p99, xatolar - 100%» qoidalari bilan birlashtiramiz.
Logi: darajalar va drossellash; tez-tez takrorlanadigan xatolar uchun - yig’ma hodisalar (dedupe kaliti).
yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10
9) Xavfsizlik va maxfiylik
In Transit/At Rest: shifrlash (TLS 1. 3, AEAD, KMS/HSM).
PII/sirlar: jo’natishdan oldin sanitizatorlar, tokenizatsiya, niqoblash.
Kirish: oʻqish uchun ABAC/RBAC; rollarni ajratish producers/readers/admins.
Audit: loglar/trassalarga kirishning o’zgarmas jurnali; eksport - shifrlangan ko’rinishda.
Ko’p ijara: siyosatchilar bilan namespaces/tenant-labels; shifrlash kalitlarini izolyatsiya qilish.
10) Konfiguratsiya profillari (parchalar)
Prometheus (HTTP + alerting metrikasi):yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']
slo. rules. yaml (RED misoli):
yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m
OpenTelemetry SDK (psevdokod):
python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass
Ilova loglari (stdout JSON):
python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})
11) Ma’lumotlar/ETL va striming
Ma’lumotlar uchun SLI: yangilik (max lag), to’liqlik (rows vs expectation), «sifat» (validatorlar/duplikatlar).
Alertlar: derazani o’tkazib yuborish, konsumer orqasi, DLQ o’sishi.
Korrelyatsiya:’run _ id’,’dataset _ urn’, lineage hodisalari; payplaynlar uchun trassirovkalar (batch/partition uchun span).
Kafka/NATS: metrika prodyuser/konsumer, lag/rad etish; headers bo’yicha trastirovkalar (shu jumladan’traceparent’).
12) Profillash va eBPF (qo’shimcha signal)
Past darajali issiq yo’llar CPU/alloc/IO; hodisa profillari.
eBPF-telemetriya (tarmoq kechikishlari, DNS, tizim qo’ng’iroqlari)’trace _ id ’/PID’ga bog’langan holda.
13) Kuzatuvni test qilish
Signal kontrakti: CI ga metrik/leybl/gistogramma eksportini tekshirish.
Synthetic probes: RUM skriptlari/tashqi SLI uchun simulyatsiya qilingan mijozlar.
Chaos/Fire drills: qaramlikni o’chirish, degradatsiya - alertlar va navbatchilar qanday munosabatda bo’lishini ko’rib chiqamiz.
Smoke prodda: yangi endpointlarda metrika va trastirovkalar mavjudligini post-deploy tekshirish.
14) Qiymati va hajmlarni nazorat qilish
Signal/buyruq bo’yicha budjetlar; «cost per signal» dashboard.
Byudjet ostidagi kardinallik (cardinality bo’yicha SLO), yangi yorliqlarga limitlar.
Downsampling, ma’lumotlar sinflari bo’yicha retensiyalar, «sovuq» arxivlar va audit uchun WORM.
15) Kuzatuv platformasidan foydalanish va SLO
SLO platformalari: 99. muvaffaqiyatli ingestlarning 9 foizi; metrik indeksgacha kechikish ≤ 30 s, loglar ≤ 2 min, trassalar ≤ 1 min.
Platforma alertlari: lag injest, droplarning o’sishi, imzo/shifrlash xatosi, buferlarning to’lib-toshishi.
DR/HA: koʻp zonali, replikatsiya, konfiguratsiya/qoidalarning zaxira nusxalari.
16) Chek varaqlari
Mahsulot oldidan:- Hamma joyda’trace _ id ’/’ span _ id’; Sxemali JSON-logi.
- Gistogrammalar bilan RED/USE metrikalari; exemplar → trassalar.
- Tail-sampling yoqilgan; qoidalar 5xx/p99 = 100%.
- Alertlar + Runibuki belgilari bo’yicha; jim soatlar/anti-flap.
- PII sanitizyerlar; at rest/in transit shifrlash; Audit uchun WORM.
- Hajmlar/kardinallik uchun retensiyalar va byudjetlar.
- Har oyda alertlarni ko’rib chiqish (shovqin/aniqlik), ostonalarni sozlash.
- Error budget bo’yicha hisobot va ko’rilgan choralar (fichfriz, hardening).
- Kritik yo’llar uchun dashbordlar/loglar/trassalar qoplamalarini tekshirish.
- Oʻquv hodisalari va runbook’larni yangilash.
17) Runbook’и
RCA: p99/pay
1. ’checkout’ uchun RED dashbordini ochish.
2. exemplar → sekin trassaga oʻtish → «tor span» ni aniqlash (masalan,’gateway. call`).
3. ’trace _ id’ boʻyicha loglarni ochish → taymaut/retrajlarni koʻrish.
4. Orqaga qaytish fich bayrogʻini/RPS limitini yoqish, qaramlik egalarini xabardor qilish.
5. Barqarorlashgandan so’ng - RCA, optimallashtirish uchun chiptalar, takrorlash testi.
1. SLI «yangilik» qizil → job trassasi → xato qadam.
2. Broker/DLQ lagini, konnektor xatolarini tekshirish.
3. Reprocess dasturini ishga tushirish, status kanali orqali isteʼmolchilarni (BI/mahsulot) xabardor qilish.
18) Tez-tez xatolar
Sxemasiz va’trace _ id’boʻlmagan loglar. Tekshiruvlar bir necha bor kechiktirilmoqda.
Simptomlar o’rniga infratuzilma bo’yicha alertlar. Paging «sutga» ketadi.
Metriklarning cheksiz kardinalligi. Xarajatlar portlashi va beqarorlik.
Barcha trassalar 100%. Qimmat va kerak emas; aqlli semplamani yoqing.
PII/sahifalardagi sirlar. Sanitar vositalar va qizil roʻyxatlarni kiriting.
«Soqovlar» chichlari. Metrik/trassasiz yangi kod.
19) FAQ
S: Xom loglarni saqlash kerakmi?
O: Ha, lekin retensiya va arxivlar bilan; alertlar va SLO uchun agregatlar etarli. Audit - WORMda.
S: Trassalar uchun nima tanlash kerak - head yoki tail sampling?
O: Kombinatsiyalash: asosiy qoplama uchun head-probabilistic + xato va anomaliyalar uchun tail-rules.
S: Foydalanuvchi metrikalari va texnik ko’rsatkichlarni qanday bog’lash kerak?
O: Umumiy’trace _ id’va biznes-yorliqlar (’route’,’tenant’,’plan’), shuningdek, trassalarga bog’langan mahsulot hodisalari (konversiyalar) orqali.
S: Qanday qilib alertlarda cho’kib ketmaslik kerak?
O: Simptomlarga ko’ra uring, sokin soatlar, deduplikatsiya, guruhlash, SLO bo’yicha ustuvorlik va har bir alertga andoza egasini kiriting.
- «Audit va o’zgarmas jurnallar»
- «In Transit/At Rest shifrlash»
- «Sirlar menejmenti»
- «Ma’lumotlarning kelib chiqishi (Lineage)»
- «Privacy by Design (GDPR)»
- «Vebxuklarni yetkazib berish kafolatlari»