Systemd e Nagios

Nei precedenti post abbiamo visto come systemd agendo al pari di un supervisor sia capace di rilevare eventuali anomalie durante l’avvio della macchina o durante tutto il periodo di funzionamento. Benché nessuno escluda che possa essere una delle funzionalità future (ma non me lo auguro visto che per molti systemd è già fin troppo corposo per assumere il ruolo di init), manca la funzionalità di notifica automatica delle anomalie.

Nagios è una delle soluzioni più diffuse per il monitoraggio, quindi l’ideale sarebbe riuscire a interrogare lo stato di systemd attraverso un plugin nagios in modo da sfruttare un sistema di notifica di sicuro più avanzato e efficiente di qualsiasi implementazione si possa realizzare dentro systemd stesso.

Abbiamo visto che il comando

systemctl --failed --no-legend

ritorna solo le unità che sono state terminate con codice di errore o terminate inaspettatamente (ad esempio con il segnale SIGABRT). Basta fare un banale parsing del risultato e il gioco è fatto.

Per evitare che il discorso rimanga in astratto mi sono divertito a scrivere in una mezz’oretta il plugin in oggetto che potete trovare al seguente link:

http://github.com/kbytesys/pynagsystemd

Per eseguirlo avete bisogno dell’interprete Python3 e della libreria nagiosplugin. Può essere usato da nagios tranquillamente perché non necessita i privilegi di root. Quando verranno rilevate delle anomalie, oltre allo stato CRITICAL verranno elencate le unità che hanno causato il fallimento del monitoraggio:

SYSTEMD CRITICAL failed units: sshd.service exim4.service

Attenzione: questo tipo di controllo è estremamente utile, ma non può in alcun modo sostituire dei controlli ben fatti sui servizi che in genere controllano anche il funzionamento del servizio. Senza dimenticare che quando fermiamo un servizio non andremo nello stato d’errore, mente dal punto di vista di un monitoraggio ben fatto, anche in questo caso bisogna comunque segnalare il down del servizio.

Tuttavia con questo plugin avremo una copertura a 360° delle possibili anomalie sulla macchina non solo per quanto riguarda i servizi, ma per tutte le unità di systemd. Si, lo so: non ne abbiamo mai parlato a fondo. Una unità può essere un processo/servizio, può essere un socket, un  mountpoint o più semplicemente tutto ciò che può essere descritto da uno dei file di configurazione posti in /lib/systemd o in /etc/systemd.

Per cui una vasta tipologia di problematiche può essere rilevata a costo quasi zero. Poi ovviamente per i servizi più critici il check usuale di nagios è più indicato, ma è sempre meglio di niente.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.