Grafana 13.2: policy di notifica multiple per instradare gli alert senza un unico albero globale

Chi gestisce Grafana Alerting per più team sullo stesso stack conosce il problema: un solo albero di notification policy condiviso da tutti, dove modificare il routing di un servizio significa toccare la configurazione di tutti gli altri. Con Grafana 13.2, annunciato il 21 settembre 2026 sul blog ufficiale del progetto, questo limite viene superato con le policy di notifica multiple, passate da feature flag a disponibilità generale.

Cosa cambia in pratica

Da Grafana 13.2 le policy di notifica multiple sono disponibili in generale nell'alerting gestito da Grafana: si possono creare alberi di notification policy con un nome, assegnare le alert rule a una policy specifica e gestire ogni policy in modo indipendente. La funzione era già presente ma riservata ai tester: richiedeva il feature flag alertingMultiplePolicies, in anteprima pubblica, e quando il flag era disattivato il sistema continuava a usare un unico albero di notification policy.

Il punto chiave per chi fa manutenzione è la compatibilità all'indietro: le alert rule esistenti continuano a usare la notification policy di default a meno che non vengano assegnate esplicitamente a una policy con nome, quindi l'adozione può avvenire a gradini senza dover migrare tutte le regole in un colpo solo.

Provisioning e permessi separati per team

Ogni policy con nome diventa una risorsa a sé stante: i team possono creare alberi di policy con nome, assegnare le alert rule direttamente a una policy specifica e gestire ciascuna policy in modo indipendente tramite UI, API o Terraform, con provisioning per team, modifiche isolate (l'aggiornamento di una policy non tocca le altre) e controllo degli accessi basato su ruoli a livello di singola policy.

Per chi gestisce l'infrastruttura come codice, la novità lato Terraform è la risorsa dedicata: ogni albero di routing con nome si configura separatamente, con supporto a route annidate, matcher, raggruppamento, timing delle notifiche e controlli di provenance per decidere se la policy resta modificabile anche fuori da Terraform.

Resta da valutare, per chi gestisce stack condivisi tra più clienti o reparti, se il modello a policy multiple semplifichi davvero la revisione degli alberi di routing o si limiti a spostare la complessità dalla configurazione unica alla gestione di più risorse separate da tenere sincronizzate.