Archivi tag: host

MRTG e Nagios: monitoraggio del throughput di rete

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 e gli event handlers

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.