Supervision légère d’un VPS : Beszel vs Netdata vs Uptime Kuma vs Nezha (et quand aucune n’est nécessaire)

15 oct. 2026 · Termalin Team vpslinuxcomparisontoolshomelab

Pour une supervision serveur légère sur un VPS, ou une poignée d’entre eux, la liste honnête est courte, et le bon choix dépend de la question que vous posez. Pour savoir si vos machines se portent bien, prenez Beszel. Pour savoir si les utilisateurs peuvent ouvrir votre site, prenez Uptime Kuma. Pour un tableau de bord d’un parc de VPS réparti sur plusieurs régions, prenez Nezha ; pour une seule machine à l’instant T, Glances ; et pour le détail à la seconde pendant un incident, Netdata. La plupart des gens ont besoin de l’un d’eux, parfois deux, rarement d’une pile d’observabilité complète.

Transparence : nous développons Termalin, l’une des options ci-dessous. Les outils open source sont décrits d’après leur documentation publique, consultée le 15 octobre 2026, et plusieurs d’entre eux l’emportent franchement sur certaines lignes.

Cet article couvre ce que chaque outil surveille, ce que « léger » coûte vraiment, et les points que les premiers résultats oublient : qui surveille le moniteur quand le VPS lui-même tombe, comment éviter que les alertes ne deviennent du bruit, un petit script de secours, et comment superviser une machine sans aucun port ouvert.

La réponse courte : quel outil pour quelle question

Beszel — « vos machines vont-elles bien ? » Un hub et un petit agent par serveur. Métriques système et stats Docker, avec des alertes vers Telegram et d’autres canaux. La référence légère.
Netdata — « que s’est-il passé à cette seconde précise ? » Des métriques à la seconde et un détail poussé par processus. Le plus gourmand en données du lot, et c’est justement son intérêt.
Uptime Kuma — « le monde extérieur peut-il joindre mon service ? » Des contrôles HTTP, TCP, ping et DNS avec des pages de statut. Il ne surveille pas le CPU, la mémoire ni le disque.
Nezha — « comment se porte mon parc de VPS, entre fournisseurs et régions ? » Un tableau de bord façon sonde, avec un terminal web, populaire pour les déploiements multi-régions.
Glances — « que fait cette machine à l’instant même ? » Une vue en direct, comme htop ou btop avec plus d’informations à l’écran. Pas un outil d’alerte.
Termalin — « surveillez mes serveurs et prévenez-moi, sans rien de plus à installer. » La supervision s’appuie sur un Connector d’accès SSH que vous avez déjà. Payant, et avec de vraies limites (plus bas).

Ce que « léger » veut vraiment dire pour la supervision de serveurs

« Léger » se mesure d’habitude à la mémoire de l’agent, et c’est le mauvais chiffre. Comptez l’ensemble :

L’agent sur chaque machine — en général un seul binaire compilé, petit par conception.
Le hub ou le tableau de bord — c’est là que se trouve le poids : une application web, souvent une base de données, qui tourne quelque part qui reste en ligne.
Les ports ouverts — chaque port en écoute est une surface d’attaque dont vous héritez.
Les conteneurs et services à patcher — une chose de plus à tenir à jour, pour toujours.

À cette aune, Beszel (un agent + un conteneur de hub) et Uptime Kuma (un conteneur) sont réellement légers. La collecte à la seconde de Netdata est la plus gourmande du groupe, en CPU comme en stockage — c’est le prix de sa résolution. Et la « grosse pile » classique — Prometheus, plus node_exporter, plus Grafana, plus Alertmanager — représente quatre pièces mobiles à déployer, sécuriser et patcher. Elle est excellente, mais elle n’est pas légère, et pour un à vingt serveurs elle en fait d’ordinaire plus que nécessaire.

Les prétendants

Beszel

Un hub (bâti sur PocketBase) et un petit agent en Go sur chaque serveur. L’agent fonctionne de deux façons : le hub s’y connecte en SSH sur le port 45876, ou bien l’agent appelle le hub vers l’extérieur par un WebSocket muni d’un jeton — le second mode ne demande aucun port entrant et fonctionne derrière un NAT. Il lit les métriques système et les stats des conteneurs Docker, et alerte sur le CPU, la mémoire, le disque, la bande passante, la température et l’état en ligne/hors ligne, vers plus de 25 canaux dont Telegram et ntfy. Sous licence MIT ; la documentation en est à la v0.21 à l’heure où nous écrivons. C’est la référence à battre pour le simple « mes machines sont-elles en forme ? ».

Netdata

Des métriques à la seconde, un tableau de bord en direct très dense et beaucoup de détail automatique par processus et par service. L’agent est gratuit et tourne sans limite sur vos propres hôtes, servant son tableau de bord en local. Netdata Cloud, qui relie les agents entre eux et achemine les notifications, est gratuit sur le palier Community jusqu’à 5 nœuds connectés ; au-delà, c’est Homelab à 90 $/an (illimité, usage raisonnable) ou Business à 4,50 $/nœud/mois facturé annuellement. À sortir quand vous déboguez un pic et qu’une moyenne sur une minute est trop grossière.

Uptime Kuma

Le moniteur de disponibilité auto-hébergé : des contrôles HTTP(s), TCP, mot-clé, ping, DNS, push et conteneur Docker, plus de 90 services de notification et des pages de statut publiques. Environ 92 000 étoiles sur GitHub, licence MIT. Le point à bien comprendre : Uptime Kuma ne collecte pas le CPU, la RAM ou le disque de l’hôte — il surveille si les services répondent, depuis l’extérieur. Cela en fait le partenaire naturel d’un outil de métriques système, pas son remplaçant, et la vraie réponse à « une alternative auto-hébergée à Uptime Kuma » est le plus souvent « associez Kuma à Beszel ».

Nezha

Un tableau de bord et un agent qui rapporte l’état du système, effectue des contrôles HTTP/TCP/ping et d’expiration de certificat, déclenche des alertes, exécute des tâches planifiées et vous donne un terminal web vers chaque hôte. L’agent appelle le tableau de bord vers l’extérieur. C’est le tableau de bord « sonde » de référence pour les VPS dans les communautés sinophones et coréennes, et il brille quand vous avez de nombreux petits VPS chez différents fournisseurs et dans différentes régions et que vous voulez une seule page pour tous.

Glances (et htop/btop)

Glances est une vue en direct d’une seule machine : CPU, mémoire, disque, réseau, processus et plus encore sur un seul écran, en SSH ou via une page web locale optionnelle. Comme htop et btop, il répond à « que fait cette machine à l’instant même » et rien de plus — ni historique, ni véritable alerte. Gardez-le dans votre boîte à outils pour le débogage manuel ; n’attendez pas de lui qu’il vous réveille.

Le tableau comparatif

Outil	Ce qu’il surveille	Alertes et canaux	Port entrant requis ?	Coût	Idéal pour
Beszel	Métriques système + stats Docker	CPU/mém/disque/bande passante/temp/état ; plus de 25 canaux (Telegram, ntfy)	Non en mode WebSocket ; oui (`45876`) en mode SSH	Gratuit, MIT (auto-hébergé)	Santé d’un parc, en léger
Netdata	Métriques système, à la seconde	Alarmes intégrées ; notifications via l’agent ou le Cloud	Tableau de bord local sur `19999` ; le lien vers le Cloud est sortant	Agent gratuit ; Cloud gratuit jusqu’à 5 nœuds, puis 90 $/an ou 4,50 $/nœud/mois	Détail d’incident haute résolution
Uptime Kuma	Disponibilité : HTTP/TCP/ping/DNS/push/conteneurs (pas de métriques système)	Plus de 90 services ; pages de statut	Il va vers les cibles ; vous hébergez son tableau de bord	Gratuit, MIT (auto-hébergé)	Disponibilité externe + pages de statut
Nezha	État système + HTTP/TCP/ping + expiration de certificat	Alertes, tâches planifiées ; terminal web	Les agents appellent le tableau de bord vers l’extérieur	Gratuit (auto-hébergé)	Tableau de bord multi-régions
Glances	Une machine, en direct	Pas un outil d’alerte	Local ; vue web optionnelle	Gratuit (auto-hébergé)	Une seule machine, à l’instant T
Termalin	Métriques système via le Connector (sans second agent)	Alertes à seuils par défaut ; e-mail, push iOS, Telegram, webhook	Non — le Connector est en sortie uniquement	Pro 10 $/mois ou 8 $/mois annuel ; Team 15 $/utilisateur	Santé + alertes sans rien installer

Qui surveille le moniteur quand le VPS meurt ?

Voici l’angle mort de la plupart des comparatifs. Si votre hub ou votre tableau de bord tourne sur le VPS même qu’il surveille, il meurt avec ce VPS — et un serveur mort ne peut pas vous dire qu’il est mort. « Serveur hors ligne » est précisément l’alerte que vous voulez le plus, et elle ne fonctionne que depuis un second point d’observation.

Trois façons d’y remédier :

Un second VPS bon marché, dans un autre lieu, qui exécute le contrôle externe. C’est ce que nous faisons : nous faisons tourner Uptime Kuma sur un VPS séparé et peu coûteux dont le seul rôle est de remarquer quand les machines principales cessent de répondre.
Un vérificateur externe gratuit qui interroge vos endpoints publics depuis l’extérieur de votre réseau.
Un service hébergé dont la logique « est-ce en ligne ? » tourne sur une infrastructure qui n’est pas la vôtre, et qui survit donc à la panne de votre machine.

Quel que soit votre choix, la règle est simple : ce qui détecte « hors ligne » ne doit pas vivre sur la machine qui tombe hors ligne.

Des alertes qui ne vous apprennent pas à les ignorer

Un moniteur qui vous sonne dix fois par heure se retrouve en sourdine en une semaine, et devient alors pire que rien. Les outils sortis de leur boîte sont soit muets jusqu’à ce que vous écriviez des règles, soit bavards jusqu’à ce que vous les régliez. Dans les deux cas, le travail est le même :

Un message quand un problème s’ouvre, un quand il se referme — pas un rappel toutes les cinq minutes.
Le regroupement — plusieurs problèmes dans la même minute arrivent en un seul message ; un problème vraiment critique passe quand même immédiatement.
Pas de répétition le même jour pour le même souci, sauf s’il est critique et persiste.
Un premier jour calme, pour qu’une machine fraîchement surveillée ne vous déverse pas d’un coup toutes ses unités déjà en échec et tous ses certificats déjà expirés.
Une mise en sourdine par type d’alerte et par serveur, pour qu’un contrôle bruyant ne vous oblige pas à tout faire taire.

Et choisissez des seuils qui veulent dire quelque chose : disque à 90 % en avertissement et 95 % en critique, ou dont on prévoit le remplissage dans la journée ; inodes en voie d’épuisement ; un processus tué faute de mémoire (OOM) ; une unité systemd en échec ; un certificat TLS à 14 jours de l’expiration (critique à 3) ; et « hors ligne » seulement après quelques minutes, pour qu’un redémarrage ne soit pas une alarme. Quel que soit l’outil que vous choisissez, ce réglage est le vrai travail de supervision — davantage que le choix de l’outil.

Le filet de secours en dix lignes : une alerte d’espace disque vers Telegram

Avant de déployer quoi que ce soit, vous pouvez couvrir la panne de VPS la plus fréquente — un disque plein — avec cron, df et curl. C’est la réponse à « disk space alert script linux » et « server monitoring telegram alerts » quand vous ne voulez pas encore de tableau de bord.

Gardez les secrets hors du script. Lisez-les depuis l’environnement :

#!/usr/bin/env bash
# disk-alert.sh — warn via Telegram when a filesystem is too full.
set -euo pipefail

: "${TELEGRAM_BOT_TOKEN:?set TELEGRAM_BOT_TOKEN}"
: "${TELEGRAM_CHAT_ID:?set TELEGRAM_CHAT_ID}"
threshold="${DISK_THRESHOLD:-90}"

df -x tmpfs -x devtmpfs --output=pcent,target | tail -n +2 | while read -r pct mount; do
  used="${pct%\%}"
  [ "$used" -ge "$threshold" ] || continue
  curl -fsS --max-time 15 \
    --data-urlencode "chat_id=${TELEGRAM_CHAT_ID}" \
    --data-urlencode "text=$(hostname): ${mount} is ${used}% full" \
    "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" >/dev/null
done

Mettez les vraies valeurs dans un fichier accessible au seul root, jamais dans le script ni dans la crontab :

# /etc/disk-alert.env  — chmod 600, owned by root
export TELEGRAM_BOT_TOKEN=123456789:replace-with-your-bot-token
export TELEGRAM_CHAT_ID=987654321
export DISK_THRESHOLD=90

Puis exécutez-le toutes les quinze minutes avec cron. Enregistrez cette ligne sous /etc/cron.d/disk-alert (ce format, avec un nom d’utilisateur, est destiné aux fichiers de /etc/cron.d/) :

*/15 * * * * root . /etc/disk-alert.env && /usr/local/bin/disk-alert.sh

Elle se répète toutes les quinze minutes tant que le disque reste plein. Pour une alerte de dernier recours, c’est voulu ; si c’est trop bruyant, lancez-la plutôt toutes les heures.

Créez un bot avec @BotFather, envoyez-lui un message pour qu’il puisse vous répondre, et relevez votre chat_id une fois via getUpdates. C’est tout : aucun agent, aucun port, aucun tableau de bord. Ça ne tiendra pas au-delà de quelques machines, mais ça attrapera la panne qui met la plupart des VPS à terre.

Superviser derrière un NAT, un CGNAT, ou sans port ouvert

Une machine derrière un NAT ou un CGNAT ne peut accepter aucune connexion entrante ; tout moniteur qui fonctionne en se connectant à la machine est donc écarté. Ceux qui marchent ont tous la même forme — c’est la machine qui appelle vers l’extérieur :

Beszel en mode WebSocket : l’agent appelle le hub vers l’extérieur, aucun port entrant. (Le mode SSH exige le port entrant 45876, à éviter ici.)
Netdata : le lien de l’agent vers Netdata Cloud est sortant.
Uptime Kuma : utilisez un moniteur push — la machine appelle une URL Kuma à intervalles réguliers, et Kuma alerte quand les appels s’arrêtent.
Termalin : le Connector est en sortie uniquement et n’écoute jamais sur un port.

La technique générale — et pourquoi « laissez-la appeler vers l’extérieur » est la seule réponse sûre pour une machine privée — est détaillée dans SSH derrière un NAT sans redirection de port (en anglais), et la version home lab se trouve dans SSH vers un NAS ou serveur maison.

Où Termalin s’inscrit — et où il ne s’inscrit pas

L’approche de Termalin diffère des outils ci-dessus : il n’ajoute aucun agent de supervision. Si un serveur a déjà un Connector Termalin — le même agent en sortie, sans port entrant, que vous utilisez pour l’accès SSH sans clé — alors il est déjà supervisé. Il n’y a pas de second agent : une fois par minute, Termalin exécute quelques commandes en lecture seule (/proc, df, ps et similaires) par la connexion que le Connector maintient déjà. Le coût pour la machine est de quelques millisecondes de CPU et d’environ un kilo-octet par minute.

Ce qu’il lit, c’est le tableau de santé habituel : le CPU (dont iowait et steal), la charge et la pression, la mémoire et le swap, l’espace disque et les inodes, les E/S disque et réseau, les sockets et les fichiers ouverts, les processus, les conteneurs, les services en échec, les connexions SSH échouées, les mises à jour de sécurité en attente, les ports en écoute, et les certificats TLS avec le nombre de jours avant expiration. Les alertes fonctionnent avec des seuils par défaut et aucune règle à écrire, et elles sont conçues pour rester discrètes : une fois à l’entrée, une fois à la sortie, regroupées, sans répétition le même jour, un premier jour calme, et une mise en sourdine par type d’alerte. Elles partent par e-mail, push iOS, Telegram (un geste pour connecter le bot) et un webhook que Slack et Discord acceptent, signé avec HMAC-SHA256. L’historique est de 90 jours sur Pro et de deux ans sur Team.

Parce qu’un assistant IA peut lire les mêmes données via l’endpoint MCP hébergé de Termalin (server_metrics et alerts_list), vous pouvez aussi simplement demander « comment vont mes serveurs ? » dans Claude ou ChatGPT et obtenir la réponse à partir des données collectées. Dans le terminal web, sélectionnez une erreur dans la sortie et choisissez « Expliquer la sélection » : l’assistant rédige un court diagnostic en langage clair et termine par quelques commandes de vérification en lecture seule qu’un bouton saisit pour vous dans la session. Le tableau complet est sur la page supervision de serveurs.

Maintenant les limites assumées, car les outils open source le battent sur plusieurs d’entre elles :

Aucun contrôle de disponibilité externe et aucune page de statut. C’est un outil de métriques système et d’alertes, pas un moniteur de disponibilité — Uptime Kuma le complète toujours utilement.
Aucune collecte de journaux et aucune métrique personnalisée. Ce n’est pas un remplaçant de Grafana/Prometheus.
Les tableaux de bord sont pour l’instant dans l’espace web uniquement, pas dans l’application de bureau — même si celle-ci affiche bien le CPU, la mémoire et le disque d’un hôte connecté en direct dans sa barre de statistiques et dans la grille de surveillance (en anglais).
Pas de chiffrement de bout en bout — ces chiffres sont stockés sous une forme que le service peut lire, parce qu’il doit les lire pour tracer les graphiques et déclencher les alertes.
Pas sur le forfait Free. Il faut un Connector, qui fait partie de Pro (10 $/mois, ou 8 $/mois facturé annuellement — 96 $/an) et de Team (15 $ par utilisateur), avec un essai Pro de 14 jours sans carte bancaire.

Si « gratuit et auto-hébergé » est une exigence ferme, Beszel ou Uptime Kuma est votre réponse, et c’est un choix tout à fait valable. Le cas de Termalin est plus étroit : vous l’utilisez déjà pour l’accès SSH, et vous préféreriez ne pas monter puis materner une pile de supervision séparée juste pour avoir des graphiques de santé et des alertes sensées.

Recommandations selon le cas

Un VPS de loisir. Beszel pour la santé, ou simplement le script cron ci-dessus si tout ce que vous craignez est un disque plein. Ajoutez Uptime Kuma plus tard si vous hébergez un site public.
5 à 20 VPS chez plusieurs fournisseurs (Hetzner, Contabo, Hostinger, un ou deux droplets). Beszel pour les métriques, plus Uptime Kuma pour la disponibilité, avec l’instance Kuma sur une machine à part. Si vous préférez un seul tableau de bord avec un terminal web, Nezha. Si vous utilisez déjà Termalin pour le SSH, activez sa supervision et faites l’économie de la pile supplémentaire.
Un home lab derrière un CGNAT. Tout ce qui est en sortie uniquement : Beszel en mode WebSocket, Netdata vers le Cloud, ou un moniteur push Kuma — voyez le guide SSH derrière un NAT (en anglais).
« Je veux que mon assistant IA réponde à ‘comment vont mes serveurs’. » C’est le cas Termalin : les mêmes données qu’un humain voit, lues par l’agent via MCP.

Questions fréquentes

Netdata est-il gratuit ? L’agent est gratuit et tourne sans limite sur vos propres hôtes, avec son propre tableau de bord local. Le palier Community de Netdata Cloud est gratuit jusqu’à 5 nœuds connectés ; au-delà, c’est Homelab à 90 $/an ou Business à 4,50 $/nœud/mois facturé annuellement.

Uptime Kuma surveille-t-il le CPU, la mémoire ou le disque ? Non. Uptime Kuma vérifie si les services répondent — HTTP, TCP, ping, DNS, conteneurs et push — depuis l’extérieur. Pour le CPU, la RAM et le disque de l’hôte, associez-le à Beszel, Netdata ou Termalin.

Beszel vs Netdata — lequel est le plus léger ? Beszel. C’est un petit agent par machine plus un hub unique. Netdata collecte à la seconde et est le plus gourmand du groupe ; on le choisit pour sa résolution, pas pour sa légèreté.

Quelle est la meilleure supervision VPS gratuite avec alertes Telegram ? Pour la santé des hôtes, Beszel envoie vers Telegram et s’auto-héberge gratuitement. Pour la disponibilité, Uptime Kuma aussi. Pour une solution de dépannage sans installation, le script cron + curl ci-dessus envoie directement vers Telegram sans rien faire tourner en arrière-plan.

Comment superviser un VPS derrière un NAT ou sans port ouvert ? Utilisez un outil où la machine appelle vers l’extérieur : Beszel en mode WebSocket, l’agent Netdata vers le Cloud, un moniteur push Kuma, ou un Connector Termalin. Aucun d’eux n’a besoin d’un port entrant. Voyez SSH derrière un NAT sans redirection de port (en anglais).

Termalin est un client SSH multiplateforme ; sur Pro et Team, chaque serveur doté d’un Connector est supervisé avec des graphiques et des alertes à seuils par défaut, et rien de plus n’est installé sur la machine — voyez la supervision de serveurs ou téléchargez-le.