Correlazione degli 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 in funzione, è 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 

Definisci quindi 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 i corrispondenti problemi root vengano chiusi, non solo tutti i problemi. È qui che il tagging può aiutare.

I problemi e le risoluzioni possono essere associati specificando un tag nella configurazione del trigger. È necessario impostare le seguenti opzioni:

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

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

Se configurato correttamente, potrai vedere gli eventi problem taggati 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. Per esempio, in un evento di ripristino, {ITEM.VALUE1} risolverà al 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 al momento del ripristino, gli eventi avranno tag diversi e non verranno correlati.

• Con due applicazioni che scrivono messaggi di errore e di ripristino nello stesso file di log, un utente potrebbe 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 service A e del service B dalla macro {ITEM.VALUE} (ad esempio quando i formati dei messaggi differiscono). Tuttavia, questo potrebbe non funzionare come previsto se non c'è corrispondenza con le espressioni regolari. Le regexp non corrispondenti produrranno valori di tag vuoti e un singolo valore di tag vuoto sia negli eventi problem sia negli eventi OK è sufficiente per correlare gli eventi. Quindi un messaggio di ripristino del service A potrebbe chiudere accidentalmente un messaggio di errore del service 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 problem iniziale con un valore di tag *UNKNOWN* viene perso, potrebbero comparire successivi eventi OK con lo stesso valore di tag *UNKNOWN* che potrebbero chiudere eventi problem che non avrebbero dovuto chiudere.

• Se un utente usa la macro {ITEM.VALUE} senza funzioni 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, questo può anche generare tag di evento simili per problemi non correlati.