Infratuzilma monitoringi
Infratuzilma monitoringi
1) Maqsadlar va ramka
Infratuzilma monitoringi - bu platformaning salomatligi, unumdorligi va qulayligi haqida signallar tizimidir. U:- Xatolar haqida foydalanuvchidan oldin ogohlantirish (erta deteksiya).
- Birlamchi sabablarga tashxis qoʻyish (from symptom to cause).
- SLO-geyting relizlari va avto-qaytishlarni qo’llab-quvvatlash.
- Hodisadan keyingi tahlilni oziqlantirish (evidence as data).
Tayanch printsiplari: Observable by design, kamroq shovqin - ko’proq signallar, reaksiyalarni avtomatlashtirish, yagona haqiqat paneli.
2) Kuzatish triadasi
Metrika (timeseries): tezlik/talab/xato/to’yinganlik (USE/RED).
Logi: voqea tafsilotlari kontekstda; sirlari yo’q/PII.
Treyslar: sabab-oqibat aloqalari bilan taqsimlangan muomalalar.
- Tizim darajasi uchun profillash (CPU/heap/lock/io), eBPF.
- Voqealar/audit (K8s Events, konfiguratsiyalar/sirlarni oʻzgartirish).
3) SLI/SLO/SLA - sifat tili
SLI (ko’rsatkich):’availability’,’error _ rate’,’p95 _ latency’,’queue _ lag’.
SLO (maqsad): "Muvaffaqiyatli soʻrovlar ≥ 99. 30 kunda 9%".
Error Budget: yo’l qo’yiladigan og’ish; avto-stop relizlari uchun ishlatiladi.
yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d
4) Monitoring qatlamlari xaritasi
1. Xostlar/VM/uzellar: CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. Tarmoq/LB/DNS: RTT, paketlar/droplar, backlog, SYN/Timeout, health-probes.
3. Kubernetes/Orchestrator: API-server, etcd, nazoratchilar, scheduler; pod/uzellar, pending/evicted, throttling, kube-events.
4. Services/konteynerlar: RED (Rate/Errors/Duration), readiness/liveness.
5. Maʼlumot/kesh bazalari: QPS, lock wait, replication lag, buffer hit, slow queries.
6. Navbatlar/shinalar: consumer lag, requeue/dead-letter, throughput.
7. Omborlar/bulutlar: S3/Blob xato va latency, 429/503 provayderlardan.
8. Perimetr chegaralari: WAF/Rate Limits, 4xx/5xx, CDN.
9. Sintetika: stsenariylarni HTTP tekshirish (depozit/chiqish), TLS/sertifikatlar.
10. Iqtisodiyot/sig’imi: cost per service, utilization, headroom.
5) Whitebox и Blackbox
Whitebox: xizmatlar ichida eksport qiluvchilar/SDK (Prometheus, OpenTelemetry).
Blackbox: turli mintaqalardan tashqi namunalar (availability, latency, TLS expiry).
Qo’shing: «belgi tashqarida» + «diagnostika ichkarida».
yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"
6) Kubernetes: asosiy signallar
Кластер: `apiserver_request_total`, `etcd_server_has_leader`, etcd fsync.
Узлы: `container_cpu_cfs_throttled_seconds_total`, `node_pressure`.
Pending/CrashLoopBackOff, OOMKilled, restartlar.
Rejalar/limitlar: Requests vs Limits, PodDisruptionBudget, HPA/VPA.
Tarmoq: NetworkPolicy, conntrack exhaustion.
Дашборды: «Cluster health», «Workload saturation», «Top erroring services».
7) DQ va navbatlar
PostgreSQL/MySQL: replication lag, deadlocks, slow query %, checkpoint I/O.
Redis/Memcached: hit ratio, evictions, rejected connections.
Kafka/RabbitMQ: consumer lag, unacked, requeue, broker ISR, disk usage.
8) RED/USE metrikasi va biznes-korrelyatsiya
RED: `rate` (RPS), `errors` (4xx/5xx), `duration` (p95/p99).
USE (resurslar uchun): Utilization, Saturation, Errors.
Mahsulot bilan bog’laning: depozitlar/to’lovlar muvaffaqiyat, frod-bayroqlar, konvertatsiya - bu kanareykali relizdagi «qo’riqchilar».
9) Alerting tuzilmasi
Tier-1 (peyj): SLOga ta’sir qiluvchi hodisalar (foydalanish imkoniyati, 5xx, yashirin, klaster kritik komponentlarining ishdan chiqishi).
Tier-2 (tiket): sig’imning tanazzulga uchrashi, SLOga ta’sir qilmasdan xatolarning o’sishi.
Tier-3 (axborot): trendlar, oldindan aytilgan sig’imlar, muddati tugaydigan sertifikatlar.
Eskalatsiya qoidalari: sukunat vaqti/dublikatlarni siqish, on-call, «follow-the-sun» rotatsiyasi.
Alertmanager routes misoli:yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"
10) Prometheus qoidalari misollari
10. 1 5xx SLO ostonasidagi xatolar
yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"
10. 2 Yondirish error-budget (multi-window burn)
yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }
10. 3 Tizim toʻyinishi (CPU Throttling)
yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }
11) Logi: yig’ish, normallashtirish, retenshn
Standartlashtirish: JSON-loglar:’ts’,’level’,’service’,’trace _ id’,’user/tenant’.
Pipline: agent (Fluent Bit/Vector) → bufer → indeks/saqlash.
Tahririyat: PII/sirlarni chetga yashirish.
Retenshn: tezkor saqlash klassi (7-14 kun), «sovuq» arxiv (30-180 kun).
Semantika: error budgets/deprekeytlar - alohida kanallar.
12) Treyslar va OpenTelemetry
Kirish nuqtalarini (gateway), mijoz → qoʻngʻiroqlar xizmati, DB/keshlar/navbatlarni instrumentatsiya qiling.
Tezkor navigatsiya uchun metrlarni treys atributlariga (Exemplars) bogʻlang.
OTEL Collector markaziy shlyuz sifatida: filtrlash, sempling, tanlangan bekendlarga eksport qilish.
yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }
13) Sintetika va tashqi tekshiruvlar
Biznes-stsenariylarning HTTP-yugurishlari (login, depozit, chiqish, sotib olish).
TLS/Domain: sertifikat muddati/CAA/DNS health.
Hududiylik: asosiy mamlakatlar/provayderlardan namunalar (yo’naltirish/blok-varaqlar).
Sintetika, agar foydalanuvchi uchun mavjud bo’lmasa, hatto yashil ichki telemetriya bilan ham alertatsiya qilinishi kerak.
14) Profillash va eBPF
Continuous profiling: issiq funksiyalarni, blokirovkalarni aniqlash.
eBPF: tizimli hodisalar (syscalls, TCP retransmits).
Profil alertlari sahifasiz (tiketlar), relizdan keyingi regressiyalar uchun esa - qaytarish signali sifatida.
15) Dashbordlar va «haqiqat paneli»
Minimal toʻplami:1. Platform Overview: Asosiy servislar, error-budget, alertlar boʻyicha SLI/SLO.
2. API RED: RPS/ERRORS/DURATION yo’nalishlari bo’yicha.
3. K8s Cluster: control-plane, узлы, capacity headroom.
4. DB/Cache: lag/locks/slow query %, hit ratio.
5. Queues: backlog/lag, qaytadan/qaytadan.
6. Per-release: metriklarni oldindan/keyin taqqoslash (kanar oynalari).
7. FinOps: cost per namespace/service, idle/oversized ресурсы.
16) Hodisalar, alert-shovqin va eskalatsiyalar
Deduplikatsiya: servis/sabab bo’yicha guruhlash, kaskadlarni bostirish.
Sukunat/maintenance: relizlar/migratsiyalar hamma narsani qizil rangga boʻyamasligi kerak.
Runbooks: diagnostika bosqichlari va orqaga qaytish tugmasi bilan har bir tanqidiy alert.
Postmortem: taymline, nimani o’rgandingiz, qanday signallarni qo’shdingiz/tozaladingiz.
17) Monitoringdagi xavfsizlik
RBAC qoidalarni/datasorlarni o’qish/tuzatish uchun.
Sirlar: eksportchilar/agentlar tokenlari - Secret Manager orqali.
Izolyatsiya: mijozlar/tenantlar metrikasi - alohida makonlarga/leyblarga.
Butunlik: agentlar/bildlarning imzosi, GitOps (merj-revyu) orqali konfigi.
18) Moliya va sig’imi (FinOps)
Kvotalar va budjetlar; g’ayritabiiy o’sish alertlari.
Right-sizing: so’rovlar/limitlarni tahlil qilish, CPU/RAMni utilizatsiya qilish, muhim bo’lmagan vazifalar uchun spot-instantsiyalar.
«Cost per request/tenant» samaradorlik KPI sifatida.
19) Anti-patternlar
Faqat foydalanuvchi SLI’siz infratuzilma metriklari.
100 + alert «hamma haqida» → ko’rlik on-call.
Logi yagona manba sifatida (metrik va treysingsiz).
Tahrirlanmagan mutabel dashbordlar/revyu.
Sintetika yo’qligi: «hamma narsa yashil», ammo front mavjud emas.
Relizlar bilan bog’liqlik yo’q: «X paytida nima o’zgardi» deb javob bera olmaysiz.
20) Joriy etish chek-varaqasi (0-60 kun)
0-15 kun
3-5 ta asosiy servislar uchun SLI/SLOni aniqlash.
Bazaviy eksport qiluvchilar/agentlarni kiritish, JSON-loglarni standartlashtirish.
Tier-1ni (availability, 5xx, p95) sozlash.
16-30 kun
Tanqidiy stsenariylarga sintetika qoʻshish.
Kirish/tanqidiy xizmatlarda treyslarni (OTel) yoqish.
Dashbordlar «Per-release» va error-budget burn-qoidalari.
31-60 kun
DB/navbat/keshni ilgʻor signallar bilan qoplash.
High-CPU xizmatlari uchun eBPF/profillashni joriy etish.
Qoidalar/dashbordlar/alertlar uchun GitOps, muntazam ravishda shovqinni tozalash.
21) Etuklik metrikasi
Asosiy xizmatlarning SLO qamrovi ≥ 95%.
MTTA/MTTR (maqsad: min/o’n daqiqa).
Avto- harakat yoki tez orqaga qaytish bilan yopilgan Tier-1 alertlari ulushi.
«Foydali «/» shovqinli »alertlarning nisbati> 3:1.
Barcha «pul» yo’llarini sintetika bilan qoplash = 100%.
22) Ilovalar: mini-shablonlar
Prometheus - maqom darajalari bo’yicha foydalanish
yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
Grafana - kanareykalar uchun maslahat
expr: histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket{version=~"stable canary"}[5m])) by (le,version))
Alertmanager - navbatchilik va sukunat
yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]
23) Xulosa
Monitoring - bu grafiklar to’plami emas, balki SRE operatsion tizimi: sifat shartnomasi sifatida SLI/SLO, haqiqat manbai sifatida metrika/treys/logi, boshqariladigan signal sifatida alertalar, «foydalanuvchi ovozi» sifatida sintetika, o’zgarishlar intizomi sifatida GitOps. Xostdan APIgacha bitta konturni quring, uni relizlar va relizlarga bog’lang va platforma oldindan aytib bo’ladigan, tez va tejamkor bo’ladi.