L’examen annuel de XDA-Developers des outils FOSS auto-hébergés a fait une chose claire: les cauchemars opérationnels ne sont pas les outils eux-mêmes, c’est l’invisibilité. Un conteneur redémarre silencieusement dans une boucle de défaillance toute la nuit, un disque se remplit pendant que personne ne regarde, un certificat expire et arrête un service, et personne ne le sait jusqu’à ce que quelqu’un ait réellement besoin de la chose qui s’est cassée. L’auto-hébergement paraît facile jusqu’au moment où une défaillance est silencieuse. La solution n’est pas plus de logiciels à surveiller, c’est l’observabilité qui expose les problèmes avant qu’ils ne deviennent des incidents. Sept applications de bureau qui rendent un stack de lab maison observable, classées par la directivité avec laquelle chacune répond à « est-ce que tout fonctionne réellement? »
Ce qu’il faut rechercher dans une application de surveillance auto-hébergée
- Empreinte de ressources. Une pile de surveillance qui consomme une partie significative du matériel qu’elle est censée surveiller va à l’encontre du but sur un petit lab maison.
- Intégrations d’alertes. La prise en charge de Discord, ntfy, Gotify, Slack et webhooks compte plus qu’un beau tableau de bord que personne ne consulte.
- Publication de page de statut. Une page publique ou interne que vous pouvez montrer aux gens vaut mieux qu’expliquer une panne après coup.
- Support natif des conteneurs. Tout ce qui exécute Docker ou Kubernetes a besoin d’une surveillance qui comprend les conteneurs, pas seulement les hôtes et les ports.
- Rétention historique. Le temps d’activité seul n’explique pas pourquoi quelque chose s’est cassé; l’historique des métriques sur des jours ou des semaines le fait.
- Friction de configuration. Un outil qui prend une soirée à configurer sera abandonné lors de la première mise à jour.
Comparaison rapide
| Application | Meilleur pour | Plates-formes | Plan gratuit | Prix de démarrage |
|---|---|---|---|---|
| Uptime Kuma | Alertes de temps d’activité rapides et page de statut | Linux, Windows, macOS | Oui, application complète | Gratuit |
| Grafana + Prometheus | Historique des métriques approfondi et tableaux de bord | Linux, Windows, macOS | Oui, application complète | Gratuit |
| Netdata | Métriques d’hôte par seconde sans configuration | Linux, Windows, macOS | Oui, niveau auto-hébergé | Gratuit |
| Beszel | Suivi léger des ressources multi-serveurs | Linux, Windows, macOS | Oui, application complète | Gratuit |
| Gatus | Pages de statut gérées par Git | Linux, Windows, macOS | Oui, application complète | Gratuit |
| Homepage | Tableau de bord unique agrégant d’autres outils | Linux, Windows, macOS | Oui, application complète | Gratuit |
| Portainer CE | Santé au niveau des conteneurs et logs | Linux, Windows, macOS | Oui, Community Edition | Gratuit |
Les applications
1. Uptime Kuma — Meilleur pour les alertes de temps d’activité rapides et les pages de statut
Uptime Kuma est l’outil sur lequel la plupart des guides de lab maison pointent en premier, et c’est mérité. Pointez-le vers des points de terminaison HTTP, des ports TCP, des enregistrements DNS ou des conteneurs Docker, définissez un intervalle de vérification, et il envoie des alertes via plus de 90 intégrations de notification, y compris Discord, Slack, ntfy, Gotify et des webhooks simples. Il génère également une page de statut publique ou privée à partir de la même liste de moniteurs, donc il y a une URL à vérifier au lieu de deviner quel service s’est arrêté.
Où il échoue: Aucun graphique de ressources ou de métriques au-delà du temps de réponse et de l’historique de temps d’activité. La configuration des notifications est par moniteur, ce qui devient répétitif après des dizaines de vérifications. Pas d’agrégation de journaux intégrée.
Tarification: Gratuit, licence MIT, auto-hébergé uniquement.
Plates-formes: Linux, Windows, macOS (fonctionne partout où Docker fonctionne; le tableau de bord lui-même est une application navigateur).
Téléchargement: GitHub
Conclusion: Le chemin le plus rapide de “rien n’est surveillé” à “nous saurons en une minute.”
2. Grafana + Prometheus — Meilleur pour l’historique des métriques approfondi et les tableaux de bord
Grafana et Prometheus ensemble sont la pile de métriques standard de l’industrie, et ils se réduisent bien à un lab maison. Prometheus récupère et stocke les données de séries temporelles à partir d’exportateurs attachés à chaque service; Grafana transforme ces données en tableaux de bord et règles d’alerte. L’écosystème des exportateurs couvre presque tout ce qui vaut la peine de surveiller: node_exporter pour les statistiques d’hôte, cAdvisor pour les conteneurs, blackbox_exporter pour les vérifications de points de terminaison.
Où il échoue: Deux services à exécuter et maintenir alignés au lieu d’un. PromQL a une courbe d’apprentissage réelle. Chaque service dont vous voulez des métriques a besoin de son propre exportateur, ce qui ajoute plus de pièces mobiles qui peuvent elles-mêmes échouer silencieusement.
Tarification: Gratuit et open-source auto-hébergé (Prometheus est Apache 2.0, l’édition open-source de Grafana est AGPL). Grafana Cloud offre des niveaux hébergés payants, mais la pile auto-hébergée reste gratuite.
Plates-formes: Linux, Windows, macOS (binaires natifs ou Docker sur les trois).
Téléchargement: Grafana · Prometheus
Conclusion: Choisissez ceci quand le temps d’activité seul ne répond pas à “pourquoi” et que l’historique compte.
3. Netdata — Meilleur pour les métriques d’hôte par seconde sans configuration
Netdata découvre automatiquement ce qui s’exécute sur un hôte au moment de l’installation et commence à le graphiquer immédiatement, aucune construction de tableau de bord requise. Il est livré avec des milliers de graphiques préconstruits couvrant le CPU, la mémoire, les E/S disque, le réseau et des centaines d’applications prises en charge, tous à une granularité par seconde. Pour une seule boîte de lab maison, c’est le moyen le plus rapide de tout voir à la fois.
Où il échoue: La rétention locale par seconde peut remplir le disque rapidement sur du matériel limité. L’invite d’inscription Netdata Cloud apparaît plus qu’il ne le faudrait. L’utilisation des ressources est plus lourde que les concurrents légers de cette liste lorsqu’ils s’exécutent sur un nœud basse consommation.
Tarification: Niveau Community gratuit auto-hébergé; le niveau Business payant ajoute la gestion centralisée de la flotte et la rétention cloud plus longue.
Plates-formes: Linux (installation native et Docker, cible principale), Windows et macOS via Docker.
Téléchargement: GitHub · Site Netdata
Conclusion: Installez-le et l’hôte s’explique lui-même, aucune configuration requise.
4. Beszel — Meilleur pour le suivi léger des ressources multi-serveurs
Beszel est ce que Netdata serait s’il restait minimaliste. Un seul binaire Go statique exécute un concentrateur qui collecte à partir d’agents légers sur chaque serveur via SSH, graphiquant le CPU, la mémoire, le disque, le réseau et les statistiques Docker par conteneur sans la surcharge d’une pile de métriques complète. Pour quelqu’un qui surveille trois ou quatre machines, c’est l’outil qui ne demande pas un deuxième serveur juste pour exécuter la surveillance.
Où il échoue: Projet plus jeune, donc moins d’intégrations et moins de documentation communautaire qu’à Netdata. Pas de liste d’intégrations de notification aussi large que celle d’Uptime Kuma. L’ensemble des fonctionnalités est intentionnellement plus étroit qu’une pile de métriques complète, par conception.
Tarification: Gratuit, licence MIT, auto-hébergé uniquement.
Plates-formes: Linux (principal, pour le concentrateur et l’agent), Windows et macOS via un binaire ou Docker pour l’agent.
Téléchargement: GitHub
Conclusion: Choisissez ceci quand Netdata semble lourd et que Grafana plus Prometheus semble excessif.
5. Gatus — Meilleur pour les pages de statut gérées par Git
Gatus traite la surveillance comme une configuration, non pas du clic. Chaque vérification de point de terminaison, qu’elle soit HTTP, TCP, DNS, ICMP ou une condition écrite personnalisée contre un corps de réponse ou un en-tête, vit dans un fichier YAML qui peut être mis en contrôle de version aux côtés du reste du code d’infrastructure du lab maison. Il rend une page de statut à partir de la même configuration, donc la source de vérité pour ce qui est surveillé et ce que le public voit est le même fichier.
Où il échoue: Éditer un moniteur signifie éditer un fichier et recharger, pas cliquer via une interface utilisateur. Pas de graphiques de ressources ou de métriques. La liste des intégrations de notification est plus étroite qu’celle d’Uptime Kuma.
Tarification: Gratuit, licence Apache 2.0, auto-hébergé uniquement.
Plates-formes: Linux, Windows, macOS, via Docker ou un binaire Go statique.
Téléchargement: GitHub
Conclusion: Choisissez ceci pour une page de statut qui vit dans git, pas dans une base de données.
6. Homepage — Meilleur pour un tableau de bord unique agrégant d’autres outils
Homepage ne surveille rien par lui-même; il récupère l’état en direct des outils qui le font déjà et les place sur une page de démarrage aux côtés des favoris et de la recherche. Les widgets peuvent afficher l’état des moniteurs Uptime Kuma, la santé des conteneurs Docker et Kubernetes, les statistiques d’hôte Proxmox et des dizaines d’autres services auto-hébergés côte à côte, donc vérifier “est-ce que tout va bien?” devient une charge de page au lieu de cinq connexions.
Où il échoue: Il affiche la santé qu’il récupère d’autres outils plutôt que de générer ses propres alertes. La configuration est constituée de fichiers YAML édités par widget, ce qui ajoute de la friction pour les changements fréquents. Pas de graphiques historiques propres.
Tarification: Gratuit, licence GPL, auto-hébergé uniquement.
Plates-formes: Linux, Windows, macOS, basé sur Docker avec un tableau de bord navigateur.
Téléchargement: GitHub
Conclusion: Choisissez ceci comme le volet unique qui expose ce qu’Uptime Kuma, Netdata ou Portainer savent déjà.
7. Portainer CE — Meilleur pour la santé au niveau des conteneurs et les logs
Portainer Community Edition donne à chaque conteneur sa propre vue: logs en direct, utilisation du CPU et de la mémoire, statistiques réseau et contrôles de redémarrage ou d’inspection, le tout à partir d’une interface web au lieu d’un terminal. La gestion des piles couvre Docker Compose et Kubernetes, donc une pile auto-hébergée complète peut être vérifiée, redémarrée ou redéployée à partir d’un seul endroit quand quelque chose dans un conteneur échoue silencieusement.
Où il échoue: La surveillance est limitée au périmètre du conteneur, pas à l’échelle de l’hôte ou de bout en bout. Pas d’alertes ou de notifications intégrées dans la Community Edition; l’édition Business payante en ajoute plus. Les graphiques de ressources historiques sont limités par rapport à Grafana plus Prometheus.
Tarification: Gratuit Community Edition (licence zlib); l’édition Business ajoute RBAC et le support sur une licence payante.
Plates-formes: Linux (l’hôte Docker le plus courant), Windows via Docker Desktop ou les conteneurs Windows, macOS via Docker Desktop.
Téléchargement: GitHub · Site Portainer
Conclusion: Choisissez ceci quand les défaillances qui valent la peine de surveiller sont à l’intérieur des conteneurs, pas seulement à la limite du réseau.
Comment choisir le bon
- Si un lab maison n’a rien de surveillé: commencez par Uptime Kuma. C’est la configuration la plus rapide et couvre la défaillance la plus courante, un service devient inaccessible.
- Si les alertes de temps d’activité ne répondent pas à “pourquoi cela s’est-il produit”: ajoutez Grafana plus Prometheus pour l’historique des métriques derrière les alertes.
- Si une seule boîte a besoin d’une visibilité complète sans configuration: Netdata la fournit en minutes.
- Si Netdata semble trop lourd pour un Raspberry Pi ou une poignée de petits nœuds VPS: Beszel fait le même travail plus légèrement.
- Si la configuration de surveillance doit vivre dans le contrôle de version aux côtés de tout le reste: Gatus.
- Si la pile a grandi au-delà de trois ou quatre outils et que vérifier chacun séparément est le problème réel: Homepage les lie ensemble.
- Si les conteneurs Docker ou Kubernetes sont la couche qui ne cesse d’échouer silencieusement: Portainer CE surveille cette couche directement.
- La plupart des labs maison finissent par exécuter deux ou trois d’entre eux ensemble: Uptime Kuma pour les alertes, Netdata ou Beszel pour l’historique des ressources et Homepage pour voir tout à la fois.
FAQ
Quel est le moniteur de temps d’activité auto-hébergé le plus facile?
Uptime Kuma. Un conteneur Docker unique obtient les moniteurs HTTP, TCP, DNS et les conteneurs en cours d’exécution avec une page de statut et des intégrations de notification en quelques minutes, sans avoir besoin de configurer une base de données de métriques séparée.
Ai-je besoin de Grafana et Prometheus pour un lab maison?
Pas pour commencer. Uptime Kuma ou Netdata couvrent la plupart des besoins d’un lab maison sans la configuration à deux services. Grafana et Prometheus gagnent leur place une fois que les alertes de temps d’activité seules ne répondent plus à ce qui s’est réellement passé, ou quand les métriques doivent être corrélées sur plusieurs services.
Comment Netdata se compare-t-il à Beszel?
Netdata découvre et graphone automatiquement beaucoup plus de la boîte, au prix d’une empreinte plus lourde et d’une invite d’inscription au cloud. Beszel fait moins par conception, un agent plus léger signalant les statistiques de ressources principales via SSH, ce qui convient pour surveiller plusieurs petits serveurs sans ajouter de surcharge à aucun d’entre eux.
Puis-je obtenir des alertes Discord d’Uptime Kuma?
Oui. Discord est l’une de plus de 90 intégrations de notification intégrées, ainsi que Slack, ntfy, Gotify, Telegram, e-mail et webhooks génériques, configurables par moniteur.
Est-ce qu’une partie de cela fonctionne sans Docker?
La plupart de ces applications envoient des images Docker comme distribution principale, mais Uptime Kuma, Netdata, Gatus et Beszel offrent tous également des binaires natifs ou des scripts d’installation bare-metal pour les hôtes Linux qui contournent complètement les conteneurs.
Lequel de ces éléments prévient réellement le problème de “défaillance silencieuse” que XDA a décrit?
Les sept y répondent, mais sous des angles différents. Uptime Kuma et Gatus attrape un service qui devient inaccessible. Netdata, Beszel et Grafana plus Prometheus attrapent l’épuisement des ressources avant qu’il ne cause une panne. Portainer attrape un conteneur coincé dans une boucle de défaillance. Exécuter au moins un outil de temps d’activité et un outil de métriques ensemble couvre les deux modes de défaillance.
