Beszel sur VPS : supervision multi-serveurs, alertes et sécurité

Pourquoi Beszel trouve le juste équilibre pour l'auto-hébergement

Grafana + Prometheus est le standard du secteur, mais s'accompagne d'une mise en place lourde : exporters, configuration Prometheus, sources de données Grafana, tableaux de bord. Uptime Kuma excelle pour les contrôles de disponibilité mais ne fournit pas de métriques de ressources. Netdata est riche en données mais consomme davantage de RAM par nœud et nécessite un compte cloud pour agréger plusieurs hôtes. Beszel se situe entre les deux : métriques de ressources complètes (CPU, RAM, disque, bande passante, températures), stats Docker par conteneur, graphiques historiques et alertes sur seuil — le tout déployé en une seule commande Docker, sans aucun fichier de configuration.

Le hub repose sur PocketBase, ce qui signifie un unique binaire Go avec une base de données embarquée. Pas de Postgres ni de Redis séparés. Aucun YAML à écrire. La contrepartie : Beszel ne permet pas les requêtes personnalisées ni les tableaux de bord libres comme Prometheus/Grafana — pour superviser les ressources d'un parc de serveurs, il est plus rapide à prendre en main et plus simple à maintenir.

Uptime Kuma · Beszel · Netdata — tableau comparatif

Critère	Uptime Kuma	Beszel	Netdata
Métriques de ressources	Non (sonde HTTP/TCP uniquement)	Oui (CPU, RAM, disque, bande passante, temp.)	Oui (très détaillé)
Multi-serveurs sans compte cloud	Oui (une instance par serveur)	Oui (hub unique, agents sans limite)	Partiel (room cloud nécessaire pour agréger)
Consommation RAM hub	< 100 Mo	< 50 Mo	300–500 Mo par nœud
Stats Docker par conteneur	Non	Oui (automatique)	Oui
Configuration requise	Interface web	Zéro fichier	Zéro fichier
Export Prometheus	Non (natif)	Non natif (via `/metrics` expérimental)	Oui (natif)

Ce que vous obtenez d'emblée

Métriques CPU, RAM, disque, bande passante et température mises à jour toutes les 15 secondes.
Stats Docker par conteneur — CPU, RAM et réseau pour chaque conteneur, détectés automatiquement.
Graphiques historiques aux résolutions horaire, quotidienne et mensuelle, sans limite de rétention.
Alertes sur seuil envoyées vers Telegram, Slack, e-mail, Discord, ntfy, PagerDuty et bien d'autres.
Multi-serveurs : un seul hub, un parc d'agents sans limite — pas de frais par serveur ni de fonctionnalités payantes.
Les agents se connectent vers le hub en sortie — aucune règle de pare-feu entrante nécessaire sur les serveurs supervisés.
Licence MIT — totalement open-source, auto-hébergé, sans dépendance au cloud.

Prérequis

Le hub est exceptionnellement léger. Il tourne sans peine sur un VPS de 512 Mo / 1 vCPU — de fait, il trouve sa place aux côtés d'autres services sur votre plus petit serveur. Prévoyez 5 à 10 Go de disque pour le répertoire de données PocketBase, qui grossit lentement à mesure que les métriques historiques s'accumulent. Les agents sont encore plus légers : quelques Mo de RAM chacun. Vous pouvez superviser plus de 20 serveurs sans que le hub ne bronche sur un VPS de 1 Go.

Dépendances : Docker installé sur le hub (pour le conteneur du hub) et sur chaque serveur supervisé (pour l'agent en mode conteneur). Une alternative binaire sans Docker existe pour les agents — consultez la documentation officielle pour cette variante.

Déployer le hub et ajouter plusieurs agents

Démarrer le hub

Sur le VPS dédié à la supervision :

docker run -d --restart=always \
  -p 8090:8090 \
  --name beszel \
  -v /opt/beszel:/beszel_data \
  henrygd/beszel:latest

Le hub démarre immédiatement — aucune variable d'environnement ni fichier de configuration requis.

Créer le compte administrateur

Ouvrez http://<hub-ip>:8090. Le premier visiteur voit l'assistant PocketBase qui crée le compte administrateur (e-mail + mot de passe fort). Ce compte contrôle l'intégralité du tableau de bord — choisissez un mot de passe solide, vous activerez le 2FA à l'étape suivante.

Activer le 2FA sur le compte administrateur

Dans PocketBase, allez dans Settings → Admins, ouvrez votre profil et activez l'authentification à deux facteurs (TOTP). Scannez le QR code avec un gestionnaire de codes (Aegis, Authy, 1Password). À partir de là, toute connexion exige le code temporaire en plus du mot de passe.

Placer le hub derrière un reverse proxy HTTPS

Pointez un sous-domaine (par exemple monitor.votre-domaine.com) vers le VPS du hub. Avec Caddy :

apt install -y caddy

Contenu de /etc/caddy/Caddyfile :

monitor.votre-domaine.com {
  reverse_proxy localhost:8090
}

Caddy provisionne le certificat TLS automatiquement. Fermez ensuite le port 8090 dans votre pare-feu — tout l'accès passe par 443 :

ufw delete allow 8090
ufw allow 443

Ajouter chaque serveur supervisé

Dans Beszel, cliquez sur Add system, saisissez un nom et l'IP ou le nom d'hôte du serveur (port 45876). Le hub génère une clé publique propre à ce système — copiez-la.

Installer l'agent sur chaque serveur supervisé

Sur chaque serveur à superviser :

docker run -d --restart=always \
  --network host \
  --name beszel-agent \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -e KEY="<clé-copiée-depuis-le-hub>" \
  henrygd/beszel-agent:latest

L'agent établit une connexion sortante vers le hub sur le port 45876 — aucun port entrant à ouvrir sur le serveur supervisé. Les métriques apparaissent dans le tableau de bord en quelques secondes.

Configurer les alertes Telegram et e-mail

Dans les réglages Beszel, ouvrez l'onglet Notifications et cliquez sur Add notification.

Telegram (canal recommandé pour sa rapidité) : créez un bot via @BotFather pour obtenir un token, puis récupérez votre chat_id en envoyant un message au bot et en appelant https://api.telegram.org/bot<token>/getUpdates. Collez le token et le chat ID dans le formulaire. Un message de test confirme la connexion.

E-mail (SMTP) : renseignez l'hôte SMTP, le port (587 pour STARTTLS), le nom d'utilisateur, le mot de passe et l'adresse de destination. Sur chaque système supervisé, définissez ensuite des seuils d'alerte : par exemple, alerte dès que l'utilisation du disque dépasse 80 %, ou que la RAM reste au-dessus de 90 % pendant 5 minutes. Plusieurs canaux peuvent coexister — Telegram pour les alertes urgentes, e-mail pour les récapitulatifs.

Dépannage — agent silencieux, TLS rejeté, port bloqué

L'agent n'apparaît pas dans le tableau de bord. Vérifiez d'abord que l'agent tourne réellement : docker logs beszel-agent. Un message connection refused indique que le port 45876 est bloqué sur le hub — ouvrez-le dans ufw du côté hub uniquement (les agents, eux, n'ont pas besoin d'ouvrir de port entrant) :

ufw allow 45876/tcp

Si les logs montrent une erreur TLS comme certificate signed by unknown authority, c'est que le hub est exposé avec un certificat auto-signé ou un certificat d'une CA non reconnue. Deux solutions : utiliser un certificat Let's Encrypt valide (chemin recommandé via Caddy), ou passer la variable AGENT_SKIP_TLS_VERIFY=true à l'agent (à éviter en production).

Le hub est derrière un reverse proxy mais les agents ne se connectent pas. Le port 45876 est un port TCP direct (pas HTTP) : le reverse proxy Caddy ou nginx ne le proxifie pas de la même façon qu'une requête web. La solution est d'exposer le port 45876 directement sur le hub (pas via le proxy) et de ne mettre que l'interface web (8090) derrière le proxy HTTPS. Autorisez le port 45876 dans votre pare-feu et assurez-vous que le groupe de sécurité de votre VPS l'autorise en TCP entrant depuis les IP de vos agents.

Métriques Docker absentes. L'agent doit avoir accès au socket Docker. Vérifiez que /var/run/docker.sock est monté en lecture seule dans la commande de démarrage de l'agent.

Sécuriser le hub

Un hub de supervision agrège des données sensibles (charge, disque, topologie réseau interne). Quelques mesures essentielles :

Accès restreint au tableau de bord. Après l'activation du 2FA, ajoutez une couche de restriction IP ou une authentification HTTP basique au niveau du reverse proxy si le hub n'est accessible qu'à une équipe restreinte. Avec Caddy :

monitor.votre-domaine.com {
  basicauth {
    <utilisateur> <hash-bcrypt>
  }
  reverse_proxy localhost:8090
}

Port 45876 non exposé publiquement. Si tous vos agents sont sur des VPS du même fournisseur et partagent un réseau privé, configurez le hub pour écouter sur l'IP privée uniquement et bloquez 45876 sur l'IP publique. Sinon, restreignez ce port aux IP connues de vos agents dans ufw.

Sauvegardes du répertoire de données. Le dossier /opt/beszel contient la base PocketBase et l'historique de métriques. Incluez-le dans votre routine de sauvegarde — une restauration après sinistre est immédiate si la sauvegarde est à jour.

Export vers Prometheus — pour aller plus loin

Si vous avez déjà une stack Prometheus/Grafana et souhaitez centraliser toutes vos métriques, Beszel expose un endpoint expérimental /metrics au format Prometheus sur le hub. Activez-le dans les réglages avancés et ajoutez un scrape job dans votre prometheus.yml :

scrape_configs:
  - job_name: beszel
    static_configs:
      - targets: ['monitor.votre-domaine.com']
    scheme: https
    metrics_path: /metrics
    basic_auth:
      username: '<utilisateur>'
      password: '<mot-de-passe>'

Ce n'est pas la voie principale de Beszel — si Prometheus/Grafana est déjà en place, vous n'avez peut-être pas besoin de Beszel du tout. Mais pour une équipe qui veut les deux tableaux de bord, c'est une passerelle utile.

Faites tourner le hub Beszel sur un VPS distinct de votre stack principale. Quand votre serveur de production est hors service, vous voulez que le système de supervision soit toujours debout et continue d'envoyer des alertes — pas qu'il tombe en même temps. L'empreinte minuscule du hub en ressources permet de justifier un VPS dédié de 512 Mo pour la supervision sans avoir l'impression de gaspiller de l'argent.

La documentation officielle

Pour la configuration avancée et les options propres à l'outil, référez-vous à la documentation officielle de Beszel. Ce guide couvre la mise en ligne sur VPS et les cas courants ; la doc éditeur reste la référence pour les mises à jour majeures et les réglages fins.