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.

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?).

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.

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:

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

/usr/local/sbin/bacula2nagios FileServer 0 "OK Incremental p00v1"