Monitorizarea infrastructurii

Monitorizarea infrastructurii

1) Obiective și cadru

• Avertizați înainte de blocarea utilizatorului (detectarea timpurie).
• Dați diagnosticul cauzei rădăcinii (de la simptom la cauză).
• Suport SLO gating de versiuni și auto-rollback.
• Hrăniți analiza post-incident (dovezi ca date).

Principii de susținere: Observabil prin design, mai puțin zgomot - mai multe semnale, automatizarea reacțiilor, un singur panou de adevăr.

2) Triada de observabilitate

Timeseries - Rata/Cerere/Eroare/Saturație (UTILIZARE/RED)

Jurnale: detaliu eveniment cu context; nu conține secrete/PII.
Urme: cazuri distribuite cu relații cauzale.

• Profilare (CPU/heap/lock/io), eBPF pentru nivelul sistemului.
• Evenimente/audit (K8s Evenimente, modificări în configurații/secrete).

3) SLI/SLO/SLA - limbaj de calitate

SLI: 'disponibilitate', 'error _ rate', 'p95 _ latency', 'queue _ lag'.

SLO (țintă): "cereri de succes ≥ 99. 9% în 30 de zile"

Bugetul de eroare: toleranță; folosit pentru auto-stop versiuni.

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) Harta straturilor de monitorizare

1. Gazde/VM/noduri: CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. Rețea/LB/DNS: RTT, pachete/picături, restanțe, SYN/Timeout, sonde de sănătate.
3. Kubernetes/Orchestrator: server API, etcd, controlere, programator; păstăi/noduri, în așteptare/evacuat, throttling, kube-evenimente.
4. Servicii/containere: RED (Tarif/Erori/Durata), disponibilitate/liveness.
5. Baze de date/cache-uri: QPS, așteptare de blocare, decalaj de replicare, lovit tampon, interogări lente.
6. Cozi/autobuze: lag de consum, cerere/scrisoare moartă, transfer.
7. Stocare/cloud: S3/Blob erori și latență, 429/503 de la furnizori.
8. Limite perimetrale: WAF/Limite de rată, 4xx/5xx pe rută, CDN.
9. Sintetice: verificări script HTTP (depozit/ieșire), TLS/certificate.
10. Economie/capacitate: cost per serviciu, utilizare, etaj.

5) Whitebox и Blackbox

Whitebox: exportatori/SDK în cadrul serviciilor (Prometheus, OpenTelemetry).
Blackbox: eșantioane externe din diferite regiuni (disponibilitate, latență, expirare TLS).
Combina: „semn în afara” + „diagnostic în interior”.

yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6) Kubernete: semnale cheie

Кластер: 'apiserver _ request _ total', 'etcd _ server _ has _ leader', etcd fsync.
Узлы: 'container _ cpu _ cfs _ throttled _ seconds _ total', 'node _ pressure'.
Tampoane: în așteptare/CrashLoopBackOff, OOMKilled, repornește.
Planuri/limite: cereri vs limite, PodDisruptionBudget, HPA/VPA.
Rețea: NetworkPolicy scade, conntrack epuizare.

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

7) DB și cozi

PostgreSQL/MySQL: decalaj de replicare, blocaje, interogare lentă%, punct de control I/O.
Redis/Memcached: hit ratio, evacuări, conexiuni respinse.
Kafka/RabbitMQ: lag de consum, unacked, requeue, broker ISR, utilizarea discului.

8) Valorile RED/USE și corelațiile de afaceri

RED: „rată” (RPS), „erori” (4xx/5xx), „durată” (p95/p99).
UTILIZARE (pentru resurse): Utilizare, saturație, erori.
Asociați-vă cu produsul: succesul depozitelor/plăților, steagurile de fraudă, conversia - acestea sunt „gărzi” pentru eliberarea canarului.

9) Structura de alertare

Nivelul 1 (pagina): incidente care afectează SLO (disponibilitate, 5xx, latență, defectarea componentelor critice ale clusterului).
Tier-2 (bilet): degradarea capacității, creșterea erorilor fără a afecta SLO.
Tier-3 (inform): tendințe, capacitate predictivă, certificate care expiră.

Reguli de escaladare: timp de liniște/compresie duplicat, rotații de gardă, urmați-soare.

yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10) Exemple de reguli Prometeu

10. 1 Erori 5xx cu prag SLO

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 Ardere eroare-buget (multi-fereastră arde)

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 Saturația sistemului (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) Jurnale: colectare, normalizare, retenție

Standardizare: jurnale JSON: 'ts',' level ',' service ',' trace _ id', 'user/chiriaş'.
Conducte: agent (Fluent Bit/Vector) → tampon → index/stocare.
Revizuire: PII/secrete de mascare la margine.
Retentie: clasa de depozitare rapida (7-14 zile), arhiva rece (30-180 zile).
Semantica: bugete de eroare/depreciază - canale separate.

12) Trasee și OpenTelemetry

Puncte de intrare instrument (gateway), apeluri kliyent→servis, DB/cache/cozi.
Legați măsurătorile pentru a urmări atributele (Exemplare) pentru navigare rapidă.
OTel Collector ca gateway central: filtrare, eșantionare, export în backendurile selectate.

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) Sintetice și controale externe

HTTP ruleaza de scenarii de afaceri (login, depozit, retragere, cumparare).
TLS/Domeniu: termen certificat/CAA/sănătate DNS.
Regionalitate: eșantioane din țări/furnizori cheie (liste de rutare/blocuri).
Sinteticele ar trebui să alerteze dacă nu sunt disponibile pentru utilizator, chiar și cu telemetrie internă verde.

14) Profilare și eBPF

Profilare continuă: identificarea funcțiilor fierbinți, încuietori.
eBPF: evenimente de sistem (syscalls, TCP retransmitts), pe produsul cu minime deasupra capului.
Alerte de profil fără încordare (bilete), și pentru regresii după eliberare - ca un semnal de rollback.

15) Tablouri de bord și „panoul adevărului”

1. Prezentare generală a platformei: SLI/SLO prin servicii cheie, eroare-buget, alerte.

2. API RED: RPS/ERORI/DURATA pe traseu.

3. K8s Cluster: control-plan, узлы, capacitate de înălțime.

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

5. Cozi: restanțe/lag, eșec/încercare din nou.

6. Per-release: compararea metricii înainte/după (ferestre canare).

7. FinOps: cost per namespace/service, ресурсы inactiv/supradimensionat.

16) Incidente, zgomot de alertă și escaladare

Eliminarea duplicatelor - gruparea service/cauze, suprimarea cascadelor

Liniște/întreținere: eliberările/migrațiile nu trebuie să „picteze” totul roșu.
Runbooks: fiecare alertă critică cu pași de diagnosticare și un „buton” rollback.
Postmortem: cronologie, ce au învățat, ce semnale au adăugat/curățat.

17) Siguranța în monitorizare

RBAC pentru reguli de citire/editare/resurse de date.
Secrete: Exportator/agent token-uri - prin intermediul Secret Manager.
Izolare: valori client/chiriaș - în spații separate/file.
Integritate: semnătura agenților/construiește, configurații prin GitOps (revizuire îmbinare).

18) Finanțe și capacitate (FinOps)

Cote și bugete; alerte de creştere anormală.
Dimensionarea corectă: analiza cererilor/limitelor, utilizarea procesorului/memoriei RAM, instanțe spot pentru sarcini non-critice.
„Cost per cerere/chiriaș” ca KPI-uri de performanță.

19) Anti-modele

Măsurători ale infrastructurii numai fără SLI-uri personalizate.
100 + alerte „despre tot” → orbire de gardă.
Jurnalele ca singura sursă (fără valori și urmărire).
Tablouri de bord mutabile fără versioning/recenzie.
Lipsa de sintetice: „totul este verde”, dar partea din față nu este disponibilă.
Nu există nicio legătură cu versiunile: este imposibil să răspundeți la "ceea ce sa schimbat în momentul X.

20) Lista de verificare a implementării (0-60 zile)

0-15 zile

Definiți SLI/SLO pentru 3-5 servicii cheie.
Activați exportatorii/agenții de bază, standardizați jurnalele JSON.
Configurați alerte de nivel 1 (disponibilitate, 5xx, p95).

16-30 zile

Adăugați sintetice pentru scenarii critice.
Activați OTel pe servicii de intrare/critice.
Tablouri de bord „Per-release” și eroare-buget arde-reguli.

31-60 zile

Acoperă DB/cozi/memorie cache cu semnale avansate.
Implementarea eBPF/profilare pentru servicii high-CPU.
GitOps pentru reguli/tablouri de bord/alerte, curățarea regulată a zgomotului.

21) Valorile maturității

Acoperirea SLO a serviciilor cheie ≥ de 95%.
MTTA/MTTR (țintă: min/zeci de minute).
Proporția de alerte de nivel 1 închise prin auto-acțiune sau rollback rapid.
Raportul dintre alertele „utile „/” zgomotoase „este> 3:1.
Acoperirea sintetică a tuturor căilor de „bani” = 100%.

22) Aplicații: mini-șabloane

Prometheus - Disponibilitate după clasa de stare

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

Grafana - sfat pentru canari

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

Alertmanager - datorie și tăcere

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

23) Concluzie

Monitorizarea nu este un set de grafice, ci sistemul de operare SRE: SLI/SLO ca un contract de calitate, metrici/trasee/jurnale ca surse de adevăr, alerte ca un semnal controlat, sintetice ca o „voce de utilizator”, GitOps ca o disciplină de schimbare. Construiți o singură buclă de la gazdă la API, legați-o la lansări și rollback-uri - iar platforma este previzibilă, rapidă și economică.