Correlazione degli eventi basata su trigger

Panoramica

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

Sebbene in generale un evento OK possa chiudere tutti gli eventi di problema creati da un trigger, in alcuni casi è necessario un approccio più dettagliato. Ad esempio, quando si monitorano file di log, potresti voler individuare determinati problemi in un file di log e chiuderli singolarmente anziché tutti insieme.

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

In Zabbix è possibile mettere in relazione gli eventi di problema in base al tagging. I tag vengono utilizzati per estrarre valori e creare un'identificazione per gli eventi di problema. Sfruttando questo meccanismo, i problemi possono anche essere chiusi singolarmente in base al tag corrispondente.

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

Come funziona

Nel monitoraggio dei log potresti incontrare righe simili a queste:

Line1: Service 1 stopped
Line2: Service 2 stopped
Line3: Service 1 was restarted
Line4: Service 2 was restarted

L'idea della correlazione degli eventi è poter associare l'evento di problema dalla Line1 alla risoluzione della Line3 e l'evento di problema dalla Line2 alla risoluzione della Line4, chiudendo questi problemi uno per uno:

Line1: Service 1 stopped
Line3: Service 1 was restarted #problem from Line 1 closed

Line2: Service 2 stopped
Line4: Service 2 was restarted #problem from Line 2 closed

Per fare ciò, devi assegnare un tag a questi eventi correlati, 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. Poi, quando gli eventi vengono creati, vengono taggati rispettivamente come "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 acquisite, quindi vai a Latest data per verificare 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.

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

• Problem event generation mode: Multiple
• OK event closes: All problems if tag values match
• 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 di problema 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 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 di, ad esempio, service A e 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 senza corrispondenza produrranno valori di tag vuoti e un singolo valore di tag vuoto sia negli eventi di problema sia in quelli OK è sufficiente per correlare gli eventi. Quindi un messaggio di ripristino di service A potrebbe chiudere accidentalmente un messaggio di errore di 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 di problema 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 di problema 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.