97-dars

Monitoring tushunchasi

Tasavvur qiling, mashinangiz bor. Panelda — spidometr, yoqilg'i ko'rsatkichi, dvigatel harorati. Siz ularga vaqti-vaqti bilan qarab turasiz — mashina hali yo'lda yiqilib qolmasdan, muammoni oldindan sezish uchun.

Monitoring — dasturda aynan shu: tizim ishlayotganda uning "sog'ligini" doimiy kuzatib borish — "server band emasmi", "xotira yetarlimi", "so'rovlar sekin javob bermayaptimi".

---

1. Logging bilan farqi — bu muhim, ko'p aralashtiriladi

	Logging	Monitoring
Savol	"Nima sodir bo'ldi?" (o'tmish, aniq voqea)	"Hozir tizim qanday holatda?" (joriy, umumiy holat)
Misol	"User 123 login qildi soat 14:30:05'da"	"Hozir sekundiga 500 ta so'rov kelyapti, o'rtacha javob vaqti 120ms"
Format	Matn/JSON yozuvlar	Sonlar (metrikalar), vaqt bo'yicha grafik
Qachon qaraladi	Muammo bo'lgandan keyin, tergov qilish uchun	Doimiy, real vaqtda, muammo bo'lishidan oldin sezish uchun

Ya'ni: logging — "nima bo'ldi" haqida hikoya, monitoring — "hozir qanday" haqida sonlar va grafiklar.

---

2. Nima o'lchanadi — asosiy metrikalar

// Oddiy misol — so'rov vaqtini o'lchash
app.use((req, res, next) => {
  const start = Date.now();
  res.on('finish', () => {
    const duration = Date.now() - start;
    metrics.recordHttpDuration(req.path, duration); // metrika tizimiga yuboriladi
  });
  next();
});

Odatda kuzatiladigan 4 asosiy metrika turi bor (bu "Golden Signals" deb ataladi):

Metrika	Nima	Misol
Latency (kechikish)	So'rov qancha vaqtda javob beradi	"Ortacha 120ms, lekin 1% so'rov 3 soniyadan ko'p"
Traffic (yuk)	Qancha so'rov kelyapti	"Sekundiga 500 so'rov"
Errors (xatolar)	Nechta so'rov muvaffaqiyatsiz	"So'rovlarning 2% — 500 xatosi bilan qaytdi"
Saturation (to'yinganlik)	Resurslar qancha band	"CPU 85%, xotira 70% ishlatilyapti"

---

3. Nega faqat "sonlarni ko'rish" yetarli emas — percentile muammosi

Bu — monitoring'dagi eng ko'p xato qilinadigan joy. Tasavvur qiling, 100 ta so'rov keldi, va siz o'rtacha (average) javob vaqtini hisoblaysiz: 120ms. Yaxshi ko'rinadi, shundaymi?

Lekin o'rtacha — aldamchi bo'lishi mumkin:

99 ta so'rov: 50ms (tez)
1 ta so'rov: 7000ms (juda sekin!)

O'rtacha = (99×50 + 7000) / 100 = 119.5ms

O'rtacha 120ms — hech qanday muammo yo'q deb ko'rsatadi, holbuki 1 ta foydalanuvchi 7 soniya kutgan! Agar bu 1% — sizning eng yirik, eng muhim mijozingiz bo'lsa-chi?

Yechim — percentile (p50, p95, p99) o'lchash:

p50 (median): 50ms   → so'rovlarning yarmi shundan tez
p95: 200ms            → 95% so'rov shundan tez, 5% sekinroq
p99: 7000ms           → 99% so'rov shundan tez, LEKIN 1% — juda sekin!

p99 — aynan shu **"eng yomon holatlar"**ni ko'rsatadi, ular o'rtachada yo'qolib ketadi. Katta kompaniyalarda (Google, Amazon) "p99 latency" — eng ko'p kuzatiladigan metrikalardan biri, chunki millionlab foydalanuvchida, "kam uchraydigan" 1% — aslida minglab odam degani.

---

4. Alerting — monitoring "sukut" saqlamasligi kerak

Agar siz grafikni doimo tikilib o'tirmasangiz (albatta o'tirmaysiz), monitoring o'zi sizga xabar berishi kerak — bu Alert (ogohlantirish) deyiladi:

// Konseptual misol — alert qoidasi
if (metrics.errorRate('last_5min') > 0.05) { // 5% dan ko'p xato
  sendAlert({
    channel: 'slack',
    message: 'Xato darajasi 5% dan oshdi! Tekshiring.',
    severity: 'critical'
  });
}

Muhim muvozanat — "alert charchashi" (alert fatigue):

Agar siz har kichik narsaga alert qo'ysangiz (masalan, "CPU 50%dan oshdi"), jamoa kuniga 50 ta bildirishnoma oladi, ko'pi — haqiqiy muammo emas. Natijada odamlar alertlarni e'tiborsiz qoldirishni o'rganib qoladi — va aynan haqiqiy muammo kelganda ham, uni sezmay qolishadi. Bu — real hayotda ko'p falokatlarning sababi bo'lgan.

Qoida: alert faqat harakat talab qiladigan narsaga qo'yilishi kerak ("hozir kimdir uyg'onib, biror narsa qilishi kerak" darajasidagi muammo), "qiziqarli, lekin harakat kerak emas" narsalar — faqat dashboard'da ko'rsatiladi, alert emas.

---

5. Health check — tizim "tirikmi" degan eng oddiy savol

app.get('/health', (req, res) => {
  res.json({ status: 'ok', uptime: process.uptime() });
});

Bu — eng sodda monitoring shakli: har 10 soniyada tashqi tizim (masalan, load balancer yoki Kubernetes) shu endpoint'ga so'rov yuboradi. Agar javob kelmasa (yoki xato bo'lsa) — bu server "o'lik" deb hisoblanadi va undan foydalanuvchi so'rovlari avtomatik boshqa serverga yo'naltiriladi.

Chuqurroq health check — bog'liq xizmatlarni ham tekshiradi:

app.get('/health', async (req, res) => {
  const dbOk = await checkDatabaseConnection();
  const cacheOk = await checkRedisConnection();

  if (dbOk && cacheOk) {
    res.json({ status: 'ok' });
  } else {
    res.status(503).json({ status: 'degraded', db: dbOk, cache: cacheOk });
  }
});

---

6. Distributed tracing — ko'p xizmatli tizimda "sekinlik qayerda"

Logging mavzusida requestId orqali loglarni bog'lashni ko'rgan edik. Monitoring'da bunga o'xshash, lekin vizual vosita — tracing deyiladi:

So'rov keldi
  │
  ├─ Auth xizmati: 5ms
  │
  ├─ Order xizmati: 15ms
  │     │
  │     └─ Database so'rovi: 200ms  ← MANA SHU YERDA sekinlik!
  │
  └─ Payment xizmati: 10ms

Jami: 230ms

Bu — masalan, Jaeger, Zipkin kabi vositalar orqali vizual grafik sifatida ko'rsatiladi: har bir xizmat qancha vaqt olganini ko'rasiz, va aniq qaysi qismda sekinlik borligini darhol topasiz — barcha xizmatlarning kodini birma-bir qidirib yurish o'rniga.

---

7. V8/Node.js darajasida — nimalarni monitoring qilish kerak (runtime metrikalar)

Bu — JS-specifik, muhim joy. Oddiy CPU/xotira'dan tashqari, Node.js'ning o'ziga xos muammo manbalari bor:

Metrika	Nima uchun muhim
Event Loop Lag	Agar event loop band bo'lsa (bir joyda uzoq sinxron kod ishlasa), barcha so'rovlar kutib qoladi. Bu — Node.js'da eng muhim runtime metrika
Heap ishlatilishi	V8'ning xotira chegarasi bor (odatda ~1.5-4GB). Agar heap to'lib borsa — bu memory leak belgisi
GC pauzalari	Garbage Collector ishlaganda, ba'zan "Stop-the-world" pauza bo'ladi — bu paytda hech qanday kod ishlamaydi. Agar bu pauzalar uzoq (masalan, 100ms+) bo'lsa — foydalanuvchi "to'xtash"ni his qiladi
Active handles/requests	Nechta ochiq socket, timer, fayl operatsiyasi bor — bu ko'payib borsa, resurs oqib ketayotganidan (leak) darak beradi

// Event Loop Lag'ni o'lchash — konseptual misol
let lastCheck = Date.now();
setInterval(() => {
  const now = Date.now();
  const lag = now - lastCheck - 1000; // kutilgan 1000ms dan qancha ortiq kechikdi
  metrics.recordEventLoopLag(lag);
  lastCheck = now;
}, 1000);

Agar lag doimiy ravishda katta bo'lsa (masalan, 50ms+) — bu degani, biror joyda sinxron, uzoq davom etadigan kod (masalan, katta massivni sinxron qayta ishlash, yoki noto'g'ri ishlatilgan JSON.parse katta faylga) event loop'ni bloklab turibdi — bu to'g'ridan-to'g'ri barcha foydalanuvchilar uchun sekinlikka olib keladi, garchi CPU/xotira "normal" ko'rinsa ham.

---

Yakuniy xulosa

• Logging — "nima bo'ldi" (o'tmish), Monitoring — "hozir qanday" (joriy holat).
• 4 asosiy metrika: Latency, Traffic, Errors, Saturation (Golden Signals).
• O'rtacha (average) — aldamchi bo'lishi mumkin; p95/p99 — "eng yomon holatlar"ni ko'rsatadi, ular ko'pincha eng muhim.
• Alert — faqat harakat talab qiladigan narsaga, aks holda "alert charchashi" yuzaga keladi.
• Health check — tizim tirikligini tekshirishning eng oddiy usuli, load balancer shu orqali qaror qabul qiladi.
• Node.js'da maxsus e'tibor: Event Loop Lag va GC pauzalari — bular JS-specifik, boshqa tillarda yo'q muammolar.