import pandas as pd

Operations: monitoring and managing Kafka in production

Un cluster Kafka 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 possa essere usato con fiducia. Conviene leggerle come un runbook: quali metriche anticipano un incidente, quali soglie richiedono escalation, quali azioni sono reversibili e quali cambiano la durabilità dei dati.

Cosa rende osservabile un cluster

Il problema operativo non è conoscere Kafka in astratto, ma capire cosa fare quando i segnali sono ambigui. Una metrica utile deve dirti quale decisione cambia: aggiungo istanze, sposto partizioni, allungo la retention, faccio escalation. Per ogni segnale tieni a mente quattro cose: la decisione che potrebbe cambiare, il dato osservabile, la baseline rispetto a cui leggerlo e il rischio che resta anche dopo l’intervento. Se un grafico non risponde a queste quattro domande, è decorazione di una dashboard, non strumento operativo.

Essential Metrics to Monitor

Quattro metriche bastano a coprire la maggior parte degli incidenti.

Metric	What it measures	Alarm threshold
Under-replicated partitions	Partitions without the configured number of ISR	>0 for more than 1 minute
Consumer lag	Offset lag between last produced and last consumed message	>100K or increasing
Request handler idle ratio	% time threads are idle	<0.2 (80% busy → overload)
Disk usage	Disk space used by logs	>70% → plan expansion

La più importante è il consumer lag, ma quello che conta non è il valore assoluto. Un lag di 100K su 10M msg/sec equivale a circa 10ms, quindi irrilevante. Conta il trend: se il lag cresce in modo lineare, il consumer non sta tenendo il passo e servono più istanze o più partizioni.

Throughput Tuning

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, e qui c’è un compromesso: più partizioni danno più throughput ma anche più overhead di coordinamento, e una regola pratica fissa le partizioni a max(throughput_target/10, consumer_threads × 2). La compressione zstd, infine, arriva fino al 90% di riduzione e si decomprime più velocemente della lettura di dati non compressi.

Disaster recovery: backup and restore

Kafka non ha un meccanismo di 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 strategia di retention è la rete di sicurezza: se imposti la retention a 30 giorni, puoi riprocessare qualsiasi pipeline dal log in caso di corruzione dei dati a valle. In pratica la retention non è solo una questione di costo storage, è la tua capacità di rifare i conti dopo un errore.

Esempio: diagnosticare un lag che cresce

Immagina un team che vede crescere il consumer lag durante una campagna e deve 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 alcuni segnali tipici.

Observed evidence	Cautious interpretation	Recommended action
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

Real case: Netflix and the discipline of metrics

Netflix è un esempio utile perché ha costruito molte decisioni di prodotto intorno a segnali comportamentali osservabili: completamento degli episodi, tempo di ricerca prima della riproduzione, abbandono dopo pochi minuti, ritorno nella settimana successiva, efficacia delle raccomandazioni. Il punto non è copiare Netflix, ma il metodo: il dato non viene trattato come ornamento, viene trattato come infrastruttura decisionale.

Quando valuta una modifica all’esperienza, per esempio una nuova riga di raccomandazioni o un diverso algoritmo di ranking, Netflix non misura solo il click immediato. Misura anche segnali di qualità: l’utente guarda davvero il contenuto, torna nei giorni successivi, riduce il tempo speso a cercare. Lo stesso principio vale per le operations di un cluster: una metrica osservata ha valore solo se cambia una decisione operativa.

SQL example: building a control view

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. Serve a creare una base analitica con metrica, segmento e finestra temporale, così da confrontare periodi e gruppi senza riscrivere la logica ogni volta.

WITH base_events AS (
  SELECT
    user_id,
    account_id,
    event_type,
    event_time,
    DATE_TRUNC('week', event_time) AS week,
    source,
    device_type
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '180 days'
    AND user_id IS NOT NULL
),
weekly_user_metrics AS (
  SELECT
    week,
    user_id,
    COALESCE(source, 'unknown') AS source,
    COALESCE(device_type, 'unknown') AS device_type,
    COUNT(*) AS total_events,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(DISTINCT event_type) AS event_diversity,
    MAX(CASE WHEN event_type IN ('purchase', 'subscribe', 'activation') THEN 1 ELSE 0 END) AS reached_key_outcome
  FROM base_events
  GROUP BY week, user_id, source, device_type
)
SELECT
  week,
  source,
  device_type,
  COUNT(DISTINCT user_id) AS users,
  ROUND(AVG(active_days), 2) AS avg_active_days,
  ROUND(AVG(event_diversity), 2) AS avg_event_diversity,
  ROUND(AVG(reached_key_outcome) * 100, 2) AS key_outcome_rate
FROM weekly_user_metrics
GROUP BY week, source, device_type
ORDER BY week, source, device_type;

La query non è la risposta finale. Crea una superficie di osservazione (trend, segmenti, differenze tra canali, variazioni nel tempo) da cui formulare ipotesi più precise.

Python example: checking stability and anomalies

Una metrica utile deve essere abbastanza stabile da orientare decisioni e abbastanza sensibile da segnalare cambiamenti reali. In Python puoi controllare le variazioni anomale settimana su settimana con un z-score mobile.

# df contiene: week, segment, users, key_outcome_rate
# key_outcome_rate espresso in percentuale, es. 12.4

df = df.sort_values(['segment', 'week']).copy()
df['previous_rate'] = df.groupby('segment')['key_outcome_rate'].shift(1)
df['wow_change_pp'] = df['key_outcome_rate'] - df['previous_rate']
df['rolling_mean'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).mean()
)
df['rolling_std'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).std()
)
df['z_score'] = (df['key_outcome_rate'] - df['rolling_mean']) / df['rolling_std']

anomalies = df[df['z_score'].abs() >= 2].sort_values('z_score')
print(anomalies[['week', 'segment', 'key_outcome_rate', 'wow_change_pp', 'z_score']])

Il valore di questo controllo è pratico. Evita di reagire a ogni oscillazione casuale e segnala solo quando una variazione merita un’indagine, alimentando alert, review settimanali e retrospettive.

Errori tipici da evitare

L’errore più frequente è usare il monitoring come etichetta invece che come processo. Succede quando si mostra 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 sbaglierei?

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.

Lab ed esercizi

Per fissare i concetti, lavora su tre livelli.

1. Scrivi in cinque righe quale decisione operativa concreta vuoi migliorare (per esempio aggiungere istanze quando il lag cresce), indicando metrica, baseline e rischio principale.
2. Costruisci una tabella con quattro colonne (segnale osservato, interpretazione prudente, controllo necessario, azione consigliata) e includi almeno un caso in cui il segnale non basta per decidere.
3. Trasforma l’esercizio in un decision memo con assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e un piano di monitoraggio dopo la decisione.

Come materiale puoi usare metriche reali del cluster, consumer lag e un dataset clickstream. In assenza di dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una di segmento e una metrica di outcome.

Checkpoint

Prima di chiudere, verifica di saper rispondere. Quale decisione operativa concreta vuoi migliorare? Quale unità di analisi rende il problema misurabile? Quale baseline useresti per evitare una lettura ingenua? Quale errore tipico potrebbe cambiare la conclusione? Quale output consegneresti a uno stakeholder non tecnico?

---

References:

• Confluent. (2024). “Kafka Monitoring and Operations.” docs.confluent.io.
• Kafka Summit. (2022). “Lessons Learned Running Kafka at Scale.” Confluent.

Operational Summary

Gestire Kafka in produzione è utile quando riduce l’incertezza su una scelta reale. Le metriche che contano sono poche (under-replicated partitions, consumer lag, idle ratio dei thread, uso del disco) e ciascuna punta a un’azione precisa. Il tuning segue il fatto che Kafka è I/O bound, e il disaster recovery si appoggia a MirrorMaker 2 e alla retention. Un buon presidio operativo non si ferma a “il numero è salito”: indica quale decisione prendere, con quale confidenza e quale metrica confermerà se era quella giusta.