Le Dashboard NOC : construire mon propre outil de supervision
Mon propre frontend de supervision développé en Python/Flask — une vue synthétique et réorganisable de mes machines, services et liens utiles, qui m'appartient du premier au dernier caractère, plutôt qu'un outil générique.
Avancement du projet
- Application Flask en service permanent (Gunicorn + systemd
- Bloc de supervision des machines (Prometheus)
- Bloc de supervision des services (Uptime Kuma)
- Bloc de liens rapides personnalisables
- Interface entiu00e8rement ru00e9organisable (blocs et colonnes)
- Authentification par mot de passe
- Bouton de rafrau00eechissement global
- Bouton de rafrau00eechissement par bloc
- HTTPS
- Ru00f4les su00e9paru00e9s (lecture seule / admin) avec tuile de profil
- Boutons d'administration (redu00e9marrage de service, reboot) via SSH
- Calendrier Outlook (flux ICS
- Masquage des IPs (ru00e9glage admin 3 modes)
- Widget mu00e9tu00e9o dans le calendrier
- Fil d'actualitu00e9s belges dans le calendrier (RTBF Info)
- Historique des incidents
- Sauvegarde automatique de la configuration
- Graphiques Grafana intu00e9gru00e9s
- Tempu00e9rature CPU
- Espace disque en valeur absolue
- Alertes visuelles
- Sparklines
- Vue mobile optimisu00e9e
- Recherche/filtre
- Thu00e8me clair/sombre
- Health check du dashboard
- Aide contextuelle par bloc
Statut : Terminé
🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 28/28 tâches terminées (100%)
Pourquoi j’ai choisi de tout coder moi-même
Dans le cadre de mon projet NOC (centre de supervision réseau domestique), j’avais déjà Grafana pour la visualisation avancée. Mais je voulais un point d’entrée unique, pensé pour mon usage quotidien plutôt qu’un outil générique : une vue synthétique des machines, des services, des liens utiles, réorganisable à la main, et qui m’appartienne du premier au dernier caractère. J’ai donc développé mon propre frontend en Python/Flask plutôt que de m’arrêter à un dashboard existant.
Choix techniques
- Flask + Gunicorn + systemd : l’application tourne en service permanent sur mon Raspberry Pi 4B (hub01), avec démarrage automatique et redémarrage en cas de crash.
- Scraping et parsing sur mesure : le backend interroge directement les endpoints /metrics de Prometheus et d’Uptime Kuma et parse les données via des expressions régulières ciblées, plutôt que via un client générique — plus léger, et un contrôle total sur ce qui remonte à l’affichage.
- Calcul d’uptime « temps réel » maison : Uptime Kuma n’expose que des ratios de disponibilité en pourcentage. J’ai donc implémenté un suivi d’état qui compare le statut courant de chaque service à son état précédent (persisté en JSON) et horodate chaque transition, pour afficher une vraie durée en ligne/hors ligne.
- Authentification : accès protégé par une page de connexion et une session sécurisée, mot de passe stocké sous forme de hash dans une variable d’environnement du service.
- Écritures atomiques : toute persistance sur disque passe par un pattern fichier temporaire + renommage atomique, pour éviter toute corruption en cas de coupure.
- Interface réorganisable : GridStack.js pour des blocs déplaçables/redimensionnables à la souris, colonnes de tableaux réordonnables individuellement, disposition persistée.
- Rafraîchissement sans rechargement complet : chaque bloc peut interroger sa propre route API et remplacer son contenu en JavaScript, sans recharger toute la page — en plus d’un bouton de rafraîchissement global classique.
- Zéro dépendance externe pour l’essentiel : pas de base de données, pas de service tiers — configuration et état vivent dans de simples fichiers JSON versionnés avec le code.
- Contrôle d’accès par rôle : les actions sensibles (redémarrage de service, reboot, masquage des IPs) sont réservées au rôle admin, vérifié côté serveur sur chaque route et pas seulement côté interface.
- Actions d’administration via SSH dédiée : une paire de clés SSH dédiée (sans mot de passe, sudo restreint à une liste blanche de commandes) permet de déclencher des actions à distance sur le Rpi3b+ depuis le dashboard hébergé sur hub01, sans jamais exposer d’identifiants génériques.
- Calendrier via flux ICS : plutôt qu’une intégration Outlook bloquée par Microsoft (iframe refusée), le calendrier lit directement mon flux ICS Outlook (bibliothèque icalevents) pour construire une vraie grille mensuelle avec les événements du mois.
- Masquage des IPs calculé côté serveur : le réglage (désactivé / masqué pour les invités / masqué pour tous) est stocké dans la configuration du dashboard, jamais côté navigateur — impossible pour un compte invité de le contourner, et l’admin voit toujours les vraies adresses quel que soit le mode choisi.
- Météo et actualités directement dans le calendrier : plutôt que d’ajouter des blocs séparés, j’ai choisi d’enrichir le bloc Calendrier existant — chaque case du mois affiche désormais une icône météo et les températures min/max du jour (API Open-Meteo, gratuite et sans clé), et un pied de page en 3 colonnes complète la vue avec les prochains événements, le détail météo du jour, et les dernières actualités belges (flux RTBF Info, filtré pour ne garder que les vraies actualités). Un grand merci à alxsxn_666 pour ses idées, qui sont à l’origine de ces deux ajouts !
- Suivi de l’espace disque des disques NAS : en creusant le sujet, j’ai découvert que mon Raspberry Pi 3B+ (qui héberge à la fois Prometheus et mes disques NAS) n’était pas surveillé pour son espace disque — le filtre par défaut de Node Exporter exclut justement tout ce qui se trouve sous /mnt. Après ajustement de sa configuration, un nouveau bloc dédié affiche désormais l’espace utilisé, libre et total de mes 3 disques NAS, avec une barre de progression colorée (vert / jaune / rouge selon le taux de remplissage).
- Navigation dans le calendrier : le bloc Calendrier ne montrait que le mois courant sans moyen d’en changer. J’ai ajouté des flèches précédent/suivant pour naviguer mois par mois, ainsi qu’un menu déroulant pour sauter directement à une année donnée — le tout sans recharger toute la page, en réutilisant la même route API de rafraîchissement par bloc déjà en place pour le reste du dashboard.
- Thème clair/sombre : bouton de bascule intégré directement à la tuile de profil, avec une palette reprise de celle de ce site (lio-web.com) pour garder une identité visuelle cohérente entre les deux. La préférence choisie est mémorisée automatiquement dans le navigateur.
- Alertes visuelles en cas d’incident : un bandeau rouge apparaît automatiquement en haut du dashboard dès qu’une machine ou un service est détecté hors ligne, listant précisément les éléments concernés — invisible le reste du temps, pour ne pas surcharger l’interface en fonctionnement normal.
- Historique des incidents : un journal garde la trace des 15 derniers changements de statut (machine ou service), avec la date, l’heure et le détail du changement (par exemple hors ligne → en ligne) — pratique pour retrouver quand un incident a commencé et combien de temps il a duré, sans avoir à s’y trouver au bon moment.
- Sauvegarde automatique de la configuration : à chaque modification de la disposition (déplacement ou redimensionnement d’un bloc), une copie horodatée de la configuration est créée automatiquement, avec les 30 versions les plus récentes conservées — de quoi revenir en arrière en cas de fausse manœuvre, sans sauvegarde manuelle à penser.
- Recherche/filtre dans les tableaux : un champ de recherche apparaît désormais au-dessus des tableaux de supervision des machines et des services, entièrement côté navigateur — les lignes qui ne correspondent pas au texte tapé disparaissent instantanément, sans aller-retour avec le serveur.
- Mini-graphiques (sparklines) : chaque machine et chaque service affiche désormais une petite courbe d’évolution récente à côté de son nom (usage CPU pour les machines, temps de réponse pour les services), construite à partir de l’historique déjà stocké par Prometheus. Petite découverte au passage : Uptime Kuma n’était jusqu’ici jamais interrogé par Prometheus (seulement par le dashboard, en direct), donc aucun historique de temps de réponse n’existait pour les services — j’ai ajouté Kuma comme source scrappée par Prometheus pour que cet historique existe aussi de son côté.
- Aide contextuelle sur chaque bloc : une petite icône « ? » apparaît désormais dans l’en-tête de chaque bloc principal, à côté du bouton de rafraîchissement. Un clic ouvre un petit popover expliquant à quoi sert le bloc, qui se referme au clic suivant n’importe où sur la page — un choix volontairement compatible tactile (plutôt qu’une info-bulle au survol) en prévision de la future vue mobile du dashboard.
- Health check du dashboard : un petit point coloré apparaît désormais à côté de l’indicateur d’état du service (« Dashboard: active »), vert si toutes les sources externes du dashboard répondent (Prometheus, Uptime Kuma, calendrier Outlook, météo, actualités), rouge si l’une d’elles est en échec. Un clic affiche le détail source par source, pour savoir immédiatement si des données affichées pourraient être obsolètes plutôt que de le découvrir après coup.
- Vue optimisée mobile : sur petit écran, les blocs s’empilent désormais en pleine largeur, dans l’ordre, plutôt que d’essayer de conserver une grille à 12 colonnes illisible. La vue mobile est volontairement simplifiée (sans les boutons de réorganisation/administration), la personnalisation de la disposition se faisant depuis un ordinateur.
- Température CPU des Raspberry Pi : la température du processeur de mes deux Raspberry Pi apparaît désormais dans l’info-bulle du bloc Machines Status, à côté du CPU, de la RAM et de l’espace disque déjà affichés. Petite découverte au passage : mon Raspberry Pi 4B (hub01, qui héberge le dashboard) n’était en réalité surveillé par Prometheus que via Uptime Kuma jusqu’ici — je l’ai ajouté comme véritable cible Prometheus, ce qui lui donne au passage les mêmes statistiques détaillées (CPU, RAM, disque) que mon Raspberry Pi 3B+.
- Graphiques Grafana intégrés : la dernière brique du module, et pas la plus simple. J’ai reconstruit un dashboard Grafana entièrement de zéro (CPU Usage, RAM Usage, CPU Temperature), exposé en lecture seule via un lien « dashboard public » scopé à ce seul dashboard plutôt qu’un accès anonyme complet à l’instance — j’ai d’ailleurs découvert au passage qu’un accès anonyme global était resté activé par erreur sur mon instance Grafana, désormais désactivé. Le tout est intégré directement dans le dashboard NOC via une iframe, en passant Grafana en HTTPS avec le même certificat que l’application Flask pour éviter tout blocage de contenu mixte du navigateur. Dernier détail soigné : les légendes affichent des noms lisibles (hub01, noc, PC Lionel, PC MT) plutôt que des adresses IP brutes, grâce à un label dédié ajouté au niveau du scraping Prometheus.
Où j’en suis
✅ Déjà en place :
- Application Flask en service permanent (Gunicorn + systemd)
- Bloc de supervision des machines (Prometheus)
- Bloc de supervision des services (Uptime Kuma — disponibilité, temps de réponse, certificats SSL, uptime temps réel)
- Bloc de liens rapides personnalisables
- Interface entièrement réorganisable (blocs et colonnes)
- Authentification par mot de passe
- Bouton de rafraîchissement global
- Bouton de rafraîchissement par bloc
- HTTPS
- Rôles séparés (lecture seule / admin) avec tuile de profil (nom, rôle, déconnexion)
- Boutons d’administration (redémarrage de service, reboot) en local sur hub01 et à distance sur le Rpi3b+ via SSH, avec confirmation avant toute action sensible
- Calendrier Outlook (flux ICS) — grille mensuelle, prochains événements, horloge en direct
- Masquage des IPs (réglage admin 3 modes)
- Widget météo dans le calendrier (icône + min/max par jour, panneau détaillé du jour)
- Fil d’actualités belges dans le calendrier (RTBF Info)
- Suivi de l’espace disque des 3 disques NAS (utilisé / libre / total, barre de progression colorée)
- Navigation calendrier (mois précédent/suivant, sélecteur d’année)
- Thème clair/sombre (bouton dans la tuile de profil, palette reprise de lio-web.com)
- Alertes visuelles en cas d’incident (bandeau rouge en haut du dashboard)
- Historique des incidents (journal des 15 derniers changements de statut)
- Sauvegarde automatique de la configuration (copie horodatée à chaque modification, 30 versions conservées)
- Recherche/filtre dans les tableaux (champ de recherche au-dessus des tableaux, filtrage instantané côté navigateur)
- Mini-graphiques (sparklines) dans les tableaux (courbe CPU pour les machines, temps de réponse pour les services)
- Aide contextuelle sur chaque bloc (icône « ? » cliquable, popover explicatif)
- Health check du dashboard (indicateur coloré + détail par source des dépendances externes)
- Vue optimisée mobile (empilement pleine largeur, vue simplifiée sans contrôles d’administration)
- Température CPU des Raspberry Pi (info-bulle du bloc Machines Status)
- Graphiques Grafana intégrés (dashboard Grafana public reconstruit de zéro — CPU, RAM, température — intégré en iframe HTTPS)
Merci à tous ceux qui ont suivi et donné des idées en cours de route 🙏
Détails du projet
- Technologies / matériel utilisés
- Python, Flask, Gunicorn, systemd, Prometheus, Uptime Kuma, GridStack.js, SSH, icalevents (flux ICS)
- Dates
- 18/09/2026 → 26/09/2026
- Budget approximatif
- 0€
- Système d'exploitation
- Debian 13 (tricie)
- Processeur
- Raspberry Pi 4B (ARM Cortex-A72)
- Mémoire vive (RAM)
- 2 Go
- Stockage
- carte SD de 64 Go
Fiche mise à jour le 26/09/2026