Archivi tag: nagios

CentOS 6: verificare la configurazione di Nagios da linea di comando

Configurare Nagios non è sicuramente un’operazione banale. Proprio per questo motivo, prima di restartare il demone in oggetto (affinchè le modifiche diventino effettive), è buona norma controllare sempre la configurazione dello stesso, utilizzando il seguente comando:

nagios -v /etc/nagios/nagios.cfg

Ovviamente tale check può essere effettuato puntando esclusivamente al file di configurazione principale (nagios.cfg), e non ai file che identificano i network element da monitorare (presenti nella directory /etc/nagios/objects).

Alla prossima.

Effettuare check su macchine remote mediante Nagios

In questo post ho discusso dell’autenticazione SSH mediante lo scambio delle chiavi RSA. Adesso spiegherò come effettuare dei check su macchine remote (CentOS 6) utilizzando uno degli NMS più diffusi in ambito open source, ovvero Nagios.

nag.jpg

In particolare, esso ci mette a disposizione un plugin pensato proprio per eseguire i suddetti check, il cui nome è piuttosto esplicativo: check_by_ssh. Prima di scendere nel dettaglio su come utilizzare il plugin in questione (con relativa sintassi), occorre descrivere, passo dopo passo, l’iter per la preparazione delle macchine remote e della macchina che ospita l’NMS vero e proprio.

Preparazione della macchina su cui è installato Nagios

Il primo step consiste nella modifica delle proprietà relative all’utente nagios, il quale verrà utilizzato dall’NMS per autenticarsi sulla macchina remota e lanciare tutti i controlli del caso. Analizzando il file /etc/passwd si nota che l’utente nagios possiede le seguenti caratteristiche:

nagios:x:496:492::/var/spool/nagios:/sbin/nologin

ciò significa che il suddetto utente non può loggarsi ed utilizzare la shell.

Per rimuovere tale limitazione è sufficiante modificare la stringa precedentemente illustrata nel modo seguente:

nagios:x:496:492::/var/spool/nagios:/bin/bash

dove 496 rappresenta l’UID, 492 il GID, /var/spool/nagios la directory home e /bin/bash la shell dell’utente.

A questo punto modifichiamo la password associata all’utente in questione:

[root@NMS ~]# passwd nagios

ed infine proviamo a loggarci:

su nagios

Se il prompt ottenuto è il seguente:

bash-4.1$

vuol dire che le nostre modifiche sono andate a buon fine.

Ora procediamo con la generazione della coppia di chiavi RSA (pubblica e privata) per la macchina su cui è installato Nagios (le quali, ovviamente, devono riferirsi all’utente nagios). Il comando da lanciare è il seguente:

 bash-4.1$ ssh-keygen
 Generating public/private rsa key pair.
 Enter file in which to save the key (/var/spool/nagios/.ssh/id_rsa):
 Enter passphrase (empty for no passphrase):
 Enter same passphrase again:
 Your identification has been saved in /var/spool/nagios/.ssh/id_rsa.
 Your public key has been saved in /var/spool/nagios/.ssh/id_rsa.pub.
 The key fingerprint is:
 f1:e5:35:cc:29:78:48:89:b5:ea:d6:ce:42:f5:3c:b8 nagios@NMS.test.loc

Preparazione delle macchine remote

Anche su ciascuna macchina remota che deve essere interrogata dal nostro NMS è necessario modificare le proprietà dell’utente nagios (seguendo quanto riportato in precedenza), eccezion fatta per la generazione delle chiavi RSA.

Una volta ottenuto il prompt:

bash-4.1$

sulla macchina remota, spostiamoci nella home directory di nagios (cd /var/spool/nagios) e lanciamo i seguenti comandi:

bash-4.1$ mkdir .ssh

bash-4.1$ cd .ssh

bash-4.1$ nano authorized_keys

inserendo al suo interno il contenuto del file id_rsa.pub presente nella macchina che ospita l’NMS.

Infine digitiamo:

bash-4.1$ chmod 600 authorized_keys

e proviamo a loggarci (dall’NMS) sulla macchina remota:

bash-4.1$ ssh remotemachine.test.loc

Se il suddetto comando non ci restituisce alcun tipo di errore (e soprattutto non ci richiede l’inserimento di password alcuna), vuol dire che l’autenticazione SSH mediante lo scambio delle chiavi RSA funziona correttamente.

Installiamo quindi i plugins di Nagios attraverso yum:

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

Ad installazione completata torniamo sulla macchina su cui è installato Nagios ed esaminiamo il plugin check_by_ssh.

Dall’help del suddetto comando si ottiene:

bash-4.1$ ./check_by_ssh --help

check_by_ssh -H <host> -C <command> [-fqv] [-1|-2] [-4|-6]
       [-S [lines-- [-E [lines-- [-t timeout] [-i identity]
       [-l user] [-n name] [-s servicelist] [-O outputfile]
       [-p port] [-o ssh-option] [-F configfile]

Ergo, editando il file commands.cfg presente nella dir /etc/nagios/objects possiamo forgiare dei comandi ad hoc, ad esempio:

# 'check_remote_disk' command definition
define command{
        command_name    check_remote_disk
        command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "/usr/lib64/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$"
        }

# 'check_remote_load' command definition
define command{
        command_name    check_remote_load
        command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "/usr/lib64/nagios/plugins/check_load -w $ARG1$ -c $ARG2$"
        }

# 'check_remote_procs' command definition
define command{
        command_name    check_remote_procs
        command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "/usr/lib64/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -s $ARG3$"
        }

# 'check_remote_swap' command definition
define command{
        command_name    check_remote_swap
        command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "/usr/lib64/nagios/plugins/check_swap -w $ARG1$ -c $ARG2$"
        }

Non ci resta che modificare il file di configurazione che consente a Nagios di monitorare la macchina remota, ad esempio remotemachine.test.loc.cfg:

define service{
        use                             local-service         ; Name of service template to use
        host_name                       remotemachine.test.loc
        service_description             Disk Usage
        check_command                   check_remote_disk!20%!10%!/
        notifications_enabled           0
        }

define service{
        use                             local-service         ; Name of service template to use
        host_name                       remotemachine.test.loc
        service_description             CPU Load
        check_command                   check_remote_load!5.0,4.0,3.0!10.0,6.0,4.0
        notifications_enabled           0
        }

define service{
        use                             local-service         ; Name of service template to use
        host_name                       remotemachine.test.loc
        service_description             CPU Procs
        check_command                   check_remote_procs!250!400!RSZDT
        notifications_enabled           0
        }

define service{
        use                             local-service         ; Name of service template to use
        host_name                      remotemachine.test.loc
        service_description             SWAP Usage
        check_command                   check_remote_swap!20!10
        notifications_enabled           0
        }

Riavviamo Nagios per rendere effettive le suddette modifiche:

[root@NMS objects]# service nagios restart

ed abbiamo finito.

Enjoy!

PS: se sulla macchina target è in funzione SElinux occorre disabilitarlo mediante il comando:

[root@remotemachine]# setenforce 0

e successivamente evitare che tale servizio venga riattivato dopo ogni reboot:

[root@remotemachine]# nano /etc/sysconfig/selinux

sostituendo la stringa

SELINUX=enforcing

con

SELINUX=disabled

Disabilitare i check di Nagios durante determinate fasce orarie

Scenario

Windows Server 2008 R2 che funge da Domain Controller ed Exchange server (si tratta di una piccola LAN, ergo, non è indispensabile dislocare tali servizi su due macchine differenti). Per monitorarne le risorse (in termini di RAM, CPU e di spazio sul disco), utilizzo delle query WMI, instradate dall’NMS (Nagios) ad un servizio dedicato in ascolto sul server (ovvero NRPE_NT – per approfondire l’argomento vi consiglio di consultare questo post).

nag.jpg

Problema

Poichè sul server in questione viene eseguito il backup dell’intero sistema operativo (compreso il DB di Exchange) a partire dalle 22 di ogni sera, durante tale lasso di tempo, Nagios produce una miriade di allarmi recanti l’errore Socket timeout after 10 seconds. Questo, in soldoni, significa che il DC non è stato in grado di servire la richiesta in quanto troppo impegnato (oppure la richiesta gli è giunta proprio durante il backup dei file utilizzati da NRPE_NT).

Soluzione

Disabilitare le query WMI di Nagios dalle 22 alle 23.

Per fare questo si possono seguire due strade:

1) utilizzare uno scrip bash creato ad hoc per disabilitare i check specifici, da lanciare mediante cron;

2) lavorare direttamente sul file di configurazione dell’NMS in questione.

Personalmente preferisco la seconda soluzione, in quanto più pulita (poichè coinvolge direttamente Nagios senza passare per uno scrip aggiuntivo e per cron – less is more).

Per prima cosa, occorre lavorare sul file timeperiods.cfg presente nella directory /etc/nagios/objects, creando l’oggetto NRPE_off:

define timeperiod{
         timeperiod_name NRPE_off
         alias           24 Hours A Day, 7 Days A Week
         sunday          00:00-22:00,23:00-24:00
         monday          00:00-22:00,23:00-24:00
         tuesday         00:00-22:00,23:00-24:00
         wednesday       00:00-22:00,23:00-24:00
         thursday        00:00-22:00,23:00-24:00
         friday          00:00-22:00,23:00-24:00
         saturday        00:00-22:00,23:00-24:00
         }

A questo punto è necessario modificare l’oggetto windows-service, presente nel file templates.cfg. Nella fattispecie, l’opzione da editare è check_period il cui valore dovrà essere NRPE_off:

define service{
        name                            windows-service
        check_period              NRPE_off

        ...

Ovviamente, le query WMI definite su Nagios sfruttano il template windows-service e quindi ereditano come check_period NRPE_off (precedentemente definito).

Per completezza, riporto uno stralcio della configurazione relativa alla query WMI che ha il compito di monitorare la RAM allocata:

define service{
         use                                  windows-service        ; Name of service template to use
         host_name                    domain-controller
         service_description     query WMI Memory for Microsoft Windows Machine
         check_command          check_WMI_mem!_TOTAL!85,95
 }

Lanciamo un restart di Nagios per rendere effettive le suddette modifiche:

[root@nagios objects]# service nagios restart

ed abbiamo finito.

Alla prossima.

Logwatch e le unmatched entries

Scenario: server casalingo con installato Nagios per controllare i servizi ed un server FTP attivo 24/7. Su tale macchina è presente Logwatch con funzioni di reportistica giornaliera, settimanale e mensile.

Problema: un numero indefinito di unmatched entries presenti nel file generato da Logwatch. Esse si riferiscono principalmente ai check di Nagios relativi al servizio FTP.

Soluzione: portare Logwatch ad ignorare i suddetti check.

logwatch.jpg

Per fare ciò occorre prima di tutto creare il file ignore.conf all’interno della directory /etc/logwatch/conf:

nightfly@nightbox:~$ cd /etc/logwatch/conf/
nightfly@nightbox:/etc/logwatch/conf$ touch ignore.conf

Successivamente, all’interno di tale file sarà necessario inserire la seguente direttiva:

.*Client "127.0.0.1"

In questo modo, tutti i check di Nagios verrano totalmente ignorati dalla reportistica di Logwatch, eliminando informazioni superflue e facilitando la vita al sysadmin (aka il sottoscritto).

Enjoy.

Nagios: monitoraggio degli host senza ricorrere ai ping

Come misura (molto blanda) di protezione per i server che gestisco (esposti su Internet), ho deciso di inibire le risposte ai ping (in gergo tecnico ICMP echo reply).

 

nag.jpg

Però, poichè ho la necessità di monitorare l’effettiva raggiungibilità di tali host, ho pensato di implementare un ckeck basato esclusivamente sul protocollo SSH. In particolare, ho effettuato le seguenti operazioni:

1) ho creato un gruppo nagios specifico, che ho chiamato noping-host. Per fare ciò mi sono posizionato nella directory /etc/nagios3/conf.d ed ho lanciato il comando:

nightfly@nightbox:/etc/nagios3/conf.d$ sudo nano noping-host_nagios2.cfg

il contenuto del suddetto file è il seguente:

define host{
        name                            noping-host    ; The name of this host template
        notifications_enabled           1       ; Host notifications are enabled
        event_handler_enabled           1       ; Host event handler is enabled
        flap_detection_enabled          1       ; Flap detection is enabled
        failure_prediction_enabled      1       ; Failure prediction is enabled
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
                check_command                   check_ssh_port!2293
                max_check_attempts              10
                notification_interval           0
                notification_period             24x7
                notification_options            d,u,r
                contact_groups                  admins
        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
        }

Come potete notare, alla direttiva check_command è associato il comando da lanciare per verificare la raggiungibilità dell’host, ovvero check_ssh_port!2293, dove 2293 è la porta su cui è in ascolto SSH.

2) ho creato il file relativo all’host da monitorare, lanciando il comando:

nightfly@nightbox:/etc/nagios3/conf.d$ sudo nano host-remoteserver_nagios3.cfg

il cui contenuto è il seguente:

define host {
        host_name   remoteserver
        alias       remoteserver
        address     remoteserver.homeip.net
        use         noping-host
        }

dove remoteserver.homeip.net è l’hostname pubblico della macchina che vogliamo monitorare.

Infine riavviamo nagios:

nightfly@nightbox:/etc/nagios3/conf.d$ sudo service nagios3 restart

ed abbiamo finito.

Alla prossima.

Controllare lo stato di iptables mediante Nagios

Recentemente su uno dei miei server ho lanciato il comando:

nightfly@nightbox:~$ sudo iptables -L

e con mio enorme disappunto mi sono accorto che le regole di firewalling che il server avrebbe dovuto caricare all’avvio erano praticamente assenti (eccezion fatta per fail2ban), indi per cui ho deciso di monitorare lo stato di iptables mediante Nagios.

iptables.jpg

Lo scrip che ho utilizzato per i check potete scaricarlo da qui. Inoltre, poichè tale scrip è piuttosto bacato, ho deciso di apportare qualche piccola correzione. Di seguito la versione originale dello scrip:

#!/bin/bash

PARAM1=$1
TABLE=$2
MINRULES=$3
PARAM4=$4
LOG=/var/log/iptables/iptables.log
CHKIPTBLS=`/sbin/iptables -n -t filter -L |wc -l`

#
# Parameter Validation
##

if [ "$PARAM1" != "-T" -o "$TABLE" == "" -o "$MINRULES" != "-r" -o "$PARAM4" == "" ]; then
        echo "Usage: $0 -T <table> -r <min rules>"
        echo ""
        exit 3
                # Nagios exit code 3 = status UNKNOWN = orange

if [ "$PARAM1" == "-h" ]; then
        echo ""
        echo "         -h = Display's this Help"
        echo "         -T = Table to check"
        echo "                 Available Tables:"
        echo "                    nat"
        echo "                    mangle"
        echo "                    filter"       
        echo "         -r = Minimun quantity of rules"
        echo ""
        # Nagios exit code 3 = status UNKNOWN = orange
                exit 3
   fi
fi

##
#    DO NOT MODIFY ANYTHING BELOW THIS
##

$CHKIPTBLS >/dev/null 2>/dev/null

if [ "$CHKIPTBLS" == 0 ]; then
    TOTRULES=$CHKIPTBLS
else
    TOTRULES=$[$CHKIPTBLS-8]
fi

if [ "$TOTRULES" -gt "$PARAM4" ]; then
                    echo "OK - Iptables are OK the table $TABLE has $TOTRULES rules configured"
                    # Nagios exit code 0 = status OK = green
                    exit 0
else
                    echo " CRITICAL - Iptables are CRITICAL the table $TABLE has $TOTRULES rules configured"
                    for i in `w  -h | cut -f1 -d" " | sort | uniq`
                    do

                        echo "`date '+%d/%m/%Y - %H:%M:%S'` - CRITICAL - $i is logged in and there are only $TOTRULES loaded" >> $LOG
                    done
                    # Nagios exit code 2 = status CRITICAL = red
                    exit 2               
fi

Punto primo: la seconda condizione dell’if non ha praticamente senso, in quanto la prima è sempre verificata.
E’ bastato invertire le due condizioni e trattarle separatamente:

#
# Parameter Validation
##

if [ "$PARAM1" == "-h" ]; then
        echo ""
        echo "          -h = Display's this Help"
        echo "          -T = Table to check"
        echo "          Available Tables:"
        echo "          nat"
        echo "          mangle"
        echo "          filter"
        echo "          -r = Minimun quantity of rules"
        echo ""
        # Nagios exit code 3 = status UNKNOWN = orange
        exit 3
fi

if [ "$PARAM1" != "-T" -o "$TABLE" == "" -o "$MINRULES" != "-r" -o "$PARAM4" ==                                                                                         "" ]; then
        echo "Usage: $0 -T <table> -r <min rules>"
        echo ""
        exit 3
        # Nagios exit code 3 = status UNKNOWN = orange
fi

Punto secondo: la variabile CHKIPTBLS utilizza sempre e comunque la tabella filter, dunque il parametro -T non ha senso di esistere. Possiamo però ovviare a tale mancanza, permettendo all’utente di scegliere su quale tabella (tra filter, mangle e nat) effettuare i controlli, modificando la variabile citata in precedenza nel seguente modo:

CHKIPTBLS=`sudo /sbin/iptables -n -t "$TABLE" -L |wc -l`

Punto terzo: la condizione

if [ "$TOTRULES" -gt "$PARAM4" ]; then

controlla che il numero di regole caricate sia strettamente maggiore di quello definito mediante il parametro -r. Questo però cozza con quanto dichiarato dall’autore dello scrip, ovvero:

OK - The number of Iprules equal o more than the minimun that we setup on the -r variable

Per ovviare a tale errore, occorre sostituire la condizione riportata in precedenza con questa:

if [ "$TOTRULES" -ge "$PARAM4" ]; then

Punto quarto: nagios non ha i permessi per lanciare iptables, ergo dobbiamo effettuare delle modifiche al file /etc/sudoers, inserendo la entry:

nagios   ALL = NOPASSWD: /sbin/iptables

alla fine del file. 

In definitiva, lo scrip per controllare lo stato di iptables dovrà essere il seguente:

#!/bin/bash

PARAM1=$1
TABLE=$2
MINRULES=$3
PARAM4=$4
LOG=/var/log/check_iptables.log
CHKIPTBLS=`sudo /sbin/iptables -n -t "$TABLE" -L |wc -l`

#
# Parameter Validation
##

if [ "$PARAM1" == "-h" ]; then
        echo ""
        echo "          -h = Display's this Help"
        echo "          -T = Table to check"
        echo "          Available Tables:"
        echo "          nat"
        echo "          mangle"
        echo "          filter"
        echo "          -r = Minimun quantity of rules"
        echo ""
        # Nagios exit code 3 = status UNKNOWN = orange
        exit 3
fi

if [ "$PARAM1" != "-T" -o "$TABLE" == "" -o "$MINRULES" != "-r" -o "$PARAM4" == "" ]; then
        echo "Usage: $0 -T <table> -r <min rules>"
        echo ""
        exit 3
        # Nagios exit code 3 = status UNKNOWN = orange
fi

##
#       DO NOT MODIFY ANYTHING BELOW THIS
##

$CHKIPTBLS >/dev/null 2>/dev/null

if [ "$CHKIPTBLS" == 0 ]; then
        TOTRULES=$CHKIPTBLS
else
        TOTRULES=$[$CHKIPTBLS-8]
fi

if [ "$TOTRULES" -ge "$PARAM4" ]; then
                    echo "OK - Iptables is OK The Table $TABLE has $TOTRULES rules configured"
                    # Nagios exit code 0 = status OK = green
                    exit 0
else
                    echo " CRITICAL - Iptables is CRITICAL The Table $TABLE has $TOTRULES rules configured"
                                        for i in `w  -h | cut -f1 -d" " | sort | uniq`
                                        do
                                                echo "`date '+%d/%m/%Y - %H:%M:%S'` - CRITICAL - $i is logged in and there are only $TOTRULES loaded" >> $LOG
                                        done
                    # Nagios exit code 2 = status CRITICAL = red
                    exit 2
fi

Se il file /var/log/check_iptables.log non esiste, dovrete crearlo mediante il comando:

nightfly@nightbox:~$ sudo touch /var/log/check_iptables.log

A questo punto possiamo rinominare lo scrip:

nightfly@nightbox:~$ mv check_iptables_status.sh check_iptables_status

rendondolo successivamente eseguibile:

nightfly@nightbox:~$ chmod +x check_iptables_status

Spostiamolo nella directory /usr/lib/nagios/plugins:

nightfly@nightbox:~$ sudo mv check_iptables_status /usr/lib/nagios/plugins

Creiamo il file iptables.cfg nella directory /etc/nagios-plugins/config:

nightfly@nightbox:/etc/nagios-plugins/config$ sudo nano iptables.cfg

il cui contenuto dovrà essere il seguente:

# 'check_iptables_status' command definition
define command{
        command_name    check_iptables_status
        command_line    /usr/lib/nagios/plugins/check_iptables_status -T '$ARG1$' -r '$ARG2$'
        }

infine aggiungiamo la seguente direttiva al file dell’host su cui vogliamo monitorare lo stato di iptables (tale file è presente nella directory /etc/nagios3/conf.d):

define service{
        use                             generic-service         ; Name of service template to use
        host_name                       localhost
        service_description             iptables
                check_command                   check_iptables_status!filter!84
}

Dove 84 è il numero minimo di regole di firewalling attive.

Infine, riavviamo nagios:

nightfly@nightbox:~$ sudo service nagios3 restart

ed abbiamo finito.

Alla prossima.

Swatch: configurazione per il monitoraggio dei server Web

Di seguito riporto la configurazione del mio Swatch, in grado di tenere sotto controllo ciò che accade sul server Web (Apache) che attualmente ho in gestione:

ignore /nagios-plugins/

#HTTP Forbidden
watchfor  /403/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Access Forbidden

#HTTP Not Found
watchfor  /404/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Not Found

#HTTP Internal Server Error
watchfor  /500/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Internal Server Error

#HTTP OK
watchfor  /200/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Hit OK

apache_display.png

Poichè sul server è presente anche nagios che ogni tanto effettua dei check sull’HTTPS, ho dovuto utilizzare la entry ignore /nagios-plugins/, evitando così di ricevere un’email ad ogni controllo.

Inoltre, sul server Web è presente l’autentica .htaccess, quindi ho messo sotto monitoraggio anche le hit andate a buon fine, in modo da poter verificare quale utente ha effettuato l’accesso alle aree riservate. Ciò è stato possibile anche grazie al fatto che sul server non vi è una grande mole di richieste. In caso contrario avrei certamente evitato una configurazione del genere, pena il rischio di beccarmi un ban sullo smarthost.

Infine, non ho ritenuto opportuno controllare gli errori HTTP 401 (Unauthorized), in quanto tale funzione è svolta egregiamente da fail2ban.

A presto.

Query WMI clientless mediante Nagios ed NRPE_NT

Premessa

Prima di introdurre questa piccola guida, occorre spiegare cosa s’intende per WMI. Nella fattispecie, tale acronimo sta per Windows Management Instrumental, ovvero un’estensione del Win32 driver model, grazie alla quale è possibile monitorare e gestire le macchine (sia client che server) su cui è installato il sistema operativo di casa Microsoft (da Windows 2000 in poi).

Inulte dire che esistono già delle piattaforme sviluppate ad hoc che supportano le query WMI (tra cui SCOM), ma la cosa veramente interessante consiste nel poter sviluppare i propri sistemi di monitoraggio basati su scrip custom editati in VBscrip o PowerShell.

Ora, nel caso in cui si voglia allestire un sistema di monitoraggio che supporti le query WMI in ambiente open source, la scelta ricade necessariamente su nagios3. Inoltre, poichè nagios3 non supporta in modo nativo le query WMI, si rende indispensabile l’utilizzo di un tool che funge da tramite tra il server di monitoraggio e le macchine che verranno interrogate. Tale tool prende il nome di NRPE_NT (potete scaricarlo da qui, è gratuito).

nrpe.png

 

Come si può capire dall’immagine precedente, nagios3, attraverso il comando check_nrpe, invia una query ad NRPE_NT (installato su una macchina Windows), il quale la inoltrerà (comportandosi come un vero e proprio proxy) all’host Microsoft di destinazione.

Ricapitolando, abbiamo bisogno dei seguenti elementi per mettere in piedi il nostro sistema di monitoraggio WMI:

1) nagios3;

2) il plugin check_nrpe;

2) NRPE_NT;

3) i plugins V2 per NRPE_NT (potete scaricarli da qui).

Installazione di check_nrpe e configurazione di nagios3

Partendo dal presupposto che nagios3 sia già presente sulla nostra linux box, procediamo con l’installazione del plugin check_nrpe. Per fare ciò occorre digitare:

nightfly@nightbox:~$ sudo apt-get install nagios-nrpe-plugin

Adesso possiamo definire alcuni comandi custom da inviare alla macchina Windows su cui è installato NRPE_NT, affinchè quest’ultima possa inoltrare la query all’host di destinazione. In particolare, creiamo il file wmi.cfg all’interno della directory /etc/nagios-plugins/config, il cui contenuto sarà:

# nagios-WMI-cpu check command definition

define command {

command_name check_WMI_cpu

command_line /usr/lib/nagios/plugins/check_nrpe -H <IP macchina NRPE_NT> -c get_cpu -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

# nagios-WMI-disk check command definition

define command {

command_name check_WMI_disk

command_line /usr/lib/nagios/plugins/check_nrpe -H<IP macchina NRPE_NT> -c get_disk -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

# nagios-WMI-mem check command definition

define command {

command_name check_WMI_mem

command_line /usr/lib/nagios/plugins/check_nrpe -H<IP macchina NRPE_NT> -c get_mem -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

Ovviamente esistono altri comandi di cui si può usufruire, una lista a cui far riferimento la trovate qui.

Bene, adesso definiamo i servizi da monitorare per i nostri host Windows. Un file di configurazione da utilizzare come template e da posizionare nella directory /etc/nagios3/conf.d è il seguente:

define host {
host_name   hostWindows
alias       nightflyclient
address     192.168.1.11
use         generic-host
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_descripion             query WMI CPU for Microsoft Windows Machine
check_command                   check_WMI_cpu!CPU0!80,90
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_descripion             query WMI Disk for Microsoft Windows Machine
check_command                   check_WMI_disk!C:!80,90
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_descripion             query WMI Memory for Microsoft Windows Machine
check_command                   check_WMI_mem!_TOTAL!80,90
}

Salviamo il file appena creato e passiamo all’installazione di NRPE_NT sulla macchina Windows che fungerà da proxy per le query WMI.

Installazione di NRPE_NT

Per prima cosa scompattiamo il file nrpe_nt.0.8b-bin.rar e salviamone il contenuto all’interno della directory NRPE_NT presente in C:

Creiamo inoltre, sempre all’interno della directory NRPE_NT, la cartella Plugins ed all’interno di quest’ultima creiamo un’ulteriore cartella che chiameremo V2, nella quale salveremo il contenuto del file wmi-1.3.rar.

A questo punto editiamo il file nrpe.cfg presente nella directory bin, che si trova dentro la cartella NRPE_NT.

I punti da modificare sono sostanzialmente tre, ovvero:

allowed_hosts=<IP della linux box su cui è installato nagios3>

(in modo da consentire a nagios di connettersi ad NRPE_NT per usarlo come proxy);

dont_blame_nrpe=1

(in modo da consentire l’esecuzione di comandi da remoto);

include=C:\NRPE_NT\Plugins\V2\V2_nrpe_commands.cfg

(per dare in pasto ad NRPE_NT alcuni comandi aggiuntivi di monitoraggio).

Una volta configurato NRPE_NT passiamo alla sua installazione. Per fare ciò apriamo il prompt (start->esegui->cmd), posizioniamoci in C: e successivamente nella dir bin presente in NRPE_NT.

cmd.jpg

A questo punto lanciamo il comando:

nrpe_nt.exe -i

dove la flag -i sta per install.

NB: nel caso in cui stiate utilizzando una macchina su cui è installato Windows 7, prima di procedere con l’installazione di NRPE_NT dovete modificare le impostazioni di controllo dell’account utente:

controllo.png

Una volta installato il servizio NRPE_NT occorre avviarlo mediante il comando net start nrpe_nt oppure attraverso pannello di controllo -> strumenti di amministrazione -> servizi.

Controlliamo ora che NRPE_NT sia in ascolto sulla nostra macchina digitando:

netstat -ano | find ":5666"

il cui output dovrà essere simile al seguente:

TCP    0.0.0.0:5666           0.0.0.0:0              LISTENING       1976

NB: affinchè la macchina su cui è installato nagios3 possa connettersi ad NRPE_NT occorre disabilitare il Firewall di Windows.

Test per verificare il corretto funzionamento di NRPE_NT

Per verificare il corretto funzionamento di NRPE_NT effettuiamo il login sulla nostra linux box e posizioniamoci nella directory /usr/lib/nagios/plugins. A questo punto lanciamo il comando:

nightfly@nightbox:/usr/lib/nagios/plugins$ ./check_nrpe -H <IP della macchina Windows su cui è installato NRPE_NT>

Se l’output immediatamente successivo sarà:

NRPE_NT v0.8b/2.0

vuol dire che NRPE_NT funziona correttamente.

Infine, riavviamo nagios3 per rendere effettive le modifiche della sua configurazione messe in atto nella prima parte di questa guida:

nightfly@nightbox:~$ sudo service nagios3 restart

Adesso sarà possibile monitorare gli host Windows mediante nagios3 ed NRPE_NT.

See ya.

Monitorare la RAM su un dispositivo Cisco mediante SNMP

Per visualizzare la RAM installata su un qualsiasi dispositivo Cisco è sufficiente lanciare il comando sh ver:

Router# sh ver

La parte di output che ci interessa è simile alla seguente:

Cisco 2851 (revision 53.51) with 249856K/12288K bytes of memory.

Il primo valore, ovvero 249856K indica la memoria libera, mentre il secondo, ovvero 12288K, indica la memoria utilizzata. Sommando dunque questi due valori otterremo la dimensione totale della RAM installata sul dispositivo (in tal caso 256 MB).

Ora, vogliamo monitorare, mediante SNMP, la RAM in uso e quella libera. Per fare ciò è possibile utilizzare i seguenti OID:

.1.3.6.1.4.1.9.9.48.1.1.1.5.1

(per la memoria attualmente in uso dal processor pool)

.1.3.6.1.4.1.9.9.48.1.1.1.5.1

(per la memoria attualmente in uso dall’I/O pool)

.1.3.6.1.4.1.9.2.1.8.0

(per la memoria libera)

Definiamo ora il comando per monitorare la memoria in uso e la memoria libera attraverso delle query SNMP:

nightfly@nightbox:~$ cd /etc/nagios-plugins/config

nightfly@nightbox:~$ sudo nano snmp.cfg

inseriamo la direttiva:

'snmp_cisco_memory_usage' command definition
 define command {
 command_name    snmp_cisco_memory_usage
 command_line    /usr/lib/nagios/plugins/check_snmp -H '$HOSTADDRESS$' -o '$ARG1$','$ARG2$','$ARG3$' -w '$ARG4$','$ARG5$','$ARG6$' -c '$ARG7$','$ARG8$','$ARG9$' -u "bytes,bytes,bytes" -l "Memory" -C '$ARG10$'
 }

In particolare, la flag -l serve per definire una label, la flag -u indica l’unità di misura a cui si riferisce l’output della query, la flag -w specifica le soglie di warning per la memoria libera ed in uso, la flag -c specifica le soglie di critical per la memoria libera ed in uso.

Non ci resta che aggiungere il servizio per il monitoraggio della RAM all’interno del file in cui è definito l’host Cisco:

nightfly@nightbox:~$ cd /etc/nagios3/conf.d

nightfly@nightbox:~$ sudo nano host-cisco_nagios3.cfg

Inseriamo quanto segue:

 define service {
 use                             generic-service         ; Name of service template to use
 host_name                       Cisco
 service_description             Cisco memory usage check
 check_command                  snmp_cisco_memory_usage!.1.3.6.1.4.1.9.9.48.1.1.1.5.1,
 .1.3.6.1.4.1.9.9.48.1.1.1.5.2,.1.3.6.1.4.1.9.2.1.8.0!140000000,10000000!60000000:!100000000,12000000!20000000:!vostracommunitystring
 }

dove i : dopo la soglia di warning 6000000 e quella di critical 40000000 indicano rispettivamente <60000000 e <40000000 (poichè abbiamo a che fare con la memoria libera).

Riavviamo Nagios:

nightfly@nightbox:~$ sudo service nagio3 restart

ed abbiamo finito.

A presto.