GH GambleHub

Infrastrukturun monitorinqi

Infrastruktur monitorinqi

1) Məqsədlər və çərçivə

Infrastruktur monitorinqi sağlamlıq, performans və platformanın mövcudluğu haqqında siqnallar sistemidir. O lazımdır:
  • İstifadəçidən əvvəl uğursuzluqlar barədə xəbərdarlıq edin (erkən deteksiya).
  • Əsas səbəblərin diaqnozunu vermək (from symptom to cause).
  • SLO-geytinq buraxılışları və avtomatik geri dönüşləri dəstəkləmək.
  • Post-insident analizi (evidence as data).

Dəstək prinsipləri: Observable by design, daha az səs-küy - daha çox siqnallar, reaksiyaların avtomatlaşdırılması, vahid həqiqət paneli.

2) Müşahidə triadası

Metrik (timeseries): sürət/tələb/səhvlər/doyma (USE/RED).
Log: kontekstlə hadisə detalı; heç bir sirr/PII.
Treys: səbəb-nəticə əlaqələri ilə bölüşdürülmüş rəftar.

Plus:
  • Profil (CPU/heap/lock/io), sistem səviyyəsi üçün eBPF.
  • Hadisələr/audit (K8s Events, konfiqurasiya/sirr dəyişiklikləri).

3) SLI/SLO/SLA - keyfiyyət dili

SLI (göstərici): 'availability', 'error _ rate', 'p95 _ latency', 'queue _ lag'.
SLO (məqsəd): "Uğurlu sorğular ≥ 99. 30 gün ərzində 9%".
Error Budget: icazə verilən sapma; avtomatik-stop relizlər üçün istifadə olunur.

SLO (YAML) nümunəsi:
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) Monitorinq təbəqələrinin xəritəsi

1. Host/VM/düyünlər: CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. Şəbəkə/LB/DNS: RTT, paketlər/damcılar, backlog, SYN/Timeout, health-probes.
3. Kubernetes/Orchestrator: API server, etcd, nəzarətçilər, scheduler; pod/düyünlər, pending/evicted, throttling, kube-events.
4. Xidmətlər/konteynerlər: RED (Rate/Errors/Duration), readiness/liveness.
5. Verilənlər bazası/caches: QPS, lock wait, replication lag, buffer hit, slow queries.
6. Növbələr/şinlər: consumer lag, requeue/dead-letter, throughput.
7. Saxlama/bulud: S3/Blob səhvlər və latency, provayderlərdən 429/503.
8. Perimetr sərhədləri: WAF/Rate Limits, marşrutlar üzrə 4xx/5xx, CDN.
9. Sintetik: HTTP-yoxlama ssenariləri (depozit/çıxarış), TLS/sertifikatlar.
10. İqtisadiyyat/tutum: cost per service, utilization, headroom.

5) Whitebox и Blackbox

Whitebox: xidmətlər daxilində ixracatçılar/SDK (Prometheus, OpenTelemetry).
Blackbox: müxtəlif bölgələrdən xarici nümunələr (availability, latency, TLS expiry).
Birləşdirin: «xaricdəki əlamət» + «daxildəki diaqnoz».

'blackbox _ exporter' nümunəsi:
yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6) Kubernetes: əsas siqnallar

Кластер: `apiserver_request_total`, `etcd_server_has_leader`, etcd fsync.
Узлы: `container_cpu_cfs_throttled_seconds_total`, `node_pressure`.
Pending/CrashLoopBackOff, OOMKilled, restarts.
Planlar/Limitlər: Requests vs Limits, PodDisruptionBudget, HPA/VPA.
Şəbəkə: NetworkPolicy draws, conntrack exhaustion.

Дашборды: «Cluster health», «Workload saturation», «Top erroring services».

7) DB və növbələr

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 metrikası və biznes korrelyasiyaları

RED: `rate` (RPS), `errors` (4xx/5xx), `duration` (p95/p99).
USE (resurslar üçün): Utilization, Saturation, Errors.
Məhsulla əlaqə saxlayın: depozitlər/müvəffəqiyyət ödənişləri, frod bayraqları, konvertasiya kanarya buraxılışında «mühafizəçilərdir».

9) Alertinq strukturu

Tier-1 (peyc): SLO-ya təsir edən hadisələr (əlçatanlıq, 5xx, gecikmə, klaster kritik komponentlərinin uğursuzluğu).
Tier-2 (bilet): qabiliyyətin deqradasiyası, SLO-ya təsir etmədən səhvlərin artması.
Tier-3 (məlumat): trendlər, proqnozlaşdırılan tutum, müddəti bitən sertifikatlar.

Eskalasiya qaydaları: sükut vaxtı/dublikatların sıxılması, on-call rotasiyası, «follow-the-sun».

Alertmanager routes nümunəsi:
yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10) Prometheus qaydaları nümunələri

10. 1 SLO həddi ilə 5xx səhvlər

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 Yandırma 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 Sistem doyması (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) Log: toplama, normallaşdırma, retenshn

Standartlaşdırma: JSON-loqlar: 'ts', 'level', 'service', 'trace _ id', 'user/tenant'.
Paypline: agent (Fluent Bit/Vector) → bufer → indeks/saxlama.
Redaktə: kənarda PII/sirləri maskalamaq.
Retenshn: sürətli saxlama sinfi (7-14 gün), «soyuq» arxiv (30-180 gün).
Semantika: error budgets/deprekeyt - ayrı-ayrı kanallar.

12) Treys və OpenTelemetry

Giriş nöqtələrini (gateway), müştəri → zəng xidməti, DB/caches/növbələri instrumentasiya edin.
Metrləri sürətli naviqasiya üçün ticarət atributlarına (Exemplars) bağlayın.
OTEL Collector mərkəzi şluz kimi: filtrasiya, sampling, seçilmiş bekendlərə ixrac.

OTel Collector nümunəsi (fraqment):
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 və xarici yoxlamalar

Biznes ssenarilərinin HTTP qaçışı (giriş, depozit, çıxış, alış).
TLS/Domain: Sertifikatların müddəti/CAA/DNS sağlamlığı.
Regionallıq: əsas ölkələrdən/provayderlərdən nümunələr (marşrut/blok vərəqləri).
Sintetika hətta yaşıl daxili telemetriya ilə istifadəçi üçün əlçatmaz olduqda alertləşdirilməlidir.

14) Profil və eBPF

Continuous profiling: isti funksiyaların, kilidlərin aşkarlanması.
eBPF: sistem hadisələri (syscalls, TCP retransmits), minimal overhead ilə prodda.
Səhifəsiz profil alertləri (biletlər) və buraxıldıqdan sonra reqressiya üçün - geri dönüş siqnalı kimi.

15) Daşbordlar və «həqiqət paneli»

Minimum dəsti:

1. Platform Overview: Əsas xidmətlər, error-budget, alertlər üzrə SLI/SLO.

2. API RED: Marşrutlar üzrə RPS/ERRORS/DURATION.

3. K8s Cluster: control-plane, узлы, capacity headroom.

4. DB/Cache: lag/locks/slow query %, hit ratio.

5. Queues: backlog/lag, nasaz/təkrar.

6. Per-release: əvvəl/sonra metrik müqayisə (kanarya pəncərələri).

7. FinOps: cost per namespace/service, idle/oversized ресурсы.

16) Hadisələr, həyəcan səs-küy və eskalasiya

Deduplikasiya: xidmət/səbəb üzrə qruplaşdırma, kaskadların yatırılması.
Sükut/maintenance: relizlər/miqrasiyalar hər şeyi qırmızı rəngləməməlidir.
Runbooks: diaqnostika addımları və «geri dönüş düyməsi» ilə hər kritik alert.
Postmortem: time line, nə öyrəndik, hansı siqnallar əlavə edildi/təmizləndi.

17) Monitorinqdə təhlükəsizlik

RBAC oxu/düzəliş qaydaları/datasors.
Secrets: ixracatçı/agent tokenləri - Secret Manager vasitəsilə.
İzolyasiya: müştərilərin/tenantların metrikası - ayrı məkanlara/etiketlərə.
Bütövlük: GitOps (merj-revyu) vasitəsilə agentlərin/binaların, konfiqlərin imzası.

18) Maliyyə və tutum (FinOps)

Kvotalar və büdcələr; anormal artım üçün alertlər.
Right-sizing: sorğuların/limitlərin təhlili, CPU/RAM təkrar emalı, kritik olmayan vəzifələr üçün spot instansiyaları.
«Cost per request/tenant» kimi KPI səmərəliliyi.

19) Anti-nümunələr

Xüsusi SLI olmadan yalnız infrastruktur metriklər.
100 + alert «hər şey haqqında» → on-call korluq.
Logi yeganə mənbə kimi (metrik və treysinq olmadan).
Version/review olmadan mutabel daşbordları.
Sintetikliyin olmaması: «hər şey yaşıl», lakin cəbhə əlçatmazdır.
Buraxılışlarla əlaqə yoxdur: «X anında nə dəyişdi» deyə cavab vermək olmaz.

20) Giriş çek siyahısı (0-60 gün)

0-15 gün

3-5 əsas xidmətlər üçün SLI/SLO müəyyən edin.
Əsas ixracatçıları/agentləri daxil edin, JSON-loqi standartlaşdırın.
Tier-1 alertləri (availability, 5xx, p95) konfiqurasiya edin.

16-30 gün

Kritik ssenarilərə görə sintetika əlavə edin.
Giriş/kritik xidmətlərdə treysləri (OTel) işə salın.
Daşbordlar «Per-release» və error-budget burn-qaydaları.

31-60 gün

qabaqcıl siqnallar ilə DB/növbə/cache örtmək.
Yüksək-CPU xidmətləri üçün eBPF/profil tətbiq edin.
GitOps qaydaları/dashboard/alerts, mütəmadi səs-küy təmizlənməsi.

21) Yetkinlik metrikası

Əsas xidmətlərin SLO əhatə dairəsi ≥ 95%.
MTTA/MTTR (hədəf: min/on dəqiqə).
Avtomatik hərəkət və ya sürətli geri dönüş ilə bağlanmış Tier-1 alertlərinin payı.
«Faydalı «/» səs-küylü »alertlərin nisbəti> 3:1.
Bütün «pul» yolları sintetik örtük = 100%.

22) Proqramlar: Mini şablonlar

Prometheus - status sinifləri üzrə əlçatanlıq

yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana - kanaryalar üçün ipucu


expr: histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m])) by (le,version))

Alertmanager - növbə və sükut

yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]

23) Nəticə

Monitorinq qrafik dəsti deyil, SRE əməliyyat sistemidir: keyfiyyət müqaviləsi kimi SLI/SLO, həqiqət mənbəyi kimi metrika/treys/log, idarə olunan siqnal kimi alert, «istifadəçi səsi» kimi sintetika, dəyişiklik intizamı kimi GitOps. Ana səhifədən API-yə qədər vahid bir konturu qurun, buraxılışlara və geri dönüşlərə bağlayın - və platforma proqnozlaşdırıla bilən, sürətli və qənaətli olacaq.

Contact

Bizimlə əlaqə

Hər hansı sualınız və ya dəstək ehtiyacınız varsa — bizimlə əlaqə saxlayın.Həmişə köməyə hazırıq!

İnteqrasiyaya başla

Email — məcburidir. Telegram və ya WhatsApp — istəyə bağlıdır.

Adınız istəyə bağlı
Email istəyə bağlı
Mövzu istəyə bağlı
Mesaj istəyə bağlı
Telegram istəyə bağlı
@
Əgər Telegram daxil etsəniz — Email ilə yanaşı orada da cavab verəcəyik.
WhatsApp istəyə bağlı
Format: ölkə kodu + nömrə (məsələn, +994XXXXXXXXX).

Düyməyə basmaqla məlumatların işlənməsinə razılıq vermiş olursunuz.