Monitoraggio dell'infrastruttura

Monitoraggio dell'infrastruttura

1) Obiettivi e cornici

• Avvisa i problemi prima dell'utente (rilevamento precoce).
• Diagnostica root cause (from symptom to cause).
• Mantenere le release SLO-gating e i rimborsi automatici.
• Nutrire analisi post-incidente (evidence as data).

Basi: Osservabile by design, meno rumore - più segnali, automazione delle reazioni, un unico pannello della verità.

2) Triade di osservabilità

Metriche (timeserie) - Velocità/richiesta/errore/saturazione (USE/RED).
Login - Dettaglio evento con contesto; non contengono segreti/PII.
Trattamenti distribuiti con rapporti causali.

• Profilassi (CPU/heap/lock/io), eBPF per il livello di sistema.
• Eventi/verifiche (K8s Events, modifiche a configurazioni/segreti).

3) SLI/SLO/SLA - linguaggio di qualità

SLI: «availability», «error _ rate», «p95 _ latency», «queue _ lag».
SLO: «Richieste di successo» 99. 9% in 30 giorni".
Errore Budget: deviazione valida; utilizzato per le release auto-stop.

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) Mappa dei livelli di monitoraggio

1. Host/VM/nodi: CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. Rete/LB/DNS: RTT, pacchetti/drop, backlog, SYN/Timeout, health-probes.
3. Kubernets/Orchestrator: server API, etcd, controller, scheduler; sotto/nodi, pending/evicted, throttling, kube-events.
4. Servizi/contenitori: RED (Rate/Errors/Duration), readava/liveness.
5. Database/cache: QPS, lock wait, replication lag, buffer hit, slow queries.
6. Code/pneumatici: consumer lag, sollue/dead-letter, throughput.
7. Storage/cloud: S3/Blob errori e latency, 429/503 da provider.
8. I bordi del perimetro sono WAF/Rate Limits, 4xx/5xx percorsi, CDN.
9. Sintetica: convalida HTTP degli script (deposito/output), TLS/certificati.
10. Economia/capacità: cost per servizio, utilization, headroom.

5) Whitebox и Blackbox

Whitebox: esportatori/SDK all'interno dei servizi (Prometheus, OpenTelemetry).
Blackbox: campioni esterni provenienti da diverse regioni (availability, latency, TLS expiry).
Combinare «segno all'esterno» + «diagnostica all'interno».

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

6) Kubernets: segnali chiave

Кластер: `apiserver_request_total`, `etcd_server_has_leader`, etcd fsync.
Узлы: `container_cpu_cfs_throttled_seconds_total`, `node_pressure`.
Pending/CrashLoopBackOff, OMKilled, wrestart.
Piani/limiti: Richiesti vs Limits, PodDisruptionBudget, HPA/VPA.
Rete: drop, connack exhaustion.

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

7) Database e code

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) Metriche RED/USE e correlazioni aziendali

RED: `rate` (RPS), `errors` (4xx/5xx), `duration` (p95/p99).
USA (risorse): Utilization, Saturation, Errors.
Collegati al prodotto: depositi/pagamenti successo, flag flag, conversione sono «guardie» per il rilascio canaresco.

9) Struttura di alerting

Tier-1 (page) - Incidenti che influiscono sull'SLO (disponibilità, 5xx, latitanza, guasto dei componenti critici cluster).
Tier-2 - Degrado della capacità, aumento degli errori senza impatto SLO.
Tier-3 - Trend, capacità predittiva, certificati in scadenza.

Regole di escalation: tempo di silenzio/compressione dei duplicati, rotazioni on-call, «follow-the-sun».

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

10) Esempi di regole Prometheus

10. 1 Errori 5xx con soglia 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 Brucia 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 Saturazione di sistema (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: raccolta, normalizzazione, retino

Standardizzazione: loghi JSON: «ts», «level», «service», «trace _ id», «user/tenant».
Pipline agente (Fluent Bit/Vector) il buffer indice/archivio.
Redazione: occultamento di PII/segreti sul bordo.
Ritensh: classe di conservazione rapida (7-14 giorni), archivio freddo (30-180 giorni).
Semantica: errore budget/deprecati - canali separati.

12) Roulotte e OpenTelemetry

Utilizzare i punti di ingresso (gateway), le chiamate, il database/cache/coda.
Associare le metriche agli attributi di trazione (Excplars) per la navigazione rapida.
OtTel Collector come gateway centrale: filtraggio, sempling, esportazione in beckend selezionati.

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) Sintetica e controlli esterni

Le corse HTTP degli script aziendali (login, deposito, output, acquisto).
TLS/Domain: scadenza certificati/CAA/DNS health.
Regionalità: campioni da paesi/provider chiave (routing/block list).
Il sintetico deve essere allertato se l'utente non è disponibile, anche con la telemetria interna verde.

14) Profilassi e eBPF

Continuous profiling - Identificazione delle funzioni hot, dei blocchi.
eBPF - Eventi di sistema (syscalls, TCP retransmits), in vendita con overhead minimo.
Gli alert di profilassi sono privi di stinicing (ticket), e per le regressioni dopo il rilascio, come un segnale di ritroso.

15) Dashboard e «pannello della verità»

1. Platform Overview: SLI/SLO per servizi chiave, errore-budget, alert.

2. API RED: RPS/ERRORS/DURATION.

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

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

5. Queues: backlog/lag, guasti/ripetizioni.

6. Per-release - Confronta le metriche prima/dopo (finestre canarie).

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

16) Incidenti, alert-rumore e escalation

Deduplicazione: raggruppamento per servizio/motivo, soppressione delle cascate.
Silenzio/maintenance: i rilasci/migrazioni non devono «colorare» tutto in rosso.
Runbooks: ogni alert critico con i passi diagnostici e il pulsante di ripristino.
Postmortem: timeline, cosa hanno imparato, quali segnali sono stati aggiunti/ripuliti.

17) Sicurezza nel monitoraggio

RBAC per la lettura/modifica delle regole/datasors.
Segreti: token di esportatori/agenti tramite Secret Manager.
Isolamento: le metriche dei clienti/tenenti - in spazi/etichette separati.
Integrità: firma degli agenti/Bildi, confighi attraverso il GitOps (merge-review).

18) Finanza e capacità (FinOps)

Quote e budget; alert per una crescita anomala.
Right-sizing: analisi di query/limiti, smaltimento CPU/RAM, istanze spot per attività non critiche.
«Cost per richiest/tenant» come efficienza KPI.

19) Anti-pattern

Solo metriche di infrastruttura senza SLI personalizzate.
100 → «su tutto» per la cecità on-call.
Logi come unica fonte (senza metriche e trailing).
Dashboard mutabili senza versioning/gelosia.
L'assenza di sintetici è «tutto verde», ma il fronte non è disponibile.
Nessun collegamento con le release, non puoi rispondere «cosa è cambiato al momento X».

20) Assegno foglio di implementazione (0-60 giorni)

0-15 giorni

Definire SLI/SLO per 3-5 servizi chiave.
Abilita esportatori/agenti di base, standardizza i loghi JSON.
Configura l'alert Tier-1 (availability, 5xx, p95).

16-30 giorni

Aggiungi sintetica agli scenari critici.
Attiva trailer (OTEL) sui servizi di input/criticità.
Dashboard «Per-release» e le regole di errore-budget burn.

31-60 giorni

Coprire database/code/cache con segnali avanzati.
Implementare eBPF/profilassi per servizi high-CPU.
GitOps per regole/dashboard/alert, pulizia regolare del rumore.

21) Metriche di maturità

La copertura SLO dei servizi chiave è pari al 95%.
MTTA/MTTR (obiettivo min/decine di minuti).
Percentuale di alert Tier-1 chiusi da un'azione automatica o da un rapido ritorno.
Rapporto alert «utili «/» rumorosi »> 3:1.
Rivestimento sintetico di tutti i percorsi «moneta» = 100%.

22) Applicazioni: mini-modelli

Prometheus - Disponibilità per classe

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

Grafana - Suggerimento per i canari

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

Alertmanager - servizio e silenzio

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

23) Conclusione

Il monitoraggio non è un insieme di grafici, ma un sistema operativo SRE: SLI/SLO come contratto di qualità, metriche/roulotte/logi come fonti di verità, alert come segnale controllato, sintetico come voce utente, come disciplina di cambiamento. Costruite un unico tracciato dall'host all'API, allacciatelo su release e reimpostazioni e la piattaforma sarà prevedibile, veloce e conveniente.