À un moment donné, tout homelab franchit une limite. On passe de trois conteneurs sur un mini PC à une douzaine de services répartis sur deux ou trois machines, et on n’a soudain plus la moindre idée de ce qui se passe sous le capot. Plex est-il sur le point de saturer la RAM ? Le reverse proxy a-t-il cessé de router le trafic en silence à 3h du matin ? Votre FAI a-t-il de nouveau bridé votre débit de moitié ? Le « monitoring » est la réponse que tout le monde envisage. Mais ce n’est pas un seul outil qui fait un seul travail : ce sont trois questions différentes avec trois réponses différentes, et choisir le mauvais outil pour la question qu’on se pose réellement, c’est comme ça qu’on finit par essayer d’utiliser Prometheus pour vérifier si un site web se charge correctement. Un peu comme utiliser une clé dynamométrique pour accrocher un cadre. Ce guide détaille les vraies options de monitoring self-hosted en 2026, ce que chaque outil est réellement conçu pour faire, et quelle combinaison a du sens pour un homelab plutôt que pour un data center d’entreprise.
Ce que « monitoring » signifie vraiment pour un homelab
Avant de comparer les outils, il est utile de découper le « monitoring » selon les tâches que les gens désignent réellement par ce mot :
- Métriques de ressources : combien de CPU, de RAM, d’I/O disque et de débit réseau une machine ou un service utilise en ce moment même, et comment cela a évolué sur la dernière heure, le dernier jour ou la dernière semaine
- Vérifications de disponibilité : si un service est joignable tout court, s’il répond aux requêtes HTTP, s’il accepte les connexions TCP, s’il répond au ping
- Observabilité à grande échelle : corréler des métriques sur des dizaines d’hôtes et de conteneurs, les interroger, construire des tableaux de bord personnalisés, et déclencher des alertes sur seuils à l’échelle de tout le parc
Netdata répond à la première question presque tout seul, dès la sortie de la boîte. Prometheus et Grafana ensemble répondent à la troisième, la première étant traitée en cours de route. Uptime Kuma répond à la deuxième et ne se soucie quasiment jamais de la première. Aucun de ces outils n’est « le meilleur » dans l’absolu. Ils résolvent des problèmes différents, ce qui explique pourquoi la plupart des homelabs qui tournent depuis un moment finissent par utiliser deux de ces trois outils, pas un seul.
Netdata : des métriques temps réel sans la moindre configuration
Netdata est l’outil à installer quand on veut une réponse honnête et immédiate à la question « que fait cette machine en ce moment », sans passer une soirée sur la configuration. Pointez l’installeur vers un hôte, du bare metal, une VM ou un simple conteneur Docker, et il détecte automatiquement ce qui tourne (bases de données, serveurs web, conteneurs, GPU) et commence à tracer des milliers de métriques par seconde, sans tableau de bord à construire ni langage de requête à apprendre au préalable. Cette granularité à la seconde est le vrai facteur différenciant : la plupart des outils de monitoring échantillonnent toutes les 15 à 60 secondes, ce qui convient pour les tendances de long terme mais ne sert à rien pour repérer un pic de CPU de cinq secondes qui vient de faire planter un conteneur. Le tableau de bord de Netdata est délibérément normatif et préconstruit. On n’assemble pas des panneaux : on regarde un écran qui a déjà du sens dès qu’il se charge.
Le compromis, c’est l’échelle. Netdata est conçu autour d’une vue par nœud unique ; comparer des métriques côte à côte sur vingt hôtes, ou écrire une requête personnalisée qui corrèle la latence d’une base de données avec le taux d’erreurs d’un reverse proxy, ce n’est pas vraiment son métier (Netdata Cloud l’étend dans cette direction, mais c’est une couche séparée, en partie payante). Pour un NAS, un hôte Proxmox ou une poignée d’hôtes Docker, rien de tout cela ne pèse vraiment. L’installation complète, le déploiement Docker réel, et la répartition des licences entre l’Agent gratuit et Netdata Cloud sont détaillés dans la fiche Netdata.
Prometheus + Grafana : la stack d’observabilité complète
Prometheus et Grafana sont cités dans la même phrase parce qu’ils sont conçus pour fonctionner ensemble. Prometheus récupère (scrape) les métriques de chaque service que vous lui indiquez selon un planning, les stocke dans sa propre base de données de séries temporelles, et vous permet d’interroger cet historique avec PromQL. Grafana transforme ensuite ces requêtes en tableaux de bord, graphiques et alertes. À eux deux, c’est ce qui se rapproche le plus, en self-hosting, de ce que des entreprises comme Datadog vendent comme produit payant, moins la facturation par hôte, et vous gardez vos données.
L’inconvénient honnête, c’est l’effort de mise en place. Netdata fonctionne dès que le conteneur démarre. Prometheus a besoin d’une configuration de scraping qui lui indique quoi surveiller et à quelle fréquence, et la plupart des services ont besoin d’un « exporter » qui tourne à côté d’eux pour exposer leurs métriques dans un format que Prometheus comprend : node_exporter pour les métriques de l’hôte, cAdvisor pour les métriques des conteneurs, etc. Grafana a ensuite besoin que Prometheus soit ajouté comme source de données, et les tableaux de bord doivent être construits de zéro ou importés depuis la bibliothèque communautaire. Rien de tout cela n’est réellement difficile, mais ça représente une après-midi de travail plutôt que cinq minutes, ce qui explique que cette stack soit décrite comme demandant « plus d’effort de configuration » que Netdata.
Ce qu’on obtient en retour, c’est une vraie échelle et une vraie flexibilité. Une seule instance Prometheus peut suivre les métriques de chaque conteneur, VM et service d’un homelab. PromQL permet de poser des questions précises comme « quel est le temps de réponse au 95e percentile pour ce conteneur sur les six dernières heures ». Les alertes de Grafana peuvent vous prévenir avant qu’un disque ne se remplisse réellement, plutôt qu’après. La documentation officielle de Prometheus vaut le détour si vous hésitez sur le fait que ce langage de requête corresponde à votre façon de penser votre infrastructure. Pour les images Docker concrètes, une configuration de scraping qui fonctionne, et la façon dont les deux se connectent en pratique, voir les fiches Prometheus et Grafana.
Uptime Kuma : disponibilité, pas métriques de ressources
Uptime Kuma résout un problème différent des deux outils précédents, et autant le dire clairement tout de suite : il ne sait pas et ne se soucie pas de combien de RAM un conteneur utilise. Ce qui l’intéresse, c’est si un service répond réellement. Vérifications HTTP/HTTPS, vérifications de port TCP, ping, DNS, et une liste croissante d’intégrations spécifiques (statut de conteneur Docker, gRPC, MQTT). Pointez-le vers un reverse proxy, un serveur DNS, un serveur multimédia, ou tout ce qui est exposé publiquement, et il interroge selon un planning, journalise le temps de réponse, et signale l’instant exact où quelque chose cesse de répondre.
Deux choses justifient de le faire tourner même à côté de Prometheus et Grafana. D’abord, les pages de statut publiques : Uptime Kuma peut générer une page partageable montrant le statut en direct des services de votre choix, la même idée que les produits SaaS publient pendant une panne, sauf que c’est self-hosted et sous votre contrôle. Ensuite, les notifications. Il embarque plus de 90 intégrations natives (Discord, Telegram, ntfy, email, et la plupart des suspects habituels), donc une alerte sur le téléphone dès qu’un service tombe est une configuration de cinq minutes plutôt qu’une configuration Alertmanager séparée. Il tourne depuis un seul conteneur Docker et, contrairement à Prometheus, vous donne quelque chose d’utile en quelques minutes plutôt qu’après une après-midi de configuration. Les étapes d’installation et la configuration des notifications sont dans la fiche Uptime Kuma ; le dépôt GitHub du projet vaut aussi le coup d’œil pour se faire une idée de son activité de maintenance. C’est l’un des projets self-hosted les plus étoilés sur GitHub, et ce n’est pas un hasard.
Monitoring spécialisé : Changedetection.io et Speedtest Tracker
Tous les besoins de monitoring ne rentrent pas proprement dans les cases « métriques de ressources » ou « est-ce que ça répond ». Deux outils résolvent des problèmes plus étroits, suffisamment bien pour que ça ne vaille pas la peine de tordre un outil généraliste pour lui faire faire leur travail à leur place.
Changedetection.io surveille les changements sur des pages web plutôt que la santé de serveurs. Pointez-le vers une page produit, et il signale quand le prix baisse ou qu’un article est de nouveau en stock. Pointez-le vers un changelog ou une page de conditions d’utilisation, et il signale quand le contenu change réellement. Il prend en charge le diff visuel et des filtres CSS/XPath pour ne surveiller qu’une partie d’une page, plus une option de navigateur headless pour les sites riches en JavaScript qu’une simple vérification HTTP raterait complètement. C’est une niche différente du monitoring serveur, mais elle revient assez souvent dans les discussions sur le monitoring self-hosted pour qu’on ne puisse pas vraiment l’ignorer.
Speedtest Tracker fait une seule chose, et la fait bien : il lance le CLI Speedtest d’Ookla selon un planning et trace les résultats dans le temps, débit descendant, débit montant, ping, et perte de paquets. Si vous soupçonnez votre FAI de brider les connexions à certaines heures, ou que vous êtes sur le point d’appeler pour vous plaindre d’une connexion lente, c’est l’outil qui vous donne un graphique plutôt qu’une impression.
Charge sur les ressources : ce que chacun coûte réellement
Ça compte davantage dans un homelab que dans un data center, parce que la machine qui fait tourner la stack de monitoring fait généralement aussi tourner tout ce qui est surveillé. Netdata est léger par hôte mais peut devenir gourmand en RAM si la rétention des métriques est poussée haut sur une machine déjà limitée en mémoire ; les réglages par défaut conviennent généralement à partir de 2 Go de RAM disponible. Prometheus est de loin le plus lourd des trois, surtout parce que sa base de données de séries temporelles garde tout en local et que l’indexation de ces données n’est pas gratuite. Pour surveiller plus qu’une poignée de cibles, donner 1 à 2 Go de RAM à Prometheus et un peu d’espace disque dédié est réaliste. Grafana lui-même est léger. Uptime Kuma est de loin le plus léger : il vérifie si les choses répondent, il n’ingère pas un déluge de métriques, et il tourne confortablement sur du matériel qui peinerait visiblement à faire tourner Prometheus et Grafana ensemble.
Lequel faut-il vraiment faire tourner ?
En pratique, la plupart des homelabs qui tournent depuis plus de quelques mois finissent par utiliser deux de ces trois outils, pas un seul. Une façon pratique de décider par où commencer :
- Vous gérez une à trois machines et voulez une image honnête de ce qui se passe en ce moment, sans configuration ? Commencez par Netdata. C’est le chemin le plus rapide vers un vrai tableau de bord.
- Vous faites tourner une douzaine de conteneurs ou plus, répartis sur plusieurs hôtes, et vous voulez corréler des métriques, construire des tableaux de bord personnalisés ou définir des alertes sur seuils ? Prometheus + Grafana vaut l’effort de configuration supplémentaire, et c’est la stack qui a le plus de chances de rester pertinente à mesure que ça grandit.
- Vous vous souciez davantage de savoir à l’instant où un service tombe que de la RAM qu’il utilisait avant ? Uptime Kuma est la réponse la plus directe, et c’est généralement le premier outil de monitoring que les gens installent vraiment, parce que ça prend des minutes plutôt qu’une après-midi.
- Besoin de suivre une page web plutôt qu’un serveur, ou un débit plutôt qu’un conteneur ? Changedetection.io ou Speedtest Tracker feront ce travail précis mieux que n’importe quel outil généraliste détourné pour l’occasion.
Aucun de ces choix n’est mutuellement exclusif, et c’est vraiment ça, la conclusion à retenir. Uptime Kuma qui surveille si les choses tournent, associé à Netdata ou à Prometheus et Grafana qui surveillent pourquoi elles se sont arrêtées, couvre les deux questions qui comptent vraiment au quotidien dans un homelab : est-ce cassé, et qu’est-ce qui l’a cassé.