[{"data":1,"prerenderedAt":188},["ShallowReactive",2],{"seo-verification":3,"blog-monitoring-alerte-proactif-self-hosted-vps-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-monitoring-alerte-proactif-self-hosted-vps-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":130,"ctaBody":131,"ctaButton":132,"ctaUrl":133,"relatedPosts":134},440,"monitoring-alerte-proactif-self-hosted-vps",{"fr":10,"en":12,"ar":13,"es":14},"proactive-vps-monitoring-beszel-uptime-kuma-v2","مراقبة-استباقية-vps-beszel-uptime-kuma","monitorizacion-proactiva-vps-beszel-uptime-kuma-v2","Stack monitoring proactif VPS : Beszel + Uptime Kuma v2","Déployez Beszel et Uptime Kuma v2 sur un VPS pour surveiller tout votre parc et recevoir des alertes Telegram ou SMTP avant que vos clients ne constatent la panne.",11,0,false,"2026-10-14T00:00:00+00:00","2026-10-14T23:33:30+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fmonitoring-alerte-proactif-self-hosted-vps-poster.svg","Un service PostgreSQL s'arrête sans déclencher aucune alerte disque. Le client appelle. Vous apprenez la panne en même temps que lui. Ce cas, documenté et relayé dans la communauté en octobre 2026, illustre le problème des piles de monitoring mono-outil : chaque couche voit ce qu'elle regarde, et rien d'autre. La combinaison Beszel et Uptime Kuma v2 couvre les deux angles — métriques système sur chaque hôte, et vérification de disponibilité de bout en bout — pour un coût en ressources inférieur à un WordPress idle.",[35,39,51,54,79,82,120,124,127],{"type":36,"title":37,"body":38},"h2","Pourquoi surveiller proactivement, et pourquoi les outils classiques ne suffisent pas","L'alerte réactive — celle qui arrive après que le client a appelé — ne protège pas la relation. Elle la répare. La différence entre les deux n'est pas une question de chance : c'est une question de couverture.\n\nUn outil de monitoring de disponibilité comme Uptime Kuma vérifie qu'un service répond sur un port ou une URL. Il ne sait pas si PostgreSQL tourne en dehors de ce port, si la mémoire du conteneur est sur le point de saturer, ou si le disque de logs remplit à 200 Mo par heure. À l'inverse, un outil de métriques système comme Beszel surveille la consommation de chaque hôte en continu, mais ne teste pas les services applicatifs de bout en bout.\n\nLe cas documenté sur \u003Ca href=\"https:\u002F\u002Flemmy.world\u002Fpost\u002F52895878\">Lemmy\u003C\u002Fa> le 11 octobre 2026 (112 votes) illustre exactement ce point : PostgreSQL s'était arrêté sur un VPS sans déclencher d'alerte disque. Aucun seuil d'espace n'avait été franchi. Seule une vérification applicative aurait détecté l'arrêt — ce que l'opérateur n'avait pas en place.\n\nLa stack Beszel + Uptime Kuma v2 répond aux deux angles. Beszel surveille les métriques de chaque hôte (CPU, RAM, disque, réseau, conteneurs) depuis un hub central. Uptime Kuma v2 vérifie la disponibilité des services exposés, avec des canaux d'alerte configurables. Les deux sont open source, auto-hébergés, et s'installent sur un VPS dédié à la supervision de votre parc.",{"type":40,"title":41,"items":42},"ul","Ce que cette stack apporte concrètement à une agence",[43,44,45,46,47,48,49,50],"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.",{"type":36,"title":52,"body":53},"Prérequis chiffrés","Pour héberger le hub Beszel et Uptime Kuma v2 sur un VPS dédié à la supervision :\n\n**Ressources minimales.** Un VPS 1 vCPU avec 1 Go de RAM est suffisant pour superviser une dizaine d'hôtes avec Beszel et une cinquantaine de moniteurs avec Uptime Kuma. En pratique, Beszel hub consomme environ 50 Mo de RAM et Uptime Kuma v2 environ 100 Mo — soit moins de 200 Mo au total au repos, selon les mesures remontées par la communauté. Pour un parc de 20 à 50 VPS, prévoir 2 Go de RAM. L'outil Beszel stocke ses données dans SQLite ; comptez 5 à 10 Go de disque pour conserver plusieurs mois d'historique.\n\n**Logiciels requis.** Docker et Docker Compose installés sur le VPS de supervision. Un nom de domaine ou sous-domaine pointant sur ce VPS (`monitoring.votre-domaine.com`) pour le reverse proxy et le SSL. Les ports 80 et 443 ouverts pour le reverse proxy, et le port `8090` ou tout autre port de votre choix pour le hub Beszel (accessible depuis les agents sur les autres VPS).\n\n**Sur les VPS supervisés.** Chaque hôte à superviser reçoit uniquement l'agent Beszel — un binaire léger ou un conteneur Docker d'environ 10 Mo de RAM. Aucune modification du pare-feu public n'est nécessaire : l'agent établit la connexion vers le hub, pas l'inverse.",{"type":55,"title":56,"steps":57},"steps","Déploiement complet : Beszel hub, agents, Uptime Kuma v2 et alertes",[58,61,64,67,70,73,76],{"title":59,"body":60},"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 :\n\n```bash\nmkdir -p \u002Fopt\u002Fmonitoring && cd \u002Fopt\u002Fmonitoring\n```\n\nCréez le fichier `docker-compose.yml` avec les deux services :\n\n```yaml\nservices:\n  beszel:\n    image: henrygd\u002Fbeszel:latest\n    restart: unless-stopped\n    volumes:\n      - .\u002Fbeszel_data:\u002Fbeszel_data\n    ports:\n      - \"8090:8090\"\n    environment:\n      - DATA_DIR=\u002Fbeszel_data\n\n  uptime-kuma:\n    image: louislam\u002Fuptime-kuma:2\n    restart: unless-stopped\n    volumes:\n      - .\u002Fuptime-kuma-data:\u002Fapp\u002Fdata\n    ports:\n      - \"3001:3001\"\n    healthcheck:\n      test: [\"CMD\", \"node\", \"extra\u002Fhealthcheck\"]\n      interval: 30s\n      timeout: 10s\n      retries: 3\n```\n\nNotez le bloc `healthcheck` sur Uptime Kuma : il est indispensable pour éviter le piège du crash-loop (voir la section « Pièges »).",{"title":62,"body":63},"Démarrer la stack et créer les comptes administrateurs","Lancez les deux conteneurs :\n\n```bash\ndocker compose up -d\n```\n\nVérifiez que les deux conteneurs sont en état `healthy` ou `running` :\n\n```bash\ndocker compose ps\n```\n\nAccédez à Beszel sur `http:\u002F\u002F\u003Cip-vps>:8090` et créez le compte administrateur lors du premier accès. Faites de même pour Uptime Kuma sur `http:\u002F\u002F\u003Cip-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.",{"title":65,"body":66},"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 :\n\n```bash\ncurl -sL https:\u002F\u002Fraw.githubusercontent.com\u002Fhenrygd\u002Fbeszel\u002Fmain\u002Fsupplemental\u002Fscripts\u002Finstall-agent.sh | bash -s -- -p 45876 -k \"\u003Cvotre-cle-publique>\"\n```\n\nAlternativement, utilisez Docker sur l'hôte supervisé :\n\n```yaml\nservices:\n  beszel-agent:\n    image: henrygd\u002Fbeszel-agent:latest\n    restart: unless-stopped\n    network_mode: host\n    volumes:\n      - \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock:ro\n    environment:\n      - KEY=\u003Cvotre-cle-publique>\n      - PORT=45876\n```\n\nDans 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.",{"title":68,"body":69},"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 :\n\n- **Disque** : alerte à 80 % et alerte critique à 90 % — couvre le cas PostgreSQL du scénario d'ouverture.\n- **RAM** : alerte à 85 % d'utilisation soutenue sur 5 minutes.\n- **CPU** : alerte si la charge dépasse 90 % pendant plus de 3 minutes.\n\nBeszel 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.",{"title":71,"body":72},"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 :\n\n**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.\n\n**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.\n\nCré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.",{"title":74,"body":75},"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 :\n\n```yaml\n  caddy:\n    image: caddy:alpine\n    restart: unless-stopped\n    ports:\n      - \"80:80\"\n      - \"443:443\"\n    volumes:\n      - .\u002FCaddyfile:\u002Fetc\u002Fcaddy\u002FCaddyfile\n      - caddy_data:\u002Fdata\n```\n\nAvec un `Caddyfile` minimal :\n\n```\nmonitoring.votre-domaine.com {\n    reverse_proxy beszel:8090\n}\n\nstatus.votre-domaine.com {\n    reverse_proxy uptime-kuma:3001\n}\n```\n\nCaddy é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.",{"title":77,"body":78},"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 \u003Cservice>`) et en vérifiant que l'alerte Telegram ou SMTP arrive en moins de deux minutes.\n\nPour 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.\n\nPour 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.",{"type":36,"title":80,"body":81},"Pièges à connaître avant de mettre en production","**Le crash-loop Docker déclaré UP — issue Uptime Kuma #7956.** Sans `healthcheck` dans le Compose, Docker peut rapporter un conteneur Uptime Kuma en état `running` alors qu'il est en boucle de redémarrage. Le moniteur Uptime Kuma sur lui-même (TCP vers le port 3001) affichera alors un faux positif : le port répond pendant le court intervalle entre deux redémarrages. Le workaround est précisément le bloc `healthcheck` montré à l'étape 1 — il utilise le script embarqué dans l'image pour tester l'état interne de l'application, pas seulement la présence du processus. Docker passe alors l'état du conteneur à `unhealthy` si le check échoue trois fois de suite, et le moniteur Uptime Kuma le voit.\n\n**L'agent Beszel en mode `network_mode: host`.** Si les hôtes supervisés font tourner des conteneurs, l'agent Beszel doit avoir accès au socket Docker (`\u002Fvar\u002Frun\u002Fdocker.sock`) pour remonter les métriques par conteneur. En mode réseau bridge, le socket est accessible mais l'adresse IP remontée par l'agent peut être celle du réseau Docker interne. Préférez `network_mode: host` sur l'agent pour garantir que Beszel hub voit l'IP publique du serveur.\n\n**Les alertes Beszel ne remplacent pas les vérifications applicatives.** Beszel surveille les ressources système et la disponibilité des conteneurs Docker. Il ne teste pas qu'une application répond correctement à une requête HTTP ou que PostgreSQL accepte des connexions. Ces deux niveaux sont complémentaires : Beszel détecte la saturation qui précède la panne, Uptime Kuma confirme la panne quand elle est là.",{"type":83,"title":84,"headers":85,"rows":90},"comparison","Comparaison des niveaux d'alerte selon la stack",[86,87,88,89],"Scénario de panne","Beszel seul","Uptime Kuma seul","Beszel + Uptime Kuma v2",[91,96,101,106,110,115],[92,93,94,95],"Disque plein à 95 %","Alerte au seuil configuré","Pas de détection","Alerte Beszel avant la panne",[97,98,99,100],"PostgreSQL arrêté (port TCP down)","Non détecté (service hors Docker)","Alerte TCP en \u003C 2 min","Alerte Uptime Kuma TCP",[102,103,104,105],"Conteneur en crash-loop","Alerte si CPU\u002FRAM impactés","Faux positif sans healthcheck","Détecté si healthcheck en place",[107,108,94,109],"Fuite mémoire progressive","Alerte sur seuil RAM","Alerte Beszel anticipée",[111,112,113,114],"Certificat SSL expiré dans 7 jours","Non surveillé","Alerte expiration SSL","Alerte Uptime Kuma SSL",[116,117,118,119],"VPS inaccessible (réseau ou host down)","Hub perd l'agent","Alerte TCP\u002FHTTP","Double signal, convergent",{"type":121,"title":122,"body":123},"tip","Durcissement : isolez le VPS de supervision","Le VPS de supervision est un actif critique : s'il tombe, vous perdez la visibilité sur tout le reste. Trois règles pour le durcir.\n\nPremièrement, n'hébergez pas d'applications clientes sur ce VPS. Sa charge doit rester prévisible et son seul rôle est la supervision.\n\nDeuxièmement, fermez tous les ports inutiles avec le pare-feu de votre VPS. Seuls 80, 443 et le port SSH (déplacé sur un port non standard) doivent être accessibles depuis Internet. Le port de l'agent Beszel (45876 par défaut) ne doit être ouvert que depuis les IP de vos autres VPS, pas depuis l'ensemble d'Internet.\n\nTroisièmement, ajoutez un moniteur Uptime Kuma externe — par exemple depuis un service de check HTTP gratuit — qui vérifie que votre propre instance Uptime Kuma répond. Sans cette couche externe, une panne du VPS de supervision passe inaperçue.",{"type":36,"title":125,"body":126},"Dépannage des problèmes courants","**L'agent Beszel apparaît hors ligne immédiatement après l'ajout.** Vérifiez que le port de l'agent (45876 par défaut) est bien accessible depuis le hub. Sur l'hôte supervisé, testez avec `nc -zv \u003Cip-hub> 8090` — si la connexion échoue, le problème est côté pare-feu du hub. L'agent lui-même ne nécessite pas de port entrant ouvert.\n\n**Uptime Kuma ne reçoit pas les alertes Telegram.** Le problème le plus fréquent est un décalage d'horloge sur le conteneur. Vérifiez avec `docker exec uptime-kuma date` que l'heure correspond à l'heure UTC réelle. Si ce n'est pas le cas, ajoutez `\u002Fetc\u002Flocaltime:\u002Fetc\u002Flocaltime:ro` dans les volumes du service Uptime Kuma.\n\n**Beszel hub ne démarre pas ou perd ses données après un redémarrage.** Vérifiez que le volume `.\u002Fbeszel_data` appartient bien à l'UID utilisé par le conteneur Beszel. Une erreur de permissions sur le dossier de données empêche SQLite d'écrire : `chown -R 1000:1000 .\u002Fbeszel_data` corrige le problème dans la plupart des cas.\n\n**Uptime Kuma en état `unhealthy` au démarrage.** L'image v2 peut mettre 30 à 60 secondes à démarrer complètement avant que le healthcheck passe. C'est normal. Si le conteneur reste `unhealthy` après deux minutes, consultez les logs : `docker compose logs uptime-kuma`.",{"type":36,"title":128,"body":129},"Pour aller plus loin","Cette stack couvre les deux niveaux essentiels : métriques système et vérification de disponibilité. Pour un troisième niveau — la traçabilité et l'analyse fine des tendances de charge — la stack Grafana + Prometheus fait suite naturellement. Elle est plus consommatrice en ressources (prévoir 2 Go de RAM dédiés), mais ouvre le langage PromQL et les dashboards sur mesure. L'article \u003Ca href=\"\u002Fblog\u002Fmonitoring-vps-grafana-prometheus\">Monitoring de VPS avec Grafana et Prometheus\u003C\u002Fa> couvre ce déploiement étape par étape.\n\nPour les sauvegardes du VPS de supervision lui-même — et éviter de reconstruire toute la configuration en cas de perte —, \u003Ca href=\"\u002Fblog\u002Fbackup-vps-restic-s3-3-2-1\">la stratégie 3-2-1 avec Restic et un stockage S3\u003C\u002Fa> s'applique directement aux volumes Docker de cette stack.\n\nSi vous gérez plusieurs serveurs clients depuis une seule plateforme, la page \u003Ca href=\"\u002Fsolutions\u002Fagences\">\u002Fsolutions\u002Fagences\u003C\u002Fa> détaille comment ServOrbit centralise la supervision de votre parc sur un VPS Start.","Superviser votre parc depuis un seul VPS","Vous gérez plusieurs serveurs clients. Centralisez la supervision de votre parc sur un VPS ServOrbit avec accès root, IPv4 dédiée et Docker préinstallé — la stack Beszel + Uptime Kuma v2 tient sur le plan d'entrée de gamme.","Superviser mon parc","\u002Fsolutions\u002Fagences",[135,154,171],{"id":136,"slug":137,"slugs":138,"title":142,"excerpt":143,"readTime":144,"views":18,"isPinned":19,"publishedAt":145,"updatedAt":146,"category":147,"categories":148,"featuredImage":30,"bgImage":31,"posterImage":150,"relatedSolution":151},105,"superviser-vps-uptime-kuma",{"fr":137,"en":139,"ar":140,"es":141},"monitoring-your-vps-with-uptime-kuma","مراقبة-خادمك-الافتراضي-vps-باستخدام-uptime-kuma","supervisar-vps-con-uptime-kuma","Superviser votre VPS avec Uptime Kuma","Déployez Uptime Kuma sur votre VPS pour surveiller vos sites et services en self-hosted, avec alertes et page de statut publique.",4,"2026-03-07T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[149],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsuperviser-vps-uptime-kuma-poster.svg",{"categorySlug":152,"appSlug":153},"monitoring","uptime-kuma",{"id":155,"slug":156,"slugs":157,"title":161,"excerpt":162,"readTime":23,"views":163,"isPinned":19,"publishedAt":164,"updatedAt":146,"category":165,"categories":166,"featuredImage":30,"bgImage":31,"posterImage":168,"relatedSolution":169},133,"self-host-beszel-vps",{"fr":156,"en":158,"ar":159,"es":160},"self-host-beszel-multi-server-monitoring-hub-on-your-vps","استضف-beszel-على-vps-مركز-مراقبة-متعدد-الخوادم","alojar-beszel-hub-monitorizacion-vps","Beszel sur VPS : supervision multi-serveurs, alertes et sécurité","Supervisez un parc de VPS depuis un hub Beszel unique : alertes Telegram\u002Fe-mail, 2FA, agents déclarés automatiquement et dépannage des connexions silencieuses.",1,"2026-02-14T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[167],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fself-host-beszel-vps-poster.svg",{"categorySlug":152,"appSlug":170},"beszel",{"id":172,"slug":173,"slugs":174,"title":178,"excerpt":179,"readTime":17,"views":18,"isPinned":19,"publishedAt":180,"updatedAt":181,"category":182,"categories":183,"featuredImage":30,"bgImage":31,"posterImage":185,"relatedSolution":186},106,"monitoring-vps-grafana-prometheus",{"fr":173,"en":175,"ar":176,"es":177},"vps-monitoring-with-grafana-and-prometheus","مراقبة-الخادم-الافتراضي-vps-باستخدام-grafana-و-prometheus","monitorizacion-vps-grafana-prometheus","Monitoring VPS avec Grafana et Prometheus","Déployez Prometheus 3.x, Grafana 13.x, Node Exporter et Alertmanager sur votre VPS avec Docker Compose. Dashboards, alertes et durcissement.","2026-03-06T00:00:00+00:00","2026-10-05T14:05:27+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[184],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitoring-vps-grafana-prometheus-poster.svg",{"categorySlug":152,"appSlug":187},"grafana",1792031905166]