Notifiche

Gran parte della complessità del sistema di notifiche di Checkmk è dovuta alle sue numerose opzioni di configurazione, grazie alle quali è possibile evitare notifiche non importanti. Nella maggior parte dei casi si tratterà di situazioni in cui le notifiche vengono già ritardate o soppresse quando si verificano. Inoltre, il nucleo di monitoraggio dispone di un'intelligenza integrata che sopprime determinate notifiche per impostazione predefinita. In questo capitolo vorremmo affrontare tutti questi aspetti.

Quando un host o un servizio è in un periodo di tempo di manutenzione programmata, le notifiche dell'oggetto verranno soppresse. Questo è – insieme a una corretta valutazione delle disponibilità – il motivo più importante per l'effettiva previsione dei tempi di manutenzione programmati nel monitoraggio. A questo proposito sono rilevanti i seguenti dettagli:

Puoi definire un periodo di notifica per ogni host e servizio durante la configurazione. Si tratta di un periodo di tempo che definisce il periodo entro il quale la notifica deve essere limitata.

La configurazione viene eseguita utilizzando l'Monitoring Configuration > Notification period for hosts, o rispettivamente il set di regole Notification period for services, che puoi trovare rapidamente tramite la ricerca nel menu di configurazione. Un oggetto che non si trova attualmente in un periodo di notifica verrà contrassegnato con un simbolo di pausa grigia .

Gli eventi di monitoraggio relativi a un oggetto che non si trova attualmente nel suo periodo di notifica non verranno segnalati. Tali notifiche verranno "riemesse" quando il periodo di notifica sarà nuovamente attivo, se l'host/servizio si trova ancora in uno stato di problema. Verrà segnalato solo lo stato più recente, anche se durante il periodo al di fuori del periodo di notifica si sono verificati più cambiamenti nello stato dell'oggetto.

Per inciso, nelle regole di notifica è anche possibile limitare una notifica a un periodo di tempo specifico. In questo modo puoi limitare ulteriormente i periodi di tempo. Tuttavia, le notifiche che sono state scartate a causa di una regola con condizioni temporali non verranno automaticamente ripetute in seguito!

Se un host ha subito un guasto completo, o è almeno inaccessibile al monitoraggio, ovviamente i suoi servizi non possono più essere monitorati. Gli active checks registreranno quindi di norma "CRIT" o "SCONOSCIUTO", poiché questi tenteranno attivamente di accedere all'host e incontreranno così un errore. In una situazione del genere tutti gli altri controlli — quindi la grande maggioranza — saranno omessi e rimarranno quindi nel loro vecchio stato. Questi saranno contrassegnati con il simbolo dell'ora "stale" .

Sarebbe ovviamente molto fastidioso se tutti i controlli attivi in tale stato segnalassero i propri problemi. Ad esempio, se un server web non è raggiungibile – e questo è già stato segnalato – non sarebbe molto utile generare anche un'e-mail per ciascuno dei suoi servizi HTTP dipendenti.

Per ridurre al minimo queste situazioni, come principio di base il nucleo di monitoraggio genera notifiche per i servizi solo se l’host si trova nello stato “UP”. Questo è anche il motivo per cui l’accessibilità dell’host viene verificata separatamente. Se non diversamente configurato, questa verifica verrà effettuata con uno Smart Ping o un ping.

Se utilizzi la Comunità Checkmk (o una delle edizioni commerciali con un core Nagios), in casi isolati può comunque accadere che un problema dell'host generi una notifica per un servizio attivo. Il motivo è che Nagios considera i risultati dei controlli dell'host ancora validi per un breve periodo nel futuro. Se sono trascorsi anche solo pochi secondi tra l'ultimo ping riuscito al server e l'active check successivo, Nagios può ancora valutare l'host come "UP" anche se in realtà è "DOWN". Al contrario, il Checkmk Micro Core (CMC) manterrà la notifica del servizio in modalità "standby" fino a quando lo stato dello host non sarà stato verificato, riducendo così in modo affidabile le notifiche indesiderate.

Immagina che un importante router di rete di una sede aziendale con centinaia di host si guasti. Tutti i suoi host non saranno più disponibili per il monitoraggio e diventeranno DOWN. Verranno quindi attivate centinaia di notifiche. Non va bene.

Per evitare questi problemi, il router può essere definito come host padre per i suoi host. Se ci sono host ridondanti, si possono definire anche più host padre. Non appena tutti gli host padre entrano in uno stato "DOWN", gli host che non sono più raggiungibili verranno contrassegnati con lo stato "UNREACH" e le loro notifiche verranno soppresse. Il problema con il router stesso verrà ovviamente comunque segnalato.

A proposito, il CMC funziona internamente in modo leggermente diverso rispetto a Nagios. Per ridurre i falsi allarmi, ma continuare a elaborare le notifiche genuine, il CMC presta molta attenzione agli orari esatti dei controlli degli host in questione. Se un controllo dell'host fallisce, il core aspetterà il risultato del controllo sull'host padre prima di generare una notifica. Questa attesa è asincrona e non ha alcun effetto sul monitoraggio generale. Le notifiche provenienti dagli host possono quindi subire ritardi minimi.

Checkmk è configurato "di default" in modo tale che, quando si verifica un evento di monitoraggio, venga inviata un'e-mail di notifica a tutti i contatti relativi all'host o al servizio interessato. Questo è sicuramente sensato all'inizio, ma in pratica sorgono molte altre esigenze, ad esempio:

Checkmk ti offre la massima flessibilità nell'implementazione di tali requisiti tramite il suo meccanismo rule-based.

Nella configurazione delle notifiche, gestisci la catena di regole di notifica, che determina chi deve essere avvisato e in che modo. Quando si verifica un evento di monitoraggio, questa catena di regole viene eseguita dall'alto verso il basso. Ogni regola ha una condizione che decide se la regola si applica effettivamente alla situazione in questione.

Se la condizione è soddisfatta, la regola determina due cose:

Importante: a differenza delle regole per host e servizi, qui la valutazione continua anche dopo che la regola applicabile è stata soddisfatta. Le regole successive possono aggiungere ulteriori notifiche. Le notifiche generate dalle regole precedenti possono anche essere eliminate.

Il risultato finale della valutazione della regola sarà una tabella con una struttura simile a questa:

Ora, per ogni voce di questa tabella verrà richiamato lo script di notifica che esegue effettivamente la notifica per l'utente appropriata al metodo.

Potresti avere servizi che occasionalmente entrano in uno stato di problema per brevi periodi, ma le interruzioni sono molto brevi e non sono critiche per te. In questi casi le notifiche sono molto fastidiose, ma possono essere facilmente soppresse. I set di regole Delay host notifications e Delay service notifications servono proprio a questo.

Qui specifichi un tempo in minuti — e la notifica verrà ritardata fino allo scadere di questo tempo. Se lo stato OK / UP si verifica di nuovo prima di allora, non verrà attivata alcuna notifica. Naturalmente questo significa anche che la notifica di un problema reale verrà ritardata.

Ovviamente, ancora meglio che ritardare le notifiche sarebbe eliminare la causa effettiva dei problemi sporadici, ma questa è ovviamente un'altra storia...

Un altro metodo molto simile per ritardare le notifiche consiste nel consentire più tentativi di controllo quando un servizio entra in uno stato di problema. Ciò si ottiene con l'Maximum number of check attempts for hosts, o rispettivamente, con il set di regole Maximum number of check attempts for service.

Se qui imposti un valore di 3, ad esempio, un check con un risultato CRIT inizialmente non attiverà una notifica. Questo viene definito stato soft CRIT. Lo stato hard rimane OK. Solo se tre tentativi consecutivi restituiscono uno stato non OK, il servizio switcherà allo stato hard e verrà attivata una notifica.

A differenza delle notifiche ritardate, qui hai la possibilità di definire delle visualizzazioni in modo che tali problemi non vengano visualizzati. È anche possibile creare un'aggregazione BI in modo che vengano inclusi solo gli hard states, non quelli soft.

Quando un host o un servizio cambia frequentemente stato in un breve lasso di tempo, viene considerato irregolare. Si tratta di uno stato effettivo. Il principio qui è la riduzione delle notifiche eccessive durante le fasi in cui un servizio non funziona (del tutto) in modo stabile. Tali fasi possono anche essere valutate in modo specifico nelle statistiche di disponibilità.

Gli oggetti irregolari sono contrassegnati dal simbolo . Finché un oggetto è irregolare, i successivi cambiamenti di stato non attivano ulteriori notifiche. Una notifica verrà tuttavia attivata ogni volta che l'oggetto entra o esce dallo stato irregolare.

Il riconoscimento dell’irregolarità da parte del sistema può essere influenzato nei seguenti modi:

Visualizza l'aiuto contestuale di Help > Show inline help per i dettagli sui valori personalizzabili.

Per iniziare, ti mostreremo come effettuare la visualizzazione della cronologia delle notifiche a livello di host e di livello del servizio in Checkmk, in modo da poter seguire il processo di notifica.

Un evento di monitoraggio che induce Checkmk a generare una notifica è, ad esempio, il cambiamento di stato di un servizio. Puoi attivare manualmente questo cambiamento di stato con il comando Fake check results a scopo di test.

Per un test di notifica, puoi spostare un servizio dallo stato "OK" a "CRIT" in questo modo. Se ora visualizzi le notifiche per questo servizio nella pagina dei dettagli del servizio con Service > Service notifications , vedrai le seguenti voci:

La voce più recente si trova in cima all'elenco. Tuttavia, la prima voce si trova in fondo, quindi esaminiamo le singole voci dal basso verso l'alto:

Per aiutarti a capire bene il contesto di tutte le varie opzioni di impostazione e le condizioni di base, e per permetterti di capire bene il problema quando una notifica appare o non appare come previsto, qui descriveremo tutti i dettagli del processo di notifica, compresi tutti i componenti coinvolti.

I seguenti componenti sono coinvolti nel sistema di notifica di Checkmk:

Una volta che il core ha generato una notifica grezza, questa passa attraverso la catena delle regole di notifica, dando come risultato una tabella di notifiche. Oltre ai dati della notifica grezza, ogni notifica contiene le seguenti informazioni aggiuntive:

In una consegna sincrona, per ogni voce della tabella verrà ora eseguito uno script di notifica appropriato. In una consegna asincrona, una notifica verrà trasmessa come file allo spooler di notifica.

Una potente funzione aggiuntiva delle edizioni commerciali è lo spooler di notifica. Questo consente una consegna asincrona delle notifiche. Cosa significa asincrono in questo contesto?

Una consegna sincrona è quindi fattibile se lo script di notifica viene eseguito rapidamente e, soprattutto, non può portare a un timeout. Con i metodi di notifica che accedono a spooler esistenti, questo è scontato. I servizi di spool del sistema possono essere utilizzati in particolare con e-mail e SMS. Lo script di notifica passa un file allo spooler: con questa procedura non può verificarsi alcuno stato di attesa.

Quando si utilizza la consegna tracciabile tramite SMTP o altri script che stabiliscono connessioni di rete, è necessario ricorrere sempre alla consegna asincrona. Ciò vale anche per gli script che inviano messaggi di testo (SMS) tramite HTTP su internet. I timeout durante la creazione di una connessione a un servizio di rete possono durare anche diversi minuti, causando un ingorgo come descritto sopra.

La buona notizia è che la consegna asincrona è abilitata di default in Checkmk. Per prima cosa, lo spooler di notifica (mknotifyd) viene avviato anche all’avvio dell’istanza, cosa che puoi verificare con il seguente comando:

D'altra parte, la consegna asincrona (Asynchronous local delivery by notification spooler) è selezionata in Global settings > Notifications > Notification Spooling:

Il monitoraggio è utile solo quando ci si può fidare. Questo richiede che le notifiche vengano ricevute in modo affidabile e tempestivo. Purtroppo, però, la consegna delle e-mail non è proprio perfetta. L'invio viene solitamente gestito passando l'e-mail al server SMTP locale. Questo cerca di consegnare l'e-mail in modo autonomo e asincrono.

In caso di errore temporaneo (ad esempio, se il server SMTP di destinazione non è raggiungibile), l'e-mail viene messa in coda e più tardi verrà fatto un nuovo tentativo. Questo "più tardi" di solito è dopo 15-30 minuti. A quel punto la notifica potrebbe arrivare troppo tardi!

Se l'e-mail non può davvero essere consegnata, il server SMTP crea un bel messaggio di errore nel suo file di log e cerca di generare un'e-mail di errore al "mittente". Ma il sistema di monitoraggio non è un vero mittente e non può nemmeno ricevere e-mail. Ne consegue che tali errori semplicemente scompaiono e le notifiche quindi non arrivano.

Le edizioni commerciali offrono la possibilità di una consegna tracciabile tramite SMTP. Questo avviene intenzionalmente senza l’aiuto del server di posta locale. Invece Checkmk stesso invia l’e-mail al tuo smarthost tramite SMTP, e poi valuta direttamente la risposta SMTP.

In questo modo, non solo gli errori SMTP vengono gestiti in modo intelligente, ma viene anche documentata con precisione una consegna corretta. È un po' come una raccomandata: Checkmk riceve una ricevuta dallo smarthost SMTP (server di ricezione) che verifica che l'e-mail sia stata accettata, compreso un ID della mail.

Il processo pratico per configurare le notifiche con consegna tracciabile tramite SMTP è descritto nelle regole di notifica globali e nelle regole di notifica personali.

Una consegna sincrona che includa messaggi di errore e tracciabilità è stata finora implementata solo per le e-mail HTML. Come restituire uno stato di errore in uno script di notifica scritto da te lo trovi nel capitolo sulla scrittura dei tuoi script.

Le notifiche possono avvenire in modi diversi e personalizzati. Esempi tipici sono:

Per questo motivo Checkmk offre un'interfaccia molto semplice che ti permette di scrivere i tuoi script di notifica. Questi possono essere scritti in qualsiasi linguaggio di programmazione supportato da Linux, anche se Shell, Perl e Python insieme coprono il 95% del "mercato".

Gli script standard inclusi in Checkmk si trovano in ~/share/check_mk/notifications. Questa directory fa parte del software e non deve essere modificata. Salva invece i tuoi script in ~/local/share/check_mk/notifications. Assicurati che i tuoi script siano eseguibili (chmod +x). Verranno quindi individuati automaticamente e resi disponibili per la selezione nelle regole di notifica.

Se desideri personalizzare uno script standard, basta copiarlo da ~/share/check_mk/notifications a ~/local/share/check_mk/notifications e apportare le modifiche alla copia. Se mantieni il nome originale, il tuo script sostituirà automaticamente la versione standard e non sarà necessario apportare modifiche alle regole di notifica esistenti.

In caso di notifica, lo script verrà eseguito con i permessi dell'utente dell’istanza. Nelle variabili d'ambiente che iniziano con NOTIFY_, lo script riceverà tutte le informazioni relative all'host/servizio interessato, all'evento di monitoraggio, ai contatti da avvisare e ai parametri specificati nella regola di notifica.

I testi che lo script scrive sull'output standard (con print, echo, ecc.) compaiono nel file di log del modulo di notifica ~/var/log/notify.log.

Gli script di notifica hanno la possibilità di utilizzare un codice di uscita per comunicare se si è verificato un errore replicabile o definitivo:

Inoltre, in tutti i casi l'output standard dello script di notifica, insieme allo stato, verrà inserito nella cronologia delle notifiche dell'host/servizio e sarà quindi visibile nella GUI.

Importante: le notifiche tracciabili non sono disponibili per le notifiche di massa!

Il trattamento degli errori di notifica dal punto di vista dell'utente verrà spiegato nel capitolo sulla consegna tracciabile tramite SMTP.

Come esempio puoi creare uno script che scriva tutte le informazioni relative alla notifica in un file. Il linguaggio di programmazione è la shell Bash di Linux:

Quindi rendi lo script eseguibile:

Ecco un paio di spiegazioni relative allo script:

Affinché lo script venga utilizzato, devi definirlo come metodo in una regola di notifica. Gli script scritti in proprio non hanno una dichiarazione dei parametri, quindi mancheranno tutte le checkbox come quelle offerte, ad esempio, nel metodo HTML Email. Invece puoi inserire un elenco di testi come parametri che possono essere disponibili come NOTIFY_PARAMETER_1, NOTIFY_PARAMETER_2, ecc. per lo script. Per un test, fornisci i parametri Fröhn, Klabuster e Feinbein:

Ora, per eseguire il test, imposta il servizio CPU load sull'host myserver su CRIT — con il comando Fake check results. Nel file di log del modulo di notifica ~/var/log/notify.log vedrai quindi l'esecuzione dello script, inclusi i parametri e il file di spool generato.:

Il file ~/tmp/foobar.out conterrà ora un elenco alfabetico di tutte le variabili d'ambiente di Checkmk che includono informazioni relative alla notifica. Qui puoi orientarti per capire quali valori sono disponibili per il tuo script. Ecco le prime dieci righe:

I parametri si possono trovare anche qui:

Nell'esempio sopra hai visto una serie di variabili d'ambiente che verranno passate allo script. Quali variabili siano disponibili dipende dal tipo di notifica, dalla versione e dall'edizione di Checkmk e dal nucleo di monitoraggio utilizzato (CMC o Nagios). Oltre al trucchetto con il comando env, ci sono altri due modi per ottenere un elenco completo di tutte le variabili:

Di seguito trovi un elenco delle variabili più importanti:

Se il tuo script deve supportare le notifiche di massa, dovrà essere preparato in modo specifico, poiché lo script deve inviare più notifiche contemporaneamente. Per questo motivo, anche l'invio tramite variabili d'ambiente non funziona in modo pratico.

Assegna un nome al tuo script nella terza riga dell'intestazione come di seguito — il modulo di notifica invierà quindi le notifiche tramite l'input standard:

Attraverso l'input standard lo script riceverà blocchi di variabili. Ogni riga ha la forma: NAME=VALUE. I blocchi sono separati da righe vuote. Il carattere ASCII con codice 1 (\a) viene utilizzato per rappresentare i caratteri di nuova riga all'interno del testo.

Il primo blocco contiene un elenco di variabili generali (ad es. parametri di chiamata). Ogni blocco successivo assembla le variabili in una notifica.

Il consiglio migliore è di provarlo tu stesso con un semplice test che scriva i dati completi in un file, in modo da poter vedere come vengono inviati i dati. A questo scopo puoi utilizzare il seguente script di notifica:

Prova lo script come descritto sopra e attiva anche l'opzione "Notification Bulking" nella regola di notifica.

Nella versione standard, Checkmk fornisce già una vasta gamma di script per effettuare le connessioni ai servizi di messaggistica istantanea più diffusi e utilizzati, alle piattaforme di gestione degli incidenti e ai sistemi di ticket. Puoi scoprire come utilizzare questi script nei seguenti articoli:

I file di log del server SMTP sono file di sistema e i loro percorsi assoluti sono elencati qui sotto. La posizione esatta in cui sono memorizzati i file di log dipenderà dalla tua distribuzione Linux.