Stack monitoring proactif VPS : Beszel + Uptime Kuma v2

Pourquoi surveiller proactivement, et pourquoi les outils classiques ne suffisent pas

Ce que cette stack apporte concrètement à une agence

• Vue unifiée de tous vos serveurs clients dans une seule interface Beszel, sans multiplier les accès SSH.
• Alertes métriques (CPU, RAM, disque, réseau) configurables par seuil sur chaque hôte du parc.
• Vérification de disponibilité HTTP(s), TCP, DNS, certificats SSL via Uptime Kuma v2 — un check toutes les 60 secondes par défaut.
• Notifications Telegram ou SMTP opérationnelles dès la première heure, sans abonnement tiers.
• Détection d'une saturation disque ou d'une fuite mémoire avant qu'elle ne bloque un service applicatif.
• Page de statut publique Uptime Kuma partageables avec les clients finaux.
• Consommation totale de la stack inférieure à 150 Mo de RAM sur le VPS de supervision.
• Déploiement reproductible via Docker Compose, versionnable et redéployable en quelques minutes.

Prérequis chiffrés

Déploiement complet : Beszel hub, agents, Uptime Kuma v2 et alertes

1. 01

   Créer la structure Docker Compose sur le VPS de supervision

   Connectez-vous au VPS dédié à la supervision. Créez un répertoire de travail et le fichier Compose :

   mkdir -p /opt/monitoring && cd /opt/monitoring

   Créez le fichier docker-compose.yml avec les deux services :

   services:
     beszel:
       image: henrygd/beszel:latest
       restart: unless-stopped
       volumes:
         - ./beszel_data:/beszel_data
       ports:
         - "8090:8090"
       environment:
         - DATA_DIR=/beszel_data
   
     uptime-kuma:
       image: louislam/uptime-kuma:2
       restart: unless-stopped
       volumes:
         - ./uptime-kuma-data:/app/data
       ports:
         - "3001:3001"
       healthcheck:
         test: ["CMD", "node", "extra/healthcheck"]
         interval: 30s
         timeout: 10s
         retries: 3

   Notez le bloc healthcheck sur Uptime Kuma : il est indispensable pour éviter le piège du crash-loop (voir la section « Pièges »).

2. 02

   Démarrer la stack et créer les comptes administrateurs

   Lancez les deux conteneurs :

   docker compose up -d

   Vérifiez que les deux conteneurs sont en état healthy ou running :

   docker compose ps

   Accédez à Beszel sur http://<ip-vps>:8090 et créez le compte administrateur lors du premier accès. Faites de même pour Uptime Kuma sur http://<ip-vps>:3001. Ces deux interfaces doivent ensuite être placées derrière un reverse proxy (nginx ou Caddy) avec SSL pour ne pas les exposer en HTTP.

3. 03

   Déployer l'agent Beszel sur chaque VPS à superviser

   Sur chaque VPS client à surveiller, copiez la clé publique générée dans l'interface Beszel (Paramètres → Clé SSH), puis exécutez :

   curl -sL https://raw.githubusercontent.com/henrygd/beszel/main/supplemental/scripts/install-agent.sh | bash -s -- -p 45876 -k "<votre-cle-publique>"

   Alternativement, utilisez Docker sur l'hôte supervisé :

   services:
     beszel-agent:
       image: henrygd/beszel-agent:latest
       restart: unless-stopped
       network_mode: host
       volumes:
         - /var/run/docker.sock:/var/run/docker.sock:ro
       environment:
         - KEY=<votre-cle-publique>
         - PORT=45876

   Dans Beszel, ajoutez chaque hôte depuis l'interface (Systèmes → Ajouter un système) en indiquant son IP et le port de l'agent. La connexion est établie par le hub vers l'agent : l'hôte supervisé n'a pas besoin d'exposer ce port publiquement.

4. 04

   Configurer les alertes métriques dans Beszel

   Dans Beszel, ouvrez la fiche d'un système et accédez à l'onglet Alertes. Configurez des seuils sur les métriques critiques :

   - Disque : alerte à 80 % et alerte critique à 90 % — couvre le cas PostgreSQL du scénario d'ouverture.
   - RAM : alerte à 85 % d'utilisation soutenue sur 5 minutes.
   - CPU : alerte si la charge dépasse 90 % pendant plus de 3 minutes.

   Beszel supporte Telegram, Discord, Slack, Gotify, Ntfy et les webhooks génériques. Pour Telegram, vous avez besoin d'un token de bot (obtenu via @BotFather) et de l'ID de votre chat ou groupe.

5. 05

   Configurer les moniteurs Uptime Kuma v2 et les alertes SMTP ou Telegram

   Dans Uptime Kuma, commencez par configurer un canal de notification (Paramètres → Notifications). Deux options courantes :

   Telegram. Renseignez le token de bot et l'ID du chat. Le même bot que pour Beszel fonctionne — gardez un seul bot pour les deux outils et distinguez-les par des canaux différents.

   SMTP. Renseignez le serveur SMTP, le port (587 en STARTTLS), les identifiants et l'adresse de destination. Utilisez de préférence un compte dédié à l'envoi d'alertes.

   Créez ensuite les moniteurs pour chaque service critique : URL HTTP(s) pour les sites, TCP pour les bases de données et les ports applicatifs. Pour le cas PostgreSQL, ajoutez un moniteur TCP sur le port 5432 de chaque VPS hébergeant une instance — si PostgreSQL s'arrête, le port ne répond plus et l'alerte part en quelques secondes.

6. 06

   Mettre le tout derrière un reverse proxy avec SSL

   Ajoutez un service nginx ou Caddy au Compose pour exposer Beszel et Uptime Kuma via HTTPS :

     caddy:
       image: caddy:alpine
       restart: unless-stopped
       ports:
         - "80:80"
         - "443:443"
       volumes:
         - ./Caddyfile:/etc/caddy/Caddyfile
         - caddy_data:/data

   Avec un Caddyfile minimal :

   monitoring.votre-domaine.com {
       reverse_proxy beszel:8090
   }
   
   status.votre-domaine.com {
       reverse_proxy uptime-kuma:3001
   }

   Caddy émet et renouvelle automatiquement les certificats Let's Encrypt. Retirez les sections ports de beszel et uptime-kuma dans le Compose dès lors qu'ils sont proxifiés — ils ne doivent plus être accessibles directement.

7. 07

   Vérifier le bon fonctionnement et configurer la rétention

   Testez l'ensemble en arrêtant manuellement un service sur un VPS de test (docker compose stop <service>) et en vérifiant que l'alerte Telegram ou SMTP arrive en moins de deux minutes.

   Pour Beszel, configurez la rétention des données dans Paramètres → Rétention : la valeur par défaut est 7 jours pour les données haute résolution, 30 jours pour les agrégats horaires. Ajustez selon la capacité de votre disque.

   Pour Uptime Kuma, la rétention se configure dans Paramètres → Avancé → Purge automatique. Conservez au moins 90 jours pour avoir des tendances d'uptime mensuelles à présenter aux clients.

Pièges à connaître avant de mettre en production

Comparaison des niveaux d'alerte selon la stack

Faites défiler le tableau

Dépannage des problèmes courants

Pour aller plus loin