Console degli Eventi

Come sempre in Checkmk, devi prima attivare le modifiche affinché diventino effettive. Questo non è uno svantaggio perché in questo modo, per le modifiche che riguardano diverse regole correlate, puoi specificare esattamente quando le regole devono essere "live". E prima puoi usare il sito Event Simulator per verificare che tutto funzioni come previsto.

Per prima cosa, clicca sul numero di modifiche accumulate in alto a destra della pagina.

Poi clicca su Activate on selected sites per attivare le modifiche. La Console degli Eventi è progettata in modo tale che questa azione venga eseguita senza interruzioni. La ricezione dei messaggi in arrivo è garantita in ogni momento, in modo che nessun messaggio vada perso durante il processo.

Solo gli amministratori sono autorizzati ad attivare le modifiche nella Console eventi. Questo viene controllato tramite il permesso Activate changes for event console.

Per i test potresti ovviamente inviare messaggi tramite syslog o SNMP. Dovresti farlo anche in seguito, ma per un primo test è più pratico l'integrato Event Simulator di EC:

Qui hai due opzioni:Try out valuta sulla base del messaggio simulato quale delle regole corrisponderebbe. Se ti trovi nel livello superiore della GUI, i pacchetti di regole saranno evidenziati. Se ti trovi all'interno di un pacchetto di regole, le singole regole sono evidenziate. Ogni pacchetto o regola è contrassegnato da uno dei tre simboli seguenti:

Facendo clic su Generate event si ottiene quasi la stessa cosa di Try out, solo che ora il messaggio viene effettivamente generato.Tutte le azioni definite vengono effettivamente eseguite e l'evento viene visualizzato anche tra gli eventi aperti del monitoraggio. Puoi vedere il codice sorgente del messaggio generato nella conferma:

L'evento generato appare nel menu Monitor alla voce Event Console > Events:

Per un primo test reale sulla rete, puoi facilmente inviare un messaggio syslog da un altro computer Linux a mano. Dato che il protocollo è così semplice, non hai nemmeno bisogno di un programma speciale: puoi semplicemente inviare i dati tramite netcat o nc utilizzando UDP. Il contenuto del pacchetto UDP consiste in una singola riga di testo. Se questo è conforme a una struttura specifica, la Console degli Eventi scompone i componenti in modo pulito:

Ma puoi anche inviare qualsiasi cosa: la CE la accetterà comunque e la valuterà come testo di un messaggio. Naturalmente mancheranno informazioni aggiuntive come l'applicazione, la priorità, ecc. Per motivi di sicurezza verrà assunto lo stato CRIT:

All'interno dell'istanza Checkmk che esegue l'EC c'è una pipe denominata, nella quale puoi scrivere messaggi di testo localmente tramite echo. Questo è un metodo molto semplice per la connessione di un'applicazione locale e anche un modo per testare il processo dei messaggi:

A proposito, è anche possibile inviare messaggi in formato syslog, in modo che tutti i campi dei dati dell'evento siano compilati in modo pulito.

Il comando Update & Acknowledge visualizza la seguente area sopra l'elenco degli eventi:

Con il pulsante Update puoi aggiungere in un'unica azione un commento all'evento, aggiungere un contatto e confermare l'evento. Il campo Change contact è intenzionalmente a testo libero. Qui puoi inserire anche cose come numeri di telefono. In particolare, questo campo non ha alcuna influenza sulla visibilità dell'evento nella GUI: è solo un campo di commento.

Il checkbox Set event to acknowledged fa sì che l'evento passi dalla fase open alla fase acknowledged e che d'ora in poi venga visualizzato come handled. Questo è analogo alla conferma dei problemi dell'host e del servizio.

Una successiva invocazione del comando con il checkbox deselezionato rimuove la conferma.

Il comando Change State permette di cambiare manualmente lo stato di un evento, ad es. da CRIT a WARN.

Con il comando Custom Action è possibile eseguire azioni liberamente definibili sugli eventi. Inizialmente è disponibile solo l'azione Send monitoring notification, che invia una notifica Checkmk che sarà gestita allo stesso modo di una notifica proveniente da un servizio di monitoraggio attivo. Questa passa attraverso le regole di notifica e può generare e-mail, un SMS o qualsiasi altra cosa tu abbia configurato di conseguenza. Vedi sotto per i dettagli sulla notifica da parte della CE.

Il pulsante Archive Event rimuove in modo permanente un evento dall'elenco degli eventi aperti. Poiché tutte le azioni sugli eventi - compresa questa cancellazione - vengono registrate anche nell'archivio, sarai ancora in grado di accedere in seguito a tutte le informazioni sull'evento. Ecco perché non si parla di cancellazione, ma di archiviazione.

Puoi anche archiviare comodamente i singoli eventi dall'elenco degli eventi utilizzando .

Per garantire la visibilità degli host e dei servizi nel monitoraggio per gli utenti normali, Checkmk utilizza i gruppi di contatto, che vengono assegnati agli host e ai servizi attraverso la configurazione della GUI, delle regole o delle cartelle.

Con la Console degli Eventi, questa assegnazione di eventi ai gruppi di contatto non esiste, perché semplicemente non si sa in anticipo quali messaggi verranno effettivamente ricevuti. Non si conosce nemmeno l'elenco degli host, perché i socket per syslog e SNMP sono accessibili da ogni parte. Per questo motivo, la Console degli Eventi include alcune funzioni speciali per definire la visibilità.

Prima di tutto, quando si configurano i ruoli utente c'è il permesso Event Console > See all events. Questo è attivo per configurazione predefinita, in modo che gli utenti normali possano vedere tutti gli eventi!Questo è stato deliberatamente impostato per garantire che importanti messaggi di errore non cadano nel dimenticatoio a causa di una configurazione errata. Il primo passo per una visibilità più precisa è rimuovere questo permesso dal ruolo user.

Per garantire che la visibilità degli eventi sia il più possibile coerente con il resto del monitoraggio, la Console degli Eventi cerca il più possibile di far corrispondere gli host da cui riceve gli eventi a quelli configurati tramite la GUI di Setup. Ciò che sembra semplice è complicato nei dettagli. A volte il nome host non è presente nell'evento e si conosce solo l'indirizzo IP. In altri casi il nome host è scritto in modo diverso da quello presente nella GUI di Setup.

L'assegnazione avviene come segue:

Puoi influenzare l'assegnazione in un punto: in particolare, se i gruppi di contatto sono definiti nella regola e l' host può essere assegnato, la mappatura ha solitamente la priorità. Puoi cambiare questo aspetto in una regola con l'opzione Precedence of contact groups:

Inoltre, puoi impostare le regole di notifica direttamente nella regola: in questo modo è possibile dare priorità al tipo di evento rispetto alle normali responsabilità di un host.

Sia per i pacchetti di regole...

... sia per le singole regole ...

... nella colonna Hits troverai le informazioni sulla frequenza con cui il pacchetto o la regola ha già trovato un matching con un messaggio. Questo ti aiuta a eliminare o a riparare le regole inefficaci. Ma può essere interessante anche per le regole che hanno un matching molto frequente. Per ottenere prestazioni ottimali dall'EC, queste dovrebbero essere all'inizio della catena di regole. In questo modo puoi ridurre il numero di regole che l'EC deve testare per ogni messaggio.

Puoi azzerare i contatori in qualsiasi momento con la voce di menu Event Console > Reset counters.

In Prova una regola hai già visto come utilizzare Event Simulator per verificare la valutazione delle tue regole. Puoi ottenere informazioni simili nel tempo di esecuzione per tutti i messaggi, se nelle impostazioni della Console degli Eventi imposti il valore da Debug rule execution a on.

Il file di log della Console degli Eventi si trova all'indirizzo var/log/mkeventd.log, in cui troverai il motivo esatto per cui una regola verificata non ha avuto effetto:

Va da sé che dovresti usare questo tipo di log intensivo solo quando necessario e con cautela: in un ambiente solo leggermente più complesso verranno generati enormi volumi di dati!

Per tutte le condizioni che coinvolgono campi di testo, il testo di confronto viene sempre trattato come un'espressione regolare. Il confronto avviene sempre ignorando le maiuscole e le minuscole. Quest'ultima è un'eccezione alle convenzioni di Checkmk in altri moduli. Tuttavia, questo rende la formulazione delle regole più robusta, soprattutto perché i nomi host negli eventi non sono necessariamente coerenti nella loro ortografia se sono stati configurati su ogni host localmente piuttosto che centralmente. Questa eccezione è quindi molto utile in questo caso.

Inoltre, si applica sempre un match parziale, cioè un controllo del contenuto del testo di ricerca, per cui puoi salvare un .* all'inizio o alla fine del testo di ricerca.

C'è però un'eccezione: se nella corrispondenza con il nome host non viene utilizzata un'espressione regolare, ma un nome host esplicito, verrà verificata la corrispondenza esatta e non il contenuto.

Attenzione: Se il testo di ricerca contiene un punto (.), sarà considerato un'espressione regolare e si applicherà la ricerca parziale, ad esempio myhost.com corrisponderà anche a notmyhostide!

Molto importante e utile è il concetto di gruppi di corrispondenza nel campo Text to match. Si tratta delle sezioni di testo che corrispondono alle espressioni parentetiche dell'espressione regolare.

Supponiamo che tu voglia monitorare il seguente tipo di messaggio nel file di log di un database:

Il campo WP41 è ovviamente variabile e sicuramente non vuoi formulare una regola separata per ogni istanza diversa. Per questo motivo, nell'espressione regolare utilizzi .*, che sta per qualsiasi stringa:

Database instance .* has failed

Se ora racchiudi la parte variabile tra parentesi tonde, la Console degli Eventi memorizzerà(catturerà) il valore effettivo per qualsiasi azione futura:

Database instance (.*) has failed

Dopo che la regola ha avuto successo, il primo gruppo di corrispondenza è ora impostato sul valore WP41 (o sull'istanza che ha prodotto l'errore).

Puoi vedere questi gruppi di corrispondenza nel sito Event Simulator se sposti il cursore sul pallino verde:

Puoi vedere i gruppi anche nei dettagli dell'evento generato:

Tra le altre cose, i gruppi di corrispondenza sono utilizzati per:

A questo punto, un consiglio: ci sono situazioni in cui devi raggruppare qualcosa nell'espressione regolare ma non vuoi creare un gruppo di corrispondenza. Puoi farlo inserendo un ?: direttamente dopo la parentesi di apertura. Esempio: L'espressione one (.*) two (?:.*) three crea per una corrispondenza su one 123 two 456 three solo il gruppo di corrispondenza 123.

Nel campo Match original source IP address puoi abbinare l'indirizzo IPv4 del mittente del messaggio. Specifica un indirizzo esatto o una rete nella notazione X.X.X.X/Y, ad es. 192.168.8.0/24 corrisponde a tutti gli indirizzi della rete 192.168.8.X.

Nota che la corrispondenza con l'indirizzo IP funziona solo se i sistemi di monitoraggio IT inviano direttamente alla Console degli Eventi. Se un altro server syslog intermedio connesso inoltra i messaggi, il suo indirizzo apparirà come mittente nel messaggio.

I campi Match syslog priority e Match syslog facility sono informazioni standardizzate, originariamente definite dalle informazioni syslog. Internamente, un campo a 8 bit è diviso in 5 bit per la struttura (32 possibilità) e 3 bit per la priorità (8 possibilità).

Le 32 strutture predefinite erano un tempo destinate a qualcosa come un'applicazione, ma all'epoca la selezione non era molto lungimirante. Una delle strutture è uucp, un protocollo che all'inizio degli anni '90 dello scorso millennio era già quasi obsoleto.

Ma è un dato di fatto che ogni messaggio che arriva via syslog porta con sé una di queste strutture. In alcuni casi puoi anche assegnarle liberamente al momento dell'invio del messaggio, in modo da poterle filtrare in un secondo momento, il che è molto utile.

L'uso di strutture e priorità ha anche un aspetto legato alle prestazioni. Se definisci una regola che in ogni caso si applica solo ai messaggi che hanno tutti la stessa struttura o priorità, dovresti definirli anche nei filtri della regola. La Console degli Eventi può quindi bypassare queste regole in modo molto efficiente quando viene ricevuto un messaggio con valori diversi. Più regole sono impostate su questi filtri, meno confronti tra le regole sono necessari.

Il checkbox Negate match: Execute this rule if the upper conditions are not fulfilled. fa sì che la regola abbia effetto solo quando nessuna delle condizioni è soddisfatta. In realtà questo è utile solo nel contesto di due tipi di regola (Rule type nel box Outcome & Action della regola):

Puoi trovare maggiori informazioni sui pacchetti di regole qui di seguito.

Quando una regola corrisponde, specifica cosa deve accadere con il messaggio. Questo viene fatto nel box Outcome & Action:

Il box Rule type può essere utilizzato per interrompere la valutazione del punto o per il pacchetto di regole corrente. In particolare, la prima opzione dovrebbe essere utilizzata per eliminare la maggior parte del "rumore" inutile utilizzando alcune regole specifiche all'inizio. Solo con le regole "normali" le altre opzioni di questo box vengono effettivamente valutate.

Con State la regola imposta lo stato dell'evento di monitoraggio. Nella regola questo stato sarà WARN o CRIT. Le regole che generano eventi OK possono essere interessanti in eccezione per rappresentare alcuni eventi in modo puramente informativo. In questo caso è interessante una combinazione con una scadenza automatica di questi eventi.

Oltre all'impostazione di uno stato esplicito, esistono altre due opzioni dinamiche. L'impostazione (set by syslog) si occupa della classificazione in base alla priorità del syslog. Questo funziona solo se il messaggio è già stato classificato in modo utilizzabile dal mittente. I messaggi ricevuti direttamente dal syslog conterranno una delle otto priorità RFC, mappate come segue:

Oltre ai messaggi syslog, i messaggi del registro eventi di Windows e i messaggi dei file di log che sono già stati classificati con il plug-in Checkmk logwatch sul sistema di destinazione, forniscono degli stati già pronti. Per le SNMP trap questo purtroppo non è disponibile.

Un metodo completamente diverso è quello di classificare il messaggio in base al testo stesso. Questo può essere fatto con l'impostazione (set by message text):

La corrispondenza con i testi configurati avviene solo dopo aver verificato la presenza di Text to match e delle altre condizioni della regola, in modo da non dover ripetere i controlli.

Se non viene trovato nessuno dei modelli configurati, l'evento restituisce lo stato SCONOSCIUTO.

L'idea alla base del campo Service Level è che ogni host e ogni servizio di un'organizzazione abbia un certo livello di importanza, che può essere associato a un contratto di servizio specifico per l'host o il servizio. In Checkmk, puoi usare delle regole per assegnare tali livelli del servizio ai tuoi host e servizi e poi, ad esempio, far dipendere da essi le regole di notifica o i dashboard autodefiniti.

Poiché gli eventi non sono necessariamente correlati agli host o ai servizi, la Console degli Eventi ti permette di assegnare un livello del servizio a un evento utilizzando una regola. In seguito potrai filtrare le visualizzazioni degli eventi in base a questo livello.

Per impostazione predefinita, Checkmk definisce quattro livelli: 0 (nessun livello), 10 (argento), 20 (oro) e 30 (platino). Puoi modificare questa selezione in base alle tue esigenze nel sito Global settings > Notifications > Service Levels. Sono decisivi i numeri per la progettazione dei livelli, poiché i livelli vengono ordinati in base a questi numeri e confrontati anche in base all'importanza relativa.

I gruppi di contatto utilizzati per la visibilità saranno utilizzati anche per la notifica degli eventi. Qui puoi utilizzare delle regole per assegnare esplicitamente i gruppi di contatto agli eventi. I dettagli si trovano nel capitolo dedicato al monitoraggio.

Le azioni sono molto simili ai gestori di avvisi per host e servizi. Qui puoi far eseguire uno script autodefinito all'apertura di un evento. I dettagli completi sulla descrizione delle azioni si trovano in una sezione separata.

La cancellazione automatica (= archiviazione), che puoi impostare con Delete event immediately after the actions, fa sì che un evento non sia mai visibile nel monitoraggio. Questo è utile se vuoi attivare automaticamente solo alcune azioni o se vuoi archiviare solo alcuni eventi per poterli cercare in seguito.

Puoi anche fare in modo che le azioni vengano eseguite automaticamente quando un evento viene eliminato. È importante sapere che quando un evento viene eliminato, alcuni campi dell'evento vengono sovrascritti dai valori del messaggio OK prima che venga eseguita qualsiasi azione. In questo modo, i dati completi del messaggio OK sono disponibili nello script dell'azione. Inoltre, durante questa fase lo stato dell'evento viene contrassegnato come OK. In questo modo uno script dell'azione può rilevare un'eliminazione e puoi utilizzare lo stesso script per i messaggi di errore e OK (es. durante la connessione a un sistema di ticket).

I seguenti campi vengono sovrascritti dai dati del messaggio OK:

Tutti gli altri campi rimangono invariati, compreso l'ID dell'evento.

Se utilizzi la riscrittura e l'annullamento nella stessa regola di eliminazione, devi fare attenzione alla riscrittura del nome host o dell'applicazione. Quando si annulla, la CE controlla sempre se il messaggio di annullamento corrisponde al nome host e all'applicazione dell'evento aperto. Se questi vengono riscritti, l'annullamento non funzionerà mai.

Per questo motivo, prima di eliminare l'evento, la Console degli Eventi simula una riscrittura del nome host e dell'applicazione per confrontare i testi pertinenti. Probabilmente è quello che ti aspetti.

Puoi anche approfittare di questo comportamento se il campo dell'applicazione nel messaggio di errore e nel successivo messaggio OK non corrispondono. In questo caso, riscrivi semplicemente il campo dell'applicazione con un valore fisso noto. In questo modo, infatti, il campo verrà ignorato.

Ci sono (purtroppo) situazioni in cui il testo dei messaggi di errore e di OK è assolutamente identico. Nella maggior parte dei casi lo stato effettivo non è codificato nel testo, ma nella priorità del syslog.

A questo scopo esiste l'opzione Syslog priority to cancel event. Inserisci ad esempio l'intervallo debug... notice. Tutte le priorità in questo intervallo sono normalmente considerate come aventi uno stato OK. Quando utilizzi questa opzione devi comunque inserire un testo adeguato nel campo Text to cancel event(s), altrimenti la regola corrisponderà a tutti i messaggi OK che riguardano la stessa applicazione.

Puoi attivare il controllo dei messaggi che si verificano troppo spesso con l'opzione Count messages in interval:

In questo caso, devi prima specificare un periodo di tempo all'indirizzo Time period for counting e il numero di messaggi che dovrebbero portare all'apertura di un evento all'indirizzo Count until triggered. Nell'esempio precedente, questo è impostato su 10 messaggi all'ora. Naturalmente non si tratta di 10 messaggi arbitrari, ma di messaggi che vengono abbinati alla regola.

Normalmente ha senso non contare tutti i messaggi corrispondenti a livello globale, ma solo quelli che si riferiscono alla stessa "causa". Per controllare questo aspetto, ci sono i tre checkbox per le opzioni con l'inizio parola (prefisso) Force separate events for different …​. Questi sono preimpostati in modo tale che i messaggi vengano contati insieme solo se corrispondono in:

Questo ti permette di formulare regole come "Se vengono ricevuti più di 10 messaggi all'ora dallo stesso host, dalla stessa applicazione e dallo stesso sito, allora...". A causa della regola, possono essere generati più eventi diversi.

Se, ad esempio, deselezioni tutti e tre i checkbox, il conteggio verrà effettuato solo a livello globale e la regola sarà in grado di generare un solo evento in totale!

A proposito, può essere utile inserire 1 come conteggio: in questo modo potrai controllare efficacemente le "tempeste di eventi". Se, ad esempio, in un breve lasso di tempo vengono ricevuti 100 messaggi dello stesso tipo, verrà comunque creato un solo evento. Nei dettagli dell'evento potrai vedere

Quando il caso viene chiuso, tramite due checkbox puoi definire quando deve essere aperto un nuovo evento. Normalmente la conferma dell'evento crea una situazione per cui se vengono ricevuti altri messaggi, viene avviato un nuovo conteggio e si attiva un nuovo evento. Puoi disabilitare questa funzione con Continue counting when event is acknowledged.

L'opzione Discontinue counting after time has elapsed assicura che venga sempre aperto un evento separato per ogni periodo di confronto. Nell'esempio precedente è stata specificata una soglia di 10 messaggi all'ora. Se questa opzione è attivata, un massimo di 10 messaggi di un'ora verrà aggiunto a un evento già aperto. Non appena l'ora è trascorsa, se è stato ricevuto un numero sufficiente di messaggi verrà aperto un nuovo evento.

Ad esempio, se imposti il numero a 1 e l'intervallo di tempo a un giorno, vedrai al massimo un evento di questo tipo di messaggio al giorno.

L'impostazione di Algorithm può essere un po' sorprendente a prima vista, ma siamo realistici: cosa intendi effettivamente per "10 messaggi all'ora"?Quale ora si intende? Sempre ore intere del giorno? Potrebbe essere che nell'ultimo minuto di un'ora vengano ricevuti nove messaggi e altri nove nel primo minuto dell'ora successiva. In questo modo si ottengono 18 messaggi in soli due minuti di tempo trascorso, ma comunque meno di 10 all'ora, e quindi la regola non si applicherebbe. Non sembra molto ragionevole...

Poiché non esiste un'unica soluzione a questo problema, Checkmk fornisce tre diverse definizioni del significato esatto di "10 messaggi all'ora":

Quindi, quale algoritmo scegliere?

Gli eventi che non hanno ancora raggiunto il numero stabilito sono latenti ma non visibili automaticamente dall'operatore. Sono nella fase counting. Puoi rendere visibili questi eventi con il filtro phase nella visualizzazione degli eventi:

Così come l'arrivo di un particolare messaggio può indicare un problema, anche l'assenza di un messaggio può indicare un problema. Potresti aspettarti almeno un messaggio al giorno da un particolare lavoro. Se questo messaggio non arriva, probabilmente il lavoro non sta funzionando e dovrebbe essere risolto con urgenza.

Puoi configurare qualcosa di simile in Counting & Timing > Expect regular messages:

Come per il conteggio, devi specificare un periodo di tempo in cui ti aspetti che appaiano i messaggi. In questo caso, però, viene utilizzato un algoritmo completamente diverso, che a questo punto ha molto più senso. Il periodo di tempo è sempre allineato esattamente alle posizioni definite. Ad esempio, l'intervallo hour inizia sempre al minuto e al secondo zero. Hai a disposizione le seguenti opzioni:

Perché è così complicato? Questo serve a evitare falsi allarmi. Ad esempio, ti aspetti un messaggio da un backup al giorno? Sicuramente ci saranno piccole differenze nel tempo di esecuzione del backup, per cui i messaggi non vengono ricevuti esattamente a 24 ore di distanza. Ad esempio, se ti aspetti che il messaggio arrivi intorno a mezzanotte, più o meno un'ora o due, un intervallo dalle 12:00 alle 12:00 sarà molto più realistico di uno dalle 00:00 alle 00:00. Tuttavia, se il messaggio non dovesse apparire, riceverai una notifica solo alle 12:00 in punto.

L'opzione Merge with open event è preimpostata in modo che, nel caso in cui lo stesso messaggio appaia ripetutamente, l'evento esistente venga aggiornato. Puoi modificare questa impostazione in modo che ogni volta venga aperto un nuovo evento.

Con il pulsante Add new action puoi creare una nuova azione. L'esempio seguente mostra come creare un semplice shell script come azione del tipo Execute Shell Script. I dettagli degli eventi sono disponibili per lo script tramite variabili d'ambiente, ad esempio $CMK_ID dell'evento, $CMK_HOST, il testo completo $CMK_TEXT o il primo gruppo di corrispondenza come $CMK_MATCH_GROUP_1. Per un elenco completo delle variabili d'ambiente disponibili, consulta l'aiuto inline.

Le versioni precedenti di Checkmk consentivano l'uso di variabili d'ambiente e di macro come $TEXT$ che venivano sostituite prima dell'esecuzione dello script. A causa del pericolo che un aggressore possa iniettare comandi tramite un pacchetto UDP appositamente creato ed eseguito con i privilegi del processo Checkmk, non è consigliabile utilizzare le macro. Attualmente le macro sono ancora supportate per motivi di compatibilità, ma ci riserviamo il diritto di rimuoverle in una versione futura di Checkmk.

Lo script di esempio mostrato nella schermata crea il file tmp/test.out nella directory del sito in cui scrive un testo contenente i valori concreti delle variabili per il rispettivo ultimo evento:

Gli script vengono eseguiti nel seguente ambiente:

Se il tuo script contiene tempi di attesa, puoi farlo eseguire in modo asincrono utilizzando lo spooler di Linux at. Per farlo, crea lo script in un file separato local/bin/myaction e avvialo con il comando at, ad es:

Il tipo di azione Send Email invia una semplice e-mail di testo. In realtà, potresti farlo anche con uno script, ad esempio utilizzando il comando da linea mail. Ma in questo modo è più comodo. Nota che i segnaposto sono ammessi anche nei campi Recipient email address e Subject.

Gli eventi possono provenire da qualsiasi host, indipendentemente dal fatto che sia configurato o meno nel monitoraggio attivo. Dopotutto, le porte syslog e SNMP sono aperte a tutti gli host della rete. Di conseguenza, gli attributi estesi dell'host come alias, tag degli host, contatti, ecc. non sono inizialmente disponibili. Questo è il motivo per cui le condizioni nelle regole di notifica non funzionano necessariamente come ti aspetteresti.

Ad esempio, al momento della notifica, la CE cerca di trovare un host all'interno dell'evento di monitoraggio attivo che corrisponda all'evento, utilizzando la stessa procedura utilizzata per la visibilità degli eventi. Se viene trovato un host, vengono presi i seguenti dati da questo host:

Di conseguenza, il nome host nella notifica elaborata potrebbe non corrispondere esattamente al nome host del messaggio originale. La codifica di testi di notifica conformi a quelli del monitoraggio attivo, tuttavia, semplifica la formulazione di regole di notifica uniformi che includono condizioni applicabili al nome host.

La mappatura viene effettuata in tempo reale inviando una query Livestatus al nucleo di monitoraggio che opera nello stesso sito dell'EC che ha ricevuto il messaggio. Ovviamente questo funziona solo se i messaggi syslog, le trap SNMP ecc. vengono sempre inviati al sito Checkmk in cui l'host viene monitorato attivamente!

Se la ricerca non funziona o l'host non può essere trovato, verranno accettati dati sostitutivi:

Se l'host non può essere assegnato nell'evento di monitoraggio attivo, questo può ovviamente portare a problemi gestiti con le notifiche: da un lato a causa delle condizioni, che potrebbero non essere più valide, e dall'altro a causa della selezione dei contatti. In questi casi puoi modificare le regole di notifica in modo che le notifiche provenienti dalla Console degli Eventi vengano gestite in modo specifico utilizzando le loro regole. A questo scopo esiste una condizione separata con la quale puoi abbinare positivamente solo le notifiche CE o viceversa escluderle:

Affinché le notifiche della CE passino attraverso il sistema di monitoraggio IT, la CE deve essere adattata al suo schema. Nel processo i campi dati tipici di una notifica vengono riempiti nel modo più efficace possibile. Abbiamo appena descritto come vengono determinati i dati dell'host. Altri campi sono:

Come descritto in precedenza, potrebbe non essere possibile determinare automaticamente i contatti per un evento. In questi casi puoi specificare i gruppi di contatto direttamente nella regola CE da utilizzare per la notifica. È importante che tu non dimentichi di selezionare il box Use in notifications:

Esiste uno switch centrale per le notifiche nello snap-in Master control. Questo vale anche per le notifiche inoltrate dall'EC:

Come per l'assegnazione dell'host, l'interrogazione dello switch da parte dell'EC richiede l'accesso di Livestatus al nucleo di monitoraggio locale. Un'interrogazione riuscita può essere visualizzata nel file di log della Console degli Eventi:

La Console degli Eventi è in grado di rilevare gli host che si trovano in un tempo di manutenzione programmata e non invia notifiche in queste situazioni. Il file di log avrà il seguente aspetto:

Naturalmente, questo richiede che l'host venga trovato con successo nel monitoraggio attivo. Se ciò non avviene, si presume che l'host non sia in tempo di manutenzione programmata e in ogni caso verrà generata una notifica.

Quando scrivi i tuoi script di notifica, in particolare per le notifiche provenienti dalla Console degli Eventi, saranno disponibili alcune variabili aggiuntive che descrivono l'evento originale (a cui si accede come sempre con il prefisso NOTIFY_):

Per misurare le prestazioni c'è uno snap-in separato per la barra laterale con il nome di Event Console Performance. Puoi includerlo come al solito con :

I valori mostrati qui sono medie dell'ultimo minuto circa. Una tempesta di eventi che dura solo pochi secondi non può essere letta direttamente qui, ma i numeri sono stati in qualche modo smussati e sono quindi più facili da leggere.

Per testare le massime prestazioni, puoi generare artificialmente una tempesta di messaggi non classificati (solo nel file system di prova!), ad esempio in un ciclo di shell scrivendo continuamente il contenuto di un file di testo nella pipe degli eventi.

Le letture più importanti dello snap-in hanno il seguente significato:

Puoi vedere quanti messaggi la Console degli Eventi può processare al secondo dal sito Processing time per message. Questo tempo è generalmente legato al numero di regole che devono essere provate prima che un messaggio venga processato. In questo caso hai diverse opzioni di ottimizzazione:

Per ogni combinazione di priorità e struttura, viene creata internamente una catena di regole separata in cui sono incluse solo le regole rilevanti per i messaggi di questa combinazione.

Ogni regola che contiene una condizione sulla priorità, sulla struttura o preferibilmente su entrambe, non sarà inclusa in tutte queste catene di regole, ma in modo ottimale solo in una. Ciò significa che la regola non deve essere controllata per i messaggi con una classificazione syslog diversa.

Dopo un riavvio, in ~/var/log/mkeventd.log vedrai una panoramica delle catene di regole ottimizzate:

Nell'esempio precedente puoi vedere che in ogni caso ci sono 67 regole che devono essere controllate. Per i messaggi della struttura daemon sono rilevanti 89 regole, mentre solo per la combinazione daemon/emerg devono essere controllate 120 regole. Ogni regola che riceve una condizione sulla priorità o sulla struttura riduce ulteriormente il numero di 67 regole.

Ovviamente puoi impostare queste condizioni solo se sei sicuro che siano soddisfatte dai messaggi in questione!

La Console degli Eventi ha una protezione automatica contro l'overflow che limita il numero di eventi correnti per host, per regola e a livello globale. Non vengono contati solo gli eventi aperti, ma anche quelli in altre fasi, come delayed o counting. Gli eventi archiviati non vengono contati.

Questo ti proteggerà nelle situazioni in cui, a causa di un problema sistematico sulla rete, migliaia di eventi critici si riversano e la Console degli Eventi si "spegnerebbe". Da un lato, questo impedisce un degrado delle prestazioni della Console degli Eventi, che dovrebbe contenere troppi eventi nella sua memoria principale. Dall'altro, la panoramica per l'operatore è (in qualche modo) protetta e gli eventi che non fanno parte della tempesta rimangono visibili.

Una volta raggiunto il limite, si verifica una delle seguenti azioni:

I limiti e gli effetti associati al loro raggiungimento sono definiti nelle impostazioni della Console degli Eventi con Limit amount of current events. La figura seguente mostra l'impostazione predefinita:

Se hai abilitato un valore con …​create overflow event, quando il limite viene raggiunto, verrà creato un singolo evento artificiale che informerà l'operatore della situazione di errore:

Se hai abilitato anche un valore con …​notify contacts, i contatti appropriati saranno avvisati tramite notifica Checkmk. Questa notifica passerà attraverso le regole di notifica Checkmk. Queste regole non devono necessariamente seguire la selezione dei contatti della Console degli Eventi, ma possono modificarla. La tabella seguente mostra quali contatti vengono selezionati se hai impostato Notify all contacts of the notified host or service (che è il valore predefinito):