 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introduzione
1.1. Gli eventi non sono stati
Il compito principale di Checkmk è il monitoraggio attivo degli stati. In qualsiasi momento, ogni servizio monitorato si trova in uno dei seguenti stati: OK, WARN, CRIT o SCONOSCIUTO. Attraverso un polling regolare, il monitoraggio aggiorna costantemente il quadro della situazione attuale.
Un tipo di monitoraggio completamente diverso è quello che gestisce gli eventi. Un esempio di evento è un'eccezione che si verifica in un'applicazione. L'applicazione può rimanere nello stato OK e continuare a funzionare correttamente, ma è successo qualcosa.
1.2. La Console degli Eventi
Con la Console degli Eventi (EC in breve), Checkmk offre un sistema completamente integrato per il monitoraggio degli eventi provenienti da fonti quali syslog, SNMP trap, registri eventi di Windows, file di log e applicazioni proprie. Gli eventi non sono semplicemente definiti come stati, ma formano una categoria a sé stante e vengono infatti visualizzati come informazioni separate da Checkmk nella barra laterale "Overview".
Internamente, gli eventi non vengono elaborati dal nucleo di monitoraggio, ma da un servizio separato: il daemon degli eventi (mkeventd).
La Console degli Eventi dispone anche di un archivio in cui è possibile cercare gli eventi passati. Tuttavia, va detto subito che questo non sostituisce un vero e proprio archivio di log. Il compito della Console degli Eventi è il filtraggio intelligente di un piccolo numero di messaggi rilevanti da un flusso di grandi dimensioni. È ottimizzata per la semplicità, la robustezza e la velocità di elaborazione, non per l'archiviazione di grandi volumi di dati.
Una breve panoramica delle funzionalità della EC:
Può ricevere messaggi direttamente tramite syslog o SNMP trap. Pertanto non è necessaria una configurazione dei corrispondenti servizi di sistema Linux.
Può anche valutare file di log di testo e registri eventi di Windows utilizzando gli agenti Checkmk.
Classifica i messaggi in base a catene di regole definite dall'utente.
Può correlare, riassumere, contare, annotare e riscrivere i messaggi, oltre a considerare le loro relazioni temporali.
Può eseguire azioni automatizzate e inviare notifiche tramite Checkmk.
È completamente integrato nell'interfaccia utente di Checkmk.
È incluso e pronto all'uso in qualsiasi versione attuale del sistema Checkmk.
1.3. Terminologia
La Console degli Eventi riceve messaggi (per lo più sotto forma di messaggi di log). Un messaggio è una riga di testo con una serie di possibili attributi aggiuntivi, ad esempio un timestamp, un nome host, ecc. Se il messaggio è rilevante, può essere convertito direttamente in un evento con gli stessi attributi, ma:
Un messaggio verrà trasformato in un evento solo se viene applicata una regola.
Le regole possono modificare il testo e altri attributi dei messaggi.
È possibile combinare più messaggi in un unico evento.
I messaggi possono anche eliminare gli eventi correnti.
Si possono generare eventi artificiali se determinati messaggi non vengono visualizzati.
Un evento può attraversare diverse fasi:
Aperto |
Lo stato "normale": è successo qualcosa: l'operatore dovrebbe occuparsene. |
Confermato |
Il problema è stato riconosciuto — è analogo ai problemi di host e di servizio nel monitoraggio basato sullo stato. |
Conteggio |
Il numero richiesto di messaggi specificati non è ancora arrivato: la situazione non è ancora problematica. L'evento non viene quindi ancora visualizzato all'operatore. |
Ritardato |
È stato ricevuto un messaggio di errore, ma la Console degli Eventi sta ancora aspettando di vedere se il messaggio "OK" verrà ricevuto entro un tempo configurato. Solo allora l'evento verrà visualizzato all'operatore. |
Chiuso |
L'evento è stato chiuso dall'operatore o automaticamente dal sistema e si trova solo nell'archivio. |
Anche un evento ha uno stato. A rigor di termini, tuttavia, qui non si intende lo stato dell'evento stesso, ma piuttosto lo stato del servizio o del dispositivo che ha inviato l'evento. Per usare un'analogia con il monitoraggio basato sullo stato, un evento può anche essere contrassegnato come "OK", "WARN", "CRIT" o "SCONOSCIUTO".
2. Configurazione della Console degli Eventi
Configurare la Console degli Eventi è semplicissimo, perché fa parte integrante di Checkmk e si attiva automaticamente.
Tuttavia, se vuoi ricevere messaggi syslog o SNMP trap tramite la rete, devi abilitare questa funzione separatamente. Il motivo è che entrambi i servizi devono aprire una porta UDP con un numero di porta specificamente identificato. E poiché solo un'istanza Checkmk per sistema può farlo, la ricezione tramite la rete è disabilitata per impostazione predefinita.
I numeri di porta sono:
| Protocollo | Porta | Servizio |
|---|---|---|
UDP |
162 |
SNMP trap |
UDP |
514 |
Syslog |
TCP |
514 |
Syslog via TCP |
Syslog via TCP viene usato raramente, ma ha il vantaggio che la trasmissione dei messaggi è protetta. Con UDP non si può mai garantire che i pacchetti arrivino davvero. E né Syslog né le SNMP trap offrono conferme di ricezione o protezioni simili contro la perdita dei messaggi. Per poter usare Syslog via TCP, il sistema mittente deve ovviamente essere in grado di inviare messaggi tramite questa porta.
Nell'appliance Checkmk, puoi abilitare la ricezione di syslog/SNMP trap nell'istanza di configurazione.
Altrimenti, usa semplicemente omd config.
Puoi trovare l'impostazione richiesta in Addons:
All'indirizzo omd start puoi vedere, nella riga contenente mkeventd, quali interfacce esterne sono aperte sul tuo EC:
3. I primi passi con la Console degli Eventi
3.1. Regole, regole, regole
All'inizio abbiamo detto che la EC serve a individuare e visualizzare i messaggi rilevanti. Purtroppo, però, la maggior parte dei messaggi — che provengano da file di testo, dal registro eventi di Windows o dal syslog — sono piuttosto irrilevanti. Inoltre, non aiuta il fatto che i messaggi siano già stati pre-classificati da chi li ha generati.
Ad esempio, nel syslog e nel registro eventi di Windows i messaggi sono classificati in categorie simili a OK, WARN e CRIT. Ma il significato effettivo di WARN e CRIT può essere definito soggettivamente dal programmatore. E non si può nemmeno affermare con certezza che l’applicazione che ha generato il messaggio sia effettivamente importante su questo computer. In breve: non puoi evitare di dover configurare quali messaggi ti sembrano un vero problema e quali possono essere semplicemente ignorati.
Come ovunque in Checkmk, la configurazione avviene tramite regole, che vengono elaborate dall'EC per ogni messaggio in arrivo secondo il principio del "primo riscontro". La prima regola applicata a un messaggio in arrivo ne decide il destino. Se non viene applicata alcuna regola, il messaggio verrà semplicemente ignorato.
Dato che col tempo di solito si accumulano moltissime regole per l'EC, le regole sono organizzate in pacchetti. Il processo di elaborazione delle regole avviene pacchetto per pacchetto e all'interno di un pacchetto dall'alto verso il basso — quindi l'ordine di elaborazione di questi pacchetti è importante.
3.2. Creare una regola semplice
Non sorprende che l'interfaccia di configurazione per l'EC si trovi nel menu Setup sotto Events > Event Console. Out of the box, troverai solo l'Default rule pack, che in realtà non contiene alcuna regola. I messaggi in arrivo vengono quindi, come già detto, scartati e non registrati. Il modulo stesso ha questo aspetto:
Inizia creando un nuovo pacchetto di regole con 
Add rule pack:
Come sempre, l'ID è un riferimento interno e non può essere modificato in seguito. Dopo aver salvato, troverai la nuova voce nell'elenco dei tuoi pacchetti di regole:
Da lì puoi ora switchare al pacchetto di regole ancora vuoto con 
e creare una nuova regola con Add rule.
Compila solo la prima box con l'intestazione Rule Properties:
L'unica cosa necessaria è un Rule ID univoco. Questo ID verrà trovato in seguito nei file di log e verrà memorizzato insieme agli eventi generati. Quindi è consigliabile assegnare agli ID nomi significativi in modo sistematico. Tutte le altre box sono facoltative. Questo vale in particolare per le condizioni.
Importante: questa nuova regola è solo un esempio a scopo di test e si applicherà a ogni evento. Pertanto è importante che tu la rimuova in seguito o almeno la disattivi, altrimenti la tua Console degli Eventi sarà inondata da ogni immaginabile messaggio inutile e diventerà praticamente inutilizzabile!
Attivazione delle modifiche
Come sempre in Checkmk, devi prima attivare le modifiche affinché abbiano effetto. Questo non è uno svantaggio perché in questo modo, per le modifiche che riguardano diverse regole correlate, puoi specificare esattamente quando le regole devono diventare "attive". E prima puoi usare l'Event Simulatore per verificare se tutto funziona come previsto.
Per prima cosa, clicca sul numero di modifiche accumulate in alto a destra nella pagina.
Poi clicca su "Activate on selected sites" per attivare la modifica. 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 possono attivare le modifiche nella EC. Questo è controllato tramite il permesso "Activate changes for event console".
Testare la nuova regola
Per il test potresti ovviamente inviare messaggi tramite syslog o SNMP. Dovresti farlo anche in seguito. Ma per un primo test, l'Event Simulator integrato nell'EC è più pratico:
Qui hai due opzioni: l' Try outvaluta, sulla base del messaggio simulato, quale delle regole corrisponderebbe. Se ti trovi al livello superiore della GUI di Setup dell'EC, i pacchetti di regole saranno evidenziati. Se ti trovi all'interno di un pacchetto di regole, saranno evidenziate le singole regole. Ogni pacchetto o regola è contrassegnato da uno dei seguenti tre simboli:
|
Questa regola è la prima ad avere effetto sul messaggio e di conseguenza ne determina il destino. |
|
Questa regola avrebbe effetto, ma il messaggio è già stato gestito da una regola precedente. |
|
Questa regola non ha effetto. Molto utile: se passi il mouse sulla pallina grigia, ottieni una spiegazione del perché la regola non si applica. |
Cliccando su "Generate event" si ottiene quasi lo stesso risultato di "Try out", solo che ora il messaggio viene effettivamente generato. Qualsiasi azione definita viene effettivamente eseguita. E l'evento apparirà quindi anche negli eventi aperti nel monitoraggio. Puoi vedere il codice sorgente del messaggio generato nella conferma:
L'evento generato appare nel menu "Monitor" sotto "Event Console > Events":
Generazione manuale di messaggi per il test
Per un primo test reale sulla rete, puoi facilmente inviare un messaggio syslog da un altro computer Linux manualmente.
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 questa è conforme a una struttura specifica, la Console degli Eventi scompone i componenti in modo chiaro:
Ma puoi anche semplicemente inviare qualsiasi cosa. L'EC lo accetterà comunque e lo valuterà semplicemente 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'è un pipe denominato, nel quale puoi scrivere messaggi di testo localmente tramite echo.
Questo è un metodo molto semplice per stabilire una connessione con un'applicazione locale e anche un modo per testare l'elaborazione dei messaggi:
A proposito, qui è anche possibile inviare in formato syslog, in modo che tutti i campi nei dati dell'evento vengano compilati correttamente.
3.3. Impostazioni della Console degli Eventi
La Console degli Eventi ha le proprie impostazioni globali, che non si trovano tra quelle degli altri moduli, ma sotto "Setup > Events > Event Console" con il pulsante "Settings".
Come sempre, puoi trovare le spiegazioni delle singole impostazioni nell'aiuto in linea e nei punti appropriati di questo articolo.
L'accesso alle impostazioni è possibile tramite il permesso "Configuration of Event Console", che di default è disponibile solo nel ruolo "admin".
3.4. Permessi
La Console degli Eventi ha anche una propria sezione dedicata ai ruoli e ai permessi:
Discuteremo alcuni di questi permessi in modo più dettagliato nei punti appropriati di questo articolo.
3.5. Assegnazione degli host nella Console degli Eventi
Una caratteristica speciale della Console degli Eventi è che, a differenza del monitoraggio basato sullo stato, gli host non sono al centro dell'attenzione. Gli eventi possono verificarsi senza alcuna assegnazione esplicita di host, cosa che spesso è proprio auspicabile. Tuttavia, dovrebbe essere possibile un'assegnazione per gli host già in monitoraggio attivo, in modo da poter accedere rapidamente alla panoramica dello stato quando si verifica un evento. O, al più tardi, se gli eventi devono essere convertiti in stati, un'assegnazione corretta è essenziale.
La regola fondamentale per i messaggi ricevuti tramite syslog è che il nome host nel messaggio deve corrispondere al nome host nel monitoraggio.
Ciò si ottiene utilizzando il nome di dominio completo (FQDN) / nome host completo (FQHN), sia nella configurazione syslog che nella denominazione degli host in Checkmk.
In Rsyslog puoi farlo utilizzando la direttiva globale $PreserveFQDN on.
Checkmk cerca di corrispondere automaticamente, nel miglior modo possibile, i nomi host degli eventi a quelli del monitoraggio attivo. Oltre al nome host, viene provato anche l'alias dell'host. Se il nome breve viene trasmesso tramite syslog, l'assegnazione sarà corretta.
Una risoluzione a ritroso dell'indirizzo IP non avrebbe molto senso in questo caso, poiché spesso vengono utilizzati server di log intermedi. Se la conversione dei nomi host in FQDN/FQHN o il reinserimento di molti alias richiede troppo tempo, puoi utilizzare l'impostazione della Console degli Eventi Hostname translation for incoming messages per tradurre i nomi host direttamente al momento della ricezione dei messaggi. In questo modo hai numerose possibilità:
Il metodo più flessibile è lavorare con le espressioni regolari, che consentono una ricerca e sostituzione intelligente all’interno dei nomi host.
In particolare, se i nomi host sono espliciti, ma manca solo la parte del dominio utilizzata in Checkmk, una semplice regola aiuta: (.*) diventa \1.mydomain.test.
Nei casi in cui tutto ciò non sia sufficiente, puoi comunque utilizzare Explicit hostname mapping per specificare una tabella di nomi singoli e le rispettive traduzioni.
Importante: la conversione del nome viene eseguita prima del check delle condizioni della regola e quindi molto prima di un'eventuale riscrittura del nome host da parte dell'azione della regola Rewrite hostname nella riscrittura automatica del testo.
L'assegnazione è un po' più semplice con SNMP. Qui l'indirizzo IP del mittente viene confrontato con gli indirizzi IP memorizzati nella cache degli host nel monitoraggio — cioè, non appena sono disponibili active checks regolari, come il controllo di accessibilità della porta Telnet o SSH su uno switch, i messaggi di stato provenienti da questo dispositivo inviati tramite SNMP verranno assegnati all'host corretto.
4. La Console degli Eventi nel monitoraggio
4.1. Visualizzazioni degli eventi
Gli eventi generati dalla Console degli Eventi vengono visualizzati in modo analogo agli host e ai servizi nell'ambiente di monitoraggio. Puoi trovare il punto di accesso a questa funzione nel menu Monitor alla voce Event Console > Events:
Puoi personalizzare la visualizzazione "Events" visualizzata proprio come qualsiasi altra. Puoi filtrare gli eventi visualizzati, eseguire comandi, ecc. Per i dettagli, consulta l'articolo sulle visualizzazioni. Quando crei nuove visualizzazioni degli eventi, gli eventi e la cronologia degli eventi sono disponibili come sorgenti dati.
Cliccando sull'ID dell'evento (qui ad esempio 27) vedrai i suoi dettagli:
Come puoi vedere, un evento presenta diversi campi dati, il cui significato verrà spiegato passo dopo passo in questo articolo. I campi più importanti meritano comunque una breve menzione qui:
| Campo | Significato |
|---|---|
State (severity) of event |
Come accennato nell'introduzione, ogni evento è classificato come OK, WARN, CRIT o SCONOSCIUTO. Gli eventi con stato OK sono piuttosto rari. Questo perché l'EC è progettato proprio per filtrare solo i problemi. Tuttavia, ci sono situazioni in cui un evento OK può avere senso. |
Text/Message of the event |
Il contenuto effettivo dell'evento: un messaggio di testo. |
Hostname |
Il nome dell'host che ha inviato il messaggio. Non deve necessariamente trattarsi di un host monitorato attivamente da Checkmk. Tuttavia, se nel monitoraggio esiste un host con quel nome, l'EC creerà automaticamente un collegamento. In questo caso, anche i campi Host alias, Host contacts e Host icons verranno compilati e l'host apparirà con la stessa notazione del monitoraggio attivo. |
Rule-ID |
L'ID della regola che ha creato questo evento. Cliccando su questo ID verrai reindirizzato direttamente ai dettagli della regola. A proposito, l'ID viene conservato anche se nel frattempo la regola non esiste più. |
Come accennato all'inizio, gli eventi vengono visualizzati direttamente nella sezione "Overview" della barra laterale:
Qui vedrai tre numeri:
Events — tutti gli eventi aperti e con conferma (corrisponde alla visualizzazione "Event Console > Events")
Problems — di cui solo quelli con stato WARN / CRIT / SCONOSCIUTO
Unhandled — di questi, ancora una volta, solo quelli non ancora oggetto di riconoscimento (ne parleremo meglio tra un attimo)
4.2. Comandi e flusso di lavoro degli eventi
Analogamente agli host e ai servizi, anche per gli eventi è prevista una semplice mappatura del flusso di lavoro.
Come al solito, questo avviene tramite comandi, che puoi trovare nel menu Commands.
Mostrando e selezionando le checkbox puoi eseguire un comando su più eventi contemporaneamente.
Una funzione speciale è l’archiviazione di un singolo evento, spesso utilizzata, direttamente tramite il simbolo 
.
Per ciascuno dei comandi è presente un permesso, che puoi utilizzare per controllare a quale ruolo è consentita l'esecuzione del comando.
Per impostazione predefinita, tutti i comandi sono consentiti ai titolari dei ruoli admin e user.
Sono disponibili i seguenti comandi:
Aggiorna e effettua la conferma
Il comando Update & Acknowledge visualizza l'area seguente sopra l'elenco degli eventi:
Con il pulsante "Update" puoi, con un'unica azione, aggiungere un commento all'evento, aggiungere una persona di contatto e effettuare la conferma dell'evento. Il campo "Change contact" è volutamente di testo libero. Qui puoi anche inserire cose come i numeri di telefono. In particolare, questo campo non ha alcuna influenza sulla visibilità dell'evento nella GUI: è puramente un campo per i commenti.
La checkbox "Set event to acknowledged" (Conferma) farà switchare l'evento dalla fase "open" (In attesa di conferma) a "acknowledged" (Confermato) e d'ora in poi verrà visualizzato come "handled". Questo è analogo al riconoscimento dei problemi relativi all'host e al servizio.
Se poi esegui di nuovo il comando senza spuntare la checkbox, la conferma verrà rimossa.
Modifica dello stato
Il comando "Change State" permette di modificare manualmente lo stato di un evento, ad esempio da "CRIT" a "WARN".
Azione personalizzata
Con il comando `Custom Action` è possibile eseguire azioni liberamente definibili sugli eventi. Inizialmente è disponibile solo l'azione `Send monitoring notification`. Questa invierà una notifica Checkmk che verrà handleata allo stesso modo di quella proveniente da un servizio monitorato attivamente. La notifica passa attraverso le regole di notifica e può generare e-mail, SMS o qualsiasi altra cosa tu abbia configurato di conseguenza. Vedi sotto per i dettagli sulla notifica tramite EC.
Archivia evento
Il pulsante "Archive Event" rimuove definitivamente un evento dall'elenco degli eventi aperti. Poiché tutte le azioni sugli eventi — compresa questa eliminazione — vengono registrate anche nell'archivio, potrai comunque accedere in un secondo momento a tutte le informazioni relative all'evento. Ecco perché non parliamo di eliminazione, ma piuttosto di archiviazione.
Puoi anche archiviare comodamente singoli eventi dall'elenco degli eventi utilizzando "".
4.3. Visibilità degli eventi
Il "problema" della visibilità
Per garantire la visibilità di host e servizi nel monitoraggio per gli utenti normali, Checkmk utilizza i gruppi di contatto. Questi gruppi vengono assegnati agli host e ai servizi tramite la GUI di configurazione, le regole o la configurazione delle cartelle.
Con la Console degli Eventi, invece, tale assegnazione degli eventi ai gruppi di contatto non esiste. Questo perché semplicemente non si sa in anticipo quali messaggi verranno effettivamente ricevuti. Non si conosce nemmeno l'elenco degli host, poiché le porte per syslog e SNMP sono accessibili da qualsiasi luogo. Pertanto, la Console degli Eventi include alcune funzionalità speciali per definire la visibilità.
Inizialmente, tutti possono vedere tutto
Prima di tutto, quando si configurano i ruoli utente c'è il permesso "Event Console > See all events".
Questo permesso è attivo di default, quindi gli utenti normali possono vedere tutti gli eventi!
È impostato così di proposito per garantire che i messaggi di errore importanti non vengano ignorati a causa di una configurazione errata.
Il primo passo per una visibilità più precisa è rimuovere questo permesso dal ruolo "user".
Assegnazione agli host
Per garantire che la visibilità degli eventi sia il più possibile coerente con il resto del monitoraggio, la Console degli Eventi cerca, per quanto possibile, di corrispondere gli host da cui riceve gli eventi a quelli configurati tramite la GUI di configurazione. Ciò che sembra semplice è in realtà complicato nei dettagli. A volte nel messaggio di evento manca il nome host ed è noto solo l'indirizzo IP. In altri casi il nome host è scritto in modo diverso rispetto a quello presente nella GUI di configurazione.
L'assegnazione viene effettuata come segue:
Se nell'evento non viene trovato alcun nome host, il suo indirizzo IP viene utilizzato come nome host.
Il nome host nell'evento viene quindi confrontato, senza distinzione tra maiuscole e minuscole, con tutti i nomi host, gli indirizzi host e gli indirizzi IP degli host nel monitoraggio.
Se si trova un host in questo modo, i suoi gruppi di contatto vengono utilizzati per l'evento, e questo viene poi utilizzato per controllare la visibilità.
Se l'host non viene trovato, i gruppi di contatto — se configurati lì — vengono presi dalla regola che ha creato l'evento.
Se non ci sono gruppi memorizzati nemmeno lì, l'utente potrà vedere l'evento solo se ha il permesso "Event Console > See events not related to a known host".
Puoi influenzare l'assegnazione in un punto: In particolare, se nella regola sono definiti gruppi di contatto e l'host può essere assegnato, la mappatura ha solitamente la priorità. Puoi modificare questo aspetto in una regola con l'opzione "Precedence of contact groups":
Inoltre, puoi effettuare le impostazioni direttamente nella regola di notifica. Questo permette di dare priorità al tipo di evento rispetto alle normali responsabilità di un host.
4.4. Risoluzione dei problemi
Quale regola si applica e con quale frequenza?
Sia per i pacchetti di regole …
… che per le singole regole …
… nella colonna “Hits” troverai le informazioni sulla frequenza con cui il pacchetto o la regola ha già corrisposto a un messaggio. Questo ti aiuta a eliminare o correggere le regole inefficaci. Ma può essere interessante anche per le regole che corrispondono molto spesso. Per performance ottimali dell’EC, queste dovrebbero trovarsi all’inizio della catena di regole. In questo modo puoi ridurre il numero di regole che l’EC deve testare su ogni messaggio.
Puoi azzerare i contatori in qualsiasi momento tramite la voce di menu "Event Console > Reset counters".
Debug della valutazione delle regole
In "Provare una regola" hai già visto come utilizzare l'Event Simulator per controllare le valutazioni 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 in var/log/mkeventd.log, dove troverai il motivo esatto per cui una regola controllata non ha avuto effetto:
[1481020022.001612] Processing message from ('10.40.21.11', 57123): '<22>Dec 6 11:27:02 myserver123 exim[1468]: Delivery complete, 4 message(s) remain.'
[1481020022.001664] Parsed message:
application: exim
facility: 2
host: myserver123
ipaddress: 10.40.21.11
pid: 1468
priority: 6
text: Delivery complete, 4 message(s) remain.
time: 1481020022.0
[1481020022.001679] Trying rule test/myrule01...
[1481020022.001688] Text: Delivery complete, 4 message(s) remain.
[1481020022.001698] Syslog: 2.6
[1481020022.001705] Host: myserver123
[1481020022.001725] did not match because of wrong application 'exim' (need 'security')
[1481020022.001733] Trying rule test/myrule02n...
[1481020022.001739] Text: Delivery complete, 4 message(s) remain.
[1481020022.001746] Syslog: 2.6
[1481020022.001751] Host: myserver123
[1481020022.001764] did not match because of wrong textVa da sé che dovresti usare questa registrazione intensiva solo quando necessario e con cautela. In un ambiente solo leggermente più complesso verranno generati enormi volumi di dati!
5. Il pieno valore delle regole
5.1. Le condizioni
La parte più importante di una regola EC è ovviamente la condizione (Matching Criteria). Solo se un messaggio soddisfa tutte le condizioni memorizzate nella regola, le azioni definite nella regola vengono eseguite e la valutazione del messaggio è quindi completata.
Informazioni generali sul confronto dei testi
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'ultimo aspetto costituisce un'eccezione alle convenzioni di Checkmk presenti in altri moduli. Tuttavia, ciò 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 localmente su ciascun host anziché centralmente. Questa eccezione è quindi molto utile in questo caso.
Inoltre, si applica sempre un match parziale, ovvero una check del contenuto del testo di ricerca.
Quindi puoi evitare di inserire 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 piuttosto un nome host esplicito, verrà checkata la corrispondenza esatta e non la presenza all'interno.
Attenzione: se il testo di ricerca contiene un punto (.), verrà considerato un'espressione regolare e si applicherà la ricerca infissa; ad esempio, myhost.com corrisponderà anche a notmyhostide!
Gruppi di corrispondenza
Molto importante e utile in questo contesto è il concetto di gruppi di corrispondenza nel campo Text to match. Questo si riferisce alle sezioni di testo che corrispondono alle espressioni tra parentesi nell'espressione regolare.
Supponiamo che tu voglia effettuare il monitoraggio del seguente tipo di messaggio nel file di log di un database:
Database instance WP41 has failedL'WP41 è ovviamente variabile e sicuramente non vuoi formulare una regola separata per ogni istanza diversa.
Pertanto utilizzi .* nell'espressione regolare, 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 eventuali azioni future:
Database instance (.*) has failed
Dopo una corrispondenza riuscita della regola, il primo gruppo di corrispondenza è ora impostato sul valore WP41 (o qualunque istanza abbia generato l'errore).
Puoi vedere questi gruppi di corrispondenza nell'Event Simulator se passi il cursore sulla pallina verde:
Puoi vedere i gruppi anche nei dettagli dell'evento generato:
Tra le altre cose, i gruppi di corrispondenza vengono utilizzati per:
Riscrivere gli eventi
Elimina automaticamente gli eventi
Il conteggio dei messaggi
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 aperta.
Esempio: L'espressione one (.*) two (?:.*) three crea, per una corrispondenza su one 123 two 456 three, un solo gruppo di corrispondenza 123.
indirizzo IP
Nel campo Match original source IP address puoi corrispondere con l'indirizzo IPv4 del mittente del messaggio.
Specifica un indirizzo esatto o una rete nella notazione X.X.X.X/Y, ad esempio 192.168.8.0/24 per trovare tutti gli indirizzi nella rete 192.168.8. X.
Tieni presente che l'indirizzo IP corrisponde solo se i sistemi monitorati inviano direttamente alla Console degli Eventi. Se un altro server syslog intermedio collegato inoltra i messaggi, nel messaggio apparirà invece il suo indirizzo come mittente.
Priorità e facility syslog
I campi Match syslog priority e Match syslog facility sono informazioni standardizzate, originariamente definite dalle specifiche syslog. Internamente, un campo a 8 bit è suddiviso in 5 bit per la facility (32 possibilità) e 3 bit per la priorità (8 possibilità).
Le 32 facility predefinite un tempo erano pensate per qualcosa come un'applicazione.
Ma all'epoca la selezione non era stata fatta in modo molto lungimirante.
Una delle facility è uucp — un protocollo che già all'inizio degli anni '90 del millennio scorso era quasi obsoleto.
Ma è un dato di fatto che ogni messaggio che arriva tramite syslog porta con sé una di queste facility. In alcuni casi puoi anche assegnarle liberamente quando invii il messaggio, in modo da poterli filtrare in seguito. Questo è piuttosto utile.
L'uso di facility e priorità ha anche un aspetto legato alla performance. Se definisci una regola che in ogni caso si applica solo ai messaggi che hanno tutti la stessa facility o priorità, dovresti definirle 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 hanno questi filtri impostati, meno confronti tra regole sono necessari.
Invertire una corrispondenza
La 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 regole (opzioni "Rule type" nella box "Outcome & Action" della regola):
Do not perform any action, drop this message, stop processing.
Skip this rule pack, continue rule execution with next pack
Puoi trovare ulteriori informazioni sui pacchetti di regole qui sotto.
5.2. Effetto della regola
Tipo di regola: Elimina o crea un evento
Quando una regola corrisponde, specifica cosa deve succedere al messaggio. Questo si fa nella box "Outcome & Action":
L'opzione "Rule type" può essere utilizzata per interrompere completamente la valutazione in quel 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" vengono effettivamente valutate le altre opzioni in questo box.
Impostazione dello stato
Con "State", la regola imposta lo stato dell'evento nel monitoraggio. Nella regola questo stato sarà "WARN" o "CRIT". Le regole che generano eventi "OK" possono essere interessanti nelle eccezioni per rappresentare determinati eventi in modo puramente informativo. In tal caso, è interessante una combinazione con una scadenza automatica di questi eventi.
Oltre all'impostazione di uno stato esplicito, ci sono altre due opzioni dinamiche. L'impostazione "(set by syslog)" (In base alla priorità syslog) si basa sulla classificazione in base alla priorità syslog. Questo funziona solo se il messaggio è già stato classificato come utilizzabile dal mittente. I messaggi ricevuti direttamente da syslog conterranno una delle otto priorità RFC, che sono sottoposte a mappatura come segue:
| Priorità | ID | Stato | Definizione secondo syslog |
|---|---|---|---|
|
0 |
CRIT |
il sistema è inutilizzabile |
|
1 |
CRIT |
è necessario intervenire immediatamente |
|
2 |
CRIT |
condizione critica |
|
3 |
CRIT |
errore |
|
4 |
WARN |
avviso |
|
5 |
OK |
normale, ma informazione significativa |
|
6 |
OK |
puramente informativo |
|
7 |
OK |
messaggio di debug |
Oltre ai messaggi syslog, i messaggi provenienti dal Registro eventi di Windows e quelli provenienti da file di testo già classificati con il plug-in Checkmk logwatch sul sistema di destinazione forniscono stati già pronti. Per le SNMP trap questa funzione purtroppo non è disponibile.
Un metodo completamente diverso consiste nel 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 qui avviene solo dopo aver verificato l'Text to match e le altre condizioni della regola, in modo da non dover ripetere tali controlli.
Se non viene trovato nessuno dei modelli configurati, l'evento restituisce lo stato SCONOSCIUTO.
Livelli del servizio
L'idea alla base del campo "Service Level" è che ogni host e ogni servizio in un'organizzazione ha un certo livello di importanza. Questo può essere associato a un accordo 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 notifiche o i dashboard personalizzati.
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 utilizzando questo livello.
Per impostazione predefinita, Checkmk definisce quattro livelli: 0 (nessun livello), 10 (argento), 20 (oro) e 30 (platino). Puoi modificare questa selezione come desideri nell'Global settings > Notifications > Service Levels. Sono determinanti i numeri che designano i livelli, poiché i livelli vengono ordinati in base a questi numeri e confrontati anche in base all'importanza relativa.
Gruppi di contatto
I gruppi di contatto utilizzati per la visibilità verranno utilizzati anche per la notifica degli eventi. Qui puoi utilizzare delle regole per assegnare esplicitamente i gruppi di contatto agli eventi. I dettagli sono disponibili nel capitolo sul monitoraggio.
Azioni
Le azioni sono molto simili ai gestori di avvisi per host e servizi. Qui puoi far eseguire uno script personalizzato quando viene aperto un evento. I dettagli completi che descrivono le azioni sono disponibili più avanti in una sezione separata.
Cancellazione automatica (archiviazione)
La cancellazione automatica (= archiviazione), che puoi impostare con Delete event immediately after the actions, assicura che un evento non sia visibile nel monitoraggio. Questo è utile se vuoi solo attivare alcune azioni automaticamente o se vuoi solo archiviare determinati eventi in modo da poterli cercare in seguito.
5.3. Riscrittura automatica dei testi
Con la funzione "Rewriting", una regola EC può riscrivere automaticamente i campi di testo in un messaggio e aggiungere annotazioni. Questo si configura in una box separata:
Durante la riscrittura, i gruppi di corrispondenza sono particolarmente importanti. Questi ti permettono di includere parti del messaggio originale nel nuovo testo. Puoi accedere ai gruppi durante la riscrittura come segue:
|
Verrà sostituito dal primo gruppo di corrispondenza nel messaggio originale. |
|
Verrà sostituito dal secondo gruppo di corrispondenza nel messaggio originale (ecc.). |
|
Verrà sostituito dal messaggio originale completo. |
Nello screenshot qui sopra, il testo del nuovo messaggio sarà codificato come Instance \1 has been shut down.
Ovviamente, questo funziona solo se l'Text to matche nella stessa regola dell'espressione di ricerca regolare ha anche almeno un'espressione tra parentesi.
Un esempio potrebbe essere ad esempio:
Alcune ulteriori note sulla riscrittura:
La riscrittura viene eseguita dopo che si è riusciti a corrispondere e prima di eseguire le azioni.
Corrispondenza, riscrittura e azioni vengono sempre eseguite nella stessa regola. Non è possibile riscrivere un messaggio e poi elaborarlo con una regola successiva.
Le espressioni
\1,\2ecc. possono essere utilizzate in tutti i campi di testo, non solo in Rewrite message text.
5.4. Eliminazione automatica degli eventi
Alcune applicazioni o dispositivi sono così gentili da inviare in seguito un messaggio OK adeguato non appena il problema è stato risolto. Puoi configurare l'EC in modo tale che, in un caso del genere, l'evento aperto dall'errore venga eliminato automaticamente. Questo viene chiamato eliminazione.
La figura seguente mostra una regola con cui vengono cercati i messaggi contenenti il testo database instance (.*) has failed.
L'espressione (.*) rappresenta una stringa arbitraria che viene intercettata in un gruppo di corrispondenza.
L'espressione database instance (.*) recovery in progress, che si trova nel campo Text to cancel event(s) nella stessa regola, chiuderà automaticamente gli eventi creati con questa regola quando viene ricevuto un messaggio corrispondente:
L'eliminazione automatica funziona fintanto che
venga ricevuto un messaggio il cui testo corrisponda a Text to cancel event(s),
il valore catturato qui nel gruppo
(.*)sia identico al gruppo di corrispondenza del messaggio originale,entrambi i messaggi provengano dallo stesso host e
si tratti della stessa applicazione (il campo Syslog application to cancel event).
Il principio del gruppo di corrispondenza è molto importante in questo caso.
Dopotutto, non avrebbe molto senso se il messaggio database instance TEST recovery in progress eliminasse un evento generato dal messaggio database instance PROD has failed, vero?
Non commettere l'errore di usare il segnaposto \1 in Text to cancel events(s).
Questo NON funziona!
Questi segnaposti funzionano solo per la riscrittura.
In alcuni casi capita che un testo venga utilizzato sia per creare che per eliminare un evento. In tal caso, l'eliminazione ha la priorità.
Esegui azioni durante l'eliminazione
Puoi anche far eseguire automaticamente delle azioni quando un evento viene eliminato. È importante sapere che quando un evento viene eliminato, alcuni campi dati dell'evento vengono sovrascritti dai valori del messaggio OK prima che vengano eseguite qualsiasi azione. In questo modo, tutti i dati del messaggio OK sono poi 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 una sovrascrittura e puoi usare lo stesso script per i messaggi di errore e OK (ad esempio durante una connessione a un sistema di ticket).
I seguenti campi vengono sovrascritti dai dati del messaggio OK:
Il testo del messaggio
Il timestamp
L'ora dell'ultimo evento
La priorità syslog
Tutti gli altri campi rimangono invariati, compreso l'ID dell'evento.
Elimina in combinazione con la riscrittura
Se utilizzi la riscrittura e l'eliminazione nella stessa regola, devi prestare attenzione quando riscrivi il nome host o l'applicazione. Durante l'eliminazione, l'EC verifica sempre se il messaggio di eliminazione corrisponde al nome host e all'applicazione dell'evento aperto. Ma se questi fossero stati riscritti, l'eliminazione non funzionerebbe mai.
Pertanto, prima di eliminare l'evento, la Console degli Eventi simula una riscrittura del nome host e dell'applicazione per confrontare i testi rilevanti. Questo è probabilmente ciò che ti aspetteresti.
Puoi anche sfruttare questo comportamento se il campo dell'applicazione nel messaggio di errore e nel successivo messaggio OK non corrispondono. In questo caso, basta riscrivere il campo dell'applicazione con un valore fisso noto. Questo di fatto fa sì che questo campo venga ignorato.
Annullamento basato sulla priorità syslog
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à syslog.
A questo scopo c'è l'opzione "Syslog priority to cancel event".
Qui inserisci l'intervallo debug … notice, ad esempio.
Tutte le priorità in questo intervallo sono normalmente considerate come aventi uno stato OK.
Quando usi questa opzione dovresti comunque inserire un testo adatto nel campo "Text to cancel event(s)", altrimenti la regola corrisponderà a tutti i messaggi OK che riguardano la stessa applicazione.
5.5. Conteggio dei messaggi
Nella box "Counting & Timing" troverai le opzioni per il conteggio dei messaggi simili. L'idea è che alcuni messaggi sono rilevanti solo se si verificano troppo frequentemente o troppo raramente entro periodi di tempo specificati.
Messaggi troppo frequenti
Puoi attivare il check dei messaggi che si verificano troppo spesso con l'opzione "Count messages in interval":
Qui devi prima specificare un periodo di tempo in "Time period for counting" e il numero di messaggi che dovrebbe portare all'apertura di un evento in "Count until triggered". Nell'esempio sopra, questo è impostato su 10 messaggi all'ora. Ovviamente non si tratta di 10 messaggi a caso, ma di messaggi che corrispondono alla regola.
Normalmente ha senso non contare globalmente tutti i messaggi corrispondenti, ma solo quelli che si riferiscono alla stessa "causa". Per controllare questo aspetto, ci sono le tre checkbox per le opzioni precedute da Force separate events for different …. Queste sono preimpostate in modo tale che i messaggi vengano conteggiati insieme solo se corrispondono in:
host
applicazione
Questo ti permette di formulare regole del tipo "Se vengono ricevuti più di 10 messaggi all'ora dallo stesso host, dalla stessa applicazione e dallo stesso sito, allora...". A causa della regola, questo può portare alla generazione di più eventi diversi.
Se, ad esempio, deselezioni tutte e tre le checkbox, il conteggio verrà effettuato solo a livello globale e la regola potrà generare un solo evento in totale!
A proposito, può avere senso inserire 1 come conteggio. In questo modo puoi gestire 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 vedrai
l'ora in cui si è verificato il primo messaggio,
l'ora in cui si è verificato il messaggio più recente e
il numero totale di messaggi combinati in questo evento.
Quando il caso viene poi chiuso, tramite due checkbox puoi definire quando deve essere aperto un nuovo evento. Normalmente, la conferma dell'evento crea una situazione in cui, se vengono ricevuti ulteriori messaggi, viene avviato un nuovo conteggio e viene attivato un nuovo evento. Puoi disabilitare questa funzione con "Continue counting when event is acknowledged".
L'opzione "Discontinue counting after time has elapsed" (Un evento per ogni periodo di confronto) garantisce che venga sempre aperto un evento separato per ogni periodo di confronto. Nell'esempio sopra è stata specificata una soglia di 10 messaggi all'ora. Se questa opzione è abilitata, 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 su 1 e l'intervallo di tempo su un giorno, vedrai solo un massimo di un evento di questo tipo di messaggio al giorno.
L'impostazione "Algorithm " potrebbe sembrare un po' strana a prima vista. Ma siamo realistici: Cosa intendi davvero con "10 messaggi all'ora"? A quale ora ti riferisci? Sempre le ore intere del giorno? Potrebbe succedere che nell'ultimo minuto di un'ora vengano ricevuti nove messaggi e altri nove nel primo minuto dell'ora successiva. Questo fa un totale di 18 messaggi in soli due minuti di tempo trascorso, ma comunque meno di 10 all'ora, quindi la regola non si applicherebbe. Non sembra molto ragionevole …
Dato che non c'è una soluzione unica a questo problema, Checkmk offre tre diverse definizioni di cosa dovrebbe significare esattamente "10 messaggi all'ora":
| Algoritmo | Funzionalità |
|---|---|
Interval |
L'intervallo di conteggio inizia al primo messaggio in arrivo corrispondente. Viene generato un evento nella fase "counting". Se il tempo specificato scade prima che il conteggio sia raggiunto, l'evento viene eliminato silenziosamente. Tuttavia, se il conteggio viene raggiunto prima della scadenza del tempo, l'evento viene aperto immediatamente (e vengono attivate tutte le azioni configurate). |
Token Bucket |
Questo algoritmo non funziona con intervalli di tempo fissi, ma implementa un metodo spesso utilizzato nelle reti per il traffic shaping. Supponiamo che tu abbia configurato 10 messaggi all'ora. Si tratta di una media di uno ogni 6 minuti. La prima volta che viene ricevuto un messaggio corrispondente, viene generato un evento nella fase "counting" e il contatore viene impostato su 1. Per ogni messaggio successivo, questo viene aumentato di 1. E ogni 6 minuti, il contatore viene nuovamente diminuito di 1 — indipendentemente dal fatto che sia arrivato un messaggio o meno. Se il contatore scende nuovamente a 0, l'evento viene eliminato. Quindi il trigger viene attivato quando la frequenza media dei messaggi è permanentemente superiore a 10 all'ora. |
Dynamic Token Bucket |
Si tratta di una variante dell'algoritmo "Token Bucket", in cui più il contatore è basso in un dato momento, più lentamente diminuisce. Nell'esempio sopra, se il contatore fosse 5, diminuirebbe solo ogni 12 minuti invece che ogni 6 minuti. L'effetto complessivo è che i tassi di notifica appena superiori al tasso consentito apriranno un evento (e quindi verranno notificati) molto più velocemente. |
Quindi quale algoritmo dovresti scegliere?
Interval è il più semplice da capire e più facile da seguire se in seguito vuoi eseguire un conteggio esatto nel tuo archivio syslog.
Token Bucket D'altra parte è più intelligente e "morbido". Ci sono meno anomalie ai margini degli intervalli.
Dynamic Token Bucket rende il sistema più reattivo e genera notifiche più velocemente.
Gli eventi che non hanno ancora raggiunto il numero impostato sono latenti ma non automaticamente visibili all'operatore. Si trovano nella fase "counting". Puoi rendere visibili tali eventi con il filtro "phase" nella visualizzazione degli eventi:
Messaggi troppo rari o mancanti
Proprio come l'arrivo di un determinato messaggio può indicare un problema, anche l'assenza di un messaggio può significare un problema. Potresti aspettarti almeno un messaggio al giorno da un determinato processo. Se questo messaggio non arriva, il processo probabilmente non è in esecuzione 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 compaiano i messaggi. Qui, tuttavia, viene utilizzato un algoritmo completamente diverso, che in questo caso 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 le seguenti opzioni:
| Intervallo | Allineamento |
|---|---|
10 seconds |
Su un numero di secondi divisibile per 10 |
minute |
Al minuto intero |
5 minutes |
Alle 0:00, 0:05, 0:10, ecc. |
15 minutes |
Alle 0:00, 0:15, 0:30, 0:45, ecc. |
hour |
All'inizio di ogni ora intera |
day |
Esattamente alle 00:00, ma in un fuso orario configurabile. Questo ti permette anche di specificare che ti aspetti un messaggio tra le 12:00 e le 12:00 del giorno successivo. Ad esempio, se ti trovi nel fuso orario UTC +1, specifica UTC -11 hours. |
two days |
All'inizio di un'ora intera. Qui puoi specificare un offset del fuso orario da 0 a 47, riferendoti al 1970-01-01 00:00:00 UTC. |
week |
Alle 00:00 di giovedì mattina nel fuso orario UTC più l'offset, che puoi esprimere in ore. Giovedì perché il 1/1/1970 — l'inizio dell'"epoca" — era un giovedì. |
Perché è così complicato? Questo serve a evitare falsi allarmi. Ti aspetti, ad esempio, un messaggio al giorno da un backup? Sicuramente ci saranno lievi differenze nel tempo di esecuzione del backup, quindi i messaggi non arriveranno esattamente a distanza di 24 ore l'uno dall'altro. Ad esempio, se ti aspetti che il messaggio arrivi intorno a mezzanotte, con un margine di 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 arrivare, riceverai una notifica solo alle 12:00 in punto.
Ripetizione dello stesso problema
L'opzione "Merge with open event" è preimpostata in modo tale che, nel caso in cui lo stesso messaggio appaia ripetutamente, l'evento esistente venga aggiornato. Puoi modificare questa impostazione in modo che venga aperto un nuovo evento ogni volta.
5.6. Tempistica
In "Counting & Timing" ci sono due opzioni che influenzano l'apertura e/o la chiusura automatica degli eventi.
L'opzione "Delay event creation" è utile se stai lavorando con l'eliminazione automatica degli eventi. Imposta ad esempio un ritardo di 5 minuti, quindi in caso di messaggio di errore l'evento creato rimarrà nello stato "delayed" per 5 minuti — nella speranza che il messaggio OK arrivi entro questo tempo. Se ciò avviene, l'evento viene chiuso automaticamente e senza complicazioni, e non compare nel monitoraggio. Se il tempo scade, tuttavia, l'evento verrà aperto e verranno eseguite le azioni eventualmente definite:
Limit event lifetime fa più o meno l'opposto. Con questa funzione puoi far sì che gli eventi si chiudano automaticamente dopo un certo tempo. Questo è utile, ad esempio, per gli eventi informativi con stato "OK" che desideri visualizzare, ma per i quali non vuoi che il monitoraggio generi alcuna attività. "Disattivandoli" automaticamente, ti risparmi la cancellazione manuale di tali messaggi:
Confermando il messaggio, l'esclusione verrà temporaneamente interrotta. Questo comportamento può essere controllato tramite le due checkbox.
5.7. Pacchetti di regole
I pacchetti di regole non solo hanno il vantaggio di rendere le cose più gestibili, ma possono anche semplificare la configurazione di più regole simili e allo stesso tempo velocizzare la valutazione.
Supponiamo che tu abbia un insieme di 20 regole che ruotano tutte attorno al registro eventi di Windows Security. Tutte queste regole hanno in comune il fatto che controllano la condizione per un determinato testo nel campo dell'applicazione (il nome di questo file di log viene utilizzato nei messaggi provenienti dall'EC come Application). In tal caso, procedi come segue:
Crea il tuo pacchetto di regole.
Crea le 20 regole per Security in questo pacchetto o spostale lì (elenco di selezione Move to pack… sul lato destro della tabella delle regole).
Rimuovi la condizione relativa all'applicazione da tutte queste regole.
Crea come prima regola del pacchetto una regola in base alla quale i messaggi escono immediatamente dal pacchetto se l'applicazione non è Security.
Questa regola di esclusione è strutturata come segue:
Matching Criteria > Match syslog application (tag) su
Security.Matching Criteria > Invert matching su Negate match: Execute this rule if the upper conditions are not fulfilled.
Outcome & Action > Rule type su Skip this rule pack, continue rule execution with next rule pack
Qualsiasi messaggio che non provenga dal log di sicurezza verrà "rifiutato" dalla prima regola di questo pacchetto. Questo non solo semplifica il resto delle regole del pacchetto, ma accelera anche l'elaborazione, poiché nella maggior parte dei casi non è necessario controllare affatto le altre regole.
6. Azioni
6.1. Tipi di azioni
La Console degli Eventi include tre tipi di azioni, che puoi eseguire manualmente oppure all'apertura o all'eliminazione degli eventi:
Esecuzione di shell scripts scritti dall'utente.
Invio di e-mail personalizzate
Generazione di notifiche Checkmk
6.2. Shell scripts ed e-mail
Devi prima definire le e-mail e gli script nelle impostazioni della Console degli Eventi. Li trovi sotto la voce "Actions (Emails & Scripts)":
Esecuzione di shell scripts
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 l'$CMK_IDe dell'evento, l'$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 in linea 
.
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 rischio che un malintenzionato possa iniettare comandi tramite un pacchetto UDP appositamente creato, eseguito con i privilegi del processo Checkmk, è consigliabile non utilizzare le macro.
Le macro sono attualmente 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 dell'istanza, in cui scrive un testo contenente i valori concreti delle variabili relative all'ultimo evento:
cat << EOF > ${OMD_ROOT}/tmp/test.out
Something happened:
Event-ID: $CMK_ID
Host: $CMK_HOST
Application: $CMK_APPLICATION
Message: $CMK_TEXT
EOFGli script vengono eseguiti nel seguente ambiente:
/bin/bashviene utilizzato come interprete.Lo script viene eseguito come utente dell’istanza con la directory home dell’istanza (ad es.
/omd/sites/mysite).Mentre lo script è in esecuzione, il processo di elaborazione degli altri eventi viene interrotto!
Se il tuo script contiene tempi di attesa, puoi farlo funzionare in modo asincrono utilizzando lo spooler Linux at.
Per farlo, crea lo script in un file separato local/bin/myaction e avvialo con il comando at, ad esempio:
echo "$OMD_ROOT/local/bin/myaction '$HOST$' '$TEXT$' | at nowInvio di e-mail
Il tipo di azione Send Email invia un'e-mail di testo semplice.
In realtà potresti farlo anche con uno script, ad esempio utilizzando il comando da riga di comando mail.
Ma in questo modo è più comodo.
Tieni presente che i segnaposto sono consentiti anche nei campi Recipient email address e Subject.
6.3. Notifiche tramite Checkmk
Oltre all'esecuzione di script e all'invio di (semplici) e-mail, l'EC dispone di un terzo tipo di azione: l'invio di notifiche tramite il sistema di notifica di Checkmk. Le notifiche possono essere generate dall'EC allo stesso modo delle notifiche relative a host e servizi provenienti dal monitoraggio attivo. I vantaggi rispetto alle semplici e-mail descritte sopra sono evidenti:
La notifica è configurata per il monitoraggio attivo e basato sugli eventi in un unico punto centrale.
Sono disponibili funzionalità come le notifiche di massa, le e-mail in HTML e altre funzioni utili.
Le regole di notifica personalizzate, la disattivazione delle notifiche e simili funzionano come al solito.
Il tipo di azione "Send monitoring notification" viene sempre processato automaticamente e non necessita di configurazione.
Poiché gli eventi differiscono in qualche modo dagli host o dai servizi "normali", ci sono alcune peculiarità nelle loro notifiche, che puoi approfondire nella sezione seguente.
Assegnazione agli host esistenti
Gli eventi possono provenire da qualsiasi host, indipendentemente dal fatto che siano configurati nel monitoraggio attivo o meno. Dopotutto, le porte syslog e SNMP sono aperte a tutti gli host della rete. Di conseguenza, gli attributi estesi dell'host come alias, tag host, contatti, ecc. inizialmente non sono disponibili. Questo in particolare è il motivo per cui le condizioni nelle regole di notifica non funzionano necessariamente come ti aspetteresti.
Ad esempio, durante la notifica, l'EC cerca di trovare un host all'interno del monitoraggio attivo che corrisponda all'evento. Questo viene fatto utilizzando la stessa procedura usata per la visibilità degli eventi. Se si riesce a trovare un host del genere, da questo host vengono prelevati i seguenti dati:
L'ortografia corretta del nome host.
L'alias dell'host
L'indirizzo IP primario configurato in Checkmk.
Tag host
La cartella nella GUI di Setup
L'elenco dei contatti e dei gruppi di contatto
Di conseguenza, il nome host nella notifica elaborata potrebbe non corrispondere esattamente al nome host nel messaggio originale. La codifica dei testi delle notifiche in linea con 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 gira nello stesso sito dell'EC che ha ricevuto il messaggio. Ovviamente questo funziona solo se i messaggi syslog, le SNMP trap ecc. vengono sempre inviati al sito Checkmk su cui l'host è attivamente monitorato!
Se la query non funziona o l'host non viene trovato, verranno accettati dati sostitutivi:
Nome host |
Il nome host dell'evento. |
Alias host |
Il nome host verrà utilizzato come alias. |
indirizzo IP |
Il campo dell'indirizzo IP contiene l'indirizzo del mittente originale del messaggio. |
Tag host |
L'host non riceverà un tag host. Se hai gruppi di tag host con tag vuoti, l'host adotta quei tag, ma in caso contrario non ha tag dal gruppo. Tienilo a mente quando definisci condizioni che fanno riferimento ai tag host nelle regole di notifica. |
Setup cartella GUI |
Nessuna cartella. Tutte le condizioni che rimandano a una cartella specifica sono quindi inapplicabili, anche nel caso della cartella Main. |
Contatti |
L'elenco dei contatti è vuoto. Se sono presenti contatti di riserva, questi verranno inseriti. |
Se l'host non può essere assegnato nel monitoraggio attivo, questo può ovviamente causare problemi con le notifiche. Da un lato a causa delle condizioni, che potrebbero non essere più applicabili, e dall'altro a causa della selezione dei contatti. In questi casi puoi modificare le tue regole di notifica in modo che le notifiche provenienti dalla Console degli Eventi vengano gestite in modo specifico utilizzando le proprie regole. A questo scopo esiste una condizione separata con la quale puoi corrispondere positivamente solo alle notifiche EC, oppure, al contrario, escluderle:
Campi di notifica rimanenti
Affinché le notifiche provenienti dall'EC passino attraverso il sistema di notifica del monitoraggio attivo, l'EC deve essere adattato per conformarsi al suo schema. In questo processo, i campi dati tipici di una notifica vengono compilati nel modo più efficace possibile. Abbiamo appena descritto come vengono determinati i dati dell'host. Altri campi sono:
Tipo di notifica |
Le notifiche EC sono sempre considerate messaggi di servizio. |
Descrizione del servizio |
Questo è il contenuto del campo "Application" dell'evento. Se questo campo è vuoto, verrà inserito " |
Numero di notifica |
È fissato su |
Data/Ora |
Per gli eventi che vengono conteggiati, questo è l'ora dell'ultima occorrenza di un messaggio associato all'evento. |
Output del plug-in |
Il contenuto testuale dell'evento. |
Stato del servizio |
Stato dell'evento, ovvero OK, WARN, CRIT o SCONOSCIUTO. |
Stato precedente |
Dato che gli eventi non hanno uno stato precedente, qui viene sempre inserito OK per gli eventi normali, mentre CRIT viene inserito quando si elimina un evento. Questa regola è quella che più si avvicina a ciò che serve per le regole di notifica che hanno una condizione sul cambiamento esatto di stato. |
Definizione manuale dei gruppi di contatto
Come descritto sopra, potrebbe non essere possibile determinare automaticamente i contatti per un evento. In questi casi puoi specificare i gruppi di contatti direttamente nella regola EC da utilizzare per la notifica. È importante non dimenticare di checkare la box "Use in notifications":
Switch globale per le notifiche
C'è un switch centrale per le notifiche nello snap-in Master control. Questo vale anche per le notifiche inoltrate dall'EC:
Proprio come per l'assegnazione dell'host, l'interrogazione dell'interruttore da parte dell'EC richiede l'accesso Livestatus al nucleo di monitoraggio locale. Una query riuscita è visibile nel file di log della Console degli Eventi:
[1482142567.147669] Notifications are currently disabled. Skipped notification for event 44Tempi di manutenzione programmati degli host
La Console degli Eventi è in grado di rilevare gli host che si trovano attualmente in un periodo di tempo di manutenzione programmata e non invia notifiche in tali situazioni. Nel file di log apparirà così:
[1482144021.310723] Host myserver123 is currently in scheduled downtime. Skipping notification of event 433.Ovviamente, questo richiede anche che l'host venga individuato correttamente nel monitoraggio attivo. Se ciò non avviene, si presume che l'host non sia in tempo di manutenzione programmata e verrà comunque generata una notifica.
Macro aggiuntive
Quando scrivi i tuoi script di notifica, specialmente per le notifiche provenienti dalla Console degli Eventi, saranno disponibili diverse variabili aggiuntive che descrivono l'evento originale (accessibili come al solito con il prefisso NOTIFY_):
|
ID evento. |
|
ID della regola che ha creato l'evento. |
|
Priorità syslog come numero compreso tra |
|
Funzionalità syslog — anch’essa espressa come numero. L’intervallo di valori va da |
|
Fase dell'evento. Dato che solo gli eventi aperti attivano le azioni, questo dovrebbe essere |
|
Il campo del commento dell'evento. |
|
Il campo "Owner". |
|
Il campo del commento con le informazioni di contatto specifiche dell'evento. |
|
L'ID del processo che ha inviato il messaggio (per gli eventi syslog). |
|
I gruppi di corrispondenza dalle corrispondenze nella regola. |
|
I gruppi di contatto opzionali definiti manualmente nella regola. |
6.4. Esecuzione delle azioni
Nella sezione Comandi sopra hai già imparato come l'operatore esegue manualmente le azioni. Ancora più interessante è l'esecuzione automatica delle azioni, che puoi configurare con le regole EC nella sezione "Outcome & Action":
Qui puoi selezionare una o più azioni che verranno eseguite ogni volta che un evento viene aperto o eliminato in base alla regola. Per quest'ultimo caso, puoi utilizzare l'elenco "Do cancelling actions" per specificare se l'azione deve essere eseguita solo se l'evento eliminato ha già raggiunto la fase "open". Quando si utilizzano il conteggio o il ritardo, può capitare che gli eventi che sono ancora in stato di attesa e non ancora visibili all'utente vengano eliminati.
L'esecuzione delle azioni viene registrata nel file di log var/log/mkeventd.log:
[1481120419.712534] Executing command: ACTION;1;cmkadmin;test
[1481120419.718173] Exitcode: 0Questi vengono scritti anche nell'archivio.
7. SNMP trap
7.1. Configurazione della ricezione delle SNMP trap
Dato che la Console degli Eventi ha un proprio motore SNMP integrato, configurare la ricezione delle SNMP trap è semplicissimo.
Non hai bisogno di unsnmptrapde dal sistema operativo!
Se ne hai già uno in esecuzione, fermalo.
Come descritto nella sezione dedicata al Setup della Console degli Eventi, usa omd config per abilitare il ricevitore di trap in questa istanza:
Poiché su ogni server la porta UDP per le trap può essere utilizzata da un solo processo, questa operazione può essere eseguita solo in un'istanza Checkmk per computer.
All'avvio dell'istanza, nella riga contenente mkeventd puoi verificare se la ricezione delle trap è stata abilitata:
Affinché le SNMP trap funzionino, il mittente e il destinatario devono concordare determinate credenziali. Nel caso di SNMPv1 e v2c si tratta di una semplice password, nota come "Community". Con la versione 3 sono necessarie alcune credenziali in più. Puoi configurare queste credenziali nelle impostazioni della Console degli Eventi alla voce "Credentials for processing SNMP traps". Puoi utilizzare il pulsante "Add new element" per impostare diverse credenziali che possono essere utilizzate come alternative dai dispositivi SNMP:
La parte molto più complessa ora è, ovviamente, specificare l'indirizzo di destinazione per tutti i dispositivi da sottoporre a monitoraggio e configurare le credenziali anche qui.
7.2. Test
Purtroppo pochissimi dispositivi offrono funzionalità di test significative.
Almeno puoi testare facilmente la ricezione delle trap manualmente utilizzando la stessa Console degli Eventi inviando una trap di prova — preferibilmente da un altro sistema Linux.
Questo può essere fatto con il comando snmptrap.
L'esempio seguente invia una trap a 192.168.178.11.
Il nome host del mittente è specificato dopo .1.3.6.1 e deve essere risolvibile o specificato come indirizzo IP (qui 192.168.178.30):
Se nelle impostazioni hai impostato l'Log levele su Verbose logging, potrai vedere la ricezione e la valutazione delle trap nel file di log dell'EC:
[1482387549.481439] Trap received from 192.168.178.30:56772. Checking for acceptance now.
[1482387549.485096] Trap accepted from 192.168.178.30 (ContextEngineId "0x80004fb8054b6c617070666973636816893b00", ContextName "")
[1482387549.485136] 1.3.6.1.2.1.1.3.0 = 329887
[1482387549.485146] 1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.0.17
[1482387549.485186] 1.3.6.1.6.3.18.1.3.0 = 192.168.178.30
[1482387549.485219] 1.3.6.1.6.3.18.1.4.0 =
[1482387549.485238] 1.3.6.1.6.3.1.1.4.3.0 = 1.3.6.1
[1482387549.485258] 1.3.6.1 = Just kiddingIn caso di credenziali errate, vedrai solo una singola riga:
[1482387556.477364] Trap received from 192.168.178.30:56772. Checking for acceptance now.Ed ecco come appare un evento generato da una trap di questo tipo:
7.3. Trasformare i numeri in testo: tradurre i trap
SNMP è un protocollo binary ed è molto parsimonioso nelle descrizioni testuali dei messaggi.
Il tipo di trap viene comunicato internamente tramite una sequenza di numeri nei cosiddetti OID.
Questi vengono visualizzati come sequenze di numeri separati da punti (ad es. 1.3.6.1.6.3.18.1.3.0).
Con l'aiuto dei cosiddetti file MIB, la Console degli Eventi può tradurre queste sequenze numeriche in testo.
Quindi, ad esempio, 1.3.6.1.6.3.18.1.3.0 diventa il testo SNMPv2-MIB::sysUpTime.0.
La traduzione dei trap può essere abilitata nelle impostazioni della Console degli Eventi:
Il trap di prova di cui sopra ora genera un evento leggermente diverso:
Se hai attivato l'opzione "Add OID descriptions", il tutto diventa molto più dettagliato — e più confuso. Aiuta comunque a capire meglio cosa fa effettivamente una trap:
7.4. Caricare i tuoi MIB
Purtroppo, i vantaggi dell’open source non si sono ancora diffusi tra gli autori dei file MIB, e quindi noi del progetto Checkmk non siamo in grado di fornire file MIB specifici per i vari produttori.
È preinstallata solo una piccola raccolta di MIB di base gratuiti, che ad esempio fornisce una traduzione di sysUpTime.
Puoi comunque aggiungere questi file alla Console degli Eventi nel modulo SNMP MIBs for trap translation tramite la voce di menu Add one or multiple MIBs per caricare i tuoi file MIB, come ha fatto chi segue con alcuni MIB provenienti dagli switch intelligenti Netgear:
Note sui MIB:
Invece di singoli file, puoi anche caricare file ZIP contenenti raccolte di MIB in un'unica operazione.
I MIB hanno dipendenze tra loro. I MIB mancanti ti verranno segnalati da Checkmk.
I MIB caricati vengono utilizzati anche sulla riga di comando da
cmk --snmptranslate.
8. Monitoraggio dei file di log
L'agente Checkmk è in grado di analizzare i file di log tramite il plug-in logwatch. Questo plug-in offre innanzitutto un proprio monitoraggio dei file di log indipendente dalla Console degli Eventi, compresa la possibilità di effettuare il riconoscimento dei messaggi direttamente nel monitoraggio. C'è anche la possibilità di trasferire i messaggi rilevati dal plug-in 1:1 nella Console degli Eventi.
Nell’agente Windows, il monitoraggio dei file di log è integrato in modo permanente — sotto forma di un plug-in per l’analisi dei file di testo e uno per l’analisi dei registri eventi di Windows.
Il plug-in scritto in Python mk_logwatch è disponibile per Linux e Unix.
È possibile accedere a tutti e tre tramite l’agent bakery per la loro installazione o configurazione.
Usa i seguenti set di regole per farlo:
Text logfiles (Linux, Solaris, Windows)
Finetune Windows Eventlog monitoring
La configurazione precisa del plug-in logwatch non è oggetto di questo articolo. Ciò che è importante, tuttavia, è che tu esegua comunque il miglior pre-filtraggio possibile dei messaggi all’interno dello stesso plug-in logwatch e non ti limiti a inviare l’intero contenuto dei file di testo alla Console degli Eventi.
Non confondere questo con la successiva riclassificazione tramite il set di regole "Logfile patterns". Questo può solo modificare lo stato dei messaggi che sono già stati inviati dall'agente. Tuttavia, se hai già impostato questi modelli e vuoi semplicemente switchare da logwatch alla Console degli Eventi, puoi mantenere i modelli. A questo scopo, le regole di inoltro (Logwatch Event Console Forwarding) includono l'opzione "Reclassify messages before forwarding them to the EC".
In questo caso, tutti i messaggi passano attraverso un totale di tre catene di regole: sull'agente, attraverso la riclassificazione e nella Console degli Eventi!
Ora modifica logwatch in modo che i messaggi rilevati dai plug-in non vengano più monitorati con il normale controllo di logwatch, ma semplicemente inoltrati 1:1 alla Console degli Eventi ed elaborati lì. Questo si ottiene con il set di regole Logwatch Event Console Forwarding:
Alcune note a questo proposito:
Se hai un ambiente distribuito in cui ogni istanza non dispone di una propria Console degli Eventi, le istanze remote devono inoltrare i propri messaggi all'istanza centrale tramite syslog.
L'impostazione predefinita per questo è UDP, tuttavia non si tratta di un protocollo sicuro.
Una soluzione migliore è utilizzare syslog tramite TCP, ma dovrai abilitarlo nell'istanza centrale (omd config).
Durante l'inoltro, specifica un Syslog facility.
In questo modo potrai riconoscere facilmente i messaggi inoltrati nella EC.
Adatti a questo scopo sono local0 a local7.
Con List of expected logfiles puoi effettuare il monitoraggio dell'elenco dei file di log previsti ed essere avvisato se determinati file non vengono trovati come previsto.
Importante: il solo salvataggio della regola non serve a nulla. Questa regola diventa attiva solo durante la scoperta del servizio. Solo quando la esegui di nuovo, i precedenti servizi logwatch verranno rimossi e al loro posto verrà creato un nuovo servizio chiamato Log Forwarding per ogni host.
Questo check ti mostrerà anche in seguito se dovessero verificarsi problemi durante l'inoltro alla Console degli Eventi.
8.1. Livello del servizio e priorità syslog
Poiché i file di log inoltrati spesso non dispongono di una classificazione syslog a seconda del formato utilizzato, puoi definire la riclassificazione nel set di regole Logwatch Event Console Forwarding in Log Forwarding. Inoltre, nei set di regole che definisci come parte dell'Rule packs, è sempre possibile impostare individualmente lo stato e i livelli del servizio.
9. Stato degli eventi nel monitoraggio attivo
Se vuoi anche vedere quali host nel monitoraggio attivo hanno attualmente eventi problematici aperti, puoi aggiungere un active check per ogni host che riassume lo stato attuale degli eventi dell'host. Per un host senza eventi aperti, apparirà così:
Se ci sono solo eventi nello stato "OK", il check mostra il loro numero, ma rimane verde:
Ecco un esempio di un caso con eventi aperti nello stato "CRIT":
Puoi creare questo active check utilizzando una regola nel set di regole "Check event state in Event Console". Puoi anche specificare se gli eventi che sono già stati confermati debbano comunque contribuire allo stato:
Con l'opzione "Application (regular expression)" puoi limitare il controllo agli eventi che contengono un testo specifico nel campo dell'applicazione. In questo caso può avere senso avere più di un controllo degli eventi su un host e separare i controlli per applicazione. Affinché questi siano distinguibili in base al nome, hai bisogno anche dell'opzione "Item (used in service description)", che aggiunge un testo da te specificato al nome del servizio.
Se la tua Console degli Eventi non è in esecuzione sullo stesso sito Checkmk di quello che monitora l'host, devi impostare Access to Event Console per un accesso remoto via TCP:
Affinché ciò funzioni, la Console degli Eventi deve consentire l'accesso tramite TCP. Puoi configurarlo nelle impostazioni della Console degli Eventi a cui si desidera accedere:
10. L'archivio
10.1. Come funziona l'archivio
La Console degli Eventi tiene un registro di tutte le modifiche apportate a un evento. Puoi trovare questo registro in due modi:
Nella visualizzazione globale "Recent event history", che trovi in "Monitor > Event Console".
Nei dettagli di un evento tramite la voce di menu "Event Console Event > History of Event".
Nella visualizzazione globale c'è un filtro che mostra solo gli eventi delle ultime 24 ore. Tuttavia, come al solito, puoi personalizzare i filtri.
La figura seguente mostra la cronologia dell'evento 33, che ha subito un totale di quattro modifiche.
In primo luogo l'evento è stato creato (NEW),
poi lo stato è stato modificato manualmente da OK a WARN (CHANGESTATE),
quindi è stato effettuato un riconoscimento con l'aggiunta di un commento (UPDATE) e
infine l'evento è stato archiviato/eliminato (DELETE):
L'archivio contiene i seguenti tipi di azione, visualizzati nella colonna "Action":
| Tipo di azione | Descrizione |
|---|---|
|
L'evento è stato appena creato (a seguito di un messaggio ricevuto o di una regola che prevedeva un messaggio che non è arrivato). |
|
L'evento è stato modificato dall'operatore (modifica del commento, delle informazioni di contatto o del riconoscimento). |
|
L'evento è stato archiviato. |
|
L'evento è stato automaticamente eliminato da un messaggio OK. |
|
Lo stato dell'evento è stato modificato dall'operatore. |
|
L'evento è stato archiviato automaticamente perché non è stata applicata alcuna regola e l'archiviazione automatica (Force message archiving) era abilitata nelle impostazioni globali. |
|
L'evento è stato archiviato automaticamente perché, mentre si trovava nella fase "counting", la regola associata è stata eliminata. |
|
L'evento è stato spostato dall'archivio temporaneo (counting) all'archivio definitivo (open) perché è stato raggiunto il numero di messaggi configurato. |
|
L'evento è stato archiviato automaticamente perché non è stato raggiunto il numero richiesto di messaggi in "counting". |
|
L'evento è stato archiviato automaticamente perché, mentre si trovava nella fase "counting", la regola associata è stata modificata in "non contare". |
|
L'evento è stato aperto perché il ritardo configurato nella regola è scaduto. |
|
L'evento è stato archiviato automaticamente perché la sua durata configurata era scaduta. |
|
È stata inviata un'e-mail. |
|
È stata eseguita un'azione automatica (script). |
|
L'evento è stato archiviato automaticamente subito dopo l'apertura, poiché ciò era configurato nella regola corrispondente. |
10.2. Posizione dell'archivio
Come accennato in precedenza, l'archivio della Console degli Eventi non è stato progettato come un archivio syslog a tutti gli effetti.
Per mantenere l'implementazione e soprattutto l'amministrazione il più semplici possibile, è stato omesso un back-end di database.
L'archivio viene invece scritto in semplici file di testo.
Ogni voce è costituita da una riga di testo, che contiene colonne separate da tabulazioni.
Puoi trovare i file in ~/var/mkeventd/history:
Per impostazione predefinita, ogni giorno viene avviato automaticamente un nuovo file. Nelle impostazioni della Console degli Eventi puoi personalizzare la rotazione del file. L'impostazione Event history logfile rotation ti permette di switchare a una rotazione settimanale.
I nomi dei file seguono il tempo Unix dal momento della creazione del file (secondi dal 1/1/1970 UTC).
I file vengono conservati per 365 giorni, a meno che non modifichi questa impostazione in "Event history lifetime". Inoltre, i file vengono registrati anche dalla gestione centrale dello spazio su disco di Checkmk, che può essere configurata nelle impostazioni globali alla voce "Site management". In questo caso, si applica il limite di tempo più breve impostato in ciascun caso. La gestione globale ha il vantaggio che, qualora lo spazio libero su disco dovesse diventare marginale, elimina automaticamente i dati storici di Checkmk in modo coerente, a partire dai più vecchi.
Se dovessi avere problemi di spazio, puoi anche semplicemente eliminare manualmente i file nella directory o spostarli altrove. Non inserire file compressi o di altro tipo in questa directory.
10.3. Archiviazione automatica
Nonostante i limiti dei file di testo, è teoricamente possibile archiviare un gran numero di messaggi nella Console degli Eventi. La scrittura nei file di testo dell’archivio è molto performante, ma a costo di una ricerca successiva meno efficiente. Poiché i file hanno come indice solo il periodo della richiesta, per ogni richiesta tutti i file rilevanti devono essere letti e cercati per intero.
Normalmente l'EC scriverà nell'archivio solo i messaggi per i quali è stato effettivamente aperto un evento. Puoi farlo in due modi diversi per estendere questa funzione a tutti gli eventi:
Crea una regola che corrisponda a tutti gli eventi (successivi) e, in "Outcome & actions", attiva l'opzione "Delete event immediately after the actions".
Attiva il switch "Force message archiving" nelle impostazioni della Console degli Eventi.
Quest'ultima opzione garantisce che i messaggi che non sono soggetti ad alcuna regola vengano comunque scritti nell'archivio (tipo di azione "ARCHIVED").
11. Performance e ottimizzazione
11.1. Elaborazione dei messaggi
Anche in un'epoca in cui i server hanno 64 core e 2 TB di memoria principale, la performance del software continua a giocare un ruolo importante. Soprattutto nell'elaborazione degli eventi, in situazioni estreme i messaggi in arrivo possono andare persi.
Il motivo è che nessuno dei protocolli utilizzati (syslog, SNMP trap, ecc.) prevede il controllo del flusso. Se migliaia di host inviano messaggi contemporaneamente ogni secondo, il destinatario non ha alcuna possibilità di rallentarli.
Pertanto, in ambienti un po' più grandi, è importante tenere d'occhio i tempi di elaborazione dei messaggi. Questo dipende da quante regole hai definito e da come sono strutturate.
Misurare la performance
Per misurare la performance è disponibile uno snap-in separato per la barra laterale denominato "Event Console Performance".
Puoi aggiungerlo come al solito con "
":
I valori qui mostrati sono medie relative all'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 livellati e sono quindi più facili da leggere.
Per testare le prestazioni massime, puoi generare artificialmente una tempesta di messaggi non classificati (per favore, solo nel sistema di test!), ad esempio in un ciclo di shell scrivendo continuamente il contenuto di un file di testo nel pipe degli eventi.
I valori più importanti dello snap-in hanno il seguente significato:
| Valore | Significato |
|---|---|
Received messages |
Numero di messaggi ricevuti al secondo. |
Rule tries |
Numero di regole che vengono provate. Questo fornisce informazioni preziose sull'efficienza della catena di regole, specialmente insieme al parametro successivo. |
Rule hits |
Numero di regole al secondo che vengono attualmente applicate. Queste possono anche essere regole che scartano i messaggi o che si limitano a contarli. Pertanto, non ogni applicazione di una regola genera un evento. |
Rule hit ratio |
Il rapporto tra Rule tries e Rule hits. In altre parole: quante regole deve provare l'EC prima che una (finalmente) abbia effetto. Nell'esempio dello screenshot il tasso è preoccupantemente basso. |
Created events |
Numero di nuovi eventi creati al secondo. Dato che la Console degli Eventi dovrebbe mostrare solo i problemi rilevanti (paragonabili ai problemi di host e servizi dal monitoraggio), il numero |
Processing time per message |
Qui puoi leggere quanto tempo ci è voluto per elaborare un messaggio. Attenzione: in generale questo non è l'inverso di Received messages. Perché mancano ancora i tempi in cui la Console degli Eventi non aveva nulla da fare, semplicemente perché non sono arrivati messaggi. Qui misuri davvero il tempo reale puro trascorso tra l'arrivo di un messaggio e il completamento finale dell'elaborazione. Puoi vedere approssimativamente quanti messaggi la Console degli Eventi può handle in un dato periodo di tempo. Nota anche che questo non è il tempo CPU, ma il tempo reale. Su un sistema con CPU libere a sufficienza, questi tempi sono più o meno gli stessi. Ma non appena il sistema è così sotto carico che non tutti i processi ottengono sempre una CPU, il tempo reale può diventare molto più alto. |
Suggerimenti per l'ottimizzazione
Puoi vedere quanti messaggi la Console degli Eventi è in grado di elaborare al secondo dall'Processing time per message. Questo tempo è generalmente correlato al numero di regole che devono essere provate prima che un messaggio venga elaborato. Qui hai diverse opzioni per l'ottimizzazione:
Le regole che escludono moltissimi messaggi dovrebbero essere posizionate il più possibile all'inizio della catena di regole.
Utilizza i pacchetti di regole per raggruppare insiemi di regole correlate. La prima regola di ogni pacchetto dovrebbe uscire immediatamente dal pacchetto se la condizione di base comune non è soddisfatta.
Inoltre, nell'EC è presente un'ottimizzazione basata sulla priorità e sulla facility di syslog. Per ogni combinazione di priorità e facility, viene creata internamente una catena di regole separata in cui sono incluse solo le regole rilevanti per i messaggi di quella combinazione.
Ogni regola che contiene una condizione sulla priorità, sulla facility o, preferibilmente, su entrambe, non sarà inclusa in tutte queste catene di regole, ma solo in una, in modo ottimale. Ciò significa che non è necessario checkare la regola per i messaggi con una classificazione syslog diversa.
Dopo un riavvio, in ~/var/log/mkeventd.log vedrai una panoramica delle catene di regole ottimizzate:
[8488808306.233330] kern : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233343] user : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233355] mail : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233367] daemon : emerg(120) alert(89) crit(89) err(89) warning(89) notice(89) info(89) debug(89)
[8488808306.233378] auth : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233389] syslog : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233408] lpr : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233482] news : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233424] uucp : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233435] cron : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233446] authpriv : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233457] ftp : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233469] (unused 12) : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233480] (unused 13) : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233498] (unused 13) : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233502] (unused 14) : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233589] local0 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233538] local1 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233542] local2 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233552] local3 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233563] local4 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233574] local5 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233585] local6 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233595] local7 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233654] snmptrap : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)Nell'esempio sopra puoi vedere che in ogni caso ci sono 67 regole che devono essere controllate.
Per i messaggi provenienti dalla funzione daemon sono rilevanti 89 regole, solo per la combinazione daemon / emerg devono essere controllate 120 regole.
Ogni regola che riceve una condizione sulla priorità o sulla funzione riduce ulteriormente il numero da 67.
Ovviamente puoi impostare queste condizioni solo se sei sicuro che siano soddisfatte dai messaggi in questione!
11.2. Il numero di eventi attuali
Anche il numero di eventi attualmente presenti può influire sulla performance dell'EC, cioè quando diventa davvero fuori controllo. Come detto prima, l'EC non va vista come un sostituto di un archivio syslog, ma solo per mostrare i "problemi attuali". La Console degli Eventi può sicuramente gestire diverse migliaia di problemi, ma non è questo il suo vero scopo.
Non appena il numero di eventi attuali supera circa 5 000, la performance inizia a deteriorarsi in modo evidente. Da un lato, questo si nota nella GUI, che reagisce più lentamente alle richieste. D'altro canto, anche l'elaborazione diventa più lenta, poiché in alcune situazioni i messaggi devono essere confrontati con tutti gli eventi attuali. Anche i requisiti di memoria possono diventare problematici.
Per motivi di performance, la Console degli Eventi mantiene sempre tutti gli eventi attuali nella RAM.
Questi vengono scritti nel file ~/var/mkeventd/status una volta al minuto (regolabile) e al completamento dell'elaborazione.
Se questo file diventa molto grande (ad esempio oltre 50 megabyte), anche questo processo diventa sempre più lento.
Puoi checkare rapidamente la dimensione attuale con ll. (alias per ls -alF):
Se hai troppi eventi correnti a causa di una regola mal concepita (ad esempio una che corrisponde a tutto), un'eliminazione manuale tramite la GUI non è ragionevolmente possibile. In questo caso, basterà semplicemente eliminare il file di stato:
Attenzione: ovviamente, tutti gli eventi attuali andranno persi, così come il contatore memorizzato e altri stati. In particolare, i nuovi eventi ricominceranno con l'ID 1.
Protezione automatica da overflow
La Console degli Eventi dispone di una protezione automatica contro l'overflow. Questa limita il numero di eventi attuali per host, per regola e a livello globale. Non vengono conteggiati solo gli eventi aperti, ma anche quelli in altre fasi, come "delayed" o "counting". Gli eventi archiviati non vengono conteggiati.
Questo ti proteggerà in situazioni in cui, a causa di un problema sistematico sulla tua rete, migliaia di eventi critici stanno inondando il sistema e la Console degli Eventi rischierebbe di "bloccarsi". Da un lato, questo impedisce un calo delle prestazioni della Console degli Eventi, che dovrebbe contenere troppi eventi nella sua memoria principale. D'altro canto, 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 verificherà una delle seguenti azioni:
La creazione di nuovi eventi viene interrotta (per questo host, per questa regola o a livello globale).
Lo stesso, ma in più viene creato un "evento di overflow".
Lo stesso, ma in più vengono avvisati i contatti appropriati.
In alternativa alle tre varianti sopra indicate, puoi anche far cancellare l'evento più vecchio per fare spazio a quello nuovo.
I limiti e l'effetto associato 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 informa l'operatore della situazione di errore:
Se hai inoltre abilitato un valore con "…notify contacts", i contatti appropriati saranno avvisati tramite notifica Checkmk. Tale notifica seguirà le regole di notifica di 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 è l'impostazione predefinita):
| Limite | Selezione dei contatti |
|---|---|
per host |
I contatti dell'host, determinati allo stesso modo delle notifiche degli eventi tramite Checkmk. |
per regola |
Lascia vuoto il campo del nome host. Se nella regola sono definiti gruppi di contatti, questi verranno selezionati, altrimenti si applicheranno i contatti di riserva. |
Globali |
I contatti di riserva. |
11.3. Archivio troppo grande
Come mostrato sopra, la Console degli Eventi dispone di un archivio di tutti gli eventi e delle relative fasi di elaborazione. Questo è memorizzato in file di testo per facilitare l'implementazione e l'amministrazione.
I file di testo sono difficili da battere in termini di performance durante la scrittura dei dati — utilizzando database, ad esempio, solo con un enorme sforzo di ottimizzazione. Ciò è dovuto, tra gli altri fattori, all’ottimizzazione di questo tipo di accesso da parte di Linux e alla gerarchia di memoria completa di dischi e SAN. Tuttavia, ciò va a discapito degli accessi in lettura. Poiché i file di testo non dispongono di un indice, è necessaria una lettura completa quando si effettua una ricerca nei file.
Nella sua forma più semplice, la Console degli Eventi utilizza i nomi dei file di log come indice per l'ora degli eventi. Più limiti il periodo di ricerca, più veloce sarà la ricerca.
Tuttavia, è molto importante che il tuo archivio non diventi troppo grande. Se usi la Console degli Eventi solo per elaborare messaggi di errore reali, questo non può realmente accadere. Se provi a usare la Console degli Eventi come sostituto di un vero archivio syslog, questo può portare a file molto grandi.
Se ti trovi in una situazione in cui il tuo archivio è diventato troppo grande, puoi semplicemente eliminare i file più vecchi in ~/var/mkeventd/history/.
Inoltre, in Event history lifetime puoi generalmente limitare la durata dei dati in modo che l'eliminazione sia l'impostazione predefinita in futuro.
Per impostazione predefinita vengono conservati 365 giorni.
Forse puoi cavartela con molto meno.
11.4. Misurazione della performance nel tempo
Checkmk avvia automaticamente un servizio per ogni istanza della Console degli Eventi, che registra i dati sulle prestazioni sotto forma di grafici e ti avvisa in caso di sovraccarichi.
A condizione che tu abbia installato un agente Linux sul server di monitoraggio, il check verrà individuato automaticamente e configurato come al solito:
Il controllo offre moltissimi tipi di misurazione interessanti, ad esempio il numero di messaggi in arrivo per ogni periodo di tempo e quanti di essi sono stati scartati:
L'efficienza della tua catena di regole è rappresentata da un confronto tra le regole testate e quelle che hanno funzionato:
Questo grafico mostra il tempo medio necessario per elaborare un messaggio:
Ci sono anche diversi altri grafici.
12. Monitoraggio distribuito
Per sapere come utilizzare la Console degli Eventi in un'installazione con più istanze Checkmk, consulta l'articolo sul monitoraggio distribuito.
13. L'interfaccia di stato
La Console degli Eventi, tramite il socket Unix ~/tmp/run/mkeventd/status, offre sia l'accesso allo stato interno sia la possibilità di eseguire comandi.
Il protocollo utilizzato qui è un sottoinsieme fortemente limitato di Livestatus.
A questa interfaccia accede il nucleo di monitoraggio, che trasmette i dati alla GUI per fornire un monitoraggio distribuito anche per la Console degli Eventi.
Le seguenti restrizioni si applicano al Livestatus semplificato della Console degli Eventi:
Le uniche intestazioni consentite sono
Filter:eOutputFormat:.Pertanto non è possibile il KeepAlive, è possibile effettuare una sola richiesta per connessione.
Sono disponibili le seguenti tabelle:
|
Elenca l'elenco degli eventi attuali. |
|
Accesso all'archivio. Una query su questa tabella consentirà di accedere ai file di testo dell'archivio. Assicurati di applicare un filtro in base alla data della voce per evitare l'accesso completo a tutti i file. |
|
Valori di stato e performance dell'EC. Questa tabella ha sempre esattamente una riga. |
I comandi possono essere scritti nel socket utilizzando unixcat con una sintassi molto semplice:
Sono disponibili i seguenti comandi:
|
Archivia un evento. Argomenti: ID evento e abbreviazione utente. |
|
Ricarica la configurazione. |
|
Esce dalla Console degli Eventi. |
|
Riapre il file di log. Questo comando è necessario per la rotazione del file di log. |
|
Elimina tutti gli eventi correnti e archiviati. |
|
Avvia un aggiornamento immediato del file " |
|
Azzeri i contatori di occorrenza delle regole (corrisponde alla voce di menu "Event Console > Reset counters" nella GUI di configurazione). |
|
Esegue un aggiornamento da un evento. Gli argomenti sono, nell'ordine: ID evento, abbreviazione utente, conferma (0/1), commento e informazioni di contatto. |
|
Modifica gli stati OK / WARN / CRIT / SCONOSCIUTO di un evento. Gli argomenti sono l'ID dell'evento, l'abbreviazione dell'utente e la cifra di stato ( |
|
Esegue un'azione definita dall'utente su un evento. Gli argomenti sono l'ID dell'evento, l'abbreviazione dell'utente e l'ID dell'azione. L'ID speciale |
14. File e directory
| Percorso del file | Descrizione |
|---|---|
|
Cartella di lavoro del daemon degli eventi. |
|
Stato attuale completo della Console degli Eventi. Include principalmente tutti gli eventi attualmente aperti (e quelli in fase di transizione come "counting" ecc.). In caso di una configurazione errata che porta a molti eventi aperti, questo file può diventare enorme e ridurre drasticamente la performance della Console degli Eventi. In una situazione del genere puoi arrestare il servizio " |
|
Percorso del file di archivio. |
|
File di log della Console degli Eventi. |
|
Le impostazioni globali della Console degli Eventi in sintassi Python. |
|
Tutti i tuoi pacchetti di regole e le regole configurate in sintassi Python. |
|
Un pipe con nome in cui puoi scrivere messaggi direttamente con |
|
Un socket Unix che svolge la stessa funzione del pipe, ma consente a più applicazioni di scriverci contemporaneamente. Per scriverci, è necessario il comando |
|
L'ID del processo corrente del daemon degli eventi mentre è in esecuzione. |
|
Un socket Unix che permette di interrogare lo stato attuale e inviare comandi. Le richieste della GUI vanno prima al nucleo di monitoraggio, che poi accede a questo socket. |
|
File MIB caricati da te per la traduzione delle SNMP trap. |