Monitoring NAS : surveiller disques, services et logs en un coup d'oeil

Pourquoi monitorer son NAS

Sur une machine qui tourne 24h/24, les disques vieillissent, des services crashent silencieusement, et les logs Docker s'accumulent sans que personne ne les lise — jusqu'au jour où un disque montre des signes de fatigue ou qu'un container redémarre en boucle sans que quiconque le remarque.

Quatre outils couvrent le besoin, chacun avec un rôle précis et sans recouvrement, tous en Docker sur un réseau isolé monitoring_net, avec leurs configs dans /mnt/data/apps/monitoring/<service>/ :

• Scrutiny (port 9998) : santé SMART des disques
• Uptime Kuma (port 3001) : disponibilité des services
• Dozzle (port 9999) : logs Docker live
• Homepage (port 3010) : dashboard central

Scrutiny : la santé des disques

L'outil critique. Scrutiny collecte les données SMART de tous les disques et les affiche avec leurs tendances historiques. Les métriques qui comptent :

• Température : un disque qui surchauffe s'use plus vite
• Reallocated Sectors : secteurs réalloués, signe de dégradation physique
• Current Pending Sectors : secteurs en attente de réallocation, problème imminent
• Read/Write errors : des erreurs qui augmentent annoncent une panne

Scrutiny fonctionne en deux parties : un collector qui interroge les disques périodiquement et une web UI pour les résultats. La config Docker est un peu spéciale, puisqu'il lui faut un 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 est indispensable : sans lui, le collector ne peut pas interroger les disques en SMART. Le montage /run/udev en read-only permet leur identification.

Uptime Kuma : la disponibilité des services

Uptime Kuma couvre HTTP, HTTPS, TCP, Ping et DNS. 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 qui est surveillé : des checks HTTP sur Jellyfin, Immich, Home Assistant, Sonarr, Radarr ; des checks TCP sur Samba (445), SSH (22), NFS (2049) ; et des pings sur le NAS lui-même, la box internet et les switches.

Au-delà des pannes franches, les graphes de latence sont précieux : une dégradation progressive révèle souvent un problème de disque, de réseau ou de RAM avant que le service ne tombe.

Les notifications passent par email, Telegram, Discord, Slack, Gotify ou ntfy. On peut aussi créer des status pages publiques ou internes pour partager l'état des services.

Dozzle : les logs en direct

Quand un container se comporte bizarrement, la première chose à regarder ce sont ses logs. Dozzle les stream en web, 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 est volontairement minimaliste : pas de base de données, pas de persistance, pas de collecte en arrière-plan. Il lit le socket Docker et affiche, ce qui le fait tenir en quelques Mo de RAM. Au quotidien : recherche et filtrage dans les logs d'un container, vue multi-containers pour corréler les événements, auto-scroll avec pause quand on remonte l'historique, et filtrage regex.

Le socket monté en ro suffit : Dozzle lit, il ne contrôle pas les containers.

Homepage : le dashboard central

Avec une vingtaine de services, retenir les ports devient pénible. Homepage fournit 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

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

Les widgets enrichissent le dashboard : Jellyfin affiche les sessions actives, qBittorrent les téléchargements en cours.

Le réseau Docker isolé

networks:
  monitoring_net:
    name: monitoring_net
    driver: bridge

L'isolation apporte deux choses : les containers de monitoring communiquent entre eux sans passer par les ports publiés, et la séparation reste nette avec les autres stacks (media, téléchargements, domotique).

Cockpit : le complément système

En parallèle, Cockpit (port 9090) installé nativement sur Debian couvre ce que les outils Docker ne voient pas : CPU, RAM, swap, espace disque, services systemd, terminal web.

sudo apt install cockpit

Cockpit pour le système hôte, les quatre outils Docker pour les services et les disques.

Bilan

Le monitoring n'est pas un luxe sur un NAS, c'est de l'assurance : Scrutiny alerte sur une température anormale avant qu'elle ne devienne critique, Uptime Kuma prévient en quelques secondes quand un service tombe, Dozzle fait gagner un temps considérable en debug, et Homepage sert de point d'entrée unique. Quatre outils légers déployés en quelques minutes via Docker Compose.