Notifiche

Nella configurazione predefinita di Checkmk, un utente riceve notifiche via e-mail quando sono soddisfatti i seguenti prerequisiti:

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

In genere la configurazione si limita alla registrazione di uno "smarthost" (noto anche come server SMTP relay) a cui verranno indirizzate tutte le e-mail. Questo sarà il server SMTP interno della tua azienda. Di regola gli smarthost non richiedono l'autenticazione in una LAN, il che semplifica le cose. In alcune distribuzioni lo smarthost viene interrogato durante l'installazione. Con l'appliance Checkmk è possibile configurare lo smarthost comodamente tramite l'interfaccia web.

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

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

L'e-mail dovrebbe essere consegnata senza ritardi. Se 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 il gruppo di contatto di un utente sono definiti nell'amministrazione dell'utente:

In un'istanza Checkmk appena creata, inizialmente esiste 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 di ogni evento di monitoraggio rilevante.

Nota: se la tua installazione di Checkmk è stata generata con una versione precedente, questo gruppo potrebbe anche chiamarsi Everybody. Ciò è tuttavia illogico, poiché questo gruppo non contiene tutti gli utenti, bensì tutti gli host. A parte i nomi diversi, la funzione è la stessa.

Invece di e-mail o SMS, puoi inviare notifiche a un sistema di ticket (come Jira o ServiceNow), a un messenger (Slack, Mattermost) o a un motore di eventi (Console degli Eventi). Esiste un metodo di notifica separato per ognuno di questi casi speciali, che può essere selezionato nella regola di notifica. Tuttavia, devi tenere presente i due punti seguenti quando crei la regola:

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 riconoscere quali regole di notifica sono efficaci. Oltre alla simulazione, puoi anche inviare una notifica e-mail.

Il modo più rapido per accedere al test di notifica è tramite Setup > Events > Notifications e il pulsante Test notifications. Inoltre, ci sono altre opzioni di chiamata da alcune visualizzazioni nel Monitoraggio (elenco dei servizi e dettagli dei servizi) e nel Menu di configurazione (proprietà degli 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. Puoi aggiungere una descrizione del servizio a Plugin output. Come evento puoi selezionare un cambiamento di stato o l'inizio di un tempo di manutenzione programmato. Usa il checkbox Send out HTML/ASCII email notification according to notification rules per specificare se la notifica è solo simulata o effettivamente inviata.

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

Clicca su Test notifications per avviare il test e anche l'invio dell'e-mail, se hai selezionato questa opzione. La finestra di dialogo Test notifications viene nascosta e vengono mostrati i risultati:

Sotto Analysis results puoi vedere quante regole di notifica si applicano e quante notifiche ne derivano. Se hai selezionato Invia notifica, viene visualizzato il messaggio corrispondente Notifications have been sent. Questo deve portare immediatamente a un'e-mail per questo problema.

La riga sottostante riassume le notifiche generate dalle tue voci. Cliccando sul simbolo, puoi visualizzare il contesto della notifica, che ti permette di vedere le variabili d'ambiente e i loro valori validi nel contesto di questa notifica.

Le due sezioni successive mostrano ulteriori dettagli:

In Resulting notifications puoi vedere a chi e come vengono inviate le notifiche. Riceverai queste informazioni sulla simulazione anche se non hai selezionato l'invio della notifica.

In Global notification rules sono elencate le regole di notifica, presentate in modo più dettagliato nel prossimo capitolo. A questo punto, è importante solo la prima colonna della tabella, che utilizza dei simboli per indicare quali regole si applicano e quali no. Nell'esempio, la prima regola non si applica perché valuta i cambiamenti di stato degli host, ma l'evento è un cambiamento di stato di un servizio.

Quando invii un'e-mail HTML, potresti voler aggiungere informazioni aggiuntive o definire in modo flessibile un indirizzo e-mail di risposta (Reply to) a un contatto specifico per qualsiasi domanda. A questo scopo, esiste la regola Setup > Services > Service monitoring rules > Parameters for HTML Email e nelle regole di notifica il metodo di notifica dell'e-mail HTML. Con queste regole puoi aggiungere una serie di parametri come l'indirizzo e-mail di risposta, campi aggiuntivi con dettagli o testo libero formattato come HTML.

Nota che nel campo Add HTML section above table (e.g. title, description…​), per motivi di sicurezza, sono consentiti solo una piccola serie di tag HTML, che sono:

Come di consueto con tutte le regole di Checkmk, è possibile un'applicazione a grana molto fine, in modo da poter personalizzare un set dettagliato di notifiche agli host e ai servizi a seconda delle esigenze.

Checkmk è configurato "di default" in modo che quando si verifica un evento di monitoraggio venga inviata un'e-mail di notifica a tutti i contatti dell'host o del servizio interessato. Questo è certamente ragionevole all'inizio, ma nella pratica sorgono molti altri requisiti, ad esempio:

Checkmk ti offre la massima flessibilità nell'implementazione di tali requisiti grazie al suo meccanismo rule-based. Accedi alla configurazione con Setup > Events > Notifications.

Nota: quando richiami la pagina Notification configuration per la prima volta, vedrai un avviso relativo all '"indirizzo e-mail di riserva" non configurato. Per il momento puoi ignorare questo avviso. Approfondiremo l'argomento più avanti.

Nella configurazione delle notifiche, gestisci la catena di regole di notifica che determinano chi deve essere avvisato e come. Quando si verifica un evento di monitoraggio, questa catena di regole viene percorsa da cima a fondo. 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, in questo caso la valutazione continua anche dopo che la regola di notifica applicabile è stata soddisfatta. Le regole successive possono aggiungere altre notifiche. Le notifiche generate dalle regole precedenti possono anche essere eliminate.

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

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

Se hai una Checkmk appena installata, è stata predefinita una regola:

Questa regola definisce il comportamento predefinito sopra descritto. È strutturata come segue:

Come al solito, puoi modificare la regola, clonarla (copiarla), eliminarla o crearne una nuova. Una volta che hai più di una regola, puoi cambiare il loro ordine di elaborazione trascinandole con il simbolo.

Nota: le modifiche alle regole di notifica non richiedono l'attivazione delle modifiche, ma hanno effetto immediato.

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

Come già accennato nella selezione del metodo di notifica, troverai anche l'opzione di selezione Cancel previous notifications. Per poter comprendere il funzionamento di una regola di questo tipo, è meglio visivamente visualizzare la tabella delle notifiche. Supponendo che il processo delle regole per un evento concreto di monitoraggio sia parzialmente completato e che a causa di una serie di regole siano state attivate le seguenti tre notifiche:

Ora viene applicata una regola successiva con il metodo SMS e la selezione Cancel previous notifications. La selezione del contatto sceglie il gruppo 'Windows', di cui fa parte Bruno Weizenkeim. Come risultato di questa regola, la voce 'Bruno Weizenkeim / SMS' viene rimossa dalla tabella, che appare così:

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

Per riassumere:

Chi configura può anche commettere degli errori. Un possibile errore nella configurazione delle notifiche potrebbe essere quello di scoprire un problema di monitoraggio critico, ma di non applicare nessuna regola di notifica.

Per proteggerti da questa eventualità, Checkmk offre l'impostazione Fallback email address for notifications che si trova sotto Setup > General > Global settings nella sezione Notifications. Inserisci qui un indirizzo e-mail che riceverà le notifiche per le quali non si applica alcuna regola di notifica.

Nota: in alternativa, puoi anche rendere un utente il destinatario nelle sue impostazioni personali. L'indirizzo e-mail memorizzato con l'utente viene utilizzato come indirizzo di riserva.

Tuttavia, l'indirizzo di riserva sarà utilizzato solo se non si applica alcuna regola di notifica, non quando non è stata attivata alcuna notifica! Come abbiamo mostrato nel capitolo precedente, la soppressione esplicita delle notifiche è voluta, non è un errore di configurazione.

L'inserimento di un indirizzo di ripiego sarà "consigliato" nella pagina Notification configuration con un avviso sullo schermo:

Se, per qualsiasi motivo, vuoi eliminare l'avviso, ma allo stesso tempo non vuoi ricevere e-mail all'indirizzo di riserva, inserisci comunque un indirizzo di riserva e poi crea una nuova regola come prima regola, che cancella tutte le notifiche precedenti. Questa regola non ha effetto sulla configurazione delle notifiche, in quanto non sono ancora state create notifiche. Tuttavia, in questo modo puoi assicurarti che almeno una regola venga sempre applicata, permettendo così di eliminare l'avviso.

Ti sconsigliamo esplicitamente di adottare questo approccio, in quanto potresti perdere delle lacune nella catena di regole.

Una funzione utile del sistema di notifiche di Checkmk è quella che permette agli utenti - anche senza diritti di amministratore - di personalizzare le notifiche. Gli utenti possono:

Il punto di accesso dal punto di vista dell'utente è il menu Utente, dove si trova la voce Notification rules. Nella pagina Your personal notification rules è possibile creare una nuova regola con Add rule.

Le regole personalizzate sono strutturate come le regole normali, con una differenza: non contengono la selezione di un contatto. L'utente stesso viene automaticamente selezionato come contatto. Questo significa che l'utente può aggiungere o eliminare notifiche solo per se stesso.

Tuttavia, l'utente può eliminare le notifiche solo se l'opzione allow users to deactivate this notification è attivata nella regola di notifica che le crea:

Nell'ordine delle regole di notifica, le regole personalizzate vengono sempre dopo le regole globali e quindi possono modificare la tabella delle notifiche che è stata generata fino a quel momento. Quindi, ad eccezione del blocco dell'eliminazione appena descritto, le regole globali sono sempre valide come impostazione predefinita che può essere personalizzata dall'utente.

Se vuoi impedire del tutto la personalizzazione, puoi revocare il permesso General Permissions > Edit personal notification settings del ruolo user.

Come amministratore, puoi visualizzare tutte le regole utente se nel menu selezioni Display > Show user rules:

Dopo le regole globali, vengono elencate le regole utente, che puoi anche modificare con .

La disattivazione completa delle notifiche da parte di un utente è protetta dal permesso General Permissions > Disable all personal notifications, che per impostazione predefinita è impostato su no per il ruolo utente user. Un utente vedrà i checkbox corrispondenti nelle sue impostazioni personali solo se assegnerai esplicitamente questo diritto al ruolo user:

In qualità di amministratore con accesso alle impostazioni personali dell'utente, puoi eseguire azioni di disabilitazione per conto dell'utente, anche se il permesso descritto sopra non è presente. Puoi trovare questa impostazione alla voce Setup > Users > Users e poi nelle proprietà del profilo dell'utente. In questo modo, ad esempio, puoi silenziare molto rapidamente le notifiche di un collega in vacanza, senza dover modificare la configurazione attuale.

Gran parte della complessità del sistema di notifiche di Checkmk è dovuta alle sue numerose opzioni di regolazione, con le quali è possibile evitare le notifiche non importanti. La maggior parte di queste situazioni è costituita da situazioni in cui le notifiche vengono già ritardate o soppresse quando si verificano. Inoltre, il nucleo di monitoraggio IT ha un'intelligenza integrata che sopprime alcune notifiche per impostazione predefinita. In questo capitolo vorremmo affrontare tutti questi aspetti.

Quando un host o un servizio si trova in un periodo di inattività programmata, le notifiche dell'oggetto vengono soppresse. Questo è, insieme alla corretta valutazione delle disponibilità, il motivo più importante per cui il tempo di manutenzione programmata è previsto nel monitoraggio. I dettagli seguenti sono rilevanti a questo proposito:

Durante la configurazione puoi definire un periodo di notifica per ogni host e servizio. Si tratta di un periodo di tempo che definisce l'arco temporale entro il quale la notifica deve essere limitata.

La configurazione viene eseguita utilizzando il sito 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 al momento in un periodo di notifica sarà contrassegnato da un simbolo grigio di pausa.

Gli eventi di monitoraggio per un oggetto che non si trova nel periodo di notifica non verranno notificati. Tali notifiche verranno "riemesse" quando il periodo di notifica sarà di nuovo attivo - se l'host/servizio si trova ancora in uno stato problematico. Verrà notificato solo lo stato più recente, anche se si sono verificate più modifiche allo stato dell'oggetto durante il periodo di tempo al di fuori del periodo di notifica.

Tra l'altro, 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 di notifica con condizioni temporali non verranno automaticamente ripetute in seguito!

Se un host è completamente fallito, o comunque inaccessibile al monitoraggio, ovviamente i suoi servizi non possono più essere monitorati. Icheck attivi registreranno di regola CRIT o SCONOSCIUTO, poiché questi tenteranno attivamente di accedere all'host e quindi incorreranno in un errore. In questa situazione, tutti gli altri check - quindi la maggior parte - saranno omessi e rimarranno nel loro vecchio stato di monitoraggio. Questi saranno contrassegnati dal simbolo stale time.

Sarebbe naturalmente molto complicato se tutti i check attivi in questo stato dovessero notificare i loro problemi: ad esempio, se un server web non è raggiungibile - e questo è già stato notificato - non sarebbe molto utile generare un'e-mail per tutti i servizi HTTP che ne dipendono.

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 della verifica UP. Questo è anche il motivo per cui l'accessibilità dell'host viene verificata separatamente. Se non è configurato diversamente, questa verifica viene effettuata con uno Smart Ping o un ping.

Se utilizzi Checkmk Raw (o una delle edizioni commerciali con 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 come ancora validi per un breve periodo di tempo nel futuro. Se sono trascorsi anche solo pochi secondi tra l'ultimo ping riuscito al server e il successivo active check, 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 alla verifica dello stato dell'host, riducendo così in modo affidabile le notifiche indesiderate.

Immagina che un importante router di rete di un'azienda con centinaia di host si guasti: tutti i suoi host non saranno disponibili per il monitoraggio e diventeranno DOWN. Si attiveranno quindi centinaia di notifiche. Non è una buona cosa.

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ù genitori. Non appena tutti i genitori entrano in uno stato DOWN, gli host che non sono più raggiungibili saranno contrassegnati con lo stato NON RAGGIUNGIBILE e le loro notifiche saranno soppresse. Il problema del router stesso sarà ovviamente notificato.

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

Con i set di regole Enable/disable notifications for hosts o Enable/disable notifications for services puoi specificare host e servizi per i quali in generale non devono essere emesse notifiche. Come già detto, il core sopprime le notifiche. Una regola di notifica successiva che "sottoscrive" le notifiche per questi servizi sarà inefficace, in quanto le notifiche non verranno semplicemente generate.

È anche possibile disabilitare temporaneamente le notifiche per singoli host o servizi tramite un comando.

Tuttavia, questo richiede che il permesso Commands on host and services > Enable/disable notifications sia assegnato al ruolo dell'utente. Per impostazione predefinita, questo non avviene per nessun ruolo.

Con il permesso assegnato, puoi disabilitare (e successivamente abilitare) le notifiche di host e servizi con il comando Commands > Notifications:

Tali host o servizi saranno contrassegnati da un simbolo.

Poiché i comandi, a differenza delle regole, non richiedono né permessi di configurazione né l'attivazione di modifiche, possono essere una soluzione rapida per reagire prontamente a una situazione.

Importante: a differenza dei tempi di inattività programmati, le notifiche disabilitate non hanno alcuna influenza sulle valutazioni di disponibilità. Se durante un'interruzione non programmata vuoi davvero solo disabilitare le notifiche senza voler alterare le statistiche di disponibilità, non devi registrare un tempo di manutenzione programmata!

Nello snap-in Master control nella barra laterale troverai uno switch master per Notifications:

Questo switch è incredibilmente utile se hai intenzione di apportare grandi modifiche al sistema, durante le quali un errore potrebbe costringere molti servizi in uno stato CRIT. Puoi usare questo switch per evitare di turbare i tuoi colleghi con una marea di e-mail inutili. Ricordati di riattivare le notifiche quando hai finito.

Ogni sito di un monitoraggio distribuito dispone di uno di questi switch. Disattivando le notifiche del sito centrale, i siti remoti possono comunque attivare le notifiche, anche se queste sono dirette e consegnate dal sito centrale.

Importante: le notifiche che sarebbero state attivate durante il periodo in cui le notifiche sono state disabilitate non saranno ripetute in seguito quando saranno riattivate.

Può capitare di avere servizi che occasionalmente entrano in uno stato problematico per brevi periodi, ma le interruzioni sono molto brevi e non sono critiche per l'utente. 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 a questa situazione.

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

Ovviamente, ancora meglio del ritardo delle notifiche sarebbe l'eliminazione della causa effettiva dei problemi sporadici, ma questa è ovviamente un'altra storia...

Un altro metodo molto simile per ritardare le notifiche è quello di consentire più tentativi di controllo quando un servizio entra in uno stato problematico. Questo si ottiene con il set di regole Maximum number of check attempts for hosts o, rispettivamente, Maximum number of check attempts for service.

Se ad esempio imposti un valore di riferimento di 3, un controllo con risultato CRIT inizialmente non farà scattare una notifica. Questo viene definito stato soft CRIT. Lo stato hard rimane OK. Solo se tre tentativi successivi restituiscono uno stato non OK, il servizio passa allo stato hard e scatta una notifica.

A differenza delle notifiche ritardate, in questo caso hai la possibilità di definire delle visualizzazioni in modo che questi problemi non vengano visualizzati. Un'aggregazione BI può anche essere costruita in modo da includere solo gli stati hard e non quelli soft.

Quando un host o un servizio cambia frequentemente il suo stato in un breve lasso di tempo, viene considerato irregolare. Si tratta di uno stato vero e proprio. Il principio è quello di ridurre le notifiche eccessive durante le fasi in cui un servizio non funziona (del tutto) in modo stabile. Tali fasi possono essere valutate in modo particolare nelle statistiche di disponibilità.

Gli oggetti irregolari sono contrassegnati da un simbolo. Finché un oggetto è irregolare, i successivi cambiamenti di stato non attivano ulteriori notifiche. Tuttavia, una notifica viene attivata ogni volta che l'oggetto entra o esce dallo stato irregolare.

Il riconoscimento dell'irregolare da parte del sistema può essere influenzato nei seguenti modi:

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

Per alcuni sistemi, può avere senso non limitarsi 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.

Per iniziare, ti mostreremo come visualizzare la cronologia delle notifiche a livello del servizio e dell'host in Checkmk per poter seguire il processo di notifica.

Un evento di monitoraggio che fa scattare una notifica in Checkmk è, ad esempio, il cambiamento di stato di un servizio. Puoi scatenare 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 di questo servizio nella pagina dei dettagli del servizio con Service > Service Notifications, vedrai le seguenti voci:

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

Per aiutare a comprendere correttamente il contesto delle varie opzioni di impostazione e delle condizioni di base e per consentire una diagnosi accurata dei problemi quando una notifica appare o non appare come previsto, qui descriveremo tutti i dettagli del processo di notifica, compresi tutti i componenti coinvolti.

Nota: la cronologia delle notifiche che abbiamo mostrato sopra per un servizio può essere visualizzata anche per un host: nella pagina dei dettagli dell'host nel menu Host per l'host stesso (voce di menuNotifications of host ) e anche per l'host con tutti i suoi servizi (Notifications of host & services).

Il sistema di notifica di Checkmk coinvolge i seguenti componenti:

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

In caso di consegna sincrona, per ogni voce della tabella verrà eseguito uno script di notifica appropriato. In caso di consegna asincrona, la notifica verrà passata come file allo spooler di notifica.

Una potente funzione aggiuntiva delle edizioni commerciali è lo spooler di notifica, che permette di inviare le notifiche in modo asincrono. Cosa significa asincrono in questo contesto?

La consegna sincrona è possibile se lo script di notifica viene eseguito rapidamente e soprattutto non può causare timeout. Con i metodi di notifica che accedono agli spooler esistenti, questo è un dato di fatto. I servizi di spool del sistema possono essere utilizzati in particolare con le e-mail e gli SMS. Lo script di notifica passa un file di spool allo spooler: con questa procedura non può verificarsi alcuno stato di attesa.

Quando utilizzi la consegna tracciabile via SMTP o altri script che stabiliscono connessioni di rete, dovresti sempre utilizzare la consegna asincrona. Questo vale anche per gli script che inviano messaggi di testo (SMS) via HTTP su internet. I timeout durante la creazione di una connessione a un servizio di rete possono durare fino a diversi minuti, causando l'inceppamento descritto sopra.

La buona notizia è che l'invio asincrono è abilitato per impostazione predefinita in Checkmk. Da un lato, lo spooler di notifica (mknotifyd) viene avviato all'avvio dell'istanza Checkmk, 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:

A tutti coloro che lavorano con il monitoraggio è capitato di avere un problema isolato che ha scatenato una vera e propria marea di notifiche (successive). Il principio degli host padre è un modo per ridurle in determinate circostanze, ma purtroppo non è utile in tutti i casi.

Puoi prendere esempio dal progetto Checkmk stesso: una volta al giorno creiamo i pacchetti di installazione di Checkmk per ogni distribuzione Linux supportata. Il nostro stato di monitoraggio di Checkmk è impostato in modo tale da avere un servizio che è OK solo se il numero giusto di pacchetti è stato costruito correttamente. A volte può succedere che un errore generale nel software ostacoli l'impacchettamento, causando il passaggio simultaneo di 43 servizi in uno stato CRIT.

Abbiamo configurato le notifiche in modo tale che, in questo caso, venga inviata un'unica e-mail che elenca tutte le 43 notifiche in sequenza. Questo è naturalmente più chiaro di 43 e-mail singole e riduce anche il rischio che "nella foga della battaglia" si perda una 44esima e-mail relativa a un altro problema.

La modalità di funzionamento di questa notifica di massa è molto semplice. Quando si verifica una notifica, in un primo momento questa viene trattenuta per un breve periodo di tempo. Le notifiche successive che si verificano durante questo lasso di tempo vengono immediatamente aggiunte alla stessa e-mail. Questa raccolta può essere definita per ogni regola di notifica. 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, in genere ti verranno offerte le seguenti opzioni:

Il tempo di attesa può essere configurato a piacimento. In molti casi è sufficiente un minuto, in quanto al più tardi a quell'ora dovrebbero essere comparsi tutti i problemi relativi. Naturalmente puoi impostare un tempo più lungo, ma questo comporterà un ritardo fondamentale nelle notifiche.

Dato che naturalmente non ha senso buttare tutto in un unico piatto, puoi specificare quali gruppi di problemi devono essere notificati collettivamente. L'opzione Host è molto utilizzata: in questo modo si 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 la contiene - e che arriva un po' più tardi - non rientra nel periodo di notifica? È possibile anche la situazione inversa...

In questo caso si applica un principio molto semplice: tutte le configurazioni che limitano le notifiche a periodi di tempo sono valide solo per la notifica vera e propria. La successiva notifica di massa sarà sempre consegnata indipendentemente da tutti i periodi di tempo.

Il monitoraggio è utile solo se si può fare affidamento su di esso. Ciò richiede che le notifiche intelligenti vengano ricevute in modo affidabile e tempestivo. Purtroppo, però, la consegna delle e-mail non è del tutto ideale. L'invio viene solitamente processato passando l'e-mail al server SMTP locale, che tenta di consegnarla in modo autonomo e asincrono.

In caso di errore temporaneo (ad es. se il server SMTP ricevente non è raggiungibile) l'e-mail viene messa in coda e in seguito viene effettuato un nuovo tentativo. Questo "in seguito" avviene di regola dopo 15-30 minuti. A quel punto la notifica potrebbe essere troppo tardi!

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

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

Le edizioni commerciali offrono la possibilità di effettuare una consegna tracciabile tramite SMTP, senza l'aiuto del server Checkmk locale: Checkmk stesso invia l'e-mail al tuo smarthost tramite SMTP e poi valuta la risposta SMTP.

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

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

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

Qui vedrai i quattro singoli passaggi nella sequenza cronologica dal basso verso l'alto, come li abbiamo già presentati nel capitolo sulla cronologia delle notifiche. La differenza importante è che ora puoi vedere nella voce più in alto che l'e-mail è stata consegnata con successo allo smarthost e la sua risposta è success.

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

Il Message-ID 1BE667EE7D6 apparirà nel file di log dello smarthost. In questo modo, se sei preoccupato, potrai verificare dove è arrivata l'e-mail. In ogni caso potrai dimostrare che, e quando, l'e-mail è stata inviata correttamente da Checkmk.

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

Cosa si può fare per le notifiche fallite? Anche in questo caso, la notifica via e-mail non sembra essere una buona soluzione, ma Checkmk mostra un chiaro avviso con sfondo rosso nella panoramica:

Qui puoi:

Importante: Nota che l'invio diretto tramite SMTP in caso di errore può portare lo script di notifica ad essere eseguito per molto tempo e a causare un timeout. Per questo motivo ti consigliamo di utilizzare lo spooler di notifica e di selezionare un invio asincrono delle notifiche.

La condotta con errori ripetibili (come un timeout SMTP) può essere definita con Global settings > Notifications > Notification spooler configuration per metodo di notifica:

Oltre a un timeout opzionale (il valore predefinito è di 1 minuto) e a un numero massimo di tentativi, si può anche definire 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, l'esecuzione in parallelo può avere senso, ma lo script deve essere programmato in modo che le esecuzioni multiple avvengano in modo pulito (e, ad esempio, che lo script non riservi alcuni dati per sé).

Una consegna multipla e parallela tramite SMTP non presenta problemi, poiché il server di destinazione è in grado di gestire più connessioni parallele. Questo non è certamente il caso quando si consegna direttamente da SMS tramite un modem senza uno spooler aggiuntivo, e in questo caso è necessario attenersi all'impostazione 1.

Finora la consegna sincrona con messaggi di errore e tracciabilità è stata implementata solo per le e-mail HTML. Per sapere come restituire uno stato di errore in uno script di notifica scritto da te, consulta il capitolo sulla scrittura dei tuoi script.

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

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

Gli script standard inclusi in Checkmk si trovano in ~/share/check_mk/notifications. Questa directory è un componente 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 trovati automaticamente e resi disponibili per la selezione nelle regole di notifica.

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

Altri script di esempio sono inclusi nel software all'indirizzo ~/share/doc/check_mk/treasures/notifications. Puoi utilizzarli come modelli per la personalizzazione. In genere la configurazione avviene direttamente nello script: nei commenti troverai suggerimenti in merito.

Nel caso di una notifica, lo script verrà richiamato con i permessi dell'utente dell'istanza. Nelle variabili d'ambiente(quelle che iniziano con NOTIFY_), riceverà tutte le informazioni sull'host/servizio interessato, l'evento di monitoraggio, i contatti da avvisare e i parametri specificati nella regola di notifica.

I testi che lo script di notifica scrive sullo standard output (con print, echo, ecc.) vengono visualizzati 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 o del 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 sarà spiegato nel capitolo sulla consegna tracciabile via SMTP.

Come esempio puoi creare uno script che scrive tutte le informazioni sulla notifica in un file. Il linguaggio di codifica è la shell Linux Bash:

Quindi rendi lo script eseguibile:

Ecco un paio di spiegazioni sullo 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 tutti i checkbox come quelli offerti, ad esempio, nel metodo HTML Email, saranno assenti. Invece puoi inserire un elenco di testi come parametri che possono essere disponibili come NOTIFY_PARAMETER_1, NOTIFY_PARAMETER_2, ecc. Per un test fornisci i parametri Fröhn, Klabuster e Feinbein:

Per fare un 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 l'esecuzione dello script, compresi 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 sui valori disponibili per il tuo script di notifica. Ecco le prime dieci righe:

Si possono trovare anche i parametri:

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

Di seguito è riportato un elenco delle variabili più importanti:

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

Dai un nome allo script di notifica nella terza riga dell'intestazione, come indicato di seguito: il modulo di notifica invierà le notifiche attraverso lo standard input:

Attraverso lo standard input lo script riceverà blocchi di variabili. Ogni riga ha il modulo: NAME=VALUE. I blocchi sono separati da righe vuote. Il carattere ASCII con il codice 1 (\a) viene utilizzato per rappresentare le linee nuove all'interno del testo.

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

Il consiglio migliore è quello di provare tu stesso con un semplice test che scriva i dati completi su 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 di notifica come descritto sopra e attiva anche il sito Notification Bulking nella regola di notifica.

Checkmk fornisce già una serie di script per la connessione a servizi di messaggistica istantanea, piattaforme di gestione degli incidenti e sistemi di ticket molto diffusi. 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 di seguito. La posizione esatta dei file di log dipende dalla tua distribuzione Linux.