Surveiller un NAS Synology : espace des volumes, santé SMART des disques, état du RAID, températures, sauvegardes et notifications. Par SNMP, par agent ou via DSM.
Un NAS occupe une position inconfortable dans un parc : il contient souvent les données les plus critiques de l'entreprise, et il est fréquemment le dernier équipement à être supervisé. Beaucoup de structures découvrent qu'un disque était en panne le jour où le second lâche.
Or c'est précisément le type d'équipement où la supervision est la plus rentable : une défaillance de disque en RAID ne provoque aucune interruption visible. Rien ne signale le problème à l'utilisateur, et le NAS continue de fonctionner — sans redondance, en attendant la panne suivante.
C'est la métrique la plus importante, et celle qui justifie à elle seule la supervision d'un NAS.
Les disques ne tombent pas brutalement : ils accumulent des secteurs réalloués, des erreurs de lecture et des délais d'accès anormaux pendant des semaines. Les attributs SMART exposent ces signaux bien avant la défaillance.
Attributs à surveiller en priorité :
Reallocated_Sector_Ct) : toute valeur non nulle qui augmente est un signal de fin de vieCurrent_Pending_Sector) : secteurs illisibles en attente de réallocationOffline_Uncorrectable)Un disque avec quelques secteurs réalloués stables depuis des mois peut vivre longtemps. Un disque dont le compteur augmente de semaine en semaine doit être remplacé avant qu'il ne lâche.
Les autres services
Comment surveiller l'espace disque d'un serveur Windows ou Linux : quels seuils choisir, pourquoi la tendance compte plus que le pourcentage, et comment éviter la saturation avant l'incident.
Les métriques indispensables à surveiller sur un serveur Windows ou Linux : disque, mémoire, processeur, services, réseau. Seuils recommandés, pièges de lecture et ordre de priorité.
Ce que la supervision d'un serveur Linux détecte avant l'incident : saturation disque, fuite mémoire, processus zombie, échec de sauvegarde, certificat expiré. Avec les commandes de diagnostic.
La question à laquelle il faut pouvoir répondre à tout moment : le volume est-il dégradé ?
Un RAID 1 ou 5 avec un disque en panne fonctionne normalement pour les utilisateurs. Il n'a simplement plus aucune tolérance de panne. Si le second disque lâche pendant la reconstruction — période où les disques restants sont fortement sollicités — les données sont perdues.
Surveillez l'état du volume et, le cas échéant, la progression de la reconstruction. C'est le signal qui doit déclencher une intervention immédiate, pas une notification qui attend le lundi.
Un NAS plein bloque les sauvegardes qui y sont dirigées, souvent silencieusement. La conséquence est double : le partage ne fonctionne plus, et le mécanisme de sauvegarde qui devait vous protéger a cessé de fonctionner.
Surveillez chaque volume séparément, avec les seuils habituels. Attention aux instantanés : sur un volume Btrfs avec instantanés activés, l'espace consommé peut croître sans qu'aucun fichier ne soit ajouté.
Si le NAS est la destination de vos sauvegardes, son bon fonctionnement conditionne toute votre stratégie de restauration. Si le NAS est la source à sauvegarder, vérifiez que sa propre réplication fonctionne.
Un NAS sauvegardé nulle part n'est pas une sauvegarde : c'est une copie unique sur un équipement qui peut brûler, être volé ou chiffré par un rançongiciel.
Un ventilateur arrêté provoque une montée en température qui réduit la durée de vie de tous les disques simultanément. C'est une panne matérielle qui, non détectée, transforme un incident sur un disque en défaillance groupée.
Trois approches, par ordre de simplicité.
DSM intègre un agent SNMP qui expose l'essentiel : état des disques, état des volumes RAID, températures, espace disponible, état des ventilateurs et de l'alimentation.
Activation dans DSM : Panneau de configuration → Terminal & SNMP → SNMP. Activez SNMPv3 plutôt que v1/v2c — ces derniers transmettent la chaîne de communauté en clair.
Synology publie ses MIB, et les identifiants d'objet correspondants sont documentés publiquement. Côté supervision, un modèle SNMP générique permet d'interroger ces valeurs sans installer quoi que ce soit sur le NAS.
SNMP est ici la voie la plus propre : elle ne demande aucune installation sur l'équipement, ce qui évite les problèmes de compatibilité lors des mises à jour de DSM.
DSM repose sur Linux, et l'installation d'un agent Zabbix est techniquement envisageable sur certains modèles via les paquets de la communauté ou Docker. Cette voie est cependant moins fiable en pratique : les mises à jour de DSM peuvent désactiver les paquets tiers, et le support officiel est inexistant.
Sur un NAS de production, SNMP reste préférable.
DSM sait envoyer des courriels sur les événements importants : disque défaillant, volume dégradé, température anormale. C'est un filet de sécurité utile, mais insuffisant comme supervision unique — il ne fournit ni historique, ni tendance, ni vision d'ensemble avec le reste du parc.
Activez-les de toute façon : deux mécanismes indépendants valent mieux qu'un, surtout sur un équipement qui porte vos données.
La supervision par SNMP d'équipements réseau et NAS n'est pas couverte par les templates fournis, qui portent sur les serveurs Windows, Linux et macOS équipés d'un agent.
Un NAS peut néanmoins être intégré à une supervision Zabbix via les modèles SNMP standards, ce qui relève d'une configuration spécifique à votre parc.
Quelle que soit la solution retenue, ne comptez pas uniquement sur les notifications intégrées du NAS. Un équipement qui tombe complètement n'envoie plus aucun courriel — c'est précisément la situation où vous voudriez être prévenu. Une supervision externe détecte l'absence de réponse, ce que l'équipement lui-même ne peut pas signaler.
Logiserv supervise votre parc à partir de cet article : essai gratuit sans carte bancaire.