Il problema delle soglie statiche negli alert
Chiunque gestisca alert su log query in Azure Monitor conosce il dilemma delle soglie statiche: se il valore è troppo basso, si ricevono notifiche continue per fluttuazioni normali (l’autoscaling di un cluster AKS, il traffico più alto del lunedì mattina, i picchi stagionali di un e-commerce); se è troppo alto, si rischia di non accorgersi di un’anomalia reale finché non è troppo tardi. Il risultato tipico è affaticamento da alert, team che silenziano le notifiche, e problemi che passano inosservati.
Azure Monitor affronta questo problema con le soglie dinamiche (dynamic thresholds) per gli alert su ricerca di log, ora in disponibilità generale e senza costi aggiuntivi rispetto alla normale tariffa degli alert su log query. Vale la pena approfondire come funzionano e come configurarle correttamente, perché il vantaggio pratico per chi gestisce infrastrutture Azure è notevole.
Come funzionano le soglie dinamiche
Le soglie dinamiche applicano algoritmi di machine learning ai risultati delle query di log per apprenderne il comportamento storico. Il sistema analizza i dati nel tempo e identifica pattern ricorrenti — la cosiddetta seasonality, ovvero le fluttuazioni prevedibili che si ripetono a intervalli regolari (orari, giornalieri, settimanali). Quando i risultati della query si discostano in modo significativo dal pattern appreso, l’alert scatta.
In pratica, quando si crea una regola di alert, le soglie dinamiche utilizzano inizialmente 10 giorni di dati storici per calcolare i pattern stagionali orari e giornalieri. Dopo tre settimane, il sistema ha raccolto abbastanza dati da identificare anche i pattern settimanali e aggiusta il modello di conseguenza. Le soglie continuano ad apprendere dai nuovi dati, migliorando l’accuratezza nel tempo.
Configurare un alert su log search con soglia dinamica
La configurazione parte dalla procedura standard per creare una regola di alert su ricerca di log nel portale Azure: si definisce la query, la misurazione e le dimensioni esattamente come si farebbe con una soglia statica. La differenza sta nella sezione Alert logic:
- Per Threshold, selezionare Dynamic invece di Static.
- Per Operator, scegliere tra tre opzioni: Greater than the upper threshold or lower than the lower threshold (l’opzione predefinita, che considera entrambe le direzioni), Greater than the upper threshold, oppure Lower than the lower threshold. Le soglie dinamiche calcolano sia un limite superiore sia uno inferiore, quindi si può scegliere quale tipo di deviazione deve far scattare l’alert.
- Per Threshold sensitivity, selezionare High, Medium (predefinito) o Low. La sensibilità alta imposta soglie strette vicine al pattern misurato e scatta anche per deviazioni minime; quella bassa tollera scostamenti maggiori e si attiva solo per anomalie evidenti.
Dopo aver configurato la condizione, il pulsante Preview Chart mostra i risultati storici della query insieme all’intervallo di soglia calcolato: una linea blu per i valori misurati, un’area viola per l’intervallo di soglia consentito, punti rossi per le violazioni della soglia e barre rosa per gli alert effettivamente scattati. Dopo ogni modifica alla condizione, è necessario selezionare Refresh Chart per aggiornare l’anteprima.
// Esempio di query KQL usata come base per un alert con soglia dinamica
// (conteggio dei riavvii dei pod in un cluster AKS)
KubePodInventory
| where TimeGenerated > ago(1h)
| summarize RestartCount = sum(PodRestartCount) by ClusterName, Namespace, Name
Suddividere l’alert per dimensioni
Una delle funzionalità più utili per chi gestisce ambienti multi-risorsa è la possibilità di suddividere la valutazione dell’alert per dimensioni, ovvero colonne dei risultati della query che contengono dati aggiuntivi come nomi di risorse, namespace o ID di sottoscrizione. Quando si usano le dimensioni, la regola di alert valuta separatamente ogni combinazione di dimensioni e genera un alert indipendente per ciascun gruppo che soddisfa la condizione. È possibile applicare fino a sei dimensioni per regola.
Un caso pratico: monitorare i riavvii dei pod in un cluster AKS suddividendo per Namespace e Name, in modo che ogni namespace e ogni pod ottenga una propria baseline di soglia dinamica. Questo evita che un singolo alert generico “spari” per l’intero cluster quando in realtà è un solo namespace ad avere un comportamento anomalo, e permette al modello di adattarsi a fluttuazioni normali dovute all’autoscaling.
Limiti da conoscere prima di usarle in produzione
Alcune limitazioni sono importanti da tenere a mente per non avere aspettative sbagliate:
- La frequenza minima di valutazione è di 5 minuti.
- Le regole non scattano prima di aver raccolto almeno 3 giorni e 30 campioni di dati: risorse nuove o con dati mancanti non genereranno alert finché non ci sono dati sufficienti.
- Servono almeno 3 settimane di dati storici per rilevare la stagionalità settimanale; pattern come cicli bi-orari o semi-settimanali potrebbero non essere rilevati affatto.
- Le soglie dinamiche sono pensate per rilevare deviazioni significative e improvvise, non problemi che si sviluppano lentamente: un degrado graduale delle prestazioni probabilmente non farà scattare l’alert.
- Non è possibile usare soglie dinamiche in regole che monitorano più condizioni contemporaneamente.
- La configurazione è possibile tramite portale Azure o template ARM; PowerShell e Azure CLI non sono ancora supportati per le regole di alert su log search con soglie dinamiche.
- Il grafico di anteprima ha limiti sull’intervallo temporale in base alla frequenza della regola: con frequenza di 5 minuti si vedono fino a 6 ore di dati, con frequenza di un’ora o superiore fino a 2 giorni.
Come ridurre il rumore (o aumentare la sensibilità)
Se una regola scatta troppo spesso, ci sono diverse leve da regolare prima di abbandonare l’approccio: abbassare la sensibilità della soglia a Low per tollerare deviazioni maggiori, aumentare la granularità di aggregazione (la finestra temporale usata per raggruppare i punti dati) per ridurre la sensibilità a picchi transitori, oppure configurare nelle impostazioni avanzate il numero di violazioni richieste in un determinato periodo prima che l’alert scatti effettivamente.
Al contrario, se una regola non è abbastanza sensibile nemmeno con sensibilità alta, è probabile che la distribuzione dei dati sia molto irregolare. In questi casi Microsoft consiglia di verificare se nei 10 giorni precedenti si è verificato un cambiamento drastico nel comportamento dei dati — per esempio un’interruzione di servizio — che può aver alterato il calcolo delle soglie. Un’altra opzione è monitorare una metrica complementare o modificare la granularità di aggregazione.
Due casi d’uso concreti
Microsoft evidenzia due scenari tipici. Il primo riguarda il monitoraggio dei riavvii dei pod Kubernetes tramite la tabella KubePodInventory, riassumendo i conteggi per cluster, namespace e nome del pod: le soglie dinamiche si adattano alle fluttuazioni normali causate dall’autoscaling e generano alert solo per anomalie reali. Il secondo riguarda il rilevamento di drift nell’inventario delle risorse tramite query di Azure Resource Graph: contando le risorse per tipo e ID sottoscrizione, le soglie dinamiche possono identificare picchi improvvisi nella creazione o cancellazione di risorse che potrebbero indicare deployment fuori controllo, adattandosi ai pattern stagionali di deployment che una soglia statica non riuscirebbe a gestire.
Conclusione
Le soglie dinamiche per gli alert su log search sono una delle funzionalità più concretamente utili di Azure Monitor per chi gestisce ambienti con carichi variabili nel tempo: riducono il rumore degli alert senza richiedere di indovinare manualmente una soglia statica per ogni metrica, e si adattano automaticamente quando cambia la scala dell’infrastruttura. Detto questo, non sono una bacchetta magica: richiedono tempo per costruire una baseline affidabile (fino a tre settimane per la stagionalità settimanale) e non sono adatte a rilevare degradi lenti e progressivi. Per la maggior parte degli scenari di monitoraggio di infrastrutture Azure dinamiche — cluster Kubernetes, ambienti con autoscaling, fleet di risorse in continua evoluzione — rappresentano comunque un netto miglioramento rispetto alle soglie statiche tradizionali.
Fonte: 4sysops.com, con riferimenti alla documentazione ufficiale Microsoft Learn.