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 servicedescription 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 .notifyalias (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!

blog comments powered by Disqus