Archivi tag: nagios

MRTG e Nagios: monitoraggio del throughput di rete

Networking, SO: Linux, , , , , , , ,

MRTG (Multi Router Traffic Grapher) rappresenta lo standard “de facto” per ciò che concerne il monitoraggio del throughput della nostra rete. Il suo funzionamento è basato sul polling SNMP, grazie al quale vengono raccolte le informazioni sul traffico che coinvolge le schede di rete monitorate, per poi procedere con la creazione di un grafico “ad hoc”, contenente le predette informazioni.

mrtg_logo

Installazione e configurazione di MRTG

La macchina che svolge le operazioni di monitoraggio è una linux box con a bordo CentOS 6. Per installare MRTG è dunque sufficiente digitare il comando:

[root@linuxbox ~]# yum install mrtg

Inoltre, sarà necessario installare anche i pacchetti net-snmp e net-snmp-utils (per effettuare il polling SNMP vero e proprio):

[root@linuxbox ~]# yum install net-snmp net-snmp-utils

Ad installazione completata passiamo alla configurazione di MRTG. Per prima cosa sarà necessario lanciare il comando:

[root@linuxbox ~]# cfgmaker --global 'WorkDir: /var/www/mrtg' --output /etc/mrtg/mrtg.cfg keypublic@iptarget

Esso ci consentirà di popolare in maniera automatica il file di configurazione /etc/mrtg/mrtg.cfg, grazie al quale, successivamente, verrà creata la pagina Web (con estensione *.html) contenente i grafici generati da MRTG. Inoltre, all’interno del file di configurazione mrtg.cfg, sarà opportuno abilitare le seguenti opzioni:

Options[_]: growright, bits

le quali consentiranno la tracciatura dei grafici da sinistra verso destra, utilizzando i bit come unità di misura (anzichè i byte).

Per creare la pagina Web contenente i grafici è necessario digitare il comando:

[root@linuxbox ~]# indexmaker --output=/var/www/mrtg/index.html /etc/mrtg/mrtg.cfg

A questo punto facciamo in modo che i dati relativi al traffico vengano aggiornati ogni 5 minuti, creando un’apposita regola mediante cron (editando il file /etc/cron.d/mrtg):

*/5 * * * * root LANG=C LC_ALL=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg --lock-file /var/lock/mrtg/mrtg_l --confcache-file /var/lib/mrtg/mrtg.ok

L’ultimo step relativo alla configurazione di MRTG riguarda il settaggio delle credenziali (username/password) per l’accesso alla pagina index.html. Per fare ciò occorre creare il file mrtg.conf, all’interno della directory /etc/httpd/conf.d di Apache (il nostro server Web), il cui contenuto dovrà essere simile al seguente:

Alias /mrtg /var/www/mrtg

<Location /mrtg>
    Order deny,allow
    Allow from all
    AuthName "MRTG Access"
    AuthType Basic
    AuthUserFile /etc/mrtg/passwd
    Require valid-user
</Location>

Ora definiamo lo username e la password (che verrà salvata nel file /etc/mrtg/passwd in formato digest), utilizzando il comando:

[root@linuxbox ~]# htpasswd -c /etc/mrtg/passwd mrtguser

Infine, ricarichiamo la configurazione Apache digitando:

[root@linuxbox ~]# service httpd reload

e proviamo ad accedere ai grafici generati da MRTG, puntando a questa URL:

http://iplinuxbox/mrtg

Se la pagina è accessibile ed i grafici sono aggiornati, possiamo passare alla configurazione di Nagios.

Integrazione tra Nagios ed MRTG

Il plugin di Nagios che ci consente di integrare tale NMS con MRTG prende il nome di check_mrtgtraf. Esso può essere installato singolarmente, digitando:

[root@linuxbox ~]# yum install nagios-plugins-mrtgtraf

oppure installando tutti i plugin di Nagios:

[root@linuxbox ~]# yum install nagios-plugins-all

Ad installazione completata, possiamo definire il comando check_local_mrtgtraf (all’interno del file /etc/nagios/object/commands.cfg), il quale si avvarrà del plugin appena installato:

# 'check_local_mrtgtraf' command definition
define command{
        command_name    check_local_mrtgtraf
        command_line    $USER1$/check_mrtgtraf -F $ARG1$ -a $ARG2$ -w $ARG3$ -c $ARG4$ -e $ARG5$
        }

dove -F indica il file di log (generato da MRTG) che dovrà essere consulato; -a indica la modalità di analisi del traffico (MAX o AVG); -w la soglia di warning e -c la soglia critica.

Non ci rimane che definire il servizio (relativo ad uno specifico host) che dovrà avvalersi del suddetto comando:

define service{
        use                             local-service   ; Inherit values from a template
        host_name                       Router-cisco
        service_description             WAN Bandwidth Usage
        check_command                   check_local_mrtgtraf!/var/www/mrtg/router-cisco/192.168.3.1_16.log!AVG!100000000,200000000!110000000,120000000!10
        }

Ricarichiamo la configurazione di Nagios mediante il comando:

[root@linuxbox ~]# service nagios reload

ed abbiamo finito.

Alla prossima.

Nagios: script bash + expect per monitorare il numero di NAT translation sui router Cisco

Networking, SO: Linux, , , , , , , ,

Dopo aver cercato a lungo un OID SNMP che potesse restituirmi on-the-fly il numero di NAT translation attive sul mio router Cisco, sono arrivato alla conclusione che il modo più semplice per ricavare tale informazione consiste nel creare uno scrip bash + expect da dare in pasto a Nagios.

Nagios_logo_blackPer prima cosa, dunque, mi sono soffermato sulla creazione dello scrip expect, in modo da poter interrogare il router oggetto di monitoraggio, lanciando un comando specifico, che è il seguente:

Router# show ip nat statistics

Ed ecco lo scrip expect vero e proprio:

#!/usr/bin/expect

set ip [lindex $argv 0]
set password1 [lindex $argv 1]
set password2 [lindex $argv 2]

spawn ssh -l nightfly "$ip"
expect "*?assword:*"
send "$password1\r"
expect ">"
send "ena\r"
expect "Password:"
send "$password2\r"
expect "#"
send "show ip nat statistics\r"
expect "#"
send "exit\r"
expect eof

Esso riceve come parametri l’IP del dispositivo, la password vty e la password ena.
Dopo averlo chiamato get_nat_num (ed averlo reso eseguibile con chmod +x get_nat_num), mi sono soffermato sulla creazione dello scrip bash, che è il seguente:

#!/bin/bash

host=$1
password1=$2
password2=$3
warning=$4
critical=$5

usage="check_nat_translations <host> <password1> <password2> <warning> <critical>"

if [ -n "$host" ]; then

        if [ -n "$password1" ];then

                if [ -n "$password2" ];then

                        if [ -n "$warning" ];then

                                if [ -n "critical" ];then

                                        if [ "$critical" -lt "$warning" ];then

                                                echo "UNKNOWN: critical has to be greater than warning"
                                                exit 3;

                                        else

                                                output=`/usr/lib64/nagios/plugins/get_nat_num $1 $2 $3 | grep "Total active translations"  | awk '{print $4}'`

                                        fi

                                        if [ -n "$output" ];then

                                                if [ "$output" -ge "$critical" ];then

                                                        echo "CRITICAL: total number of active NAT translations is $output | nat_translations=$output;$warning;$critical";
                                                        exit 2;

                                                elif [ "$output" -lt "$critical"  -a  "$output" -ge "$warning" ];then

                                                        echo "WARNING: total number of active NAT translations is $output | nat_translations=$output;$warning;$critical";
                                                        exit 1;

                                                else

                                                        echo "OK: total number of active NAT translations is $output | nat_translations=$output;$warning;$critical";
                                                        exit 0;

                                                fi
                                        else

                                                echo "UNKNOWN: output is null"
                                                exit 3;

                                        fi

                                else

                                        echo "$usage"
                                        exit 3;
                                fi

                        else

                                echo "$usage"
                                exit 3;
                        fi

                else

                        echo "$usage"
                        exit 3;
                fi
        else

                echo "$usage"
                exit 3;
        fi

else

        echo "$usage"
        exit 3;

fi

Esso accetta in ingresso 5 parametri: i primi 3 da passare allo scrip get_nat_num, gli ultimi 2 da utilizzare come soglie per Nagios (una warning ed una critical).

Rendiamo eseguibile anche questo scrip (chmod +x check_nat_translations) e soffermiamoci sulla configurazione di Nagios.

Come primo step occorre creare il comando che utilizza i plugin appena creati:

# 'check_nat_translations' command definition
 define command{
 command_name    check_nat_translations
 command_line    $USER1$/check_nat_translations $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$
 }

Successivamente è necessario creare un servizio (da inserire nel file di configurazione relativo ad un host determinato), che si avvalga del comando creato in precedenza:

define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_descripion             NAT Translations Number
 check_command                   check_nat_translations!password1!password2!40000!50000
 }

Salviamo la configurazione, riavviamo Nagios, ed il gioco è fatto.

Alla prossima.

Nagios troubleshooting

Networking, SO: Linux, , , , , ,

In questo post ho illustrato il comando da lanciare per appurare molto velocemente l’eventuale presenza di errori all’interno della configurazione di Nagios . Qui, invece, ho discusso di un valido tool in grado di debuggare i plugin utilizzati dall’NMS in questione.

nagiosEntrambi i suddetti metodi non rappresentano le uniche alternative in fase di troubleshooting. Infatti, Nagios mette a disposizione nativamente una modalità debug, la quale è in grado di “mostrare” come i vari comandi (configurati all’interno del file commands.cfg e valorizzati in nomehost.cfg) vengono interpretati ed eseguiti di volta in volta.

Per attivare tale modalità occorre operare all’interno del file /etc/nagios/nagios.cfg, impostando il debug level a 2048 (macros):

debug_level=2048

Il file da consultare sarà questo:

/var/log/nagios/nagios.debug

Inoltre, quando si ha a che fare con alcuni plugin sviluppati soprattutto in perl che lanciati da linea di comando come utente nagios funzionano correttamente mentre da pagina Web restituiscono un risultato di tipo Critical con output null, si può aggiungere, all’interno del file /etc/nagios/commands.cfg (in corrispondenza del comando che fa uso del suddetto plugin), la seguente entry:

2>&1

Ad esempio, per il plugin check_squid.pl ho definito il seguente comando:

'check_squid' command definition
define command{
        command_name    check_squid
        command_line    $USER1$/check_squid -u $ARG1$ -p $HOSTADDRESS$ -l $ARG2$ -e $ARG3$ 2>&1
        }

in modo tale da pololare il risultato del check presente nella pagina Web reindirizzando lo standard err (2>) nello standard out (&1).

Entrambi i metodi illustrati in questo post prevedono un reload della configurazione di Nagios per entrare in funzione:

[root@NMS ~]# service nagios reload

Per ora è tutto.

Alla prossima.

check_arptables: script Nagios per verificare lo stato di arptables_jf

Networking, SO: Linux, , , , , ,

In questo post ho discusso della configurazione di LVS in modalità Direct Routing. Tale configurazione richiedeva l’installazione e la corretta configurazione di arptables_jf per la gestione delle richieste ARP dirette ai frontend. Adesso vedremo come verificare l’effettivo funzionamento del suddetto applicativo attraverso l’NMS open source per eccellenza, Nagios.

nagiosCreazione dell’eseguibile e configurazione dell’NMS

Il codice bash che ho creato per effettuare i controlli sullo status di arptables_jf è il seguente:

#!/bin/bash

host=$1
warning=$2
critical=$3

usage="check_arptables <host> <warning> <critical>"

if [ -n "$host" ]; then

        if [ -n "$warning" ];then

                if [ -n "critical" ];then

                        if [ "$warning" -lt "$critical" ];then

                                echo "UNKNOWN: warning has to be greater than critical"
                                exit 3;

                        else

                                output=`sudo arptables -L | grep -v Chain | grep -v target | wc -l`

                                if [ "$output" -le "$critical" ];then

                                        echo "CRITICAL: total number of rules is $output";
                                        exit 2;

                                elif [ "$output" -gt "$critical"  -a  "$output" -le "$warning" ];then

                                        echo "WARNING: total number of rules is $output";
                                        exit 1;

                                else

                                        echo "OK: total number of rules is $output";
                                        exit 0;

                                fi
                        fi
                else

                        echo "$usage"
                        exit 3;

                fi
        else

                echo "$usage"
                exit 3;

        fi
else

        echo "$usage"
        exit 3;

fi

Il suddetto codice è abbastanza esplicativo: dopo aver verificato la presenza di tutti i parametri richiesti e la loro consistenza (ovvero la soglia di warning deve essere strettamente maggiore di quella di critical), viene effettuato il conteggio delle regole arptables attive sul frontend monitorato. Il comando principale è il seguente:

sudo arptables -L | grep -v Chain | grep -v target | wc -l

Da notare che è presente la direttiva sudo poichè l’applicativo arptables richiede i privilegi di root per essere eseguito. Rendiamo il suddetto codice eseguibile:

[root@NMS ~]# chmod +x check_arptables

e copiamolo nella directory /usr/lib64/nagios/plugins del frontend:

[root@NMS ~]# scp check_arptables root@frontend.dominio.com:/usr/lib64/nagios/plugins

Ora è possibile, all’interno della configurazione di Nagios, definire il comando da lanciare per monitorare arptables sul frontend (all’interno del file /etc/nagios/commands.cfg):

# 'check_remote_arptables' command definition
define command{
        command_name    check_remote_arptables
        command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "/usr/lib64/nagios/plugins/check_arptables $ARG1$ $ARG2$ $ARG3$"
        }

Tale comando non fa altro che connettersi al frontend via SSH (senza password, mediante un semplice scambio di chiavi RSA) e lanciare l’eseguibile precedentemente creato.

Nella configurazione di Nagios relativa allo specifico frontend, invece, occorre creare un servizio simile al seguente:

define service{
        use                             local-service         ; Name of service template to use
        host_name                       frontend.dominio.com
        service_description             Arptables Rules Status
        check_command                   check_remote_arptables!localhost!3!2
        notifications_enabled           0
        }

Configurazione del frontend

Sul frontend è sufficiente editare il file /etc/sudoers per consentire all’utente nagios di lanciare il comando arptables senza sessione TTY e senza richiesta di inserimento della password. Nella fattispecie, nel primo caso è sufficiente commentare la direttiva:

#Defaults requiretty

mentre nel secondo caso occorre inserire la seguente stringa:

nagios  ALL=(root)      NOPASSWD: /sbin/arptables

A configurazione del frontend terminata possiamo lanciare sull’NMS il comando:

[root@NMS ~]# service nagios reload

ed abbiamo finito.

Ora arptables è correttamente monitorato.

Alla prossima.

Nagios e gli event handlers

Networking, SO: Linux, , , , , , ,

Come già affermato in più occasioni, Nagios è sicuramente uno dei migliori NMS open source in circolazione.  Esso mette a disposizione del sysadmin tutta una serie di funzioni utilissime per verificare lo stato di salute relativo agli host monitorati e consente, in alcune circostanze, di gestire i downtime in modo automatico (ad esempio riavviando il servizio che ha generato lo status di tipo CRITICAL).

Nagios_logo_blackTale gestione automatica dei downtime viene realizzata attraverso i cosiddetti event handlers. Vediamo come configurarli.

Per prima cosa è necessario creare un comando simile al seguente, editando il file /etc/nagios/object/commands.cfg

define command {
command_name      flushcache
command_line      /usr/lib/nagios/plugins/eventhandlers/flushcache $HOSTADDRESS$ $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$
}

Nella fattispecie, il suddetto comando utulizza l’eseguibile flushcache, il cui compito è quello connettersi alla macchina target e di cancellare la cache del sistema operativo in caso di memory leak.

Occorre ora configurare l’event handler all’interno del servizio che si occupa del monitoraggio della RAM:

define service{        
use                            local-service              host_name                       vostrohost.vostrodominio.it        service_description             FREE RAM        check_command                   check_remote_ram!10!5        event_handler                   flushcache        notifications_enabled           0        
}

A questo punto la configurazione di Nagios può ritenersi ultimata. Non ci rimane che creare l’eseguibile flushcache all’interno della directory /usr/lib/nagios/plugins/eventhandlers/:

[root@NMS eventhandlers]# nano flushcache

il cui contenuto dovrà essere il seguente:

#!/bin/bash
if [ -n "$1" ];then
        case "$2" in
        OK)
                ;;
        WARNING)
                ;;
        UNKNOWN)
                ;;
        CRITICAL)
                case "$3" in
                SOFT)
                        case "$4" in
                        3)
                                echo -n "Flushing cache memory (3rd soft critical state)..."
                                /usr/lib/nagios/plugins/eventhandlers/connect_server.sh $1
                                ;;
                                esac
                        ;;
                HARD)
                        echo -n "Flushing cache memory..."
                        /usr/lib/nagios/plugins/eventhandlers/connect_server.sh $1
                        ;;
                esac
                ;;
        esac
else
        echo "Usage: flushcache <hostname>"
fi

exit 0

Dove $1 è la variabile $HOSTADDRESS$, $2 è il $SERVICESTATE$, $3 è il $SERVICESTATETYPE$ e $4 è il $SERVICEATTEMPT$ (sono semplicemente le variabili utilizzate nella definizione del comando flushcache in command.cfg).

Premesso che per il tipo di servizio local-service il max_check_attempts è impostato a 4 (nel file template.cfg), il suddetto codice bash non fa altro che interrogare la macchina target ($HOSTADDRESS), ricavando il $SERVICESTATE$ (OK, WARNING, UNKNOWN o CRITICAL), il $SERVICESTATETYPE$ (SOFT oppure HARD) ed il $SERVICEATTEMPT$ (ovvero il numero di check già eseguiti da Nagios nel caso in cui il $SERVICESTATE$ sia diverso da OK).

Il suddetto eseguibile prevede delle operazioni solo se il $SERVICESTATE$ è di tipo CRITICAL: in tal caso, al terzo check consecutivo (siamo ancora in SOFT state – parliamo di HARD state solo se il $SERVICESTATE$ è ancora CRITICAL dopo il quarto check), verrà lanciato l’eseguibile connect_server.sh (expect) che si occuperà di svuotare la cache della macchina monitorata. La suddetta operazione verrà eseguita nuovamente appena il $SERVICESTATETYPE$ passerà da SOFT a HARD.

Inoltre, tale eseguibile prevede come unico parametro in ingresso l’IP dell’host, ovvero $HOSTADDRESS$ (connect_server.sh $1).

Di seguito il sorgente relativo a connect_server.sh:

#!/usr/bin/expect

set hostname [lindex $argv 0]
set password "vostrapass"

spawn ssh -l root $hostname
expect "*assword:"
send "$password\n"
expect "#"
send "sync && echo 3 > /proc/sys/vm/drop_caches\n"
expect "#"
send "exit\n"
expect eof

Nella fattispecie, il comando vero e proprio che si occupa dello svuotamento della cache sulla macchina target è:

sync && echo 3 > /proc/sys/vm/drop_caches

A questo punto possiamo ricaricare la configurazione di Nagios per rendere effettive le suddette modifiche:

[root@NMS eventhandlers]# service nagios reload

ed abbiamo finito.

A presto.

Nagios e contenuti Web: script per verificare il codice HTML del nostro sito Internet

Networking, SO: Linux, , , , , , , , ,

In questo blog ho dedicato diversi post a Nagios, essendo, a mio avviso, uno dei migliori NMS open source in circolazione. Tra i vari plugin messi a disposizione dal suddetto software di monitoraggio vi è check_http, il quale è in grado di inviare delle richieste apposite al sito Web che intendiamo monitorare, segnalando eventuali problemi di connessione o errori di protocollo (401, 403, 404, 500, ecc.).

nagiosSpesso, però, si rende necessario verificare anche che il contenuto del sito Web sia effettivamente visualizzato dall’utente finale (cosa non sempre vera, soprattutto quando si ha un’infrastruttura costituita na N frontend che contattano N server API per “popolare” la pagina Web da offire ai client). Per questo motivo ho deciso di creare il seguente script, in grado di saggiare il contenuto del sito Web:

#!/bin/bash

if [ -n "$1" ];then
 result=`curl -s $1 | grep ng-controller=\"Main\"`
 if [ -n "$result" ]; then
       echo "OK"
       exit 0
 else
       echo "CRITICAL"
       exit 2
 fi
else
      echo "Usage: check_content <URL>"
fi

exit 0

Il suo funzionamento è abbastanza banale. Sostanzialmente esegue una chiamata curl al sito target, cercando un determinato pattern nel sorgente della pagina Web (in questo caso la stringa cercata è ng-controller=\”Main\”).

Se il suddetto pattern viene trovato, l’eseguibile esce con status 0 (OK), altrimenti restituisce un errore di tipo CRITICAL (exit 2).

Ovviamente occorre scegliere la stringa da cercare molto attentamente, ovvero deve essere qualcosa che non varia in base alle eventuali modifiche del codice HTML (release).

Spero che il suddetto script possa tornarvi utile.

Alla prossima.

LVS e Nagios: script bash per controllare lo stato dell’interfaccia virtuale

SO: Linux, , , , , , , ,

Ho realizzato il seguente script bash (da integrare a Nagios) per verificare lo stato dell’interfaccia virtuale presente su ciascun frontend dietro bilanciatore LVS (configurato in direct routing).

nagios

#!/bin/bash

if [ -n "$1" ];then
        status=`/sbin/ifconfig | grep $1 2> /dev/null`

        if [ -n "$status" ]; then
                echo "OK"
                exit 0
        else
                echo "CRITICAL"
                exit 2
        fi

else
        echo "Usage: check_if_status <IP>"
fi

exit 0

Lo script è abbastanza semplice. Per prima cosa lancio il comando ifconfig facendo un grep sull’IP specificato nella configurazione di Nagios. Se tale comando genera un output diverso dalla stringa vuota significa che l’interfaccia virtuale è attiva e quindi esco (exit 0), altrimenti genero un errore di tipo critico (exit 2).

Alla fine dello script ho inserito anche la parte relativa allo usage.

Alla prossima.

Debug dei plugin di Nagios mediante caputre_plugin.pl

SO: Linux, , ,

Nagios è sicuramente uno dei migliori NMS open source in circolazione. La sua configurazione, però, non è banale, soprattutto quando prevede l’utilizzo di alcuni plugin self-made di dubbia qualità.

Nagios_logo_blackAffinchè si possa effettuare un debug serio dei suddetti plugin è possibile utilizzare il seguente tool:

capture_plugin.pl, scaricabile da qui.

Una volta scaricato occorre convertirlo in eseguibile mendiante il comando:

[root@server ~]# chmod +x capture_plugin.pl

e successivamente salvarlo nella directory:

/usr/lib/nagios/plugins

mediante il comando:

[root@server ~]# mv capture_plugin.pl /usr/lib/nagios/plugins

A questo punto basterà anteporre nel file /etc/nagios/objects/command.cfg la seguente direttiva:

command_line $USER1/capture_plugin.pl

al comando che utilizza il plugin che si vuole debuggare. Ad esempio:

command_line $USER1/capture_plugin.pl $USER1$/check_smtp -H $HOSTADDRESS$ $ARG1$

dove check_smtp è il plugin di cui vogliamo testare il corretto funzionamento.

I comandi inviati dal suddetto plugin e la risposta ricevuta da parte dei sistema interrogato verranno salvati all’interno del file di testo /tmp/capture_plugin.log.

Ora anche il lavoro svolto dai nostri plugin potrà essere tenuto sotto controllo.

Alla prossima.

Graficizzare i risultati dei check di Nagios mediante pnp4nagios su Centos 6

SO: Linux, , , , , , , , , ,

Un sistema di monitoring degno di questo nome deve prevedere la possibilità di tracciare dei grafici in base ai risultati dei check automatici da esso effettuati.

Purtroppo Nagios non supporta tale funzionalità in maniera nativa, ma, per fortuna, sono disponibili tutta una serie plugin pensati appositamente per il suddetto NMS, in grado di svolgere la funzione in oggetto.

Il plugin che ho scelto prende il nome di pnp4nagios ed è scaricabile da qui.

pnp4nagios

Una volta completato il download vediamo come installare e configurare il tutto.

Preparazione della macchina ed installazione di pnp4nagios

Per prima cosa scompattiamo la tarball mediante il comando:

 [root@NMS ~]# tar -xzvf pnp4nagios-0.6.21.tar.gz

Come prerequisiti per la compilazione degli eseguibili presenti all’interno della directory appena creata è necessario installare sul nostro sistema il compilatore (gcc), una libreria perl, ovvero perl-time-HiRes (utile per testare la configurazione ad installazione avvenuta), una libreria PHP (necessaria per l’esportazione dei grafici in formato pdf) ed il software rrdtool:

[root@NMS ~]# yum install gcc
[root@NMS ~]# yum install perl-Time-HiRes
[root@NMS ~]# yum install php-gd
[root@NMS ~]# yum install rrdtool perl-rrdtool

Ad installazione avvenuta, posizioniamoci nella dir appena creata

[root@NMS ~]# cd pnp4nagios-0.6.21

e lanciamo i comandi:

[root@NMS pnp4nagios-0.6.21]# ./configure
[root@NMS pnp4nagios-0.6.21]# make all
[root@NMS pnp4nagios-0.6.21]# make fullinstall

In particolare, il primo comando serve a verificare che il sistema sia dotato di tutti gli applicativi necessari per la compilazione dei sorgenti relativi a pnp4nagios; il secondo comando esegue la compilazione vera e propria mentre il terzo comando installa il plugin sulla nostra macchina.

La dir target dell’installazione sarà la seguente: /usr/local/pnp4nagios/

Configurazione dell’interfaccia Web di pnp4nagios

Per ragioni di sicurezza occorre dapprima disabilitare la pagina install.php, semplicemente rinominandola:

[root@NMS ~]# mv /usr/local/pnp4nagios/share/install.php /usr/local/pnp4nagios/share/install.php.ignore

In seguito dobbiamo linkare la dir share di pnp4nagios all’interno di /var/www/html, in modo che sia raggiungibile via Web:

[root@NMS ~]# ln -s /usr/local/pnp4nagios/ /var/www/html/pnp4nagios

Inoltre, bisogna fare in modo che il suddetto plugin utilizzi lo stesso file di autenticazione HTTP utilizzato da Nagios:

[root@NMS ~]# cat /etc/httpd/conf.d/nagios.conf | grep AuthUserFile

Tale file (per default) dovrebbe essere il seguente: /etc/nagios/passwd

Ergo sostituiamo la entry presente nativamente su /etc/httpd/conf.d/pnp4nagios.conf con alla voce AuthUserFile con /etc/nagios/passwd

Ricarichiamo la configurazione di httpd per rendere effettive le suddette modifiche:

[root@NMS ~]# service httpd reload

Configurazione di Nagios

Supponendo che la modalità di funzionamento di pnp4nagios sia la synchronous, le modifiche da apportare alla configurazione di Nagios (/etc/nagios/nagios.cfg) sono le seguenti:

1) Abilitare i perfdata, sostituendo

process_performance_data=0

con

process_performance_data=1

2) Decommentare le diciture:

host_perfdata_command=process-host-perfdata service_perfdata_command=process-service-perfdata

All’interno del file /etc/nagios/objects/commands.cfg occorre sostituire le diciture:

'process-host-perfdata' command definition define command{        command_name    process-host-perfdata        command_line    /usr/bin/printf "%b" "$LASTHOSTCHECK$t$HOSTNAME$t$HOSTSTATE$t$HOSTATTEMPT$t$HOSTSTATETYPE$t$HO$        } 'process-service-perfdata' command definition define command{        command_name    process-service-perfdata        command_line    /usr/bin/printf "%b" "$LASTSERVICECHECK$t$HOSTNAME$t$SERVICEDESC$t$SERVICESTATE$t$SERVICEATTEMP$        }

con:

define command {        command_name    process-service-perfdata        command_line    /usr/bin/perl /usr/local/pnp4nagios/libexec/process_perfdata.pl } define command {        command_name    process-host-perfdata        command_line    /usr/bin/perl /usr/local/pnp4nagios/libexec/process_perfdata.pl -d HOSTPERFDATA }

Ciò si rende necessario per consentire a pnp4nagios di processare le perfdata provenienti dai plugin utilizzati per effettuare i check (se le supportano).

Per quanto riguarda il file /etc/nagios/objects/templates.cfg occorre aggiungere la stringa:

action_url      /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=_HOST_

nella definizione degli host, e la stringa:

action_url      /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$

nella definizione dei servizi.

A configurazione di Nagios completata lanciamo un restart del demone in questione:

[root@NMS ~]# service nagios restart

Verifica della configurazione di Nagios e pnp4nagios

Per effettuare i check della configurazione relativa a Nagios ed al suo plugin pnp4nagios è possibile scaricare lo script perl verify_pnp_config:

[root@NMS ~]# wget http://verify.pnp4nagios.org/verify_pnp_config

Rendiamolo eseguibile:

[root@NMS ~]# chmod +x  verify_pnp_config

Lanciamo dunque il comando:

[root@NMS ~]# ./verify_pnp_config -m sync -c /etc/nagios/nagios.cfg -p /usr/local/pnp4nagios/etc

e se il check da risultato positivo significa che la procedura di configurazione è andata a buon fine.

Come ulteriore check, verifichiamo che nella dir /usr/local/pnp4nagios/var/perfdata vi sia una dir per ogni host su cui è stata abilitata l’action_url e che tali directory contengano dei file con estensione *.rrd (round robin data) ed *.xml.

Nel caso in cui queste dir non contengano i suddetti file (recanti nomenclatura del tipo nomeservizio.rrd e nomeservizio.xml) significa che i plugin utilizzati per effettuare i check non supportano le perfdata.

Infine, all’interno della directory /usr/local/pnp4nagios/share/templates.dist sono presenti le pagine Web contenenti la struttura dei grafici per i plugin nativi di Nagios. Se avete installato qualche plugin aggiuntivo, solitamente viene resa disponibile per il download anche la pagina Web per i grafici ad esso associati. Tale pagina dovrà essere salvata all’interno della directory /usr/local/pnp4nagios/share/templates.

Fine del post, alla prossima.

PS: per fare in modo che pnp4nagios possa creare i file *.rrd è necessario disabilitare SElinux mediante il comando:

[root@NMS ~]# setenforce 0

Nagios ed il carattere di escape

SO: Linux, , , , , , ,

Potrebbe succedere che su un determinato sito Web monitorato da Nagios sia stata abilitata l’autentica HTTP (per ovvie ragioni di sicurezza). Nel caso in cui la coppia username/password contenesse il carattere $, ovvero un carattere speciale utilizzato abbondantemente all’interno delle configurazioni relative all’NMS in questione (ad esempio per identificare le variabili in genere ed i parametri da passare ai vari comandi per eseguire i check), è necessario utilizzare la sequenza di escape. ovvero \\.

Nagios2.png

Ad esempio, supponendo che lo username sia user e che la password sia $password$, la configurazione di Nagios dovrà essere simile alla seguente:

define service{
        use                                  local-service         ; Name of service template to use
        host_name                       sito.dominio.it
        service_description            HTTP
        check_command               check_http_auth!sito.dominio.it!user:\\$password$
        notifications_enabled         0
        }

Come al solito, per rendere effettive le modifiche sarà necessario riavviare il demone in questione.

Alla prossima.