XDA a couvert cet mois un outil de lab maison appelé Pulse, et la moitié de r/selfhosted a passé la semaine à arracher Uptime Kuma de leurs configurations Proxmox, Docker et TrueNAS pour l’essayer. Uptime Kuma reste l’outil que nous recommandons à quiconque configure une première page de statut. Il s’installe en une commande Docker, l’UI a du sens en cinq minutes, et le compte de monitors gratuits est généreux.
Cependant, une fois que nous avons dépassé une trentaine de vérifications, les limites sont apparues rapidement. Nœud unique, pas de clustering, pas d’endpoint Prometheus natif, et les types de vérification sont essentiellement du ping et de l’HTTP. Si nous voulions des graphiques de CPU, mémoire ou disque par hôte, nous devions brancher un second outil. Le tableau de bord est fonctionnel, pas quelque chose que nous voulons projeter sur un mur.
Nous avons testé sept alternatives auto-hébergées sur Debian 12, Docker Compose, et un petit cluster Proxmox. Voici comment elles se comparent.
Comparaison rapide
| Application | Idéale pour | Plan gratuit | Prix de départ | Caractéristique distinctive |
|---|---|---|---|---|
| Pulse | Proxmox + Docker + TrueNAS dans un seul tableau de bord | Entièrement gratuit | Gratuit (donations) | Tableau de bord unifié pour lab maison |
| Beszel | Utilisateurs Kuma qui veulent des métriques d’hôte | Entièrement gratuit | Gratuit | Petit agent Go, UI élégante |
| Gatus | Vérifications de santé définies en YAML | Entièrement gratuit | Gratuit | Vérifications d’endpoints en code |
| Statping-ng | Pages de statut publiques | Entièrement gratuit | Gratuit | Page de statut themable |
| Checkmk Raw | Flottes de 50+ nœuds | Entièrement gratuit (Raw) | Environ $600/an (Enterprise) | Écosystème de plugins profond |
| Zabbix | Profondeur entreprise avec un budget maison | Entièrement gratuit | Gratuit (support payant) | N’importe quelle métrique, n’importe quel déclencheur |
| Netdata | Dépannage en temps réel | Entièrement gratuit (auto-hébergé) | Environ $3/nœud/mois (Cloud) | Résolution à la seconde |
Pourquoi les labs maison dépassent Uptime Kuma
Le schéma apparaît dans les mêmes fils de forum chaque mois. Quelqu’un publie un tableau de bord avec cinquante monitors, mentionne que sa base de données SQLite se bloque lors des balayages ping, et demande sur quoi passer. La couche de stockage de Kuma n’a pas été conçue pour les écritures haute fréquence sur plusieurs vérifications, et il n’y a pas d’option de clustering pour répartir la charge.
L’écart plus important concerne la portée. Kuma sonde les services de l’extérieur. Elle ne peut pas nous dire que le pool ZFS du nœud Proxmox est à 87 pour cent, qu’un hôte Docker fait de la pagination, ou que la carte SD Raspberry Pi lance des erreurs de lecture. Ce sont des faits au niveau du hôte, et les obtenir nécessite un agent s’exécutant sur la machine, que Kuma n’a jamais livré.
Les notifications sont la troisième accroche. Kuma couvre les bases (Discord, Telegram, email, webhooks génériques), mais il n’y a pas de concept de règles, silences ou rotation d’astreinte. Si nous voulons pager quelqu’un de spécifique entre 22:00 et 06:00 uniquement quand trois vérifications échouent d’affilée, nous finissons par écrire cette logique dans un récepteur webhook.
Enfin, pas de Prometheus scrape de première classe. Il y a un endpoint communautaire, mais si notre stack exécute déjà Grafana au-dessus de Prometheus, nous voulons généralement que l’outil de monitoring expose les métriques nativement.
Les alternatives
Pulse, le choix de XDA qui a unifié notre lab maison
Pulse est l’outil qui a illuminé r/selfhosted ce mois. Il cible exactement la configuration que la plupart des labs maison exécutent (un ou deux hôtes Proxmox, une boîte Docker, et un TrueNAS ou Synology pour le stockage) et met tout cela sur un écran. Les VMs, conteneurs, LXC, santé des pools et charge des nœuds sont côte à côte sans construction de tableau de bord manuel.
La configuration est un unique fichier Docker Compose. Nous la pointons vers un token API Proxmox et un socket Docker, et en une minute nous avons des comptages en direct, des graphiques de ressources par VM, et le statut du conteneur. Sur un cluster Proxmox de trois nœuds avec environ quarante conteneurs, le tableau de bord restait réactif et inactif autour de 90 MB de RAM.
Où elle est courte : Pulse est jeune. Les pages de statut publiques, la rétention historique au-delà de quelques semaines, et les règles d’alerte sont encore légères. C’est d’abord un tableau de bord de lab maison, deuxièmement une plateforme d’alerting.
Tarification : Gratuit et open source (les donations sont bienvenues).
vs Uptime Kuma : Kuma nous montre qu’une URL est up. Pulse nous montre que la VM derrière l’URL a 4 GB de libre et le pool ZFS est sain. Des travaux différents.
Télécharger : https://github.com/rcourtman/Pulse
En résumé : Si nous exécutons Proxmox plus Docker, installez Pulse ce week-end.
Beszel, la jolie Kuma avec un agent
Beszel est ce qui se passe quand quelqu’un aime l’interface épurée de Kuma mais a besoin de métriques d’hôte. Elle est livrée comme deux petits binaires Go (un hub et un agent), pas de dépendances runtime, et l’UI web est genuinely sympa. Les graphiques pour CPU, mémoire, disque, réseau, et stats de conteneur Docker sont tous built-in.
Nous avons exécuté l’agent sur six machines, un mélange x86 et ARM. Chaque agent utilisait moins de 20 MB de RAM. Ajouter un système au hub était un échange de clé copier-coller, pas de fichiers de configuration pénibles.
Où elle est courte : Beszel ne fait pas du monitoring d’endpoint HTTP comme Kuma le fait. Elle observe les hôtes et conteneurs, pas les URLs distantes. Les intégrations de notification sont encore en croissance (Discord, Telegram, email, webhook générique, SMTP), mais le templating n’est pas aussi riche que Gatus.
Tarification : Gratuit et open source.
vs Uptime Kuma : Kuma ping les services de l’extérieur. Beszel rapporte ce qui se passe à l’intérieur du hôte. Beaucoup de labs finissent par exécuter les deux.
Télécharger : https://beszel.dev
En résumé : Le plus joli moniteur d’hôte auto-hébergé que nous avons testé cette année.
Gatus, vérifications YAML et règles d’alerte sérieuses
Gatus retourne le modèle. Au lieu de cliquer dans une UI pour ajouter des monitors, nous décrivons chaque endpoint dans un fichier YAML, le commitons dans Git, et Gatus recharge au changement. Le langage de condition est expressif : temps de réponse, code de statut, assertions de corps JSON, expiration TLS, DNS, ICMP, TCP, et plus.
L’alerting est où Gatus se distingue. Slack, Teams, Discord, PagerDuty, Opsgenie, Gotify, ntfy, et Matrix sont tous de première classe, et chaque endpoint peut avoir ses propres seuils d’alerte et cooldowns. Nous avons poussé une config de taille moyenne avec environ soixante-dix vérifications pendant le test et le CPU est resté sous deux pour cent.
Où elle est courte : Le tableau de bord est minimaliste. Si nous voulons une page de statut publique themable, Gatus n’est pas l’outil. Elle stocke aussi l’historique dans une base de données que nous devrions sauvegarder séparément.
Tarification : Gratuit et open source.
vs Uptime Kuma : Kuma c’est UI-first, Gatus c’est config-first. Si notre monitoring appartient dans un repo Git, Gatus gagne.
Télécharger : https://gatus.io
En résumé : Pour quiconque exécute déjà l’infrastructure en tant que code, c’est l’ajustement naturel.
Statping-ng, une page de statut publique faite correctement
Statping-ng a repris là où le Statping original s’est endormi. Son focus c’est la page de statut public, celle que nous montrons à nos clients, famille, ou coéquipiers quand quelque chose est en panne. Les thèmes sont interchangeables, les incidents peuvent être postés du panneau admin, et tout s’affiche vite même sur un petit VPS.
Nous l’avons mis en place sur un droplet à $5 avec environ quinze services et l’empreinte mémoire tenait autour de 60 MB. Les notifications couvrent les platforms de chat et email habituelles.
Où elle est courte : Le moteur de vérification interne n’est pas aussi flexible que Gatus, et les métriques d’hôte sont en dehors de sa portée. Sous le capot, les releases ont été stables mais pas fréquentes, ce qui importe si nous devons savoir qu’une CVE est patchée rapidement.
Tarification : Gratuit et open source.
vs Uptime Kuma : La page de statut de Kuma c’est bien pour un lab maison. Statping-ng c’est celle à donner aux utilisateurs payants.
Télécharger : https://github.com/statping-ng/statping-ng
En résumé : L’outil à utiliser quand la page de statut elle-même est le produit.
Checkmk Raw, quand la flotte devient sérieuse
Checkmk Raw est l’édition gratuite d’une plateforme de monitoring commerciale complète. Cet héritage se voit partout : des centaines de plugins built-in, découverte d’agent automatique, monitoring distribué, corrélation d’événements, et un marketplace de plugins avec intégrations communautaires et signées par les vendors. Sur le papier c’est le plus proche que nous obtenons du monitoring entreprise sans payer.
Nous avons exécuté l’image Docker contre une petite flotte mixte (Linux, Windows, un switch réseau via SNMP, et un cluster Kubernetes) et Checkmk a tiré environ 400 services automatiquement. Une fois que nous avons réglé la découverte, le bruit a baissé et les tableaux de bord étaient utilisables.
Où elle est courte : La courbe d’apprentissage est réelle. L’UI porte beaucoup de patterns hérités, et Raw manque les beaux tableaux de bord opérateurs, les rapports, et le contrôle d’accès basé sur les rôles que les éditions payantes livrent.
Tarification : L’édition Raw est gratuite à jamais. Les éditions Cloud et Enterprise commencent autour de $600 par an pour des petites configurations.
vs Uptime Kuma : Kuma est un tournevis, Checkmk est un atelier.
Télécharger : https://checkmk.com
En résumé : Ça vaut l’effort d’apprentissage une fois que nous dépassons environ cinquante nœuds.
Zabbix, profondeur entreprise sans facture
Zabbix existe depuis assez longtemps pour avoir monitoré notre premier rack de serveurs. C’est entièrement gratuit, incluant les features entreprise (monitoring distribué, proxies HA, chiffrement partout, RBAC granulaire), et les plans payants achètent du support, pas des features. N’importe quelle métrique peut déclencher n’importe quelle action, et le langage de déclencheur est genuinely puissant.
Nous avons testé Zabbix 7 contre une flotte mixte. L’agent est mature et léger, la découverte automatique fonctionnait out of the box pour les appareils réseau, et les templates pour Docker, Kubernetes, PostgreSQL, Redis, et la plupart des bases de données sont officiels.
Où elle est courte : L’UI par défaut est datée comparée à Beszel ou Netdata. Mettre en place des tableaux de bord frontend demande de l’effort, et beaucoup d’équipes finissent par envoyer les données Zabbix à Grafana pour l’expérience de visualisation réelle.
Tarification : Gratuit. Des niveaux de support payants existent pour les équipes qui ont besoin d’SLAs.
vs Uptime Kuma : Kuma couvre les labs maison de week-end. Zabbix couvre les datacenters.
Télécharger : https://zabbix.com
En résumé : Si un lab maison a grandi vers une petite entreprise, Zabbix c’est le pari sûr à long terme.
Netdata, métriques temps réel avec une UI par défaut superbe
Le pitch de Netdata c’est une résolution à la seconde sur chaque métrique, avec des tableaux de bord qui ont l’air superbes avant que nous touchions à un seul réglage. L’agent s’exécute sur l’hôte, collecte tout du jitter CPU aux requêtes Postgres, et expose une UI web locale immédiatement après l’installation. C’est le moyen le plus rapide de voir, là maintenant, pourquoi une machine se sent lente.
La topologie parent-enfant auto-hébergée nous permet d’agréger beaucoup d’agents vers un nœud central sans payer pour Netdata Cloud. Cela dit, Cloud c’est où vivent les vues multi-nœud, les tableaux de bord sauvegardés, et les alertes mobiles, et pour les petites équipes ce n’est pas cher.
Où elle est courte : La rétention du côté free auto-hébergé est limitée par le disque. Le stockage à long terme signifie soit envoyer à Prometheus soit upgrader vers Cloud. L’alerting existe mais c’est per-agent, donc tuner une grande flotte c’est plus lent que Gatus ou Zabbix.
Tarification : Entièrement gratuit auto-hébergé. Les niveaux payants Netdata Cloud commencent autour de $3 par nœud par mois.
vs Uptime Kuma : Kuma nous dit que quelque chose ne va pas. Netdata nous dit quel processus sur quel core le fait.
Télécharger : https://netdata.cloud
En résumé : L’outil que nous ouvrons en premier quand une machine malfonctionnne là maintenant.
Comment choisir
Choisissez Pulse si nous exécutons Proxmox et Docker et voulons un tableau de bord pour VMs, conteneurs, et santé du pool. C’est le moyen le plus facile de consolider un petit lab, et la configuration prend une soirée.
Choisissez Beszel si nous aimons la simplicité de Kuma mais avons besoin de graphiques CPU, RAM, et disque basés sur agents. C’est le remplacement le plus proche en sensation, avec une meilleure couche graphique.
Choisissez Gatus pour l’alerting le plus strict basé en YAML. Si notre infra est déjà dans Git, ajouter un monitor devrait être une pull request, pas un clic.
Choisissez Statping-ng si la page de statut c’est le point. Les clients, coéquipiers, ou membres de la famille voient une timeline d’incident propre, pas notre tableau de bord interne.
Choisissez Checkmk Raw si nous gérons plus de cinquante nœuds et voulons la couverture de plugins qui scale sans écrire des vérifications personnalisées. L’apprentissage est réel, et ça s’amortit une fois que la flotte est grande.
Choisissez Zabbix pour la profondeur entreprise sans facture. C’est l’option free la plus complète, et elle a le plus long track record dans cette liste.
Choisissez Netdata pour le dépannage temps réel et les superbes tableaux de bord par défaut. Elle complète bien les autres, donc beaucoup de labs l’exécutent à côté de Gatus ou Beszel.
Restez sur Uptime Kuma si nous avons moins de 30 vérifications et besoin seulement du monitoring HTTP ou ping. C’est toujours le chemin le plus rapide vers une page de statut fonctionnelle, et les coûts de switch sont réels. Bougez seulement quand une limite spécifique (métriques d’agent, règles d’alerte, count de nœuds, polish de tableau de bord) bloque le lab.
Questions fréquemment posées
Quelle est la meilleure alternative gratuite à Uptime Kuma ?
Pulse et Beszel sont les deux que nous recommandons le plus souvent. Pulse gagne pour les labs Proxmox et Docker qui veulent un seul panneau de verre. Beszel gagne pour quiconque veut la simplicité de Kuma plus les métriques d’hôte réelles. Les deux sont entièrement gratuits et open source.
Uptime Kuma supporte-t-il le monitoring basé agents ?
Non. Uptime Kuma vérifie les services de l’extérieur, utilisant HTTP, ping, port TCP, DNS, et sondes similaires. Il n’y a pas d’agent s’exécutant sur l’hôte cible pour rapporter CPU, mémoire, ou disque. Pour cela nous avons besoin de Beszel, Netdata, Checkmk, ou Zabbix.
Uptime Kuma peut-elle monitorer Proxmox ?
Seulement indirectement. Nous pouvons pointer Kuma vers l’UI web Proxmox ou les endpoints d’API et confirmer qu’ils répondent, mais Kuma ne peut pas rapporter la charge CPU per-nœud, le count de VM, l’usage de stockage, ou la santé du pool ZFS. Pulse est construite exactement pour ce travail.
Quel outil de monitoring auto-hébergé a le plus joli tableau de bord ?
Beszel et Netdata sont les deux vers lesquels nous pointons les gens pour l’apparence. L’UI de Beszel se sent comme une Kuma affinée avec des graphiques. Les animations à la seconde de Netdata n’ont pas d’égal pour démontrer à quoi ressemble un serveur sain. Pulse est proche derrière et s’améliore vite.
Zabbix c’est-il excessif pour un lab maison ?
Généralement, oui. Zabbix est conçu pour des centaines ou milliers d’hôtes, et l’effort de setup le reflète. Pour un lab maison d’environ vingt machines, Beszel, Pulse, ou Netdata vont donner un meilleur ratio d’insight au temps investi. Zabbix s’amortit quand nous passons en territoire petite entreprise.
