Grafana Alloy come gateway centrale: i numeri di un dimensionamento reale

Chi gestisce una piattaforma enterprise con decine di team applicativi prima o poi si scontra con lo stesso problema: dove far confluire metriche, log e tracce prima di spedirli al backend di osservabilità. Il blog di Grafana Labs ha pubblicato il 21 agosto un resoconto tecnico, con dati reali e anonimizzati, su come è stato dimensionato un cluster Kubernetes di Alloy usato come gateway centrale di telemetria per un grande cliente enterprise.

Il problema del gateway centrale

Nel modello a gateway, tutta la telemetria dei team applicativi—metriche, log e tracce—converge su una flotta condivisa di Alloy via OTLP o protocolli nativi Prometheus/Loki write. Alloy bufferizza, processa, raggruppa e inoltra tutto verso Grafana Cloud. Il vantaggio è un unico punto di autenticazione, rate limiting e attribuzione dei costi; lo svantaggio è che questo diventa un pezzo critico dell'infrastruttura: quando va in difficoltà, lo sente tutto il sistema. Per questo va trattato come qualsiasi altro servizio in produzione: prima la capacity planning, poi il load testing prima del go-live.

I numeri di partenza

Per il cliente seguito dal team Professional Services di Grafana, il traffico atteso era di circa 17 milioni di serie attive (via OTLP e RW), 1 TB/giorno di log con picco a 17,5 MB/s (via OTLP e LW), e circa 1 TB/giorno di tracce con picco a circa 23 MB/s (via OTLP). La cifra non era quella attuale ma quella di fine onboarding: Grafana spiega che bisognava dimensionare per quel margine, non solo per la base attuale, perché la maggior parte delle grandi aziende aggiunge team gradualmente ma serve comunque preparare in anticipo la capacità piena.

Risorse e configurazione

Il budget di risorse pianificato è stato di circa 187 GB di memoria e 7 core CPU per le metriche, 2,1 GB e 17,5 core per i log, 4 GiB e 3 core per le tracce: un totale di circa 195 GB di memoria e 28 core CPU. I pod sono stati configurati con 0,5 CPU in request, 6 GiB di memoria in request e limit, ma senza limite di CPU, per evitare il throttling che in Kubernetes genera latenza nascosta nei carichi ad alto throughput. L'HPA è stato impostato con minReplicas 30, maxReplicas 100, target al 70% di CPU e 90% di memoria.

In produzione

Dal go-live il cluster ha retto volumi superiori a quelli pianificati: circa 17 milioni di serie attive, 20-30 MB/s di log e fino a 150 MB/s di tracce. Tra le lezioni operative segnalate da Grafana, due riguardano direttamente chi opera il cluster: il write-ahead log di Alloy può saturare la memoria se non monitorato sotto pressione sostenuta, e GOMEMLIMIT va impostato a circa l'80% del limite di memoria del pod (esempio: 4915MiB su un limite di 6Gi) per far scattare il garbage collector di Go prima dell'OOM kill del container.