Eventi e reazioni

Panoramica

In Zabbix vengono generati diversi tipi di eventi:

  • eventi di trigger - ogni volta che un trigger cambia stato (OK→PROBLEM→OK)
  • eventi di servizio - ogni volta che un servizio cambia stato (OK→PROBLEM→OK)
  • eventi di discovery - quando vengono rilevati host o servizi
  • eventi di autoregistrazione - quando gli agent attivi vengono autoregistrati dal server
  • eventi interni - quando un item/regola di discovery a basso livello diventa non supportato o un trigger entra in uno stato sconosciuto

Gli eventi sono associati a un timestamp e possono essere la base per azioni come l'invio di email di notifica, la creazione di ticket o l'esecuzione di comandi remoti.

Per visualizzare i dettagli di un evento nel frontend, vai su Monitoring > Problems. Lì puoi fare clic sulla data e sull'ora dell'evento per aprire la pagina dei dettagli dell'evento, dove puoi vedere informazioni aggiuntive sull'evento, incluso se è stato soppresso a causa della manutenzione o soppresso manualmente da un utente.

Problem resolution

Problem events created by triggers are resolved automatically, if the condition that caused the problem no longer exists.

To add flexibility and convenience to problem event management, the following options exist:

Eventi trigger

La modifica dello stato del trigger è la fonte di eventi più frequente e più importante. Ogni volta che il trigger cambia stato, viene generato un evento. L'evento contiene i dettagli della modifica dello stato del trigger: quando è avvenuta e qual è il nuovo stato.

I trigger generano due tipi di eventi: Problem e OK.

Eventi di problema

Un evento di problema viene creato:

  • quando un'espressione di trigger viene valutata come TRUE se il trigger è in stato OK;
  • ogni volta che un'espressione di trigger viene valutata come TRUE se la generazione di più eventi di problema è abilitata per il trigger.
Eventi OK

Un evento OK chiude il o gli eventi di problema correlati e può essere creato da 3 componenti:

  • trigger - in base alle impostazioni "OK event generation" e "OK event closes";
  • correlazione degli eventi
  • task manager - quando un evento viene chiuso manualmente

I trigger hanno un'impostazione "OK event generation" che controlla come vengono generati gli eventi OK:

  • Expression - un evento OK viene generato per un trigger nello stato di problem quando la sua espressione viene valutata come FALSE. Questa è l'impostazione più semplice, abilitata per impostazione predefinita.
  • Recovery expression - un evento OK viene generato per un trigger nello stato di problem quando la sua espressione viene valutata come FALSE e la recovery expression viene valutata come TRUE. Questa opzione può essere usata se i criteri di ripristino del trigger sono diversi dai criteri di problem.
  • None - un evento OK non viene mai generato. Questa opzione può essere usata insieme alla generazione di più eventi di problem per inviare semplicemente una notifica quando accade qualcosa.

Inoltre, i trigger hanno un'impostazione "OK event closes" che controlla quali eventi di problem vengono chiusi:

  • All problems - un evento OK chiuderà tutti i problem aperti creati dal trigger
  • All problems if tag values match - un evento OK chiuderà i problem aperti creati dal trigger che hanno almeno un valore di tag corrispondente. Il tag è definito dall'impostazione del trigger "Tag for matching". Se non ci sono eventi di problem da chiudere, l'evento OK non viene generato. Questo è spesso chiamato correlazione degli eventi a livello di trigger.
Correlazione degli eventi

La correlazione degli eventi (chiamata anche correlazione globale degli eventi) è un modo per configurare regole personalizzate di chiusura degli eventi (con conseguente generazione di eventi OK).

Le regole definiscono come i nuovi eventi di problema vengono associati agli eventi di problema esistenti e consentono di chiudere il nuovo evento o gli eventi corrispondenti generando i relativi eventi OK.

Tuttavia, la correlazione degli eventi deve essere configurata con molta attenzione, poiché può influire negativamente sulle prestazioni di elaborazione degli eventi o, se configurata in modo errato, chiudere più eventi del previsto (nel caso peggiore, potrebbero essere chiusi persino tutti gli eventi di problema). Alcuni suggerimenti di configurazione:

  1. ridurre sempre l'ambito della correlazione impostando un tag univoco per l'evento di controllo (l'evento che viene associato agli eventi precedenti) e usare la condizione di correlazione 'new event tag'
  2. non dimenticare di aggiungere una condizione basata sul vecchio evento quando si usa l'operazione 'close old event', altrimenti potrebbero essere chiusi tutti i problemi esistenti
  3. evitare di usare nomi di tag comuni utilizzati da diverse configurazioni di correlazione
Task manager

Se l'impostazione 'Allow manual close' è abilitata per il trigger, è possibile chiudere manualmente gli eventi di problema generati dal trigger. Questa operazione viene eseguita nel frontend quando si aggiorna un problema. L'evento non viene chiuso direttamente: viene invece creato un task 'close event', che viene gestito a breve dal task manager. Il task manager genererà un evento OK corrispondente e l'evento di problema verrà chiuso.

Eventi del servizio

Gli eventi del servizio vengono generati solo se le azioni del servizio per questi eventi sono abilitate. In questo caso, ogni modifica dello stato del servizio crea un nuovo evento:

  • Evento di problema - quando lo stato del servizio cambia da OK a Problem
  • Evento OK - quando lo stato del servizio cambia da Problem a OK

L'evento contiene i dettagli della modifica dello stato del servizio: quando è avvenuta e qual è il nuovo stato.

Eventi di discovery

Zabbix esegue periodicamente la scansione degli intervalli IP definiti nelle regole di discovery di rete. La frequenza del controllo è configurabile singolarmente per ciascuna regola. Una volta che un host o un servizio viene scoperto, viene generato un evento di discovery (o più eventi).

Zabbix genera i seguenti eventi:

Evento Quando viene generato
Service Up Ogni volta che Zabbix rileva un servizio attivo.
Service Down Ogni volta che Zabbix non riesce a rilevare il servizio.
Host Up Se almeno uno dei servizi è UP per l'IP.
Host Down Se tutti i servizi non rispondono.
Service Discovered Se il servizio torna disponibile dopo un periodo di inattività o viene scoperto per la prima volta.
Service Lost Se il servizio viene perso dopo essere stato UP.
Host Discovered Se l'host torna disponibile dopo un periodo di inattività o viene scoperto per la prima volta.
Host Lost Se l'host viene perso dopo essere stato UP.

Eventi di autoregistrazione dell'agent attivo

L'autoregistrazione dell'agent attivo crea eventi in Zabbix.

Se configurata, viene creato un evento di autoregistrazione dell'agent attivo quando un agent attivo precedentemente sconosciuto richiede controlli oppure se i metadati dell'host sono cambiati. Il server aggiunge un nuovo host autoregistrato, usando l'indirizzo IP e la porta dell'agent ricevuti.

Per ulteriori informazioni, vedere la pagina autoregistrazione dell'agent attivo.

Eventi interni

Gli eventi interni si verificano quando:

  • un item cambia stato da 'normal' a 'unsupported'
  • un item cambia stato da 'unsupported' a 'normal'
  • una regola di discovery a basso livello cambia stato da 'normal' a 'unsupported'
  • una regola di discovery a basso livello cambia stato da 'unsupported' a 'normal'
  • un trigger cambia stato da 'normal' a 'unknown'
  • un trigger cambia stato da 'unknown' a 'normal'

L'obiettivo dell'introduzione degli eventi interni è consentire agli utenti di essere avvisati quando si verifica un qualsiasi evento interno, ad esempio quando un item diventa unsupported e smette di raccogliere dati.

Gli eventi interni vengono creati solo quando le azioni interne per questi eventi sono abilitate. Per interrompere la generazione di eventi interni (ad esempio, per item che diventano unsupported), disabilita tutte le azioni per gli eventi interni in Alerts > Actions > Internal actions.

Se le azioni interne sono disabilitate, mentre un oggetto si trova nello stato 'unsupported', verrà comunque creato un evento di recovery per questo oggetto.

Se le azioni interne sono abilitate, mentre un oggetto si trova nello stato 'unsupported', verrà creato un evento di recovery per questo oggetto, anche se per l'oggetto non è stato creato alcun 'problem event'.

Vedi anche: Ricevere notifiche sugli item unsupported