Configurazione delle notifiche tramite regole

Sul lato sinistro della pagina viene visualizzata una panoramica dello stato attuale delle notifiche:

Vengono visualizzati:

A destra delle visualizzazioni di stato troverai i link a tutte le regole di notifica esistenti in Checkmk:

Da qui puoi accedere alle regole per ottimizzare le tue notifiche e a tutte le altre regole relative alle notifiche.

L'ultima parte della pagina di panoramica è costituita dalla regola globale esistente.

Se hai appena effettuato l'installazione di Checkmk, sarà stata predefinita esattamente una regola:

Tale regola è strutturata come segue:

Come al solito, puoi modificare la regola , clonarla , eliminarla o crearne una nuova. Una volta che hai più di una regola, puoi modificarne l'ordine di elaborazione trascinandole con il simbolo .

Nella configurazione predefinita di Checkmk, un utente riceverà notifiche via e-mail quando saranno soddisfatti i seguenti prerequisiti:

Per poter inviare correttamente le e-mail, il tuo server Checkmk deve avere una configurazione del server SMTP funzionante. A seconda della tua distribuzione Linux, questa potrebbe utilizzare, ad esempio, Postfix, Qmail, Exim o Nullmailer. La configurazione verrà implementata con le risorse della tua distribuzione Linux.

La configurazione si limita generalmente alla registrazione di uno "smarthost" (noto anche come server di inoltro SMTP) a cui verranno indirizzate tutte le e-mail. Questo sarà quindi il server di posta SMTP interno della tua azienda. Di norma gli smarthost non richiedono l’autenticazione in una LAN, il che semplifica le cose. In alcune distribuzioni lo smarthost verrà richiesto durante l’installazione. Con l’appliance Checkmk è possibile configurare comodamente lo smarthost tramite l’interfaccia web.

Puoi testare facilmente l'invio delle e-mail con il comando mail dalla riga di comando. Poiché esistono numerose implementazioni diverse di questo comando su Linux, per motivi di standardizzazione Checkmk fornisce la versione del progetto Heirloom mailx direttamente nel percorso di ricerca dell'utente dell’istanza (come ~/bin/mail). Il file di configurazione corrispondente è ~/etc/mail.rc. Il modo migliore per testarlo è come utente dell’istanza, poiché gli script di notifica verranno successivamente eseguiti con gli stessi permessi.

Il contenuto dell'e-mail viene letto dall'input standard, l'oggetto specificato con -s e l'indirizzo del destinatario semplicemente aggiunto come argomento alla fine della riga di comando:

L'e-mail dovrebbe essere recapitata senza ritardi. Se questo non funziona, puoi trovare informazioni nel file di log del server SMTP nella directory /var/log (vedi File e directory).

L'indirizzo e-mail e i gruppi di contatto di un utente sono definiti nell'amministrazione utenti:

In un'istanza Checkmk appena generata, inizialmente è presente solo il gruppo di contatto Everything. I membri di questo gruppo sono automaticamente responsabili di tutti gli host e i servizi e riceveranno una notifica via e-mail per ogni evento di monitoraggio rilevante.

Invece che via e-mail o SMS, puoi anche inviare notifiche a un sistema di ticket (come Jira o ServiceNow), a un servizio di messaggistica (Slack, Mattermost) o a un motore di eventi (Console degli Eventi).

Per ciascuno di questi casi speciali esiste un metodo di notifica separato, che può essere selezionato nella regola di notifica. Tuttavia, quando crei la regola devi tenere presente i seguenti due punti:

Quando invii e-mail HTML, potresti voler aggiungere informazioni aggiuntive o definire in modo flessibile un indirizzo di risposta (Reply to) a un contatto specifico per eventuali domande. A questo scopo, c'è la regola "Setup > Notifications > Parameters for notification methods > HTML Email" e, nelle regole di notifica, il metodo di notifica via e-mail HTML. Con queste regole puoi aggiungere una serie di parametri come l'indirizzo di risposta, campi aggiuntivi con dettagli o testo libero formattato in HTML.

Tieni presente che nel campo Custom HTML section (e.g. title, description…), per motivi di sicurezza, è consentito solo un numero limitato di tag HTML. Questi sono:

Come sempre con tutte le regole in Checkmk, è possibile un'applicazione molto dettagliata, in modo da poter personalizzare una serie dettagliata di notifiche per host e servizi secondo necessità.

Per facilitare la creazione delle regole per le notifiche, l'interfaccia di Checkmk in questa sezione è diversa da quella a cui sei abituato in altre aree. Con l'opzione "Setup > Events > Notifications > Add notification rule" puoi iniziare a creare le notifiche:

Ora dovrai prendere una decisione.

Se selezioni "Guided mode,", verrai guidato, sezione per sezione, attraverso la creazione di una regola di notifica. Ogni sezione tratta specificamente un aspetto della notifica. Compila la rispettiva sezione con i dati rilevanti per il tuo ambiente. Le descrizioni dei singoli temi sono disponibili più avanti in questo articolo. Una volta modificata una sezione, clicca su "Next step…​". I tuoi dati verranno quindi verificati, a condizione che siano tecnicamente obbligatori. Se, ad esempio, mancano dati tecnicamente rilevanti come l'indirizzo e-mail da utilizzare, riceverai un messaggio di errore. Una volta inseriti correttamente i dati di base essenziali, verrai reindirizzato alla sezione successiva e infine alla fine, dove avrai preparato una regola di notifica completa. Completa quindi la creazione con "Apply & test notification rule" o "Apply & create another rule".

In alternativa, puoi utilizzare l’Overview mode. Questo è particolarmente utile per la modifica mirata di singoli parametri in una regola di notifica esistente — allo stesso modo se hai già molta familiarità con la creazione delle regole e non desideri più essere guidato. In Overview mode vedi tutte le sezioni di modifica contemporaneamente e puoi modificare direttamente tutti i campi e le opzioni. La verifica tecnica viene quindi eseguita una sola volta e su tutte le sezioni non appena clicchi su Apply & test notification rule o Apply & create another rule.

Di seguito presentiamo la struttura generale delle regole di notifica con le definizioni di condizioni, tipi di evento, filtri, metodi di notifica, contatti e proprietà generali.

Puoi definire parametri separati per ogni metodo di notifica. Questi parametri vengono definiti e gestiti separatamente dalle regole di notifica effettive in Checkmk. Questo ti permette di utilizzare i parametri per più regole contemporaneamente. Devi solo apportare eventuali modifiche centralmente in un unico posto e otterrai un aspetto uniforme per tutte le notifiche dello stesso tipo, indipendentemente dalle regole di attivazione.

Apri la panoramica di tutti i parametri personalizzabili tramite Setup > Events > Notifications e il pulsante Parameters for notifications methods:

Da qui puoi creare, modificare e — se non sono utilizzati in nessuna regola — eliminare i parametri generali per ciascun metodo.

Per testare le regole di notifica, Checkmk offre uno strumento intelligente con Test notifications. Puoi usarlo per simulare una notifica per un host o un servizio e capire quali delle tue regole di notifica sono efficaci. Oltre alla simulazione, puoi anche far inviare la notifica.

Il modo più veloce per accedere al test di notifica è tramite Setup > Events > Test notifications. Inoltre, ci sono altre opzioni per richiamarlo da alcune visualizzazioni in Monitoraggio (elenco dei servizi e dettagli del servizio) e in Setup (proprietà dell'host), in ogni caso nel menu Host > Test notifications.

Per prima cosa, clicca su uno dei due pulsanti per decidere se la notifica è per un Host o un Service. Poi seleziona quale host o servizio deve essere. Come evento puoi selezionare un cambiamento di stato o l'inizio di un periodo di tempo di manutenzione programmata. Puoi aggiungere una descrizione dell'evento a Plugin output. Usa la checkbox Send out notification for specific method per specificare se la notifica è solo simulata o effettivamente inviata.

Infine, sotto "Advanced condition simulation" ci sono altre due opzioni con cui puoi definire l'ora e il numero di notifiche. Questo ti permette di testare regole di notifica che si applicano solo in un determinato periodo di tempo (ad es. fuori dall'orario di lavoro) o che avviano un'escalation dopo un numero specificato di notifiche ripetute.

Clicca su "Test notifications" per avviare il test — e anche l'invio, se hai selezionato questa opzione. I risultati vengono visualizzati sotto la box "Test notifications":

Per prima cosa viene visualizzato il riepilogo. Sotto "Test results" puoi vedere quante regole di notifica si applicano e quante notifiche ne derivano. Se hai selezionato "Invia notifica", qui viene visualizzato il messaggio di notifications have been sent out corrispondente. Questo deve quindi portare immediatamente all'invio di un'e-mail relativa a questo problema.

La riga sottostante riassume le notifiche generate dai tuoi inserimenti. Cliccando sul simbolo "", puoi visualizzare il contesto della notifica. Questo ti permette di vedere le variabili d'ambiente e i loro valori validi nel contesto di questa notifica.

Le due sezioni seguenti mostrano poi ulteriori dettagli:

Sotto "Predicted notifications" puoi vedere a chi e come verrebbero inviate le notifiche. Riceverai queste informazioni anche sulla simulazione se non hai selezionato l'invio della notifica.

Sotto "Global notification rules" c'è un elenco delle regole di notifica che hai creato qui. A questo punto, è importante solo la prima colonna della tabella, che usa dei simboli per indicare quali regole si applicano e quali no .

Per alcuni sistemi, può avere senso non affidarsi a una singola notifica quando un problema persiste per un periodo di tempo più lungo, ad esempio per gli host il cui tag host Criticality è impostato su Business critical.

Come già accennato nella selezione del metodo di notifica, troverai anche l'opzione di selezione "Suppress all previous". Per capire come funziona una regola del genere, è meglio visualizzare la tabella delle notifiche. Supponendo che l'elaborazione delle regole per un evento di monitoraggio concreto sia parzialmente completata e che, a causa di una serie di regole, siano state attivate le seguenti tre notifiche:

Ora arriva una nuova regola con il metodo "SMS" e la selezione "Suppress all previous". La selezione dei contatti sceglie il gruppo di contatto "Windows", di cui Bruno Weizenkeim fa parte. Come risultato di questa regola, la voce "Bruno Weizenkeim / SMS" viene rimossa dalla tabella, che ora appare così:

Se una regola successiva dovesse definire nuovamente una notifica SMS per Bruno, questa regola avrà la priorità e l'SMS verrà aggiunto nuovamente alla tabella.

Riassumendo:

Puoi selezionare e configurare la consegna tracciabile tramite SMTP per il metodo di notifica e-mail HTML inserendo lo smarthost (con nome e numero di porta), i dati di accesso e il metodo di crittografia:

Nella cronologia del servizio in questione, potrai quindi tracciare la consegna con precisione. Ecco un esempio in cui un servizio — a scopo di test — è stato impostato manualmente su CRIT. Lo screenshot qui sotto mostra le notifiche per questo servizio, che puoi visualizzare nella pagina dei dettagli del servizio all’indirizzo Service > Service Notifications:

Qui vedrai i quattro singoli passaggi in ordine cronologico dal basso verso l’alto, così come li abbiamo già presentati nel capitolo sulla cronologia delle notifiche nell’articolo sulle nozioni di base sulle notifiche. La differenza importante è che ora puoi vedere nella voce più in alto di che l’e-mail è stata consegnata con successo allo smarthost e la sua risposta è success.

Puoi anche seguire i singoli passaggi nel file ~/var/log/notify.log. Le righe seguenti appartengono all'ultimo passaggio e contengono la risposta del server SMTP:

L'ID del messaggio 1BE667EE7D6 apparirà nel file di log dello smarthost. Lì, se ti interessa, puoi verificare dove è finita l'e-mail. In ogni caso puoi dimostrare che l'e-mail è stata inviata correttamente da Checkmk e quando.

Ripetiamo il test di cui sopra, ma questa volta con una password configurata in modo errato per il trasferimento SMTP allo smarthost. Qui puoi vedere in chiaro il messaggio di errore SMTP Error: authentication failed proveniente dallo smarthost:

Cosa si può fare in caso di notifiche fallite? Anche in questo caso, la notifica via e-mail non sembra essere una buona soluzione. Invece Checkmk mostra un chiaro avviso con sfondo rosso nello snap-in Panoramica:

Qui puoi:

Importante: tieni presente che la consegna diretta tramite SMTP in caso di errore può causare l'esecuzione dello script di notifica per un tempo molto lungo e portare a un timeout. Per questo motivo ti consigliamo vivamente di utilizzare lo spooler di notifica e di selezionare una consegna asincrona delle notifiche.

Il comportamento in caso di errori ripetibili (come un timeout SMTP) può essere definito con Global settings > Notifications > Notification spooler configuration per ogni metodo di notifica:

Oltre a un timeout opzionale (il valore predefinito è 1 minuto) e a un numero massimo di tentativi, è possibile definire anche se lo script può essere eseguito più volte in parallelo e quindi inviare più notifiche (Maximum concurrent executions). Se lo script di notifica è molto lento, un'esecuzione in parallelo può avere senso — tuttavia lo script deve essere programmato in modo tale che le esecuzioni multiple funzionino correttamente (e, ad esempio, che lo script non riservi determinati dati per sé stesso).

Un invio multiplo e parallelo tramite SMTP non presenta problemi, poiché il server di destinazione è in grado di gestire più connessioni parallele. Questo non è certamente il caso quando si invia direttamente tramite SMS tramite un modem senza uno spooler aggiuntivo, e in questo caso è consigliabile mantenere l'impostazione 1.

Importante: la consegna tracciabile tramite SMTP non è disponibile per le notifiche di massa!

Chiunque si occupi di monitoraggio ha sicuramente sperimentato come un singolo problema possa scatenare una vera e propria valanga di notifiche (successive). Il principio degli host padre è un modo per ridurre queste notifiche in circostanze specifiche, ma purtroppo non è efficace in tutti i casi.

Puoi prendere un esempio dallo stesso progetto Checkmk: Una volta al giorno creiamo i pacchetti di installazione di Checkmk per ogni distribuzione Linux supportata. Il nostro monitoraggio Checkmk è configurato in modo tale da avere un servizio che entra in stato "OK" solo se il numero corretto di pacchetti è stato creato correttamente. Può capitare occasionalmente che un errore generale nel software ostacoli la creazione dei pacchetti, causando l'entrata simultanea di 43 servizi nello stato "CRIT".

Abbiamo configurato le notifiche in modo tale che, in un caso del genere, venga inviata una sola e-mail che contiene l'elenco delle 43 notifiche in sequenza. Questo è ovviamente più chiaro rispetto a 43 e-mail singole e riduce anche il rischio che, "nel pieno della battaglia", si perda la 44ª e-mail relativa a un problema completamente diverso.

Il funzionamento di questa notifica di massa è molto semplice. Quando si verifica una notifica, inizialmente verrà trattenuta per un breve periodo. Le notifiche successive che si verificano durante questo periodo verranno immediatamente aggiunte alla stessa e-mail. Questa raccolta può essere definita per ogni regola. Quindi, ad esempio, durante il giorno puoi operare con e-mail singole, ma durante la notte con una notifica di massa. Se viene attivata una notifica di massa, ti verranno generalmente offerte le seguenti opzioni:

Il tempo di attesa può essere configurato a piacere. In molti casi è sufficiente un minuto, poiché entro quel momento dovrebbero essere comparsi tutti i problemi correlati. Ovviamente puoi impostare un tempo più lungo, ma ciò comporterà un ritardo sostanziale nelle notifiche.

Dato che ovviamente non ha senso mettere tutto nello stesso calderone, puoi specificare quali gruppi di problemi devono essere notificati collettivamente. L'opzione "Host" è molto usata: garantisce che vengano raggruppate solo le notifiche provenienti dallo stesso host.

Ecco alcune informazioni aggiuntive sulle notifiche di massa:

Cosa succede quando una notifica rientra nel periodo di notifica, ma la notifica di massa che contiene questa notifica – e che arriva un po' più tardi – è fuori dal periodo di notifica? È possibile anche la situazione opposta…​

Qui si applica un principio molto semplice: tutte le configurazioni che limitano le notifiche a determinati periodi di tempo sono valide solo per la notifica effettiva. La successiva notifica di massa verrà sempre recapitata indipendentemente da tutti i periodi di tempo.