Monitoring NAS : surveiller disques, services et logs en un coup d'oeil
- Publié le
- ·5 min de lecture
Pourquoi monitorer son NAS ?
Un NAS qui tourne 24h/24, c'est une certitude : les disques vieillissent, des services vont cracher silencieusement, et les logs Docker s'accumulent sans qu'on les lise jamais. Jusqu'au jour où un disque commence à montrer des signes de fatigue, qu'un service plante sans prévenir, ou qu'un container redémarre en boucle et personne ne le remarque.
Sur mon TerraMaster F4-424 sous Debian 13, j'ai déployé quatre outils qui font du monitoring sérieux. Chacun a un rôle précis, zéro overlap. Tout en Docker sur un réseau isolé.
L'archi du monitoring
Avant de rentrer dans les détails :
- Scrutiny (port 9998) : santé SMART des disques
- Uptime Kuma (port 3001) : dispo des services
- Dozzle (port 9999) : logs Docker live
- Homepage (port 3010) : dashboard central
Tous sur monitoring_net, configs dans /mnt/data/apps/monitoring/<service>/.
Scrutiny : pas le droit de se louper
C'est l'outil critique. Un disque qui faiblit, c'est une alerte à pas rater. Scrutiny collecte les data SMART de tous les disques et les affiche avec les tendances historiques.
Les métriques qui comptent :
- Température : disque qui surchauffe = usure accélérée
- Reallocated Sectors : secteurs réalloués = dégradation physique
- Current Pending Sectors : secteurs en attente de reallocation = problèmes imminents
- Read/Write errors : erreurs qui augmentent = rouge très bientôt
Scrutiny fonctionne en deux parties : un collector qui interroge les disques périodiquement, et une web UI pour voir les résultats.
Config Docker un peu spéciale car Scrutiny a besoin d'accès direct aux disques :
# docker-compose.yml (extrait monitoring)
services:
scrutiny:
image: ghcr.io/analogj/scrutiny:master-omnibus
container_name: scrutiny
restart: unless-stopped
ports:
- '9998:8080'
volumes:
- /mnt/data/apps/monitoring/scrutiny/config:/opt/scrutiny/config
- /mnt/data/apps/monitoring/scrutiny/influxdb:/opt/scrutiny/influxdb
- /run/udev:/run/udev:ro
devices:
- /dev/sda
- /dev/sdb
- /dev/sdc
- /dev/sdd
cap_add:
- SYS_RAWIO
networks:
- monitoring_net
cap_add: SYS_RAWIO? Indispensable. Sans ça, le collector peut pas interroger les disques via SMART. Le montage /run/udev en ro permet l'identification des disques.
Uptime Kuma : l'alerte que tu veux vraiment
Uptime Kuma c'est mon outil préféré pour la dispo des services. HTTP, HTTPS, TCP, Ping, DNS - tout ça. Chaque service du NAS a son moniteur.
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
ports:
- '3001:3001'
volumes:
- /mnt/data/apps/monitoring/uptime-kuma/data:/app/data
networks:
- monitoring_net
Ce que je surveille vraiment :
- HTTP checks : Jellyfin, Immich, Home Assistant, Sonarr, Radarr, etc.
- TCP checks : Samba (445), SSH (22), NFS (2049)
- Ping checks : le NAS lui-même, la box internet, les switches
Bon au-delà des vraies pannes, les graphes de latence c'est dingue. Une dégradation progressive peut te révéler un problème de disque, réseau ou RAM avant que le service ne crash vraiment.
Notifications? Uptime Kuma supporte email, Telegram, Discord, Slack, Gotify, ntfy... J'utilise Telegram pour les alertes directement sur le téléphone.
Ah et tu peux créer des status pages publiques ou internes. Pratique pour partager l'état des services avec les autres du foyer.
Dozzle : débugger en 30 secondes
Container qui se comporte bizarrement? Première chose : regarder les logs. Dozzle te donne une interface web pour streamer les logs de tous les containers en live, sans SSH ni docker logs.
dozzle:
image: amir20/dozzle:latest
container_name: dozzle
restart: unless-stopped
ports:
- '9999:8080'
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
networks:
- monitoring_net
Dozzle c'est volontairement minimaliste : pas de DB, pas de persistence, pas de collecte en arrière-plan. Lit le socket Docker, affiche les logs. C'est ça qui le rend léger - quelques Mo de RAM.
Features que j'utilise tous les jours :
- Recherche et filtrage dans les logs d'un container
- Vue multi-containers pour corréler les événements
- Auto-scroll avec pause quand tu remonte dans l'historique
- Regex pour filtrer finement
Le socket en ro? Suffisant. Dozzle lit juste, il contrôle pas les containers.
Homepage : le dashboard qu'il te faut
Avec une vingtaine de services qui tournent, se souvenir des ports devient un casse-tête. Homepage te donne un dashboard configurable en YAML.
homepage:
image: ghcr.io/gethomepage/homepage:latest
container_name: homepage
restart: unless-stopped
ports:
- '3010:3000'
volumes:
- /mnt/data/apps/monitoring/homepage/config:/app/config
- /var/run/docker.sock:/var/run/docker.sock:ro
networks:
- monitoring_net
Config via des fichiers YAML dans le dossier config. Extrait de services.yaml :
# /mnt/data/apps/monitoring/homepage/config/services.yaml
- Media:
- Jellyfin:
href: http://192.168.1.50:8096
icon: jellyfin.svg
description: Serveur multimédia
widget:
type: jellyfin
url: http://192.168.1.50:8096
key: '{{HOMEPAGE_VAR_JELLYFIN_KEY}}'
- Immich:
href: http://192.168.1.50:2283
icon: immich.svg
description: Photos et vidéos
- Downloads:
- qBittorrent:
href: http://192.168.1.50:8080
icon: qbittorrent.svg
description: Client BitTorrent
widget:
type: qbittorrent
url: http://192.168.1.50:8080
username: admin
password: '{{HOMEPAGE_VAR_QBIT_PASSWORD}}'
- Sonarr:
href: http://192.168.1.50:8989
icon: sonarr.svg
description: Gestion des séries
- Monitoring:
- Scrutiny:
href: http://192.168.1.50:9998
icon: scrutiny.svg
description: Santé des disques
- Uptime Kuma:
href: http://192.168.1.50:3001
icon: uptime-kuma.svg
description: Disponibilité des services
Homepage supporte des widgets pour plein de services : Jellyfin affiche les sessions actives, qBittorrent montre les téléchargements en cours. Le dashboard devient un vrai centre de contrôle.
Le réseau Docker isolé
Tous les services partagent monitoring_net :
networks:
monitoring_net:
name: monitoring_net
driver: bridge
Isolation = deux trucs : les containers monitoring communiquent entre eux sans passer par les ports publiés, et tu gardes une séparation claire avec les autres stacks (media, téléchargements, domotique).
Cockpit : le complément système
En parallèle, j'ai Cockpit (port 9090) installé nativement sur Debian. Console d'admin web avec des metrics que les outils Docker ne couvrent pas : CPU, RAM, swap, espace disque, services systemd, terminal web.
sudo apt install cockpit
Ça se complète bien : Cockpit pour le système hôte, les quatre outils Docker pour les services et les disques.
Bilan
Monitoring c'est pas un luxe sur un NAS, c'est de l'assurance. Scrutiny m'a alerté sur une température anormale avant que ça devienne critique. Uptime Kuma me prévient en quelques secondes quand un service tombe. Dozzle me fait gagner un temps fou en debug. Homepage = point d'entrée unique vers tout l'écosystème. Quatre outils légers, chacun avec un rôle précis, déployés en quelques minutes via Docker Compose. C'est ça qui est beau.
Article suivant
Accès distant sécurisé à son NAS avec Tailscale→