status bacula en zabbix

By: Javier on 9/11/2012

De bacula ya hemos hablado alguna vez en este blog y de zabbix, creo que también, así que ahora estaría bien unir ambos en un mismo post y hacer que los mensajes de estado de los trabajos de bacula vayan a un monitor zabbix, para así saber si el proceso de backup se realizó o no correctamente. Saber que el backup está OK es muy importante y zabbix nos permite sacar alertas de cambios de estado de forma muy simple, por lo que se acabó leer los informes que bacula envía por mail! En los foros de zabbix hay un ejemplo de cómo unir zabbix + bacula, pero la verdad es que no me pareció un poco consufa y complicada de montar, así que me puse a investigar un poco las posibilidades de bacula de enviar informes y cómo poder obtener el estado para enviárselo a zabbix. Tras leer un poco de documentación, simplemente me di cuenta de que era más efectivo emplear la directiva RunScript dentro de Jobs que editar y capturar todo el mensaje. Así que... manos a la obra! Primero comenzamos editando los ficheros de trabajos de cada cliente, ya que el envío del estado del backup lo realizará el propio cliente y no el servidor. Esto tiene sus pros y sus contras. Por el momento he decidido dejarlo así. Un ejemplo de trabajo sería el siguiente,

Job {
  Name = "backup-equipo23"
  JobDefs = "DefaultJob"
  Client = equipo23-fd
  FileSet = "equipo23-fs"
  Write Bootstrap = "/var/lib/bacula/backup-equipo23.bsr"
  RunScript {
    RunsWhen = After
    Command = "/usr/local/bin/bacula %l %e"
    RunsOnClient = yes
    RunsOnFailure = yes
    RunsOnSuccess = yes
  }
  Enabled = yes
}

La única diferencia respecto de lo que ya había, fue agregarle las líneas que están en negrita y que hacen justamente lo que nos interesa, ejecutar un pequeño script que envía el estado del backup según el tipo (Full, Incremental, etc). En la documentación oficial de bacula está descrito, pero el tipo de variables que se le pueden pasar son:

• %c -- Client's name
• %d -- Director's name
• %e -- Job Exit Status
• %i -- JobId
• %j -- Unique Job id
• %l -- Job Level
• %n -- Job name
• %s -- Since time
• %t -- Job type (Backup, ...)
• %v -- Volume name

Y en nuestro caso pasamos un %l, para que nos indique el nivel de trabajo y %e, el estado de finalización del mismo.

Ahora hay que hacer el pequeño script que se ejecutará cuando el trabajo finalice. Éste es,

#!/bin/bash

case "$1" in
 Incremental)
  zabbix_sender -c zabbix_agentd.conf -k bacula.inc.verify.result -o $2
  ;;
 Full)
  zabbix_sender -c zabbix_agentd.conf -k bacula.full.verify.result -o $2
  ;;
 *)
  zabbix_sender -c zabbix_agentd.conf -k bacula.other.verify.result -o $2
  ;;
esac

Ya que como $1 recibimos el tipo de nivel de backup y sólo realizamos backup's Full o Incremental y como $2 recibimos el estado, por lo tanto, es lo que directamente enviamos a zabbix. El estado enviado puede ser OK, Error, Fatal Error, Canceled, Differences o Unknown term code. Aquí podemos optar por pasarlo a número o no, yo prefiero dejarlo como tipo texto, ya que zabbix también permite sacar alertas de campos de tipo texto.

Llegados a este punto ya sólo queda crear una pequeña plantilla de zabbix que permita obtener los datos enviados como Trapper y un trigger que reaccione ante cambios. Los 3 items a los que hace referencia el script tienen estas propiedades:

Nombre descriptivo: Full backup
Tipo: Trapper ZABBIX
Monitor: bacula.full.verify.result
Tipo de información: Texto
Conservar el histórico durante (en días): 60
Estado: Activo
Aplicaciones: bacula

Y por su parte, los triggers asociados,

Nombre: {HOSTNAME} Full backup fail!
Expresión: {Template_bacula:bacula.full.verify.result.regexp(OK)}#1
Gravedad: Alta