Operations: monitorare e gestire Kafka in produzione
Monitoring, tuning e gestione operativa di un cluster Kafka in produzione.
Cosa imparerai
- Impostare soglie di escalation su lag, partizioni sotto-replicate e spazio disco
- Applicare il tuning I/O con page cache, partizioni calibrate e compressione zstd
- Pianificare retention e replica MirrorMaker 2 per riprocessare dopo un errore
Collegamenti
Operations: monitorare e gestire Kafka in produzione
Questa lezione chiude il percorso tecnico del binario ml-tabellare: un cluster si giudica nei momenti difficili, e l’operatività è la disciplina che trasforma ogni metrica in un’azione di escalation precisa e reversibile.
L’idea in una frase
Gestire Kafka in produzione significa leggere poche metriche con soglie esplicite e trasformare ogni segnale in un’azione di escalation reversibile.
La procedura in cinque passi
- Controlla le partizioni sotto-replicate e scala se restano sopra zero oltre un minuto.
- Leggi il trend del consumer lag: una crescita lineare chiede più capacità.
- Controlla il rapporto di idle dei thread e l’uso disco con soglie di escalation.
- Applica il tuning I/O: page cache, partizioni calibrate e compressione
zstd. - Fissa retention e replica MirrorMaker 2 per poter riprocessare dopo un errore.
Cosa rende osservabile un cluster
Un cluster funziona davvero solo quando resta comprensibile nei momenti difficili: consumer lag che cresce, broker sotto pressione, partizioni sbilanciate, retention quasi piena, leader election inattese. Questa lezione porta il modulo dal design all’esercizio quotidiano. Le operations non sono un capitolo finale, sono la condizione perché Kafka sia usabile con fiducia. Leggile come un runbook: quali metriche anticipano un incidente, quali soglie richiedono escalation, quali azioni sono reversibili e quali cambiano la durabilità dei dati.
Il problema operativo non è conoscere Kafka in astratto, ma decidere cosa fare quando i segnali sono ambigui. Una metrica utile deve dirti quale decisione cambia: aggiungi istanze, sposti partizioni, allunghi la retention, fai escalation. Per ogni segnale tieni a mente quattro cose: la decisione che potrebbe cambiare, il dato osservabile, la baseline di lettura e il rischio che resta dopo l’intervento. Se un grafico non risponde a queste domande, decora una dashboard ma non guida l’operatività.
Metriche essenziali da monitorare
Quattro metriche coprono la maggior parte degli incidenti.
| Metrica | Cosa misura | Soglia di allarme |
|---|---|---|
| Under-replicated partitions | Partizioni senza il numero configurato di ISR | >0 per più di 1 minuto |
| Consumer lag | Offset lag tra ultimo messaggio prodotto e ultimo consumato | >100K o in crescita |
| Request handler idle ratio | % tempo in cui i thread sono idle | <0.2 (80% busy → sovraccarico) |
| Disk usage | Spazio disco usato dai log | >70% → pianifica espansione |
La più importante è il consumer lag, ma conta il trend, non il valore assoluto. Un lag di 100K su 10M di messaggi al secondo equivale a circa 10ms, quindi è irrilevante. Se invece il lag cresce in modo lineare, il consumer non tiene il passo e servono più istanze o più partizioni.
Tuning per il throughput
Kafka è I/O bound, quindi le ottimizzazioni che contano riguardano dischi, rete e memoria, non la CPU. La page cache del sistema operativo è centrale: Kafka non usa una cache propria, si appoggia alla page cache del kernel, perciò RAM extra per il sistema operativo rende più dell’heap Java extra. Il parametro num.partitions regola il parallelismo, con un compromesso: più partizioni danno più throughput ma anche più overhead di coordinamento. Una regola pratica fissa le partizioni al massimo tra throughput target diviso 10 e thread dei consumer per due. La compressione zstd, infine, arriva fino al 90% di riduzione e si decomprime più velocemente della lettura di dati non compressi.
Disaster recovery: backup e restore
Kafka non ha un backup nativo, perché è già replicato. Per il disaster recovery cross-region si usa MirrorMaker 2, che replica i topic tra cluster in datacenter diversi. La retention è la rete di sicurezza: con 30 giorni di retention puoi riprocessare qualsiasi pipeline dal log dopo una corruzione a valle. In pratica la retention non è solo costo storage, è la capacità di rifare i conti dopo un errore.
Esempio: diagnosticare un lag che cresce
Il caso tipico è un lag che cresce durante un picco di traffico: bisogna capire dove sta il collo di bottiglia, nel producer, nei broker, nella cardinalità delle partizioni o nei consumer. La decisione richiede metriche coordinate, non una dashboard generica piena di segnali non azionabili. La tabella mostra come leggere i segnali tipici.
| Evidenza osservata | Lettura prudente | Azione consigliata |
|---|---|---|
| Il lag cresce solo su alcune partizioni | Quelle partizioni hanno chiavi calde | Rivedere la chiave o aumentare le partizioni |
| Il lag cresce su tutto il consumer group | I consumer non hanno capacità sufficiente | Aggiungere istanze fino al numero di partizioni |
| Il throughput dei broker è saturo | Il collo di bottiglia è a monte dei consumer | Stimare il trade-off tra costo broker e SLA |
Errori tipici da evitare
L’errore più frequente è usare il monitoring come etichetta invece che come processo. Succede quando mostri un grafico senza una decisione, una metrica senza baseline o una conclusione senza dire quale assunzione potrebbe invalidarla. La domanda di controllo è: se questo risultato fosse instabile, quale scelta sbaglieresti?
Sul lato dati ci sono tre trappole. La prima è lavorare su aggregati troppo presto, perché una media globale nasconde segmenti che si muovono in direzioni opposte. La seconda è non controllare la qualità del dato: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. La terza è confondere correlazione e causalità. Tre controlli minimi riducono il rischio: definizione esplicita della metrica, confronto per segmento e verifica contro un periodo precedente.
L’esempio che fa da riferimento
La documentazione operativa di Confluent del 2024 consolida le metriche nate dall’esercizio di Kafka su larga scala: partizioni sotto-replicate, lag dei consumer, saturazione dei thread e spazio disco. Al Kafka Summit 2022 i resoconti di esercizio hanno mostrato lo stesso schema decisionale: il trend del lag guida il capacity planning e la retention decide la capacità di riprocessare dopo un errore. MirrorMaker 2 è lo strumento standard per la replica cross-region quando un singolo cluster non basta. Il filo comune è operativo: ogni metrica esiste per un’azione di escalation precisa.
Verdetto: la più importante è il consumer lag, ma conta il trend, non il valore assoluto: una crescita lineare chiede più capacità, e ogni metrica esiste per un’azione di escalation reversibile, non per decorare una dashboard.
Domande per verificare la lezione
- Quale metrica guardi per prima quando il lag cresce e quale trend ti fa scalare?
- Quale soglia di partizioni sotto-replicate fa scattare l’escalation nel tuo runbook?
- Quanta retention tieni e quale incidente ti permette di riprocessare?
- Quale azione è reversibile e quale cambia la durabilità dei dati?
Bloccato su questo argomento o vuoi applicarlo al tuo caso? Prenota una call di 15 minuti con un analista esperto.
Percorso collegato
Lezioni da leggere insieme
Questi collegamenti portano la lezione dentro il resto del corso: basi da riprendere, passaggi successivi e connessioni tematiche tra moduli.