Politiche di notifica - Grafana gestito da Amazon

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à.

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

Per le aree di lavoro Grafana che supportano la versione 8.x di Grafana, vedere. Funzionamento in Grafana versione 8

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, consultaCome funziona l'abbinamento delle etichette.

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.

Ecco un'analisi dettagliata di come vengono selezionate queste politiche:

Pod stuck in CrashLoop non ha un'severityetichetta, quindi nessuna delle sue politiche per bambini corrisponde. Ha un'team=operationsetichetta, 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'severityetichetta che corrisponde a una politica secondaria del team operativo.

La voce di registro non autorizzata ha un'teametichetta 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=highetichetta 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.

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