Mémo de la fiche B2-27 : une page A4, à imprimer ou à enregistrer en PDF.
B2-27

Surveiller la disponibilité avec Uptime Kuma

Mesurer la disponibilité d'un service, choisir les bonnes sondes, régler les alertes, publier une page de statut et installer Uptime Kuma avec Docker Compose (Traefik en option).

Version en ligne
SIO1 · semestre 22 h (cours + TP)Bloc 2 – SISRMémo · Portail SIO
UptimeKuma Mesurer(temps prévu − arrêt) ÷ prévuSLA 99,5 % = 3 h 36 / mois SondesHTTP + mot-clé · ping · TCPDNS · certificat · push Réglerintervalle · tentativesDOWN au (N + 1)e échec PrévenirSMTP · Discord/Teams · ntfycanal indépendant, testé Informerpage de statut publiquemaintenance planifiée InstallerCompose · volume · 127.0.0.1Traefik · admin + 2FA

L'essentiel

  1. Disponibilité = (temps prévu − arrêt) ÷ temps prévu ; un mois de 30 jours fait 43 200 minutes.
  2. Le SLA fixe l'engagement (99,5 % tolère 3 h 36 min par mois) ; la supervision fournit la mesure.
  3. Kuma teste de l'extérieur (« ça répond ? ») ; Zabbix mesure de l'intérieur (« comment va-t-il ? »). Les deux se complètent.
  4. Sondes : HTTP(S) avec mot-clé, ping, port TCP, DNS, certificat, push.
  5. Un code 200 ne suffit pas : le mot-clé détecte la page d'erreur.
  6. La sonde push surveille ce qui doit arriver (sauvegarde) : pas de signal, pas de vert.
  7. Intervalle, tentatives, délai : DOWN au (N + 1)e échec ; le délai d'attente reste inférieur à l'intervalle.
  8. Notifications testées, avec un canal indépendant de l'infrastructure surveillée.
  9. Page de statut sans information sensible ; maintenance planifiée pour les arrêts prévus.
  10. Installation : louislam/uptime-kuma:2, volume pour /app/data, port sur 127.0.0.1, Traefik en fichier dynamique, compte admin, 2FA, sauvegarde.

Le calcul de la disponibilité

Disponibilité (%) = (temps prévu − temps d'arrêt) ÷ temps prévu × 100. Sur un mois de 30 jours, le temps prévu est 30 × 24 × 60 = 43 200 minutes pour un service attendu 24 h sur 24.

Un code 200 ne prouve pas que le site fonctionne

Une application en panne de base de données affiche souvent une page d'erreur avec un code HTTP 200. Une sonde HTTP simple reste verte pendant que les utilisateurs ne peuvent rien faire. Ajoute un mot-clé qui n'existe que sur la vraie page (un titre, le nom de l'entreprise) : s'il manque, la sonde passe au rouge.

Délai de détection

Une sonde passe à DOWN au (N + 1)e échec consécutif (N = nouvelles tentatives). Le délai maximal entre le début de la panne et l'alerte vaut environ intervalle + N × intervalle de nouvelle tentative. Les valeurs de départ raisonnables : 60 s, 2 tentatives, délai de 48 s.

Commandes clés

Pour…Commandes
Démarrer ou arrêter Kumasudo docker compose up -d · sudo docker compose stop (dans /opt/kuma)
Voir l'état et les journauxsudo docker compose ps · sudo docker compose logs -f kuma
Mettre à joursudo docker compose pull puis sudo docker compose up -d
Tester l'application en localcurl -sI http://127.0.0.1:3001
Simuler un signal pushcurl -fsS "https://kuma…/api/push/JETON?status=up&msg=OK"
Tester un port ou un nom (Windows)Test-NetConnection 172.16.50.10 -Port 3389 · Resolve-DnsName intranet.broceliande.lan -Server 172.16.50.10
Lire la date d'un certificatopenssl s_client -connect nom:443 </dev/null | openssl x509 -noout -enddate