Un array RAID peut sembler sain alors que l’un de ses disques se détériore discrètement. Il peut également devenir dégradé alors que les disques restants indiquent toujours SMART PASSED.
Une bonne surveillance nécessite donc plus qu’un simple voyant d’état vert. La meilleure configuration pour un serveur domestique surveille l’array, les disques physiques, les reconstructions ou scrubs, ainsi que les alertes qui signalent un changement.
La surveillance RAID ne se limite pas au SMART
L’état du RAID et celui des disques répondent à des questions différentes.
Un outil de surveillance de l’array indique si le système de stockage possède toujours les membres attendus, si la redondance a été perdue et si une reconstruction, une resynchronisation, un scrub ou une opération de cohérence est en cours.
La surveillance SMART examine sous cet array les disques durs, SSD et disques NVMe individuels. Elle peut révéler la température, les erreurs de support, les secteurs en attente, les secteurs réalloués, l’endurance, les résultats des autotests et d’autres signaux au niveau du périphérique.
Surveillance RAID
|
+-- État de l’array
| Sain / Dégradé / Hors ligne
|
+-- État du disque
| SMART / NVMe / Température
|
+-- Récupération
| Reconstruction / Resynchronisation / Scrub
|
+-- Historique
| Tendances / Erreurs / Capacité
|
+-- Alertes
E-mail / Notifications push / Webhook / Chat
Cette distinction est importante, car un array sain peut contenir un disque en cours de détérioration, tandis qu’un array dégradé peut encore contenir plusieurs disques individuels dont l’état SMART reste normal.
Le modèle RAID sous-jacent est expliqué plus en détail dans le fonctionnement du RAID, mais la surveillance commence par une règle plus simple : surveillez à la fois l’array et les disques qui le composent.
Que doit réellement surveiller un outil de surveillance RAID ?
Un outil de surveillance utile pour un serveur domestique doit couvrir autant de ces couches que son rôle l’exige :
| Couche | Signaux importants | Pourquoi c’est important |
|---|---|---|
| État de l’array | Sain, dégradé, hors ligne, membre manquant | Indique si la redondance existe toujours |
| Disques physiques | SMART, température, état des SSD NVMe, usure | Peut révéler la détérioration d’un disque avant la défaillance de l’array |
| Récupération | Reconstruction, resynchronisation, resilver, scrub, vérification de cohérence | Indique si la redondance est en cours de restauration ou de vérification |
| Erreurs | Erreurs d’E/S, erreurs de somme de contrôle, secteurs irrécupérables | Fournit des preuves que la fiabilité du stockage évolue |
| Capacité | Utilisation des pools, systèmes de fichiers et disques | Empêche le manque d’espace de provoquer une panne |
| Historique | Température, attributs SMART, tendances des erreurs | Montre une détérioration progressive plutôt qu’un seul instantané |
| Alertes | E-mail, webhook, notifications push, chat, escalade | Un tableau de bord ne sert à rien si personne ne l’ouvre après une panne |
Comment nous avons classé les meilleurs outils de surveillance RAID
Il ne s’agit pas de classer les plus beaux tableaux de bord. Les outils ci-dessous répondent à différentes fonctions de la pile de surveillance.
Nous les avons évalués autour de cinq questions pratiques :
- Que peut-il réellement surveiller ? L’état de l’array, les disques individuels, les pools ZFS, le RAID matériel ou l’ensemble du serveur ?
- Conserve-t-il l’historique ? Une hausse progressive du nombre d’erreurs est souvent plus utile qu’une seule valeur actuelle.
- Peut-il envoyer des alertes sans vérification manuelle ? La surveillance doit signaler les problèmes de manière proactive.
- Est-il difficile à déployer ? Un seul NAS domestique ne devrait pas nécessiter une infrastructure d’observabilité d’entreprise, sauf si l’utilisateur le souhaite.
- Complète-t-il les outils RAID natifs ? Les configurations les plus performantes combinent généralement un outil de surveillance spécifique à l’array avec une couche de contrôle de l’état des disques.
L’ordre numérique est éditorial et ne constitue pas un score issu d’un benchmark synthétique.
Les 10 meilleurs outils de surveillance RAID pour les serveurs domestiques en un coup d’œil
| Classement | Outil | Idéal pour | État de l’array | État des disques | Historique | Difficulté |
|---|---|---|---|---|---|---|
| 1 | Netdata | Un tableau de bord pour un serveur domestique | Oui | Oui | Oui | Faible à moyenne |
| 2 | Scrutiny | Tendances de l’état SMART | Non | Excellent | Excellent | Faible |
| 3 | smartmontools | Surveillance fondamentale des disques | Non | Excellent | Limité sans couche supplémentaire | Faible |
| 4 | Moniteur mdadm | RAID logiciel Linux | Excellent | Non | Orienté événements | Faible |
| 5 | OpenZFS ZED | Événements des pools ZFS | Excellent pour ZFS | Indirect | Orienté événements | Faible à moyenne |
| 6 | Stockage Cockpit | Interface graphique Linux conviviale pour les débutants | Oui | Oui | Limitée | Faible |
| 7 | Prometheus + Grafana | Métriques personnalisées à long terme | Avec des exportateurs | Excellent | Excellent | Élevée |
| 8 | Checkmk | Plusieurs serveurs domestiques | Avec des vérifications/plug-ins | Oui | Oui | Moyenne |
| 9 | StorCLI | RAID matériel LSI/Broadcom | Excellent | Excellent pour les disques des contrôleurs | Orienté ligne de commande | Moyenne |
| 10 | Zabbix | Alertes personnalisées avancées | Avec des modèles/scripts | Oui | Excellent | Élevée |
1. Netdata — Meilleur tableau de bord global pour la surveillance RAID
Netdata est le meilleur choix global lorsque vous souhaitez une seule couche de surveillance pour le système de stockage et le reste du serveur domestique.
Ses collecteurs de stockage actuels couvrent plusieurs architectures pertinentes pour les utilisateurs de RAID.
Pour les RAID logiciels Linux, le collecteur RAID MD lit /proc/mdstat et suit les périphériques MD. Pour les disques physiques, Netdata dispose d’un collecteur SMART basé sur smartctl. Son collecteur de pools ZFS surveille l’état et l’espace des pools via zpool, tandis que son collecteur RAID StoreCLI peut surveiller les adaptateurs RAID matériels pris en charge, les disques physiques et les batteries de secours.
Cette couverture donne à Netdata un avantage sur les tableaux de bord SMART plus spécialisés.
RAID MD
SMART
ZFS
RAID matériel
Systèmes de fichiers
CPU
RAM
Réseau
Conteneurs
|
Netdata
|
Un tableau de bord
Un seul agent Netdata peut fonctionner de manière autonome et exposer son tableau de bord local sur le port 19999. La connectivité au cloud est facultative pour l’agent de surveillance lui-même, bien que Netdata Cloud ajoute des vues centralisées et des fonctionnalités supplémentaires pour la gestion de plusieurs nœuds.
Cela rend Netdata particulièrement utile sur un serveur domestique, où la surveillance du stockage peut côtoyer celle de la charge du système, de la pression exercée sur la RAM, de la capacité du système de fichiers, de l’activité Docker et des performances réseau.
Idéal pour : les utilisateurs qui souhaitent un tableau de bord unique couvrant le RAID et le reste du serveur.
Compromis : Netdata offre une vue étendue plutôt qu’une surveillance exclusivement axée sur les disques. Scrutiny fournit une vue plus claire lorsque l’objectif est d’étudier les attributs SMART et la détérioration à long terme des disques physiques.
2. Scrutiny — le meilleur outil pour repérer les tendances de l’état des disques

Scrutiny est l’un des ajouts les plus utiles à un NAS domestique, car il corrige plusieurs faiblesses de la surveillance SMART brute.
SMART expose un grand nombre d’attributs, mais tous ne sont pas aussi utiles les uns que les autres. Les seuils définis par les fabricants peuvent également être suffisamment prudents pour qu’un disque paraisse « sain » jusqu’à ce que la défaillance soit relativement proche.
Scrutiny combine les données SMART avec une interface web, le stockage de l’historique des tendances, le suivi de la température et des seuils supplémentaires fondés sur des données réelles de défaillance des disques.
Cela permet de poser des questions telles que :
Secteurs actuellement en attente
Janvier 0
Mars 0
Juin 2
Août 8
Un seul rapport SMART actuel vous indique que la valeur est de huit. Scrutiny vous indique que la métrique évolue dans la mauvaise direction.
Il prend également en charge les notifications configurables par e-mail, via des webhooks, ntfy, Gotify, Slack, Discord, Telegram et d’autres services.
La prise en charge des contrôleurs RAID dépend de la possibilité smartctl peut accéder aux disques physiques sous-jacents. Scrutiny documente le passthrough du contrôleur et la configuration du mappage des périphériques Docker pour cette raison.
La principale limitation est tout aussi claire :
Scrutiny surveille les disques, pas la matrice RAID elle-même.
Une matrice Linux MD doit tout de même être surveillée avec mdadm ou une autre couche prenant en compte les matrices. Un pool ZFS doit toujours disposer d’une surveillance spécifique à ZFS.
Idéal pour : les serveurs domestiques équipés de plusieurs disques durs ou SSD, lorsque l’historique SMART et les tendances de température sont importants.
Compromis : ne prenez pas une rangée de disques sains dans Scrutiny pour preuve que la matrice RAID est saine.
La couche de surveillance de l’état des disques dépend également des disques eux-mêmes. Le choix de disques NAS adaptés réduit les problèmes évitables lors des reconstructions et des charges de travail continues 24 h/24 et 7 j/7.
3. smartmontools — la meilleure base pour surveiller les disques durs, SSD et NVMe
smartmontools est bien moins impressionnant visuellement que Scrutiny, mais il est plus fondamental.
Le projet fournit deux outils principaux :
smartctl
|
Inspecter et tester un disque
smartd
|
Surveiller les disques en continu
smartctl peut inspecter les informations SMART et d’état des périphériques ATA/SATA, SCSI/SAS et NVMe, et déclencher des autotests de disque. smartd fonctionne comme un démon et vérifie en continu les périphériques pour détecter les conditions d’état configurées.
De nombreux produits de surveillance de niveau supérieur dépendent en fin de compte de ces données. Le collecteur SMART de Netdata nécessite smartmontools, Scrutiny construit sa couche d’état des disques autour des données de smartctl, et les exportateurs smartctl de Prometheus utilisent la même interface.
Le projet continue également d’évoluer. Le journal des modifications amont actuel indique que smartmontools 8.0 sera la prochaine version, encore non publiée, après la 7.5.
Pour un serveur domestique léger, smartd peut être tout ce dont vous avez besoin :
Disque
|
SMART
|
smartd
|
Alerte
Vous n’avez pas nécessairement besoin d’une base de données, d’un tableau de bord et d’une pile de métriques distincts pour savoir qu’un disque a dépassé un seuil important.
Idéal pour : les utilisateurs qui souhaitent une base légère et éprouvée pour l’état des disques physiques et les tests automatisés.
Compromis : la sortie en ligne de commande est moins accessible que Scrutiny ou Cockpit, et smartd ne fournit pas à lui seul la même analyse visuelle historique.
4. Moniteur mdadm — Le meilleur moniteur natif pour le RAID logiciel Linux
Si le tableau est un RAID MD Linux, mdadm doit rester intégré au plan de surveillance, même si Netdata ou un autre tableau de bord est installé.
mdadm --monitor comprend le tableau lui-même.
Il peut signaler des événements tels que :
- défaillance d’un périphérique ;
- tableaux dégradés ;
- activation d’un disque de secours ;
- disparition d’un périphérique ;
- début de la reconstruction ;
- progression de la reconstruction ;
- fin de la reconstruction.
Cela comble la lacune laissée par SMART :
smartd
|
Les disques sont-ils en bon état ?
mdadm --monitor
|
Le tableau RAID est-il sain ?
Pour un serveur domestique Linux minimal, combiner la surveillance de mdadm avec smartd crée un système de surveillance étonnamment performant sans ajouter une pile Web volumineuse.
Idéal pour : Debian, Ubuntu et les autres serveurs Linux reposant sur le RAID MD 1, 5, 6 ou 10.
Compromis : mdadm se concentre sur le RAID logiciel Linux plutôt que sur ZFS, le RAID matériel ou l’analyse graphique à long terme.
5. OpenZFS ZED — La meilleure surveillance native des événements pour les pools ZFS
Les utilisateurs de ZFS devraient superviser ZFS en tant que tel plutôt que d’essayer de faire correspondre chaque événement à la terminologie RAID traditionnelle.
ZED, le démon d’événements ZFS, surveille les événements générés par le module du noyau ZFS et exécute les actions ZEDLET configurées lorsque des classes d’événements correspondantes apparaissent.
La relation de supervision devient :
Noyau ZFS
|
zevents
|
ZED
|
Actions ZEDLET
|
Notifications / automatisation
ZED est ainsi adapté aux événements de pool et de périphérique propres à ZFS, plutôt qu’à un tableau de bord externe dédié aux disques.
Une pile ZFS complète pour serveur domestique peut donc inclure :
ZED
|
Événements des pools
smartd / Scrutiny
|
État des disques physiques
Netdata / Grafana
|
Tableau de bord et historique
Idéal pour : les utilisateurs de TrueNAS, OpenZFS ou ZFS sous Linux/BSD qui souhaitent une gestion native des événements liés à leurs pools.
Compromis : ZED est un démon d’événements, pas un tableau de bord tout-en-un sophistiqué. Associez-le à une autre couche si la visualisation à long terme est importante.
6. Cockpit Storage — Meilleure interface graphique de supervision du RAID pour les débutants sous Linux

Cockpit est l’un des moyens les plus simples d’ajouter une interface d’administration accessible depuis un navigateur à un serveur Linux standard.
Son application Stockage prend en charge les disques locaux, les partitions, le RAID, le chiffrement, NFS, iSCSI et d’autres opérations de stockage courantes.
Cockpit a également ajouté des informations sur l’état SMART des périphériques à la page Stockage, notamment la possibilité d’exécuter des autotests de disque depuis le navigateur.
Cela en fait une excellente option pour débutants pour un serveur qui ressemble autrement à ceci :
Ubuntu / Debian / Fedora
|
Cockpit
|
Interface de stockage dans le navigateur
|
RAID + SMART + points de montage
Il est particulièrement utile lorsque l’utilisateur souhaite gérer le stockage plutôt que créer une pile d’observabilité dédiée.
Idéal pour : les débutants sous Linux qui veulent afficher l’état du RAID et des disques dans une interface claire de gestion de serveur.
Compromis : Cockpit est plus efficace pour afficher et gérer l’état actuel du serveur que pour conserver plusieurs mois d’historique SMART détaillé.
7. Prometheus + smartctl_exporter + Grafana — Idéal pour les métriques à long terme
Lorsque la supervision devient un loisir à part entière, la pile Prometheus offre bien plus de contrôle qu’un tableau de bord NAS spécialisé.
L’officiel smartctl_exporter convertit les statistiques de smartctl en métriques Prometheus. Il nécessite smartmontools 7.0 ou version ultérieure, car il dépend de la sortie JSON de smartctl.
L’architecture est modulaire :
Exportateurs SMART / RAID / ZFS
|
Prometheus
|
Grafana
|
Tableaux de bord + alertes
Des exporters supplémentaires ou des métriques de nœud peuvent ajouter :
- capacité du système de fichiers ;
- E/S disque ;
- pools ZFS ;
- état du RAID logiciel MD ;
- température ;
- charge du serveur ;
- métriques de l’onduleur ;
- activité réseau.
C’est la meilleure option lorsque vous souhaitez répondre à des questions historiques plutôt que simplement vérifier l’état actuel.
Par exemple :
- La température du disque a-t-elle augmenté pendant la dernière reconstruction RAID ?
- Quand les erreurs irrécupérables sont-elles apparues pour la première fois ?
- La latence du stockage a-t-elle changé après l’ajout d’un autre disque ?
- À quelle vitesse l’utilisation du pool a-t-elle augmenté au cours de l’année dernière ?
Les alertes Grafana peuvent également évaluer les règles basées sur Prometheus et acheminer les notifications lorsque les conditions sont réunies.
Idéal pour : les passionnés qui souhaitent disposer de métriques à long terme, de tableaux de bord personnalisés, de corrélations et d’alertes flexibles.
Compromis : Prometheus + exporters + Grafana nécessite nettement plus de configuration que Scrutiny ou Netdata. Pour un NAS domestique simple, cette complexité peut apporter peu d’avantages pratiques.
8. Checkmk — Idéal pour surveiller plusieurs serveurs domestiques
Checkmk devient plus intéressant lorsque le homelab contient plusieurs machines.
Au lieu de penser uniquement à un NAS, vous pouvez avoir :
NAS
Serveur de sauvegarde
Hôte Proxmox
Mini-PC
Routeur
Onduleur
Commutateur
|
Checkmk
L’agent Linux de Checkmk prend en charge la surveillance matérielle via des plug-ins, notamment les valeurs SMART des disques durs et SSD modernes.
Sa documentation prend également explicitement en charge les disques masqués derrière des contrôleurs RAID compatibles. Selon le contrôleur, des outils tels que smartmontools, tw_cli, ou les utilitaires MegaRAID peuvent être nécessaires avant que Checkmk puisse accéder aux informations des périphériques sous-jacents.
L’avantage principal réside dans la gestion centralisée : plusieurs hôtes, états des services, règles d’alerte, graphiques, inventaire, capacité et surveillance du système peuvent tous être regroupés dans une seule interface.
Idéal pour : les homelabs où l’état du stockage doit être surveillé aux côtés de plusieurs serveurs Linux et appareils d’infrastructure.
Compromis : Checkmk constitue une surcharge inutile pour un NAS unique si Netdata ou la surveillance native du système d’exploitation couvre déjà les signaux de panne importants.
9. StorCLI — Idéal pour le RAID matériel LSI et Broadcom
Le RAID matériel nécessite une approche différente de la surveillance, car le système d’exploitation peut ne voir qu’un seul disque virtuel, tandis que le contrôleur gère plusieurs disques physiques en dessous.
Système d’exploitation
|
Disque virtuel
|
Contrôleur RAID
|
+-----+-----+-----+
Disque 1 Disque 2 Disque 3
StorCLI est l’utilitaire de gestion en ligne de commande de Broadcom pour les contrôleurs RAID LSI/Broadcom pris en charge.
Il peut inspecter l’état du contrôleur, les disques virtuels, les disques physiques, les opérations de reconstruction, les informations sur le boîtier, le cache ainsi que les composants de batterie ou de secours pris en charge.
L’état d’un RAID matériel peut inclure des états tels que :
- Optimal ;
- Partiellement dégradé ;
- Dégradé ;
- Hors ligne.
Cette visibilité au niveau du contrôleur est essentielle, car les outils SMART génériques peuvent ne pas détecter automatiquement les disques membres via tous les contrôleurs RAID.
Une combinaison de surveillance utile est la suivante :
RAID Broadcom / LSI
|
StorCLI
|
Netdata
|
Tableau de bord + alertes
Le collecteur StoreCLI de Netdata peut utiliser les informations du contrôleur et les afficher à côté des autres métriques du serveur.
Idéal pour : les serveurs domestiques équipés de contrôleurs matériels Broadcom, LSI ou MegaRAID pris en charge.
Compromis : StorCLI est un outil d’administration propre aux contrôleurs, et non un tableau de bord universel pour serveur domestique.
10. Zabbix — Idéal pour les alertes RAID avancées et l’automatisation
Zabbix est l’option la plus orientée infrastructure de cette liste.
Ses modèles actuels pour Agent 2 incluent une surveillance SMART officielle, tandis que l’état des ensembles et des contrôleurs peut être ajouté au moyen d’intégrations prises en charge, d’éléments personnalisés, de scripts ou de modèles adaptés à l’environnement.
Un déploiement Zabbix plus vaste peut combiner :
SMART
RAID
ZFS
Système de fichiers
Onduleur
Température
Réseau
Services
|
Zabbix
|
Historique
Déclencheurs
Notifications
Escalade
La force de cet outil ne réside pas dans un écran RAID conçu spécifiquement à cet effet, mais dans la possibilité de définir précisément ce qui constitue une panne et ce qui doit se produire ensuite.
Par exemple, un avertissement pourrait être envoyé vers un canal de notification standard, tandis qu’un ensemble dégradé ou un disque virtuel hors ligne déclencherait une escalade plus urgente.
Idéal pour : les utilisateurs avancés qui exécutent déjà Zabbix ou qui souhaitent des règles détaillées d’alerte et d’automatisation pour plusieurs systèmes.
Compromis : la configuration est complexe. Installer Zabbix uniquement pour surveiller deux disques dans un seul NAS domestique est généralement inutile.
Quel outil de surveillance RAID devriez-vous réellement utiliser ?
| Si vous voulez… | Commencer par | Pourquoi |
|---|---|---|
| Un seul tableau de bord pour un serveur domestique | Netdata | Prend en charge le RAID logiciel MD, SMART, ZFS, le RAID matériel et les métriques système |
| Historique détaillé de l’état des disques | Scrutiny | Suivi ciblé des tendances SMART, de la température, des seuils et des notifications |
| Surveillance légère des disques | smartmontools | Outils en ligne de commande matures sans pile de supervision volumineuse |
| Événements du RAID logiciel Linux | Moniteur mdadm | Comprend les défaillances, reconstructions et états dégradés des matrices MD |
| Événements des pools ZFS | OpenZFS ZED | Démon d’événements natif pour ZFS |
| Une interface graphique Linux simple pour le stockage | Cockpit | Gestion du RAID et état SMART dans le navigateur |
| Tableaux de bord personnalisés à long terme | Prometheus + Grafana | Métriques, historique, corrélation et alertes flexibles |
| Plusieurs serveurs domestiques | Checkmk | Centralise la supervision de l’hôte, des services, des disques et de l’infrastructure |
| RAID matériel LSI/Broadcom | StorCLI | Lit directement l’état du contrôleur, des disques virtuels et des disques physiques |
| Automatisation complexe des alertes | Zabbix | Déclencheurs, modèles, historique et escalade flexibles |
État du RAID et état SMART : ce n’est pas la même chose
Cette distinction est plus importante que le choix entre la plupart des outils du classement.
| Signal | Ce que cela vous indique | Ce que cela ne vous indique pas |
|---|---|---|
| RAID sain | La matrice dispose actuellement des membres requis | Chaque disque restera en bonne santé |
| RAID dégradé | La redondance ou l’appartenance attendue a été perdue | La cause physique exacte dans tous les cas |
| SMART RÉUSSI | Le disque n’a pas atteint son état de défaillance SMART | Que chaque attribut soit idéal |
| Secteurs en attente | Les secteurs attendent une relecture ou une réaffectation réussie | L’état de santé complet de la matrice RAID |
| Secteurs réaffectés | Le disque a réaffecté des secteurs inutilisables | Si la matrice dispose toujours de sa redondance |
| Température | Conditions thermiques actuelles ou historiques | Si le système de fichiers est cohérent |
| Progression de la reconstruction | La progression de la restauration de la redondance | Si les anciennes sauvegardes sont récupérables |
| Erreurs de somme de contrôle ZFS | ZFS a détecté des problèmes d’intégrité | Chaque mode de défaillance mécanique sous-jacent |
Un exemple utile est le suivant :
mdadm :
Matrice saine
Scrutiny :
Disque 3
Secteur actuellement en attente = 0 → 2 → 8
La matrice n’est pas encore en panne, mais l’historique du disque physique vous donne une raison d’enquêter.
L’inverse peut également se produire :
mdadm :
Matrice dégradée
smartctl :
Disque 1 RÉUSSI
Disque 2 RÉUSSI
Disque 3 RÉUSSI
Le membre manquant peut avoir disparu en raison d’un problème de câblage, d’alimentation, de contrôleur, d’énumération du périphérique ou d’une autre panne non signalée par un seuil de défaillance SMART.
Supervision de mdadm, de ZFS et des RAID matériels
L’outil de supervision approprié dépend en partie de l’emplacement de la logique RAID.
| Architecture de stockage | Supervision native | Couche secondaire utile |
|---|---|---|
| RAID MD Linux | mdadm | Scrutiny / Netdata |
| OpenZFS | ZED / zpool | Scrutiny / Netdata / Grafana |
| RAID matériel LSI/Broadcom | StorCLI | Netdata / Checkmk |
| RAID de l’appliance NAS | Supervision intégrée au système d’exploitation du NAS | Outil SMART et historique, lorsque pris en charge |
C’est pourquoi la configuration du stockage influence l’architecture de supervision. Les RAID logiciels, ZFS et les RAID matériels exposent différents états via différentes couches de contrôle.
Scrutiny ou Netdata : lequel devriez-vous installer ?
Ils fonctionnent mieux ensemble que l’un contre l’autre.
| Domaine | Scrutiny | Netdata |
|---|---|---|
| Objectif principal | État de santé des disques physiques | Supervision de l’ensemble du serveur |
| Historique SMART | Excellent | Disponible sous forme de métriques |
| Tendances de température | Excellent | Oui |
| état du RAID logiciel MD | Non | Oui |
| état du pool ZFS | Non | Oui |
| RAID matériel | dépend du relais SMART | collecteur StoreCLI |
| processeur / mémoire vive / réseau | Non | Oui |
| Rôle principal | Spécialiste des disques | Tableau de bord du serveur |
Une combinaison simple pour un serveur domestique est donc :
Netdata
|
État de la baie et du serveur
Scrutiny
|
Tendances des disques physiques
Si vous ne voulez qu’une seule application, Netdata couvre davantage de couches.
Si le système d’exploitation du NAS surveille déjà correctement l’état de la baie, Scrutiny peut apporter davantage d’informations, car il offre un meilleur historique des disques physiques.
Avez-vous besoin de Prometheus et Grafana pour un NAS domestique ?
Généralement, non.
Si la seule exigence est :
Prévenez-moi lorsque le RAID est dégradé
Prévenez-moi lorsqu’un disque est défaillant
les alertes natives de la baie associées à smartd, Scrutiny ou Netdata peuvent résoudre le problème avec beaucoup moins d’infrastructure.
Prometheus et Grafana commencent à avoir du sens lorsque vous vous intéressez à :
- des historiques couvrant plusieurs mois ou années ;
- plusieurs serveurs ;
- des tableaux de bord personnalisés ;
- la corrélation entre la température et les E/S ;
- le suivi de la croissance du stockage ;
- la combinaison du RAID avec les métriques de l’onduleur, du réseau, de Docker et de l’hôte ;
- règles d’alerte PromQL personnalisées.
La mauvaise raison d’installer Grafana est simplement que le tableau de bord semble impressionnant.
La bonne raison est que vous avez des questions qui nécessitent un historique en séries temporelles.
Quelles alertes RAID devez-vous configurer ?
La supervision devient utile uniquement lorsque quelque chose peut vous atteindre sans que vous ayez à ouvrir le tableau de bord au préalable.
Alertes de la baie
- baie dégradée ;
- baie hors ligne ;
- membre manquant de manière inattendue ;
- disque de secours activé ;
- reconstruction ou resynchronisation démarrée ;
- reconstruction échouée ;
- reconstruction terminée.
Alertes des disques physiques
- échec de l’état de santé global SMART ;
- le nombre actuel de secteurs en attente augmente ;
- le nombre de secteurs irrécupérables hors ligne augmente ;
- le nombre de secteurs réalloués augmente de manière significative ;
- avertissement critique NVMe ;
- l’endurance ou l’usure du SSD approche du niveau de remplacement ;
- la température du disque reste en dehors de la plage attendue.
Alertes ZFS
- pool dégradé ;
- défaillance du périphérique ;
- les erreurs de somme de contrôle augmentent ;
- le scrub détecte des erreurs ;
- le resilver commence ou échoue ;
- la capacité du pool approche du seuil choisi.
Alertes RAID matériel
- disque physique défaillant ;
- disque virtuel dégradé ;
- disque virtuel hors ligne ;
- reconstruction bloquée ou échouée ;
- défaillance du cache du contrôleur ou de la batterie de secours.
La température exacte et les seuils SMART ne doivent pas être copiés aveuglément depuis un autre serveur. Les différents modèles de disques exposent des attributs et des plages de fonctionnement différents.
Le principe est plus important :
Un tableau de bord que vous n’ouvrez jamais n’est pas une solution de supervision.
Test SMART, scrub et reconstruction : trois tâches différentes
Ces opérations sont souvent confondues, mais elles inspectent des éléments différents.
Autotest SMART
Un autotest SMART est effectué par un périphérique de stockage individuel.
Un seul disque
|
Test SMART
|
Résultat au niveau du périphérique
Un test SMART long peut analyser une plus grande partie de la surface du disque qu’un test court, mais il ne vérifie ni la parité du RAID ni les copies de données de ZFS sur l’ensemble du système de stockage.
RAID Rebuild or Resync
Reconstruction ou resynchronisation RAID
Une reconstruction restaure la redondance après la défaillance ou le remplacement d’un membre.
|
RAID dégradé
|
Disque de remplacement
|
Reconstruction / Resynchronisation
Redondance restaurée
Il s’agit d’une opération de récupération, et non d’un test de l’état du disque.
Un scrub ZFS ou un contrôle de cohérence RAID
Il répond à une autre question :
> Les données stockées correspondent-elles toujours aux informations d’intégrité et de redondance attendues par le système de stockage ?C’est pourquoi la surveillance doit exposer ces trois éléments lorsque l’architecture de stockage les prend en charge.
Activez les alertes natives du NAS avant d’installer un autre tableau de bord
Un système d’exploitation NAS dédié fournit peut-être déjà la première couche de surveillance dont vous avez besoin.
Par exemple, la gestion actuelle du stockage de ZimaOS affiche l’état de la baie, l’état des disques, la capacité utilisable et les vitesses de lecture/écriture sous Settings > Storage. La défaillance d’un membre RAID fait passer la baie à l’état dégradé, et le processus de récupération guide l’utilisateur lors de la reconstruction après le remplacement du disque.
ZimaOS affiche également la progression des opérations RAID et des contrôles de parité de longue durée, ainsi que des informations détaillées sur l’état des disques dans son interface de stockage.
L’ordre pratique devrait donc être le suivant :
1. Activer les alertes natives du NAS
|
2. Vérifier la détection des baies dégradées
|
3. Ajouter l’historique des disques physiques
|
4. N’ajouter une pile d’observabilité plus complète que si elle est utile
TrueNAS, Unraid, Synology, QNAP et les autres plateformes NAS proposent également des fonctions natives de surveillance de l’état du stockage, qui doivent être configurées avant l’ajout d’un second système de surveillance.
Cette couche supplémentaire doit répondre à une question à laquelle l’interface native ne répond pas correctement.
La surveillance du RAID ne remplace pas la sauvegarde
Une alerte parfaite peut vous indiquer qu’un disque est tombé en panne en quelques secondes.
Il ne peut pas restaurer la version d’hier d’un dossier supprimé.
Il ne peut pas récupérer les fichiers déjà chiffrés par un rançongiciel.
Il ne peut pas recréer le NAS après un vol, un incendie ou une défaillance catastrophique du contrôleur.
C’est pourquoi le RAID ne remplace pas une sauvegarde.
RAID
|
Disponibilité après la défaillance de certains disques
Surveillance
|
Détecter rapidement les problèmes
Sauvegarde
|
Récupérer les données perdues ou endommagées
Tous trois résolvent des aspects différents du problème de fiabilité.
La surveillance devient particulièrement importante pendant les reconstructions, car les disques restants peuvent subir une activité soutenue alors que la redondance est réduite. Une coupure de courant inattendue pendant cette période ajoute un risque supplémentaire, c’est pourquoi la protection par onduleur pendant les opérations de stockage est importante indépendamment de la surveillance de l’état des disques.
Piles de surveillance RAID recommandées
Serveur RAID Linux simple
mdadm --monitor
+
smartd
C’est l’option légère.
mdadm surveille l’agrégat Linux. smartd surveille les disques. Aucun des deux ne nécessite une plateforme web lourde.
NAS domestique simple
Surveillance native du NAS
+
Scrutiny
L’interface du NAS gère l’état de l’agrégat et les reconstructions, tandis que Scrutiny ajoute l’historique de l’état des disques et les notifications.
Serveur domestique Linux standard
Netdata
+
Scrutiny
Netdata fournit la surveillance de l’agrégat et de l’ensemble du serveur. Scrutiny fournit un historique plus détaillé des disques physiques.
Serveur domestique ZFS
ZED
+
Scrutiny
+
Netdata
ZED gère les événements natifs de ZFS, Scrutiny surveille les tendances des disques et Netdata fournit une vue d’ensemble plus large du système.
Homelab avancé
smartctl_exporter
Exportateurs MD / ZFS
node_exporter
|
Prometheus
|
Grafana
|
Alertes
Cette solution est adaptée lorsque l’historique des métriques et la gestion de plusieurs serveurs justifient la maintenance d’une pile complète d’observabilité.
Serveur avec RAID matériel
StorCLI
|
Netdata / Checkmk
|
Alertes + tableau de bord
L’utilitaire du contrôleur reste la source de vérité pour la couche RAID matérielle, tandis que la plateforme de surveillance rend son état visible et exploitable.
Verdict final
Netdata est le meilleur outil global de surveillance du RAID pour la plupart des serveurs domestiques, car il peut couvrir plusieurs architectures de stockage tout en surveillant également l’hôte lui-même.
Scrutiny est le meilleur outil complémentaire lorsque l’historique de chaque disque est important. Il est particulièrement utile pour repérer les changements progressifs des attributs SMART avant que l’agrégat n’atteigne lui-même un état dégradé.
smartmontools reste la couche fondamentale pour l’état de santé des disques, tandis que mdadm Monitor demeure l’une des solutions les plus simples pour le RAID logiciel Linux.
OpenZFS ZED doit rester au cœur d’une stratégie de surveillance native de ZFS, plutôt que de tenter de remplacer les événements des pools par des données SMART génériques.
Cockpit est l’option graphique la plus simple pour un serveur Linux standard, tandis que Prometheus et Grafana sont plus adaptés lorsque les métriques à long terme deviennent une véritable exigence.
Checkmk et Zabbix deviennent plus utiles à mesure que le nombre de systèmes surveillés augmente, tandis que StorCLI est essentiel lorsque la logique RAID est gérée par un contrôleur LSI/Broadcom pris en charge.
La stratégie la plus fiable pour un serveur domestique est donc la suivante :
État de l’agrégat
+
État des disques
+
État de la récupération
+
Alertes
+
Historique
Le RAID tombe généralement en panne par couches ; la surveillance doit donc elle aussi être organisée en couches.
FAQ
Quel est le meilleur outil de surveillance du RAID pour un serveur domestique ?
Netdata est l’une des meilleures options globales, car il peut surveiller le RAID MD Linux, les périphériques SMART, les pools ZFS, les contrôleurs RAID matériels pris en charge et le reste du serveur depuis une seule interface. Scrutiny est un outil spécialisé plus performant lorsque l’historique détaillé du SMART des disques physiques est prioritaire.
Scrutiny est-il un outil de surveillance du RAID ?
Scrutiny surveille les disques physiques situés sous une baie RAID grâce aux données SMART. Il ne remplace pas la surveillance au niveau de la baie, comme mdadm pour le RAID MD Linux, ZED pour les événements ZFS ou StorCLI pour les contrôleurs RAID matériels pris en charge.
SMART peut-il indiquer PASSED alors qu’un disque est défaillant ?
SMART PASSED signifie que le disque n’a pas atteint la condition générale d’échec SMART du périphérique. Des attributs individuels peuvent néanmoins évoluer de manière préoccupante avant que cet état ne passe à failed. La surveillance historique est utile, car elle rend ces tendances visibles.
Quelle est la meilleure façon de surveiller un RAID mdadm ?
Utilisez le mode de surveillance de mdadm pour les événements de la baie, et associez-le à smartmontools ou Scrutiny pour l’état des disques physiques. Netdata peut fournir une couche graphique supplémentaire pour la surveillance du RAID MD et du serveur.
Quelle est la meilleure façon de surveiller un pool ZFS ?
Utilisez des outils natifs de ZFS tels que ZED et zpool pour les événements et l’état du pool. Ajoutez smartmontools ou Scrutiny pour l’état de chaque disque, ainsi que Netdata, Prometheus ou Grafana si une visualisation historique est nécessaire.
La surveillance du RAID détecte-t-elle un disque dur défaillant avant sa panne ?
La surveillance de la baie seule ne le permet pas forcément. Les outils fondés sur SMART peuvent révéler des changements dans l’état des disques avant qu’une baie ne perde un membre, même si aucun système de surveillance ne peut prédire de manière fiable chaque panne de disque.
Dois-je utiliser Netdata ou Scrutiny ?
Utilisez Netdata si vous souhaitez un tableau de bord couvrant l’ensemble du serveur : RAID, stockage, processeur, mémoire vive, réseau et services. Utilisez Scrutiny si les tendances SMART détaillées et l’historique de l’état des disques sont prioritaires. Exécuter les deux peut être utile, car ils couvrent des couches différentes.
Ai-je besoin de Grafana pour surveiller un RAID ?
Non. Grafana est utile pour les métriques à long terme, les tableaux de bord personnalisés, la surveillance de plusieurs systèmes et la corrélation des données. Un NAS domestique simple peut souvent être surveillé correctement avec ses alertes natives, complétées par smartmontools, Scrutiny ou Netdata.
Quelles alertes un serveur RAID doit-il envoyer ?
Au minimum, configurez des alertes pour les baies dégradées ou hors ligne, les membres manquants, les échecs de reconstruction, les échecs d’état SMART, les changements importants des attributs SMART, les températures élevées des disques, les erreurs ZFS et, le cas échéant, les défaillances du contrôleur RAID matériel ou de son cache.
Un scrub RAID est-il identique à un test SMART ?
Non. Un test SMART s’exécute sur un disque individuel. Un scrub ou une vérification de cohérence valide les données et la redondance au niveau du système de stockage. Une reconstruction rétablit la redondance après la panne ou le remplacement d’un disque.
La surveillance du RAID remplace-t-elle les sauvegardes ?
Non. La surveillance aide à détecter rapidement les défaillances, et le RAID peut maintenir la disponibilité après certaines pannes de disque. Ni l’un ni l’autre ne restaure les fichiers supprimés, chiffrés, corrompus ou modifiés au fil du temps. Une sauvegarde distincte reste nécessaire.
Dois-je surveiller les SSD et les disques NVMe en RAID ?
Oui. Les SSD et les disques NVMe exposent des informations d’état telles que les avertissements critiques, la température, les erreurs de support et l’endurance ou l’usure. Les attributs exacts diffèrent des données SMART des disques durs, l’outil de surveillance doit donc prendre en charge les périphériques concernés.
Comparaisons de produits
Plus à lire

Home Assistant peut-il remplacer openHAB pour contrôler tous les appareils de la maison ?
Home Assistant ne peut remplacer openHAB que lorsque chaque appareil et automatisation essentiels a réussi un test parallèle de migration et de restauration.

Mini-PC vs serveur monocarte vs NAS pour Home Assistant
Choisissez un ordinateur monocarte pour un appareil compact et économe, un mini-PC pour davantage de flexibilité et de marge de puissance, ou un NAS...

Comment choisir entre un serveur Home Assistant dédié et un hébergeur d’applications partagé
Choisissez un hébergement dédié pour une isolation des pannes plus simple ; choisissez un hébergement mutualisé lorsque l’isolation, les fenêtres de maintenance et la...

