Fransys

Blog technique — Architecture, Cloud & DevOps

BlogServicesContactÀ propos

Suivez-moi

githubGitHublinkedinLinkedinmailMail

© 2026 Fransys • Fransys

Fransys

Catégories

  • Tous les articles
  • Tags
  • productivite10
  • nas10
  • ia8
  • securite7
  • linux6
  • claude-code6
  • auto-hebergement6
  • neovim5
  • docker5
  • editeur4
  • mcp3
  • vpn3
  • reseau3
  • lua2
  • terminal2
nasdockerauto-hebergementmonitoring

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

Publié le
2 mars 2026·5 min de lecture
Avatar François GUERLEZFrançois GUERLEZ

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 précédent

← Status line Claude Code : afficher sa consommation API en temps réel

Article suivant

Accès distant sécurisé à son NAS avec Tailscale→
← Retour au blog

Sommaire

  • Pourquoi monitorer son NAS ?
  • L'archi du monitoring
  • Scrutiny : pas le droit de se louper
  • Uptime Kuma : l'alerte que tu veux vraiment
  • Dozzle : débugger en 30 secondes
  • Homepage : le dashboard qu'il te faut
  • Le réseau Docker isolé
  • Cockpit : le complément système
  • Bilan