GH GambleHub

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.

Plyus:
  • 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.

SLO (YAML) misoli:
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».

’blackbox _ exporter’ misoli:
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.

OTel Collector misoli (parcha):
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.

Contact

Biz bilan bog‘laning

Har qanday savol yoki yordam bo‘yicha bizga murojaat qiling.Doimo yordam berishga tayyormiz.

Integratsiyani boshlash

Email — majburiy. Telegram yoki WhatsApp — ixtiyoriy.

Ismingiz ixtiyoriy
Email ixtiyoriy
Mavzu ixtiyoriy
Xabar ixtiyoriy
Telegram ixtiyoriy
@
Agar Telegram qoldirilgan bo‘lsa — javob Email bilan birga o‘sha yerga ham yuboriladi.
WhatsApp ixtiyoriy
Format: mamlakat kodi va raqam (masalan, +998XXXXXXXX).

Yuborish orqali ma'lumotlaringiz qayta ishlanishiga rozilik bildirasiz.