← Tous les guidesExploitation de site

Surveiller un site depuis un serveur séparé avec Uptime Kuma

31 août 2026

Exécutez Uptime Kuma sur un serveur Linux distinct, vérifiez un site en HTTPS et prouvez que l'alerte vous parvient avant une panne.

Dépôt GitHub compagnonConfiguration compagnon Uptime KumaTylorMayfield/uptime-kuma-droplet-monitorVoir sur GitHub

Décider ce que ce moniteur peut prouver

Uptime Kuma peut indiquer si son propre serveur atteint une URL, un port, un certificat ou une autre cible configurée. C'est utile. Cela ne prouve pas que chaque utilisateur atteint votre service et ne remplace ni les journaux de l'application ni un vrai plan d'incident.

Placez le moniteur sur un serveur différent de celui du site contrôlé. Si le Droplet de l'application tombe, remplit son disque ou perd son chemin réseau, le moniteur doit encore pouvoir envoyer l'alerte. Un second Droplet chez le même fournisseur améliore la séparation avec l'application, mais ne prouve pas une couverture indépendante par région ou fournisseur.

  • Un nom DNS pour le tableau de bord privé, par exemple status-admin.example.com.
  • Un second Droplet Linux avec une clé SSH. Ne réutilisez pas le serveur de l'application.
  • Une URL du site cible qui peut être demandée sans créer de données ni envoyer d'e-mail.
  • Une destination de notification que vous pouvez recevoir pendant le test.

Créer et restreindre le serveur de supervision

Créez un Droplet Linux pour le moniteur. Choisissez volontairement sa région. Une proximité avec l'application réduit le risque de confondre une latence normale avec une panne. Une autre région révèle davantage de problèmes réseau. Notez ce que votre choix doit mesurer.

  1. Dans DigitalOcean, créez un Droplet avec une clé SSH. Nommez-le selon son rôle, par exemple uptime-kuma-monitor.
  2. Créez un Cloud Firewall réservé à ce Droplet. Autorisez TCP 80 et 443 depuis Internet pour le certificat HTTPS et le tableau de bord. Autorisez TCP 22 seulement depuis votre adresse d'administration ou votre VPN.
  3. Créez un enregistrement A ou AAAA pour le tableau de bord vers l'adresse publique du Droplet. Attendez sa résolution avant de lancer Caddy, qui utilise ce nom pour obtenir un certificat public.
  4. N'ouvrez pas le port 3001 d'Uptime Kuma dans le pare-feu. Le fichier Compose compagnon le garde sur le réseau Docker interne et Caddy reste le seul service public.

Démarrer Uptime Kuma derrière HTTPS

Le dépôt compagnon garde la configuration courte. Uptime Kuma stocke son état dans ./data. Caddy écoute sur les ports 80 et 443 et relaie vers le conteneur Uptime Kuma. La configuration utilise l'image officielle avec son étiquette de version majeure. Consultez les notes de mise à jour du projet avant de la modifier.

Uptime Kuma indique que ses données doivent rester sur un répertoire ou volume local, jamais NFS. Gardez-les sur le disque local du Droplet et incluez-les dans votre plan de sauvegarde.

monitor-droplet8 étapes

Avant de continuer : Cette procédure démarre des services HTTPS publics sur le Droplet de supervision. Confirmez l'enregistrement DNS et les règles de pare-feu avant de l'exécuter.

  1. Cloner le projet compagnonmonitor-droplet
    git clone https://github.com/TylorMayfield/uptime-kuma-droplet-monitor.git
  2. Ouvrir le dossiermonitor-droplet
    cd uptime-kuma-droplet-monitor
  3. Créer le fichier d'environnementmonitor-droplet
    cp .env.example .env
  4. Définir le nom DNSÉditeur de fichiers du serveur
    nano .env
  5. Rendre les scripts exécutablesmonitor-droplet
    chmod 700 scripts/preflight.sh scripts/check-dashboard.sh
  6. Exécuter le contrôle préalablemonitor-droplet
    ./scripts/preflight.sh
  7. Démarrer les servicesmonitor-droplet
    docker compose up -d
  8. Vérifier le tableau de bordmonitor-droplet
    ./scripts/check-dashboard.sh

Vérifier la première réponse

Résultat attendu
Le tableau de bord est disponible en HTTPS, la notification de panne arrive après l'échec contrôlé et la notification de reprise arrive lorsque la cible réussit de nouveau.
Arrêter si
Arrêtez si le moniteur fonctionne sur le serveur applicatif, si le port 3001 est public, si le tableau de bord n'a pas de compte administrateur, si le DNS ne pointe pas vers le moniteur ou si le test de notification n'arrive pas.
Étape suivante
Consignez les délais d'alerte et de reprise, puis ajoutez le contrôle de santé de production seulement après avoir défini son URL et sa réponse attendue.

Créer un moniteur et une notification avant d'en ajouter d'autres

Ouvrez https://KUMA_DOMAIN et créez le premier compte administrateur. Considérez-le comme un tableau de bord privé. Une page d'état publique est un choix distinct et peut révéler des noms de services ou l'historique des pannes.

Ajoutez une méthode de notification que vous pouvez tester. Ajoutez ensuite un moniteur HTTP(s) pour une URL de santé inoffensive, définissez le code attendu et associez la notification. Commencez avec un seul moniteur.

  1. Envoyez le test de notification d'Uptime Kuma et confirmez que la bonne personne ou le bon canal le reçoit.
  2. Créez un moniteur HTTP(s) pour une URL de santé qui renvoie une réponse prévisible sans modifier l'état de l'application.
  3. Choisissez un délai et des nouvelles tentatives qui correspondent au service. N'utilisez pas un délai minuscule seulement pour animer le tableau de bord.
  4. Donnez au moniteur un nom qui décrit la panne, par exemple Vérification HTTPS du site.

Prouver l'alerte et la reprise sans arrêter la production

Ne considérez pas la supervision terminée parce que le tableau est vert. Créez une route temporaire ou une cible jetable qui renvoie une erreur, pointez un moniteur temporaire dessus et attendez la notification de panne. Faites ensuite réussir la cible et confirmez la notification de reprise. Notez le délai entre la panne et l'alerte.

N'arrêtez pas le site réel pour tester ce guide. Une cible contrôlée apporte la même preuve sans provoquer un incident évitable. Si vous ne pouvez pas créer une cible inoffensive, testez d'abord un service jetable et indiquez que le chemin d'alerte de production reste non prouvé.

Avant de continuer : Cette commande redémarre le tableau de bord de supervision. Exécutez-la seulement après un déploiement fonctionnel.

Vérifier l'accès au tableau de bord après un redémarragemonitor-droplet
cd uptime-kuma-droplet-monitor
docker compose restart
./scripts/check-dashboard.sh

Garder un signal utile

Relisez les moniteurs après la première fausse alerte. Si une défaillance temporaire est fréquente et inoffensive, ajustez les nouvelles tentatives ou le délai après l'avoir comprise. Ne réduisez pas au silence un moniteur parce qu'il a signalé un problème gênant.

Mettez Uptime Kuma à jour volontairement. Sauvegardez ses données locales, lisez les notes amont, récupérez l'image, recréez les services puis vérifiez une connexion, un moniteur et une notification.