Gestori di avvisi

Si potrebbe pensare che sia ovvio che un sistema di monitoraggio non debba mai intervenire negli eventi, ma piuttosto che debba, beh, monitorare. E probabilmente è una buona idea lasciare le cose come stanno.

Tuttavia, l'idea che un sistema in grado di identificare in modo affidabile i problemi possa anche correggerli, a patto che funzioni in modo automatico, è indubbiamente interessante.

Si possono facilmente immaginare alcuni esempi calzanti:

Se si riesce ad accettare questo, allora bisogna pensare in modo diverso al monitoraggio: da un sistema che semplicemente osserva e non è "necessario" per le operazioni di monitoraggio, un processo graduale porta il monitoraggio a diventare un organo vitale del data center.

Ma la correzione dei problemi non è l'unica cosa che il monitoraggio può fare automaticamente quando identifica un problema. Molto utile, ma anche innocua, è la raccolta di dati diagnostici aggiuntivi nel momento in cui si verifica un guasto. Senza dubbio potresti pensare a numerosi altri problemi per i quali si potrebbero usare i gestori di avvisi come punto di partenza.

I gestori di avvisi sono script che scrivi tu stesso e che vengono eseguiti da Checkmk nelle edizioni commerciali quando viene rilevato un problema o, più precisamente, quando un host o un servizio cambia stato.

I gestori di avvisi sono molto simili alle notifiche e sono configurati in modo simile, ma ci sono alcune importanti differenze:

Si può anche dire che i gestori di avvisi sono molto "di basso livello". Non appena un host o un servizio cambia stato, i gestori di avvisi configurati si attivano immediatamente. In questo modo un gestore di avvisi può persino eseguire una riparazione con successo prima che venga generato un avviso vero e proprio.

Naturalmente, come sempre in Checkmk, puoi utilizzare delle regole per definire le condizioni per le quali un particolare gestore deve essere eseguito. Puoi scoprire come fare questo e tutto il resto sui gestori di avvisi in questo articolo.

Un consiglio per gli utenti di Checkmk Raw: puoi anche fare in modo che il monitoraggio esegua automaticamente delle azioni, utilizzando i "gestori di eventi" di Nagios. Configura questi file di configurazione manuale nella sintassi di Nagios all'indirizzo ~/etc/nagios/conf.d/. I gestori di eventi sono ben documentati e le informazioni possono essere trovate semplicemente con Google.

I gestori di avvisi sono script che vengono eseguiti sul server Checkmk. Devono essere salvati nella directory ~/local/share/check_mk/alert_handlers/ e possono essere codificati in qualsiasi linguaggio supportato da Linux, ad es. BASH, Python o Perl. Non dimenticare di rendere gli script eseguibili con chmod +x.

Se viene inserito un commento nella seconda riga dello script (con un hash # ), questo apparirà come nome dello script nell'elenco di selezione della regola:

Come per le notifiche, lo script ottiene tutte le informazioni relative all'host o al servizio come variabili d'ambiente, che iniziano tutte con il prefisso ALERT_.

Per verificare esattamente quali variabili d'ambiente appaiono nello script, puoi utilizzare il seguente gestore di avvisi per un test:

L'attivazione del gestore avviene tramite Setup > Events > Alert handlers.

Procedi come segue:

Il modulo per la selezione del gestore di avvisi consente l'accesso diretto e mostra il titolo che viene logato nella seconda riga dello script. Inoltre, puoi aggiungere degli argomenti che vengono inseriti nei campi di testo e che saranno interpretati come argomenti della riga di comando nello script. Nella tua shell puoi accedervi con $1, $2, ecc.

Importante: dopo aver salvato la regola, il gestore di avvisi sarà immediatamente attivo e verrà eseguito a ogni cambio di stato dell'host o del servizio!

Per effettuare un test, imposta manualmente un servizio, ad esempio Fake check results, su CRIT. A questo punto il file dovrebbe essere stato creato con le variabili. Ecco le prime venti righe:

Il file di log per la (non) esecuzione del gestore di avvisi si troverà in ~/var/log/alerts.log. La sezione per l'esecuzione del gestore debug, per il servizio Filesystem / sull'host myserver123sarà simile a questa:

Un altro paio di consigli utili:

I gestori di avvisi vengono spesso utilizzati per effettuare il log in a un computer interessato da remoto tramite SSH o un altro protocollo e, una volta lì, eseguire un'azione controllata da uno script. Poiché questo computer sta riscontrando un problema, non è da escludere che la connessione richieda molto tempo o addirittura vada in timeout.

Per evitare che il monitoraggio rimanga fermo o che altri gestori di avvisi si blocchino in questo lasso di tempo, in linea di principio i gestori di avvisi vengono eseguiti in modo asincrono. Un processo ausiliario - l'assistente agli avvisi - è responsabile di questa funzione e viene avviato dal CMC. Per ridurre l'overhead, questo avviene solo se è stata creata almeno una regola per il gestore di avvisi. Nel sito cmc.log vedrai quindi la seguente riga:

Ad ogni cambiamento di stato di un host o di un servizio, l'assistente agli avvisi riceve una notifica dal CMC contenente tutte le informazioni rilevanti per l'evento. Quindi valuta tutte le regole di notifica e determina se deve essere attivato un gestore di avvisi. In caso affermativo, lo script di notifica appropriato viene avviato ed eseguito in background come processo esterno.

Quando si arresta il CMC (ad es. tramite omd stop o spegnendo il server di monitoraggio), tutti gli assistenti agli avvisi ancora in esecuzione vengono interrotti. Questi non verranno ripetuti in seguito, perché chi può sapere quando sarà il momento? È possibile che il riavvio di un servizio o simili possa essere più dannoso che utile!

Per proteggersi dall'avvio di un numero eccessivo di processi in caso di errore, quando un gestore di avvisi è in esecuzione è in vigore un timeout di 60 secondi (impostabile) al termine del quale il gestore verrà arrestato. In dettaglio, ciò significa che al termine di un timeout verrà inviato al gestore un Segnale 15 (SIGTERM). In questo modo avrà la possibilità di arrestarsi in modo pulito. Dopo altri 60 secondi (timeout doppio) verrà "terminato" con un Segnale 9 (SIGKILL).

Checkmk impedisce l'esecuzione simultanea di assistenti agli avvisi se si riferiscono allo stesso host/servizio e se eseguono lo stesso script con gli stessi parametri. Una situazione del genere indica che il primo gestore è ancora in esecuzione e che non ha senso avviare una seconda copia dello stesso gestore: il secondo gestore verrebbe immediatamente eliminato e identificato come "fallito".

Le uscite e i codici di uscita del gestore di avvisi vengono valutati in modo affidabile e restituiti al core, dove vengono salvati nella cronologia del monitoraggio. Inoltre puoi attivare una notifica (vedi sotto).

Esistono diverse impostazioni globali per l'esecuzione dei gestori di avvisi:

L'opzione Alert handler log level influenza la registrazione nel file di log dell'assistente agli avvisi (~/var/log/alerts.log).

Con un clic nello snap-in Master control puoi disattivare i gestori di avvisi a livello globale. I gestori attualmente in esecuzione non saranno interessati e verranno eseguiti fino al completamento.

Non dimenticare di riportare il piccolo switch sul verde non appena possibile, altrimenti potresti essere ingannato dal falso senso di sicurezza che il monitoraggio stia sistemando ogni aspetto...

Ogni versione di Checkmk include un gestore di avvisi integrato che consente l'esecuzione affidabile degli script sui sistemi Linux monitorati. Le caratteristiche più importanti di questa soluzione sono:

I gestori di avvisi remoti di Linux sono costituiti dai seguenti elementi:

Supponendo di voler eseguire lo script /etc/init.d/foo restart sul sistema Linux myserver123 ogni volta che il servizio Process FOO diventa critico (che abbiamo già impostato), procedi come segue:

Naturalmente, la preparazione manuale di un agente funziona anche. In questo caso, ti consigliamo di eseguire la procedura Agent bakery su un sistema di prova, quindi di esaminare i dati rilevanti e di replicarli manualmente sul tuo sistema. Un elenco dei percorsi dei file è disponibile qui.

In questo caso è importante che nell'Agent bakery tu crei una regola per l'installazione del gestore remoto, perché in questa regola verranno generate le chiavi SSH per l'accesso e per l'utilizzo da parte del gestore di avvisi! La chiave pubblica per l'installazione in authorized_keys si trova nel file di configurazione di ~/etc/check_mk/conf.d/wato/rules.mk (o in una sottocartella di rules.mk).