Dashboard dell'infrastruttura

1) Perché è necessario

Un unico quadro dello stato, dal cluster alle reti fino ai database e alle code.
RCA e post mortem veloci, un collegamento di metriche di di di .
SLO per i servizi e la piattaforma: controllo della disponibilità e della latenza.
Trasparenza FinOps: volume/costo per servizi, tenant's e ambienti.
Completamento/sicurezza: stato di patch/vulnerabilità, disponibilità, anomalie.

Metodologie: Golden Signals (latency, traffic, errors, saturation), RED (Rate, Errors, Duration) per le richieste, USE (Utilization, Saturation, Errors) per le risorse.

2) Principi del buon dashbord

Attività (Actionable) - Ogni pannello risponde a «cosa fare».
Gerarchica: panoramica dei domini deep dive raw.
Modelli/variabili: «cluster», «namespace», «service», «tenant», «env».
Unità uniche: ms per latitanza,%, RPS, operazioni/s, byte.
Timpicker concettuale: predefinito 1-6 ore, preavviso veloce 5m/15m/24h.
Drilldown: dal pannello al cavo (Loki/ELK) e dalla pista (Tempo/Jaeger).
Proprietà: sul dashbord è indicato il proprietario, SLO, runbook, contatto in on-call.

3) Struttura di cartelle e ruoli

00 _ Overview è una panoramica di livello superiore della piattaforma.
10 _ Kubernets - cluster, nodi, workloads, NRA/VPA, contenitori.
20_Network_Edge — Ingress/Envoy/Nginx, LB, DNS, CDN, WAF.
30 _ Storage _ DB - PostgreSQL/MySQL, Redis, Kafka/RabbitMQ, archivio oggetti.
40 _ CICD _ Runner - Pipline, agenti, manufatti, registry.
50 _ Security _ Compliance - vulnerabilità, patch, RBAC, audit events.
60_FinOps_Cost - costo per servizi/tenant/cluster, smaltimento.
99 _ Runbooks - Collegamenti alle istruzioni e schede SLO.

Ruoli: Platform-SRE, Service-Owner, Security/Compliance, Finance/FinOps, View-only.

4) Dashboard panoramica piattaforma (Landing)

L'obiettivo è di capire se è tutto a posto.

• Piattaforma SLO (API edge): target, effettivo, era degli errori, burn-rate.
• Latenza p50/p95/p99 sui punti di ingresso principali.
• Errori 4xx/5xx e top endpoint con regressione.
• Saturazione delle risorse (CPU, RAM, rete, disco): p95 per cluster.
• Incidenti/allerti (attivi) e ultimi comunicati.
• Costo/ora (approssimativamente) e trend settimanale.

Modelli di variabili: «env», «region», «cluster», «tenant».

5) Kubernets: cluster e worcload

1. Cluster/nodi

Smaltimento CPU/Memory, pressure (memory/cpu), disco IO, inode.
Sottosistemi: kube-api, etcd, controller; kubelet health.

2. Worcload

RPS/RPM, latency p95, error rate, restarts, throttling, OOMKills.
HPA target vs metriche reali.

3. Percorso di rete all'interno del cluster

eBPF/Netflow: top talkers, drops, retransmits.

4. Eventi K8s

Rate по Warning/FailedScheduling/BackOff.

promql
API (5xx) errors by sum by (service) (rate (http_requests_total{status=~"5"..}[5m]))

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

Throttling CPU контейнеров sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m]))

6) Edge, griglia e DNS

• Ingress/Envoy/Nginx: RPS, p95, 4xx/5xx, upstream_errors, active_conns.
• LB/Anycast: distribuzione del traffico in zone, eventi failover.
• NXDOMAIN/SERVFAIL rate, hit-ratio cache.
• CDN/WAF: blocchi regolamentari, traffico anomalo (bot/screen).

promql sum(rate(nginx_http_requests_total[5m])) by (status)

7) Database e storiage

PostgreSQL/MySQL: qps, latency, lock wates, replication lag, backup/fallimenti.
Redis: hit ratio, eviczioni, memoria, comandi lenti.
Kafka/RabbitMQ: lag per gruppo consumer, rebalance, messaggi unacked.
Archiviazione oggetti: query, errori, egress, lat p95.

promql
Replication lag in seconds max by (replica) (pg_replication_lag_seconds)

Slow Queries> 1s rate (pg_stat_activity_longqueries_total[5m])

promql
Lag by group max by (topic, group) (kafka_consumergroup_lag)

8) CI/CD e manufatti

Pipeline overview: successo/runtime, coda runner.
Deployment health: versioni, stato canary/blue-green, tempo di riscaldamento.
Maiuscole immagini: dimensioni, ultimi push'e, smaltimento.

promql
Rate (ci_pipeline_success_total[1h] )/rate (ci_pipeline_total[1h]) success rate

9) Sicurezza e compliance

Patch e vulnerabilità: percentuale di nodi/immagini con CVE critici, tempo medio fino a patch.
I RBAC e i segreti sono tentativi di accesso non completi, di accesso ai segreti.
Controllo eventi - input/modifiche nei componenti critici, draft.
WAF/DLP/PII - Blocchi regole, errori di occultamento.

10) Fogli e piste: panoramica completa

Riepilogo errori da logi (Loki/ELK) - Top exceptions, nuove firme.
Il pulsante Vai ai loghi filtri (LogQL/ES query).
Piste: top slow spans, percentuale di query senza contesto trace.

{app="api", level="error"}     = "NullReference"
{app="nginx"}      json      status="5.."      count_over_time([5m])

11) FinOps: costo e smaltimento

Costo per servizi/tenenti/cluster (dati di billing/esportatori).
Nodi caldi/freddi: idle risorse, rightsizing raccomandazioni (CPU/Mem).
Data egress, L7 richieste e il loro costo.
Dinamica settimana/mese, prognosi.

• cost_per_rps, cost_per_request, storage_cost_gb_day, idle_cost.
• RPS/$ o SLO-minuti/dollari.

12) SLO, errori e burn-rate

Scheda SLO su ogni dashboard di dominio: obiettivo, periodo, errori (budget get).
Burn-rate alert (due velocità: veloce/lenta).

promql
Bad budget: 5xx as a fraction of sum (rate (http_requests_total{status=~"5"..}[5m])) traffic
/
sum(rate(http_requests_total[5m]))

Burn-rate (fast channel ~ 1h)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14. 4

13) Standard di visualizzazione

Timps dei pannelli: time-series per le serie, stat per KPI, table per top-N, heatmap per la latitanza.
Leggende e unità sono obbligatorie; etichette ridotte, formato SI.
Zone colore: verde/giallo/rosso SLO/threshold (uniforme).
Descrizione del pannello: cosa misuriamo, origine, link runbook, proprietario.

14) Modelli di pannello (avvio rapido)

(A) API Overview

KPI: `RPS`, `p95`, `5xx%`, `error_budget_remaining`.
Top endpoints by error/latency.
Drilldown in «trace _ id = $ trace».

(B) Node Health

CPU/Memory/Disk/Network - p95 su nodi, lista hot.
Pressure, throttling, drop pacchetti.

(C) DB Health

TPS, latency p95, locks, replication lag, slow queries.
Backup status/ultimo successo.

(D) Kafka Lag

Lag per gruppo, velocità di consumo vs produzione, rebalance.

(E) Cost & Util

Cost/hour per servizi, idle%, rightsizing hants, previsione.

15) Variabili e tag (set consigliato)

`env` (prod/stage/dev)

`region`/`az`

`cluster`

`namespace`/`service`/`workload`

`tenant`

`component` (edge/db/cache/queue)

`version` (release/git_sha)

16) Integrazione con alerting e gestione degli incidenti

Regole in Alertmanager/Grafano alert con riferimenti al dashboard desiderato e variabili già impostate.
P1/P2 secondo i criteri SLO, auto-assign su on-call.
Annotazioni di release/incidenti sui grafici.

17) Qualità dei dashboard: assegno-foglio

• Proprietario e contatto.
• SLO/thresholds documentati.
• Le variabili funzionano e limitano la quantità di query.
• Tutti i pannelli con unit e leggenda.
• Drilldown in un percorso/pista.
• I pannelli sono posizionati in 2-3 «schermate» (senza scroll per chilometro).
• Tempo di risposta alle richieste -3 c (cache, downsample).
• Nessun pannello morto e nessuna metrica deprecata.

18) Prestazioni e costo dei dashboard stessi

Downsampling/recording rule per aggregazioni pesanti.
Cache (query-frontend/repiter) e limiti per range/step.
Hangar test: carico di lavoro su TSDB/cluster per le normali richieste di dashboard.
Sanità discografica (bassa cardinalità), abbandono wildcards.

19) Piano di implementazione (iterazione)

1. Settimana 1: Landing + K8s/Edge recensioni, SLO base, proprietari.
2. Settimana 2: DB/Queues, integrazione di logi e piste (drilldown), burn-rate alert.
3. Settimana 3: FinOps-dashboard, linee guida rightsizing, rapporto sul costo.
4. Settimana 4 +: Sicurezza/Compliance, generazione automatica delle schede SLO, test di regressione dei dashboard.

20) Mini FAQ

Quanti dashboard ti servono?
Almeno 1 sfoglia + uno per dominio (K8s, Edge, DB, Queues, CI/CD, Security, Cost). Il resto è maturo.

La cosa più importante sono le metriche o i fogli?
Metriche per sintomi e SLO, per cause. Collegamento attraverso «trace _ id» e etichette concertistiche.

Come non annegare nei pannelli?
Gerarchia, proprietari espliciti, igiene delle metriche, gelosia regolare e rimozione dei pannelli «morti».

Totale

I dashboard delle infrastrutture non sono «bei grafici», ma uno strumento di gestione: controllo SLO, RCA rapido e FinOps consapevole. Standardizzare variabili, modelli visivi e proprietari fornite il drilldown ai fogli/piste e automatizzare i burn-rate alert. Questo fornirà prevedibilità, velocità di risposta e trasparenza dei costi a livello di piattaforma.