Superviser Synology HyperBackup Vault

L’idée est de pouvoir monitorer l’état des tâches de sauvegardes HyperBackup Vault depuis un outil type Centreon/Nagios.

N’ayant pas trouvé mon bonheur dans les MIBs SNMP Synology, j’ai été fouiller dans les logs du serveur synology et on a bien un fichier de logs correspondant à HyperBackup.

/var/log/synolog/synobackup_server.log

Ces logs sont présentés de la façon suivante :

info    2017/09/26 19:48:42     admin:  {"TARGET_UNIQUE_ID":"2","USER":"admin"} [192.168.10.x] Backup started.
info    2017/09/26 19:54:28     admin:  {"TARGET_UNIQUE_ID":"2","USER":"admin"} [192.168.10.x] Backup complete.
info    2017/09/26 22:00:07     admin:  {"TARGET_UNIQUE_ID":"3","USER":"admin"} [192.168.2.x] Backup started.
info    2017/09/26 22:01:24     admin:  {"TARGET_UNIQUE_ID":"3","USER":"admin"} [192.168.2.x] Backup complete.
info    2017/09/27 19:48:41     admin:  {"TARGET_UNIQUE_ID":"2","USER":"admin"} [192.168.10.x] Backup started.
info    2017/09/27 19:54:01     admin:  {"TARGET_UNIQUE_ID":"2","USER":"admin"} [192.168.10.x] Backup complete.

L’idée est donc de pouvoir récupérer le statut d’un backup en filtrant sur l’ip source ainsi que sur la date de la sauvegarde.

Avant tout, il faut que le moteur de supervision dispose d’un accès sans mot de passe en SSH sur le Synology. Pour cela se référer a cet article mais globalement la démarche est la suivante :

  • Activation SSH sur le synology
  • Création d’un utilisateur lambda
  • Connexion SSH en admin sur le synology, puis en root modification de /etc/passwd afin que l’utilisateur accède au shell (/bin/sh à la place de /bin/false)
  • Dans /etc/ssh/sshd_config s’assurer que les options PubkeyAuthentication yes / AuthorizedKeysFile sont bien dé-commentées
  • Echange de clef SSH (ssh-copy-id user@synology) depuis le serveur source

Un autre article qui détaille précisément la procédure.

Ensuite il faut autoriser l’utilisateur que nous avons créé à accéder au logs du synology, par défaut aucun utilisateur n’y à accès. Nous allons donc l’ajouter dans le group log en éditant le fichier /etc/group

log:x:19:root,username

Ensuite pour le script de supervision je me suis tourné vers python, présent par défaut sur synology : (le lien gist):

#!/usr/bin/env python
"""
Nagios plugin to check synology hyperbackup vault server
"""
import re
import sys
import datetime
from datetime import timedelta

LOGFILE = open('/var/log/synolog/synobackup_server.log', 'r')
FILE = LOGFILE.readlines()
LOGFILE.close()

TABLEAU = []
SOURCE = sys.argv[1]
COMPLETE = "Backup complete"
# datetime - nb de jours en param
DELTA = (datetime.datetime.now() - timedelta(days=int(sys.argv[2])))
DATE = (DELTA.strftime("%Y/%m/%d %H:%M:%S"))

# split log lines in sorted array
for line in FILE:
    if re.search(SOURCE, line):
        lines = line.split('\t')
        TABLEAU.append(lines)
TABLEAU.sort(reverse=True)

# if error exit critical
for row in TABLEAU:
    if row[1] > DATE:
        if re.search("err", row[0]):
            print("CRITICAL - %s" % row[1]+' '+row[4])
            sys.exit(2)

# if complete exit success
for row in TABLEAU:
    if row[1] > DATE:
        if re.search(COMPLETE, row[4]):
            print("OK - %s" % row[1]+' '+row[4])
            sys.exit(0)

# if another state exit critical and display last log line
print(TABLEAU[-1])
sys.exit(2)

En gros le fonctionnement est le suivant :

  1. On parse le fichier de log, on le split et on le trie dans un tableau
  2. On cherche dans l’intervalle de date si il y’a une ligne en erreur auquel cas on exit avec le code retour critique
  3. Si pas d’erreur on cherche dans l’intervalle de date le dernier statut pour une IP source donnée qui matche avec le statut « complete »
  4. Si pas de ligne de log dans l’intervalle de temps données on exit en critique et on renvoie la dernière ligne de log

Pour l’utiliser il faut passer en  paramètre l’IP source et le nombre de jour pour définir l’intervalle de date (date du jour – le nombre de jour spécifié)

./check_backup.py 192.168.1.10 2
OK - 2017/09/27 19:54:01 [192.168.10.2] Backup complete.

Pour l’utilisation depuis centreon j’utilise check_by_ssh

$USER4$check_by_ssh -H $ARG1$ -p $ARG2$ -t 60 -l $ARG3$ -C '/volume1/homes/username/check_backup.py $ARG4$ $ARG5$'

 

 

Et voilà 🙂

 

A voir comment ça tourne dans le temps maintenant…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.