Alerting e anomaly detection su stream

Il binario di questa lezione è ml-tabellare, ma il gioco cambia: ogni riga che arriva va confrontata con un passato che si muove con lei. L’obiettivo è svegliare una persona solo quando serve davvero, non a ogni rumore di fondo.

L’idea in breve

L’anomaly detection su stream confronta ogni metrica con una baseline adattiva per svegliare una persona solo quando serve un intervento umano. Meno falsi allarmi, più fiducia in ogni segnale.

Il percorso in cinque passi

Per costruire un sistema di alert che regga il traffico reale:

1. Definisci quale metrica merita un alert e quale azione umana deve seguire.
2. Costruisci baseline adattive per fascia oraria invece di soglie statiche.
3. Fissa severità, owner e rate limiting per evitare duplicati e rumore.
4. Arricchisci ogni alert con contesto su inizio, baseline e impatto atteso.
5. Misura falsi positivi e detection reale e ritaratura soglie ogni settimana.

Soglie statiche e soglie dinamiche

Il modo più semplice di rilevare un’anomalia è la soglia statica: se error_rate supera l’uno per cento, manda un alert. Funziona finché il traffico è stabile. Se una campagna raddoppia il volume, l’alert scatta anche su sistema sano. La soglia dinamica confronta il valore con una baseline adattiva: se error_rate supera media mobile a sette giorni più tre deviazioni standard, manda un alert.

WITH stats AS (
  SELECT AVG(error_rate) OVER (ORDER BY minute ROWS 10080 PRECEDING) AS baseline,
         STDDEV(error_rate) OVER (...) AS stddev
  FROM metrics
)
SELECT * FROM stats WHERE error_rate > baseline + 3 * stddev;

La baseline si muove con il volume e i falsi positivi crollano. Questa è la prima leva per ridurre il rumore.

Tre livelli di sofisticazione

Le tecniche stanno su una scala. Al primo livello c’è l’approccio a soglie: semplice e veloce ma rumoroso. È adatto a metriche stabili come l’health check che smette di rispondere. Al secondo livello stanno metodi statistici come Z-score o IQR: sensibili ai cambi di distribuzione e adatti a metriche con pattern noti come throughput orario con picchi attesi. Al terzo livello arrivano metodi come Isolation Forest o LSTM, che catturano pattern non lineari con stagionalità multiple e interazioni tra variabili. Salire di livello costa complessità e manutenzione e va giustificato dalla metrica.

Verdetto: parti da soglie dinamiche su baseline adattive e sali a metodi statistici o ML solo dove stagionalità e interazioni lo richiedono.

Le regole per un buon sistema di alert

Ogni alert deve richiedere un’azione umana: senza azione è un log, non un alert. La priorità riflette impatto su business e non rarità statistica, con P1 che sveglia di notte e P3 che attende il giorno dopo. Serve rate limiting con al massimo un alert al minuto per stesso problema, perché i duplicati non aggiungono informazione. Ogni alert porta contesto: non CPU sopra il novanta per cento ma quale host, contro quale baseline, da quando e con quale impatto su checkout.

Gli errori da evitare

L’errore più frequente è trattare detection come etichetta invece che come criterio di scelta, con numeri senza decisione, senza baseline e senza rischio residuo. Gli altri tre sono medie globali premature che nascondono segmenti opposti, qualità del dato con duplicati e timezone incoerenti e scambi tra correlazione e causalità. Ogni analisi porta definizione esplicita, confronto per segmento e verifica contro periodo precedente o controllo.

Riferimenti: Netflix Technology Blog (2018), Radon con Robust PCA per anomaly detection; Hochenbaum e colleghi (2017), Automatic Anomaly Detection in the Cloud su KDD 2017.

Il caso di Netflix e Radon

Netflix presenta nel 2018 Radon, sistema di anomaly detection basato su Robust Principal Component Analysis per migliaia di metriche operative. Il metodo separa pattern normale a basso rango da anomalie sparse e resta eseguibile su stream. Il risultato documentato è il passaggio da migliaia di alert giornalieri a poche decine con detection dei problemi reali sopra il 95 per cento. Il guadagno è fiducia: ogni segnale torna a produrre una risposta utile invece di rumore.

Domande per ripassare

1. Quando una soglia statica genera falsi positivi sul tuo traffico?
2. Quale baseline adattiva useresti per error rate e latenza?
3. Chi è owner di ogni alert e quale azione deve seguire?
4. Come misuri se un alert produce risposte utili o solo rumore?