Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Notifications
****
**Questo argomento della documentazione è progettato per le aree di lavoro Grafana che supportano la versione 10.x di Grafana.**
Per le aree di lavoro Grafana che supportano la versione 9.x di Grafana, vedere. [Lavorare nella versione 9 di Grafana](using-grafana-v9.md)
Per le aree di lavoro Grafana che supportano la versione 8.x di Grafana, vedere. [Funzionamento in Grafana versione 8](using-grafana-v8.md)
La scelta di come, quando e dove inviare le notifiche di avviso è una parte importante della configurazione del sistema di avviso. Queste decisioni avranno un impatto diretto sulla vostra capacità di risolvere rapidamente i problemi e di non tralasciare nulla di importante.
Come primo passo, definisci i tuoi [punti di contatto](v10-alerting-explore-contacts.md), che definiscono dove inviare le notifiche di avviso. Un punto di contatto è un insieme di una o più integrazioni utilizzate per inviare notifiche. Aggiungi modelli di notifica ai punti di contatto per riutilizzarli e inviare messaggi coerenti nelle notifiche.
Successivamente, crea una politica di notifica che consiste in un insieme di regole per stabilire dove, quando e come gli avvisi vengono indirizzati ai punti di contatto. In una politica di notifica, definisci dove inviare le notifiche di avviso scegliendo uno dei punti di contatto che hai creato.
## Gestori di avvisi
Grafana utilizza Alertmanager per inviare notifiche di attivazione e avvisi risolti. [Grafana ha il proprio Alertmanager, denominato **Grafana** nell'interfaccia utente, ma supporta anche l'invio di notifiche da altri Alertmanager, come Prometheus Alertmanager.](https://prometheus.io/docs/alerting/latest/alertmanager/) Grafana Alertmanager utilizza politiche di notifica e punti di contatto per configurare come e dove inviare una notifica, con quale frequenza deve essere inviata una notifica e se gli avvisi devono essere inviati tutti nella stessa notifica, inviati in notifiche raggruppate sulla base di un set di etichette o come notifiche separate.
## Politiche di notifica
Le politiche di notifica controllano quando e dove vengono inviate le notifiche. Una politica di notifica può scegliere di inviare tutti gli avvisi insieme nella stessa notifica, inviare avvisi in notifiche raggruppate in base a un set di etichette o inviare avvisi come notifiche separate. È possibile configurare ogni politica di notifica per controllare la frequenza di invio delle notifiche e disporre di uno o più orari di silenziamento per inibire le notifiche in determinate ore del giorno e in determinati giorni della settimana.
Le politiche di notifica sono organizzate in una struttura ad albero in cui alla radice dell'albero è presente una politica di notifica chiamata politica predefinita. Può esserci solo una politica predefinita e la politica predefinita non può essere eliminata.
Le politiche di routing specifiche sono figli della politica principale e possono essere utilizzate per abbinare tutti gli avvisi o un sottoinsieme di avvisi in base a un set di etichette corrispondenti. Una politica di notifica corrisponde a un avviso quando le etichette corrispondenti corrispondono alle etichette dell'avviso.
Una politica annidata può avere le proprie politiche annidate, che consentono un'ulteriore corrispondenza degli avvisi. Un esempio di policy annidata potrebbe essere l'invio di avvisi di infrastruttura al team Ops; mentre una policy secondaria potrebbe inviare avvisi ad alta priorità a Pagerduty e avvisi a bassa priorità a Slack.
Tutti gli avvisi, indipendentemente dalle etichette, corrispondono alla politica predefinita. Tuttavia, quando la politica predefinita riceve un avviso, esamina ogni politica annidata e invia l'avviso alla prima politica nidificata che corrisponde all'avviso. Se la politica annidata include ulteriori politiche annidate, può tentare di abbinare l'avviso a una delle sue politiche nidificate. Se nessuna politica annidata corrisponde all'avviso, la politica stessa è la politica corrispondente. Se non ci sono politiche nidificate o nessuna politica nidificata corrisponde all'avviso, la politica predefinita è la politica corrispondente.
Per informazioni più dettagliate sulle politiche di notifica, vedere. [Politiche di notifica](v10-alerting-explore-notifications-policies-details.md)
## Modelli di notifica
Puoi personalizzare le notifiche con modelli. Ad esempio, i modelli possono essere utilizzati per modificare il titolo e il messaggio delle notifiche inviate a Slack.
I modelli non si limitano a una singola integrazione o a un singolo punto di contatto, ma possono essere utilizzati in diverse integrazioni nello stesso punto di contatto e persino in integrazioni tra diversi punti di contatto. Ad esempio, un utente Grafana può creare un modello chiamato `custom_subject_or_title` e utilizzarlo sia per gli argomenti dei modelli in Pager Duty che per i titoli dei messaggi Slack senza dover creare due modelli separati.
Tutti i modelli di notifica sono scritti nel [linguaggio dei modelli di Go](https://pkg.go.dev/text/template) e si trovano nella scheda Punti di contatto della pagina Avvisi.
Per informazioni più dettagliate sulla personalizzazione delle notifiche, consulta. [Personalizza le notifiche](v10-alerting-manage-notifications.md)
## Silenzi
Puoi usare i silenzi per disattivare le notifiche provenienti da una o più regole di attivazione. I silenzi non impediscono che gli avvisi si attivino o vengano risolti, né nascondono gli avvisi di attivazione nell'interfaccia utente. Un silenzio dura quanto la sua durata, che può essere configurata in minuti, ore, giorni, mesi o anni.
Per informazioni più dettagliate sull'uso dei silenzi, vedere[Silenziamento delle notifiche di avviso](v10-alerting-silences.md).
# Politiche di notifica
****
**Questo argomento della documentazione è progettato per le aree di lavoro Grafana che supportano la versione 10.x di Grafana.**
Per le aree di lavoro Grafana che supportano la versione 9.x di Grafana, vedere. [Lavorare nella versione 9 di Grafana](using-grafana-v9.md)
Per le aree di lavoro Grafana che supportano la versione 8.x di Grafana, vedere. [Funzionamento in Grafana versione 8](using-grafana-v8.md)
Le politiche di notifica offrono un modo flessibile per indirizzare gli avvisi a vari ricevitori diversi. Utilizzando label matchers, puoi modificare l'invio delle notifiche di avviso senza dover aggiornare ogni singola regola di avviso.
In questa sezione, scoprirai di più su come funzionano e sono strutturate le politiche di notifica, in modo da poter sfruttare al massimo la configurazione delle politiche di notifica.
## Albero delle politiche
Le politiche di notifica *non* sono un elenco, ma sono strutturate secondo una struttura ad albero. Ciò significa che ogni policy può avere policy secondarie e così via. La radice dell'albero dei criteri di notifica è denominata **Politica di notifica predefinita**.
Ogni policy è costituita da una serie di abbinatori di etichette (0 o più) che specificano quali etichette sono o non sono interessati a gestire.
Per ulteriori informazioni sulla corrispondenza delle etichette, consulta[Come funziona l'abbinamento delle etichette](v10-alerting-overview-labels-matching.md).
**Nota**
Se non hai configurato alcun abbinatore di etichette per la tua politica di notifica, la politica di notifica corrisponderà a *tutte le* istanze di avviso. Ciò potrebbe impedire la valutazione delle politiche relative ai minori a meno che tu non abbia abilitato **Continua ad abbinare fratelli** nella politica di notifica.
## Routing
Per determinare quale politica di notifica gestirà quali istanze di avviso, devi iniziare esaminando il set esistente di politiche di notifica, a partire dalla politica di notifica predefinita.
Se non sono configurate politiche diverse dalla politica predefinita, la politica predefinita gestirà l'istanza di avviso.
Se vengono definite politiche diverse da quelle predefinite, verranno valutate tali politiche di notifica nell'ordine in cui vengono visualizzate.
Se una politica di notifica contiene criteri di abbinamento delle etichette che corrispondono alle etichette dell'istanza di avviso, passerà alle relative politiche secondarie e, se presenti, continuerà a cercare eventuali criteri secondari che potrebbero avere abbinatori di etichette che restringono ulteriormente il set di etichette e così via fino a quando non saranno più disponibili criteri secondari.
Se nessun criterio figlio è definito in un criterio di notifica o se nessuno dei criteri figlio ha abbinamenti di etichette che corrispondono alle etichette dell'istanza di avviso, viene utilizzato il criterio di notifica principale.
Non appena viene trovata una politica corrispondente, il sistema non continua a cercare altre politiche corrispondenti. Se desideri continuare a cercare altre politiche che potrebbero corrispondere, abilita **Continua ad abbinare i fratelli** in base a quella particolare politica.
Infine, se nessuna delle politiche di notifica è selezionata, viene utilizzata la politica di notifica predefinita.
### Esempio di routing
Ecco un esempio di un albero di policy di notifica relativamente semplice e di alcune istanze di avviso.
![\[Un'immagine che mostra una serie di politiche di notifica in una struttura ad albero e una serie di istanze di avviso con etichette diverse da abbinare alle politiche.\]](http://docs.aws.amazon.com/it_it/grafana/latest/userguide/images/notification-routing.png)
Ecco un'analisi dettagliata di come vengono selezionate queste politiche:
**Pod stuck in CrashLoop** non ha un'`severity`etichetta, quindi nessuna delle sue politiche per bambini corrisponde. Ha un'`team=operations`etichetta, quindi la prima politica corrisponde.
La `team=security` politica non viene valutata poiché abbiamo già trovato una corrispondenza e **Continue matching siblings** non è stata configurata per quella politica.
**Utilizzo del disco: l'80%** ha `team` sia un'`severity`etichetta che corrisponde a una politica secondaria del team operativo.
La **voce di registro non autorizzata** ha un'`team`etichetta ma non corrisponde alla prima policy (`team=operations`) poiché i valori non sono gli stessi, quindi continuerà a cercare e corrisponderà alla `team=security` policy. Non ha criteri secondari, quindi l'`severity=high`etichetta aggiuntiva viene ignorata.
## Ereditarietà
Oltre a essere un concetto utile per indirizzare le istanze di avviso, le politiche secondarie ereditano anche le proprietà dalla politica principale. Ciò vale anche per tutte le politiche che sono politiche secondarie della politica di notifica predefinita.
Le seguenti proprietà vengono ereditate dalle politiche secondarie:
+ Punto di contatto
+ Opzioni di raggruppamento
+ Opzioni di tempistica
+ Tempi di silenziamento
Ognuna di queste proprietà può essere sovrascritta da una singola politica se si desidera sovrascrivere le proprietà ereditate.
Per ereditare un punto di contatto dalla politica principale, lasciala vuota. **Per ignorare le opzioni di raggruppamento ereditate, abilita Ignora raggruppamento.** **Per sovrascrivere le opzioni di temporizzazione ereditate, abilita Sovrascrivi i tempi generali.**
### Esempio di ereditarietà
L'esempio seguente mostra come l'albero delle politiche di notifica del nostro esempio precedente consenta alle politiche secondarie di `team=operations` ereditare il proprio punto di contatto.
In questo modo, possiamo evitare di dover specificare lo stesso punto di contatto più volte per ogni politica sui minori.
![\[Un'immagine che mostra una serie di politiche di notifica in una struttura ad albero, con punti di contatto assegnati ad alcune politiche, ma con alcune politiche per bambini che ereditano i punti di contatto dei genitori, anziché definire i propri.\]](http://docs.aws.amazon.com/it_it/grafana/latest/userguide/images/notification-inheritance.png)
## Opzioni di configurazione aggiuntive
### Raggruppamento
Il raggruppamento è una funzionalità importante di Grafana Alerting in quanto consente di raggruppare gli avvisi pertinenti in un numero inferiore di notifiche. Ciò è particolarmente importante se le notifiche vengono inviate ai primi soccorritori, come i tecnici di guardia, dove ricevere molte notifiche in un breve periodo di tempo può essere difficile e in alcuni casi può influire negativamente sulla capacità del primo soccorritore di rispondere a un incidente. Ad esempio, si consideri un'interruzione di corrente di grandi dimensioni in cui molti sistemi sono inattivi. In questo caso, il raggruppamento può fare la differenza tra ricevere 1 telefonata e 100 telefonate.
Puoi scegliere come raggruppare gli avvisi utilizzando l'opzione Raggruppa per in una politica di notifica. Per impostazione predefinita, le politiche di notifica in Grafana raggruppano gli avvisi per regola di avviso utilizzando le `grafana_folder` etichette `alertname` e (poiché i nomi degli avvisi non sono univoci in più cartelle). Se desideri raggruppare gli avvisi in base a qualcosa di diverso dalla regola di avviso, modifica il raggruppamento in base a qualsiasi altra combinazione di etichette.
#### Disabilita il raggruppamento
Se desideri ricevere ogni avviso come notifica separata, puoi farlo raggruppandoli in base a un'etichetta speciale chiamata. `...` Ciò è utile quando gli avvisi vengono inviati a un sistema automatizzato anziché a un primo soccorritore.
#### Un unico gruppo per tutti gli avvisi
Se desideri ricevere tutti gli avvisi insieme in un'unica notifica, puoi farlo lasciando vuoto il campo Raggruppa.
### Opzioni di temporizzazione
Le opzioni di tempistica determinano la frequenza di invio delle notifiche per ogni gruppo di avvisi. È necessario conoscere tre timer: Attesa di gruppo, Intervallo di gruppo e Intervallo di ripetizione.
#### Attesa di gruppo
L'attesa di gruppo è la quantità di tempo che Grafana attende prima di inviare la prima notifica per un nuovo gruppo di avvisi. Maggiore è l'attesa di gruppo, maggiore è il tempo a disposizione per l'arrivo di altri avvisi. Più breve è l'attesa di gruppo, tanto prima verrà inviata la prima notifica, ma con il rischio di inviare notifiche incomplete. Dovresti sempre scegliere un'attesa di gruppo più adatta al tuo caso d'uso.
**Impostazione predefinita**: 30 secondi
#### Intervallo di gruppo
Una volta inviata la prima notifica per un nuovo gruppo di avvisi, Grafana avvia il timer a intervalli di gruppo. Questo è il periodo di tempo che Grafana attende prima di inviare notifiche sulle modifiche al gruppo. Ad esempio, un altro avviso di attivazione potrebbe essere appena stato aggiunto al gruppo mentre un avviso esistente potrebbe essere stato risolto. Se un avviso è arrivato troppo tardi per essere incluso nella prima notifica a causa dell'attesa di gruppo, verrà incluso nelle notifiche successive dopo l'intervallo di gruppo. Una volta trascorso l'intervallo di gruppo, Grafana ripristina il timer degli intervalli di gruppo. Questo si ripete finché non ci sono più avvisi nel gruppo, dopodiché il gruppo viene eliminato.
**Impostazione predefinita**: 5 minuti
#### Intervallo di ripetizione
L'intervallo di ripetizione determina la frequenza con cui le notifiche vengono ripetute se il gruppo non è cambiato dall'ultima notifica. Puoi considerarle come promemoria del fatto che alcuni avvisi sono ancora attivi. L'intervallo di ripetizione è strettamente correlato all'intervallo di gruppo, il che significa che l'intervallo di ripetizione non deve essere solo maggiore o uguale all'intervallo di gruppo, ma deve anche essere un multiplo dell'intervallo di gruppo. Se l'intervallo di ripetizione non è un multiplo dell'intervallo di gruppo, verrà forzato a formare un unico intervallo. Ad esempio, se l'intervallo di ripetizione è di 5 minuti e l'intervallo di ripetizione è di 9 minuti, l'intervallo di ripetizione verrà arrotondato al multiplo di 5 più vicino, ovvero 10 minuti.
**Impostazione predefinita: 4 ore**