Raccolta delle metriche: Prometheus, Grafana

Raccolta delle metriche: Prometheus, Grafana

1) Obiettivo e cornice

Il compito del tracciato delle metriche è quello di raccogliere e conservare le righe temporali in modo affidabile, dare un rapido PromQL per RCA, alert SLO e dashboard comprensibili. Coppia di base: Prometheus (scrape store) e Grafana (visualizzazione, alert, registrazioni di rilascio). Thanos/Cortex/Mimir per la conservazione a lungo termine e la richiesta globale.

2) Modello di dati e semantico

Serie = nome metrico + insieme label'o (chiave = valore).
Tipi: counter, gauge, historogram, summary (più spesso istogram).

• RED (API): «rate», «errors», «duration» (istogrammi).
• USE (ресурсы): Utilization, Saturation, Errors (CPU/RAM/Disk/Net).
• Nome: 'namespace _ subsystem _ metric _ unit' (ad esempio 'http _ server _ sollests _ total', 'db _ connection _ current').

Anti-cardinalizia: minimizza i diversi valori label'ov '(niente user _ id, richiest _ id in label).

3) Esposizione e servizio discovery

Esportatori: node _ exporter, kube-state-metrics, cAdvisor, database/code (postgres _ exporter, redis _ exporter, kafka _ exporter).
Servizi personalizzati: librerie client (Go/Java/Node/Python) «/metrics ».
Service Discovery: Kubernetes, EC2/ASG, Consul, static files.

yaml global:
scrape_interval: 15s evaluation_interval: 15s scrape_configs:
- job_name: 'kubernetes-nodes'
kubernetes_sd_configs: [{ role: node }]
relabel_configs:
- action: labelmap regex: __meta_kubernetes_node_label_(.+)
- job_name: 'apps'
kubernetes_sd_configs: [{ role: pod }]
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep regex: "true"
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
target_label: __metrics_path__
regex: (.+)
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
target_label: __address__
regex: (.+)
replacement: $1

yaml prometheus. io/scrape: "true"
prometheus. io/path: /metrics prometheus. io/port: "8080"

4) Istogrammi e latency

• Web/API: '[10ms, 25,50,100,200,400,800,1600]'
• Pagamenti/pagamenti: aggiungi una coda fino a 5-10s.

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

promql histogram_quantile(0. 95,
sum by (le, route) (rate(traces_spanmetrics_duration_bucket{route="/withdraw"}[5m]))
)

5) Regole di scrittura (recording rule)

Riducono le richieste pesanti, standardizzano la SLI.

yaml groups:
- name: api_sli interval: 30s rules:
- record: job:http:success_ratio:rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
- record: job:http:duration_p95:5m expr: histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) SLO e alert (multi-window burn)

SLO 99. 9% richieste di successo/30d.

yaml groups:
- name: slo_burn rules:
- alert: ErrorBudgetBurnHighShort expr: (1 - job:http:success_ratio:rate5m) > (1 - 0. 999) 14 for: 5m labels: { severity: critical }
annotations: { summary: "Fast burn >14x for 5m" }

- alert: ErrorBudgetBurnHighLong expr: (1 - job:http:success_ratio:rate5m) > (1 - 0. 999) 6 for: 1h labels: { severity: critical }
annotations: { summary: "Long burn >6x for 1h" }

yaml route:
receiver: pager group_by: ["service"]
receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true

7) Igiene e risparmi label

I nomi label'ov sono stabili e standardizzati: 'service', 'env', 'region', 'route', 'code', 'variante'.
Limitare la cardinalità: le metriche con "route" devono usare il modello "http. route '(non un URL completo).
La logica del sampling è nelle roulotte; nelle metriche: niente user _ id.
Proprietà di rilascio ('service. version ') sono utili per confrontare la versione precedente/nuova.

8) Scalabilità e HA

• Due Prometheus (A/B) tracciano gli stessi obiettivi (HA → alert).
• Thanos: Sidecar per ogni Prometheus, Store + Query per query globale e conservazione a lungo termine (S3/GCS).
• Alternativa: Cortex/Mimir (remote-write, molteplicità, ridimensionamento orizzontale).

yaml remote_write:
- url: https://mimir. example. com/api/v1/push basic_auth: { username: tenantA, password: $MIMIR_TOKEN }

yaml
--storage. tsdb. retention. time=15d
--storage. tsdb. max-block-duration=2h

9) Grafana: dashboard, alert, annotazioni

1. Platform Overview (SLO/RED, error-budget).

2. API by Route (RPS/5xx/p95, confronto «variante»).

3. K8s Cluster/Nodes (control-plane, saturation).

4. DB/Cache/Queues (lag/locks/hit ratio/backlog).

5. Per-Release (prima/dopo, annotazioni di release CI).

Grafana Alerting: trigger, rotazioni on-call, mute-times «finestre di rilascio».

Annotations: CI aggiunge una release-evento con "commit", "immagine. tag ', con riferimento al pipeline.

10) Kubernets: cosa è necessario misurare

Control-plane: `apiserver_request_total`, etcd leader/fsync, scheduler latency.
Workloads: restrizioni, 'container _ cpu _ cfs _ throttled _ seconds _ total', OOM, Pending/Evicted, PDB violazioni.
Rete: drop, conntrack, «kube-proxy» errori.
Quote/limiti: Richiesti vs Limits, HPA/VPA, saturation nodi.

11) Database/cache/code: segnali chiave

PostgreSQL/MySQL: `connections`, `locks`, `deadlocks_total`, `xact_commit/rollback`, replication lag.
Redis: hit ratio, `evictions`, latency `instantaneous_ops_per_sec`.
Kafka/RabbitMQ: consumer lag, unacked, ISR, disk usage.

promql
Queue backlog sum by (topic) (kafka_consumergroup_lag)> 1000

Postgres replication lag max(pg_replication_lag_seconds) > 2

12) Sicurezza e multi-tenenza

RBAC a Prometheus/Grafana, datasource-permissivi.
La catena è TLS/mTLS a ingress/tra i componenti.
Isolamento degli affittuari: singoli Prometheus o tenant-label in Cortex/Mimir; limiti per serie e richiesta.
I segreti negli alert/notifiche sono proibiti (utilizzare l'ID del ticchetto, non il PII).

13) Integrazione con le release e i rimborsi automatici

Regole SLO (Argo Rollouts) o CI-gate.
Quando si attivano i burn-alert - pausa/rollback canary; in/annotazione - Riferimento al rilascio.
Confronto tra la versione stabile e quella canaresca tramite label'variante '.

14) Errori tipici (anti-pattern)

Radicalità incontrollata label'ov '(user _ id, url. full, chiavi dinamiche).
Mescolare prod e stage in un unico cluster senza «env» label.
Solo gauge senza RED/USE; senza istogrammi p95/p99.
Gli alert di ferro non sono collegati alla SLO.
L'assenza di recording rule ha riportato richieste «pesanti» negli incidenti di prod.
Nessuna annotazione di rilascio. È difficile confrontare cambiamenti e degrado.

15) Assegno foglio di implementazione (0-45 giorni)

0-10 giorni

Node/kube-state/cAdvisor esportatori; '/metrics'nei servizi.
I dashboard RED/USE di base; I bustini standard di istogrammi.
Abilita le annotazioni di release di CI.

11-25 giorni

Recording rule per SLI; multi-window burn alert.
HA Prometheus (doppio scrape), backup delle configurazioni GitOps.
Alertmanager: itinerari/modalità silenziosa/rotazione on-call.

26-45 giorni

Remote-write in Thanos/Cortex/Mimir, conservazione prolungata.
Ottimizzazione della radicalità, limiti di serie, richieste.
Rilascio SLO-gating e auto-rollback integrazione.

16) Metriche di maturità

La copertura RED/USE per i servizi chiave è pari al 95%.
Tempo medio di esecuzione «pesante» <2 c (p95) grazie a recording rule.
Rapporto alert utili/rumorosi> 3:1.
Radicalità controllata: <10M serie attive per cluster, nessun picco.
100% delle release hanno annotazione Grafana e mappatura delle metriche prima/dopo.

17) Snippet utili

Confronto stabile vs canary

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

Errori di percorso 5xx

promql topk(5,
sum by (route) (rate(http_requests_total{status=~"5.."}[5m]))
)

CPU saturation contenitore

promql rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1

Collegamento tra metriche e trailer (Exeplars inclusi)

promql sum (rate (http_request_duration_seconds_bucket[5m])) by (le) # clickable to the track

18) Conclusione

Prometheus + Grafana è uno standard di fatto per le metriche. La semantica e la disciplina vincono: RED/USE, label, istogrammi SLO, recording rule e SLO-alert. Aggiungete HA e conservazione a lungo termine, annotazioni di rilascio e integrazione con i reimpostatori automatici, in modo da ottenere un tracciato di metriche veloce, scalabile e a basso costo che ti aiuta a prendere decisioni in vendita.