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…

2 commentaires

  1. Bonjour Vincent,
    Je suis intéressé par votre script, j’ai tenté de reproduire votre travail dans centreon, mais je ne parviens pas ramener le status de mon interrogation grace à check_by_ssh.
    Une commande classique comme -C ‘ls -la /var/services/homes/’ me ramène bien les répertoires.
    Mais pas check_backup.py, à priori je n’ai pas l’output en retour de commande.
    Je n’ai pas compris s’il fallait ou pas utiliser le connecteur de centreon, ou si le fait d’avoir échangé les clés RSA suffisait, je pense que oui puisque la commande avec un simple ls -la fonctionne.
    Je suis en Centreon 18.10 mais je pense que ça ne doit pas changer grand chose.
    La réponse à check_backup.py est

    centreon@centreon:/usr/lib/nagios/plugins$ ./check_by_ssh -H asps-slt.fr -p 43210 -l centreon -C ‘/var/services/homes/centreon/scripts_py/check_hyperbackup.py $ARG6$ $ARG7$’
    L’exécution de la commande à distance Traceback (most recent call last): à échoué

    $ARG6$ c’est le job de sauvegarde que je cherche dans le PARSING et $ARG7$ l’intervalle de date ici 0.
    c’est à dire dans le même jour.
    Quand je lance la commande en local ça me retourne bien l’info (je suis en train d’adapter le script)

    centreon@Asps_Synology:~/scripts_py$ ./check_hyperbackup.py ‘Rsync Sylvie’ 0
    [‘info’, ‘2018/10/19 04:00:03’, ‘SYSTEM:’, ‘[Network][Rsync Sylvie Jour] Backup task started.\n’]

    Merci par avance si vous pouvez documenter votre réponse avec des images de Centreon / Service / Commande / (éventuellement connecteur)

  2. Bonjour Vincent,
    SI vous avez réalisé ce scripting c’est que vous avez réussi sans encombre à installer Centreon.
    Je rencontre plein de problème sur l’installation de ce produit en opensource sous CentOS 7.
    Enfin plein, un seul en fait, je bloque sur une étape du setup de la version Centreon 18.10 depuis les dépôts de Centreon.
    J’ai suivi scrupuleusement les documentations, ici
    https://documentation-fr.centreon.com/docs/centreon/en/18.10/installation/from_packages.html
    et j’ai tenté de corriger les erreurs de Partitioning Database Table sur lequel tout le monde semble bloquer.
    la section de MariaDB ici
    https://github.com/centreon/centreon/issues/5088
    Mais rien n’y fait.
    Je travaille en VM sur un Synology et j’ai l’intention de monitorer un parc de Synology pour une grosse association de 3000 adhérents à Savigny le Temple 77.
    Voilà, j’espère que vous aurez réussi l’installation du produit (open source) et que vous aurez trouvé la solution qui me permettra de débloquer mon problème.
    Je dispose d’une :
    – VM (Fresh install ) CentOS 7 avant Installation de Centreon et parfaitement propre (à cloner éventuellement.
    – d’une autre VM (Full install) CentOS 7 + Centreon avant setup et avec les correctif MariaDB.

    Je peux donc repartir avant le setup.

    Merci par avance.
    Dominique MACHURE

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.