1 Correlazione di eventi basata su trigger

Panoramica

La correlazione degli eventi basata sui trigger consente di correlare problemi separati segnalati da un trigger.

Sebbene in generale un evento OK possa chiudere tutti gli eventi problema creati da un trigger, ci sono casi in cui è necessario un approccio più dettagliato. Per esempio, durante il monitoraggio dei file di log potresti voler individuare determinati problemi in un file di log e chiuderli singolarmente anziché tutti insieme.

Questo è il caso dei trigger con il parametro PROBLEM event generation mode impostato su Multiple. Tali trigger sono normalmente utilizzati per il monitoraggio dei log, l'elaborazione delle trap, ecc.

In Zabbix è possibile mettere in relazione gli eventi problema in base ai tag. I tag vengono utilizzati per estrarre valori e creare un'identificazione per gli eventi problema. Sfruttando questo, i problemi possono anche essere chiusi singolarmente in base alla corrispondenza del tag.

In altre parole, lo stesso trigger può creare eventi separati identificati dal tag dell'evento. Pertanto gli eventi problema possono essere identificati uno per uno e chiusi separatamente in base all'identificazione tramite il tag dell'evento.

Come funziona

Nel monitoraggio dei log potresti incontrare righe simili a queste:

Riga1: Service 1 stopped
Riga2: Service 2 stopped
Riga3: Service 1 was restarted
Riga4: Service 2 was restarted

L'idea della correlazione degli eventi è poter associare l'evento di problema della Riga1 alla risoluzione della Riga3 e l'evento di problema della Riga2 alla risoluzione della Riga4, e chiudere questi problemi uno per uno:

Riga1: Service 1 stopped
Riga3: Service 1 was restarted #problema della Riga 1 chiuso

Riga2: Service 2 stopped
Riga4: Service 2 was restarted #problema della Riga 2 chiuso

Per fare questo è necessario assegnare a questi eventi correlati dei tag come, ad esempio, "Service 1" e "Service 2". Questo può essere fatto applicando una espressione regolare alla riga di log per estrarre il valore del tag. Quindi, quando gli eventi vengono creati, ricevono rispettivamente i tag "Service 1" e "Service 2" e il problema può essere associato alla risoluzione.

Configurazione

Item

Per iniziare, potresti voler configurare un item che monitori un file di log, ad esempio:

log[/var/log/syslog]

Una volta configurato l'item, attendi un minuto affinché le modifiche di configurazione vengano recepite, quindi vai a Ultimi dati per assicurarti che l'item abbia iniziato a raccogliere dati.

Trigger

Con l'item funzionante, è necessario configurare il trigger. È importante decidere quali voci nel file di log meritano attenzione. Ad esempio, la seguente espressione del trigger cercherà una stringa come 'Stopping' per segnalare potenziali problemi:

find(/My host/log[/var/log/syslog],,"regexp","Stopping")=1 

Quindi definire un'espressione di ripristino. La seguente espressione di ripristino risolverà tutti i problemi se viene trovata una riga di log contenente la stringa "Starting":

find(/My host/log[/var/log/syslog],,"regexp","Starting")=1 

Poiché non vogliamo questo, è importante assicurarsi in qualche modo che vengano chiusi i corrispondenti problemi radice, non semplicemente tutti i problemi. È qui che il tagging può essere d'aiuto.

I problemi e le risoluzioni possono essere associati specificando un tag nella configurazione del trigger. Devono essere effettuate le seguenti impostazioni:

• Modalità di generazione degli eventi di problema: Multiple
• L'evento OK chiude: Tutti i problemi se i valori dei tag corrispondono
• Inserire il nome del tag per la corrispondenza degli eventi

• configurare i tag per estrarre i valori dei tag dalle righe di log

Se configurato correttamente, sarà possibile vedere gli eventi di problema etichettati per applicazione e associati alla loro risoluzione in Monitoring → Problems.

• Le macro indicizzate fanno sempre riferimento al campo Expression della configurazione del trigger, non alla Recovery expression. Ad esempio, in un evento di ripristino, {ITEM.VALUE1} verrà risolta nel valore più recente del primo item nell'espressione del problema al momento del ripristino. Se l'espressione di ripristino si basa su un item diverso e il valore dell'item dell'espressione del problema cambia entro il momento del ripristino, gli eventi otterranno tag diversi e non verranno correlati.

• Con due applicazioni che scrivono messaggi di errore e di ripristino nello stesso file di log, un utente può decidere di usare due tag service nello stesso trigger con valori di tag diversi utilizzando espressioni regolari separate nei valori dei tag per estrarre i nomi, ad esempio, del servizio A e del servizio B dalla macro {ITEM.VALUE} (ad es. quando i formati dei messaggi differiscono). Tuttavia, questo potrebbe non funzionare come previsto se non c'è corrispondenza con le espressioni regolari. Le regexp senza corrispondenza produrranno valori di tag vuoti e un singolo valore di tag vuoto sia negli eventi di problema sia negli eventi OK è sufficiente per correlarli. Quindi un messaggio di ripristino del servizio A può accidentalmente chiudere un messaggio di errore del servizio B.

• I tag effettivi e i valori dei tag diventano visibili solo quando un trigger si attiva. Se l'espressione regolare utilizzata non è valida, viene sostituita silenziosamente con una stringa *UNKNOWN*. Se l'evento di problema iniziale con un valore di tag *UNKNOWN* viene perso, possono comparire successivi eventi OK con lo stesso valore di tag *UNKNOWN* che possono chiudere eventi di problema che non avrebbero dovuto chiudere.

• Se un utente usa la macro {ITEM.VALUE} senza funzioni di macro come valore del tag, si applica il limite di 255 caratteri. Quando i messaggi di log sono lunghi e i primi 255 caratteri non sono specifici, anche questo può causare tag evento simili per problemi non correlati.