User Tools

Site Tools


doc:appunti:linux:sa:nagios_passivo

Check passivo con Nagios3 e Bacula

Vedere questa pagina per riferimento: Monitoring Bacula with Nagios.

Si scelie l'opzione check passivo, cioè il server Nagios resta in attesa che l'host Bacula lo avverta al termine dell'operazione di backup. Normalmente accade il viceversa: il server Nagios interroga l'host per sapere lo stato del servizio.

Per questo occorre installare NSCA (Nagios Service Check Acceptor), che funziona in architettura client-server, sulla porta TCP 5667.

L'installazione è stata fatta con Nagios 3.2.0 su Debian Squeeze e Bacula 5.0.1 con NSCA 2.6 su Suse SLES 10.

Configurazione del server (Nagios)

In Debian Squeeze troviamo il singolo pacchetto nsca, che contiene il client send_nsca e il server nsca. In Debian Wheezy invece si hanno i due pacchetti nsca e nsca-client, openSUSE fornisce nagios-nsca-client e nagios-nsca.

La comunicazione tra client e server avviene in chiaro e senza password, se si vuole qualcosa di meglio editare il file /etc/nsca.cfg sul server e /etc/send_nsca.cfg sul client. Purtroppo l'eventuale password deve essere condivisa tra tutti i client.

Anzitutto si definisce un template per i servizi passivi, creando un file /etc/nagios3/conf.d/passive-service.cfg:

# Passive service definition template
define service{
    name            passive-service     ; The 'name' of this service template,
                                        ; referenced in other service definitions
    active_checks_enabled         0     ; Active service checks are disabled
    passive_checks_enabled        1     ; Passive service checks are enabled/accepted
    parallelize_check             1     ; Active service checks should be parallelized
                                        ; (disabling this can lead to major performance problems)
    obsess_over_service           1     ; We should obsess over this service (if necessary)
    check_freshness               1     ; Default is to NOT check service 'freshness'
    freshness_threshold           4800  ; Threshold for fresh/stale data (seconds)
    notifications_enabled         1     ; Service notifications are enabled
    event_handler_enabled         1     ; Service event handler is enabled
    flap_detection_enabled        1     ; Flap detection 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
    notification_interval         0     ; Only send notifications on status change by default.
    is_volatile                   0
    check_period                  24x7
    normal_check_interval         5
    retry_check_interval          1
    max_check_attempts            4
    notification_period           24x7
    notification_options          w,u,c,r
    contact_groups                admins
    register                      0     ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE,
                                        ; JUST A TEMPLATE!
}

Quindi si definisce un più specifico bacula-service basato sul template precedente. Lo possiamo aggiungere al file /etc/nagios3/conf.d/services_nagios2.cfg:

# Template service (not registered) for Bacula backups.
# Bacula checks are received as passive checks (see the
# passive_service definition), so this check is only run
# if no passive checks are received past freshness_threshold.
# In that case a status 2 (CRITICAL) is assumed.
define service {
        name                            bacula-service
        use                             passive-service
        freshness_threshold             93600   ; 26 hours
        max_check_attempts              1
        check_command                   return-critical
        notification_interval           1440
        register                        0
}

Due parametri i fondamentali da configurare. Il primo è freshness_threshold: aspettiamo fino a 26 ore di ricevere un check passivo, altrimenti si esegue un check attivo che ritorna uno stato CRITICAL. Il secondo parametro importante è max_check_attempts da impostarsi ad un valore molto basso, possibilmente 1; in questo modo lo status type diviene HARD al primo check fallito. Se si lasciasse il valore predefinito di max_check_attempts pari a 4 si avrebbe che per 26 * 4 = 104 ore il servizio risulta SOFT CRITICAL, e quindi mostrato in verde nel grafico del trend.

Poi si aggiunge un finto host, che serve solo per raggruppare tutti i backup monitorati. Si può creare il file /etc/nagios3/conf.d/bacula_backups.cfg:

# Dummy host configuration.
# Bacula backups are reported as passive checks (initiated by
# the Bacula director), so we really do not check anything here.
# The check command will therefore always return OK.
define host {
        host_name                       Bacula_backups
        address                         127.0.0.1
        use                             generic-host
        check_command                   return-ok
        notification_interval           86400
        notification_period             24x7
        notification_options            d,u,r
        contact_groups                  admins
}

Infine, per ogni job Bacula, si aggiunge un effettivo servizio, ad esempio nel file /etc/nagios3/conf.d/services_nagios2.cfg:

# We need a backup service for each Bacula job.
# The host is just dummy, used to group the backup jobs.
define service {
        service_description             FileserverHome
        use                             bacula-service
        host_name                       Bacula_backups
}

Quando Nagios è in esecuzione riceve le notifiche da nsca sulla pipe /var/lib/nagios3/rw/nagios.cmd, ma questa esiste solo se sono attivi gli external commands. Per questo verificare che in /etc/nagios3/nagios.cfg ci siano almeno queste impostazioni:

check_external_commands=1
command_check_interval=10

Se la pipe non esiste i comandi vengono accodati al file /var/run/nagios/nsca.dump e processati in seguito (Davvero? Non pare proprio! Come dovrebbe funzionare?).

Problema di versione

Attenzione alla versione del client e del server nsca! Debian Squeeze (nsca 2.7.2) e Debian Wheezy (nsca 2.9.1) non sono compatibili, ma il messaggio di errore del server non è chiaro, con la crittografia attiva l'errore è:

Dropping packet with invalid CRC32 - possibly due to client using wrong password or crypto algorithm?

più comprensibile se la crittografia è disabilitata:

Received invalid packet type/version from client - possibly due to client using wrong password or crypto algorithm?

Per fortuna si trova il backport del pacchetto per Debian Squeeze.

Configurazione del client (Bacula)

Installare il cient che consiste essenzialmente nel programma send_nsca. In GNU/Linux Suse SLES 10 troviamo il pacchetto nagios-nsca-client.

Predisporre uno script del tipo (ATTENZIONE il separatore per il file da dare in input a send_nsca è il TAB):

#!/bin/sh
# Inform nagios about the success (or lack thereof) of the most recent
# attempt of each backup job
#
# args:
# $1: job name
# $2: status (0 for success, anything else for failure)
# $3: whatever you want to appear as the plugin output
 
if [ "$2" -eq "0" ]
then
    status=0
else
    status=2
fi
 
send_nsca -H 172.16.237.211 -c /etc/send_nsca.cfg <<END
Bacula_backups    $1    $status    $3
END

Aggiungere queste due righe alla definizione del job di backup, nel file /etc/bacula/bacula-dir.conf:

  Run After Job = "/usr/local/sbin/bacula2nagios \"%n\" 0 \"%e %l %v\""
  Run After Failed Job = "/usr/local/sbin/bacula2nagios \"%n\" 1 \"%e %l %v\""

Dove i vari token significano:

%n Job Name
%e Job Exit Status
%l Job Level
%v Volume Name

Per simulare la notifica di un avvenuto backup al server nsca/nagios:

/usr/local/sbin/bacula2nagios FileServer 0 "OK Incremental p00v1"
doc/appunti/linux/sa/nagios_passivo.txt · Last modified: 2014/01/31 16:39 by niccolo