TommyBlue.it

Configurare i check passivi in Nagios per l'integrazione con Munin

Continuo la serie di guide sulla configurazione di Nagios spiegando come attivare i check passivi con NSCA e come usare Munin per avvertire Nagios di ciò che non va’.

Intanto ricordo i link alla prima e alla seconda parte della guida:

Tornando a Nagios e Munin: l’uso dei check passivi può tornare utile se si va ad installare Nagios in una rete in cui è già  presente Munin che, per chi non lo conoscesse, è un software che crea grafici di andamento di una lunga serie di servizi o aspetti dei server (anch’esso configurabile con agenti su vari server e un’applicazione centralizzata per la raccolta dei dati). Se Munin non fosse già  installato si può valutare una configurazione Nagios-centrica con i check effettuati da NRPE e i grafici fatti con NagiosGraph.

Nel mio caso era già  presente Munin e ho quindi optato per la configurazione dei check passivi.

Configurazione del server (Nagios e nsca)

Si comincia come sempre installando i pacchetti necessari: 
apt-get install libmcrypt-dev xinetd
Quindi si scarica NSCA dalla pagina degli addon di Nagios, si scompatta, si compila e si installa: 
tar xzf nsca-2.7.2.tar.gz
cd nsca-2.7.2/
./configure prefix=/usr/local/nagios –with-nsca-user=nagios –with-nsca-grp=nagcmd
make all
cp -a src/nsca /usr/local/nagios/bin/
cp sample-config/nsca.cfg /usr/local/nagios/etc/
chown nagios:nagcmd /usr/local/nagios/etc/nsca.cfg
chmod g+r /usr/local/nagios/etc/nsca.cfg
cp sample-config/nsca.xinetd /etc/xinetd.d/nsca
Bisogna anche aggiungere al file /etc/services il servizio NSCA con la riga: 
nsca    5667/tcp    # NSCA
Nel file /etc/xinetd.d/nsca bisogna modificare il parametro only_from per consentire l’accesso al server in cui gira Munin, poi possiamo riavviare xinetd.

Configurazione del client (send_nsca e Munin)

Nel client da cui arriveranno i check (ovvero dove gira Munin) bisogna ugualmente scaricare il pacchetto NSCA e compilarlo. Differisce l’installazione del binario che in questo caso è send_nsca e può essere posizionato dove si vuole (stessa cosa vale per il suo file di configurazione). Dato che nel mio caso Munin e Nagios sono sullo stesso server ho usato la directory di Nagios per ospitare questi file: 
cp -a src/send_nsca /usr/local/nagios/bin/
cp sample-config/send_nsca.cfg /usr/local/nagios/etc/
Se i due software sono su server diversi potete impostare un metodo di cifratura nel file send_nsca.cfg e impostare una password (che deve essere la stessa sul server e sul client).

Proviamo adesso se send_nsca funziona. I check passivi consistono in una riga contenente: 

HOSTNAME[tab]SERVIZIO[tab]CODICE[tab]DESCRIZIONE
quindi per fare un test possiamo creare un file con il contenuto: 
hostAcaso   pippo   0   OK
e fare un test di connessione con: 
/usr/local/nagios/bin/send_nsca localhost -c /usr/local/nagios/etc/send_nsca.cfg < test
1 data packet(s) sent to host successfully.
Nei log di Nagios troveremo: 
nagios: Warning:  Passive check result was received for service ‘pippo’ on host ‘hostAcaso’, but the host could not be found!
Funziona! Non fatevi spaventare dal warning: Nagios ha ricevuto il check ma non ha nessun host corrispondente nella sua configurazione. Niente di male, glielo spiegheremo più tardi.

Possiamo quindi configurare Nagios per accettare i check passivi. Per farlo andiamo nel server e inseriamo nel file etc/objects/templates.cfg il template per un servizio che accetta sono check passivi: 

define service{
 name                            passive-service
 use                             generic-service
 active_checks_enabled           0
 passive_checks_enabled          1
 flap_detection_enabled          0
 register                        0
 is_volatile                     0
 check_period                    24x7
 max_check_attempts              1
 normal_check_interval           5
 retry_check_interval            1
 check_freshness                 0
 contact_groups                  admins
 notification_options            w,u,c,r
 stalking_options                w,c,u
 notification_interval           120
 check_command                   check_dummy!0
}
Inseriamo poi nel file etc/objects/commands.cfg la definizione del comando check_dummy: 
define command{
 command_name    check_dummy
 command_line    $USER1$/check_dummy $ARG1$
}
Fatto questo possiamo inserire un check di prova in un host: 
define service{
 use                             passive-service
 host_name                       hostCheEsiste
 service_description             TestMessage
}
Una volta riavviato Nagios vedremo questo servizio in stato pending. Modificando il file di prima con: 
hostCheEsiste    TestMessage    0     Messaggio di OK
ed eseguendo nuovamente: 
/usr/local/nagios/bin/send_nsca localhost -c /usr/local/nagios/etc/send_nsca.cfg < test
possiamo mettere il servizio in stato di OK.

Per finire dobbiamo dire a Munin di chiamare Nagios quando qualcosa non va. Per farlo dobbiamo modificare il file munin.conf inserendo: 

contacts nagios
contact.nagios.command /usr/local/nagios/bin/send_nsca -H localhost -c /usr/local/nagios/etc/send_nsca.cfg
Modificate le path secondo la vostra configurazione e inserite nel file send_nsca.cfg l’eventuale password per comunicare con NSCA.

Ma come funzionano in dettaglio gli avvertimenti di Munin?

Munin si basa su plugin e ognuno di essi ha dei limiti. Per vederli basta lanciare (in questo caso interrogo il plugin cpu): 
munin-run cpu config
Nella risposta si possono individuare i limiti: 
system.warning 60
system.critical 100
Tali limiti possono essere monitorati da munin-limits, un eseguibile che, per essere lanciato automaticamente, va inserito in crontab. Di base ne trovate una configurazione in /etc/cron.d/munin (se non c’è createlo). Io l’ho modificato così: 
*/5 * * * *     munin if [ -x /usr/share/munin/munin-limits ]; then /usr/share/munin/munin-limits –force –contact nagios –contact old-nagios; fi
Quindi ogni 5 minuti fa il check e contatta Nagios per passargli il risultato.

L’ultima cosa da fare è adattare i limiti di ogni plugin secondo le proprie esigienze. Si possono definire in munin.conf per ogni host: 

df._mapper_sda1_vm_root.warning      0:90
df._mapper_sda1_vm_root.critical     0:95
df.notify_alias     Disk usage
La logica con cui vengono definiti i limiti è un po’ cervellotica e dipende molto dal tipo di plugin. In questo caso ho usato df che controlla l’uso del disco. Il limite di warning 0:90 viene superato se il limite è al di fuori di questo range (il range è 0:100). Ma a sua volta il limite critico è al di fuori del range 0:95. Il risultato è che il plugin entra in warning se la partizione è occupata tra il 90% e il 94% e in critical da 95% in sù. Vi lascio divertire con gli altri plugin :)

Inseriamo in Nagios questi check

Ho già  mostrato prima come inserire un check passivo in un host, ovvero: 
define service{
 use                             passive-service
 host_name                       hostCheEsiste
 service_description             TestMessage
}
Per accettare un check passivo valido da Munin bisogna modificare service_description affinchè sia uguale al nome del servizio che definisce il plugin di Munin. Dato che hanno nomi non facilmente individuabili e che a volte contengono caratteri incompatibili con Nagios (ad esempio %) una cosa furba è rinominarli in munin.conf con .notify_alias (guardate qualche riga più in sù nel caso del df) e usare quell’alias in Nagios.

A questo punto la teoria è finita e non rimane altro da fare che iniziare a scrivere le definizioni dei check in Nagios e le configurazioni dei plugin in Munin, buon lavoro!