B2-27 Surveiller la disponibilité avec Uptime Kuma

1. Mesurer la disponibilité

Un service est disponible quand un utilisateur peut s'en servir normalement. La SLA fixe l'engagement (par exemple 99,5 % par mois, voir B1-03) ; la supervision fournit la mesure qui permet de dire si l'engagement est tenu.

Ce calcul suppose qu'on mesure : sans sonde, on ne connaît que les pannes que quelqu'un a signalées. Uptime Kuma affiche lui-même le pourcentage sur 24 heures, 30 jours et un an pour chaque service.

2. Disponibilité ou supervision complète ?

Deux familles d'outils se complètent. Une sonde de disponibilité se place à l'extérieur du service, comme un utilisateur, et pose une seule question : « est-ce que ça répond ? ». Une supervision complète installe un agent dans chaque machine et mesure l'intérieur : processeur, mémoire, disque, trafic, services. Elle sait pourquoi et peut prévenir avant la panne.

3. Les sondes d'Uptime Kuma

Dans Uptime Kuma, chaque élément surveillé est un sonde. Chaque sonde a un type, qui décide de ce qu'on teste, et une cible. Plus le test est proche de l'usage réel, plus l'alerte est fiable.

3.1 Les champs d'une sonde HTTP

• Type de sonde (Monitor Type)Le type de sonde : HTTP(s), HTTP(s) - Keyword, TCP Port, Ping, DNS ou Push.
• URLL'adresse complète à interroger, par exemple https://intranet.broceliande.lan. Utilise le nom que les utilisateurs utilisent, pas l'adresse IP.
• Mot-clé (Keyword)Le mot attendu dans la page. La casse compte : Accueil et accueil sont deux mots différents.
• Codes HTTP acceptés (Accepted Status Codes)Les codes de réponse considérés comme normaux (200-299 par défaut). Une redirection ou un code 401 attendu s'ajoute ici.
• Ignorer les erreurs liées au certificat SSL/TLS (Ignore TLS/SSL errors)Accepte un certificat non reconnu (autosigné). Pratique au labo ; en production, on installe plutôt l'autorité de certification. La sonde ne sert plus alors à détecter un faux certificat.
• Notification d'expiration du certificat (Certificate Expiry Notification)Case à cocher qui active l'alerte avant l'expiration du certificat.

4. Intervalle, nouvelles tentatives, délai

Une sonde qui alerte au premier échec est une sonde qui crie au loup : un paquet perdu, une page lente pendant la sauvegarde, et le téléphone sonne. Trois réglages équilibrent rapidité et fiabilité.

• Intervalle de vérification (Heartbeat Interval)Le temps entre deux vérifications, en secondes (60 par défaut). Plus il est court, plus la détection est rapide, et plus la charge et les risques de fausse alerte augmentent.
• Tentatives (Retries)Le nombre de nouvelles tentatives avant de déclarer la panne (0 par défaut, 2 ou 3 est un bon réglage).
• Intervalle entre chaque nouvelle tentative (Heartbeat Retry Interval)Le temps entre deux tentatives quand la sonde est en attente. Il peut être plus court que l'intervalle normal.
• Délai d'expiration de la demande (Request Timeout)Le temps maximal d'attente d'une réponse. Il doit rester inférieur à l'intervalle (par défaut, 80 % de l'intervalle).
• Renvoyer la notification (Resend Notification)Répète l'alerte tant que le service reste en panne, toutes les N vérifications (0 : une seule alerte).

5. Prévenir, informer, planifier

5.1 Les notifications

Une panne détectée mais jamais lue ne sert à rien. Uptime Kuma sait envoyer l'alerte par des dizaines de canaux. On les crée une fois (Paramètres → Notifications), puis on les rattache aux sondes. La case Activé par défaut (Default enabled) les applique à toutes les nouvelles sondes, et Appliquer sur toutes les sondes existantes aux sondes déjà créées.

5.2 La page de statut

Une page de statut affiche l'état des services sur une adresse dédiée, sans connexion : /status/nom-de-la-page. Les utilisateurs la consultent avant d'appeler le support. On crée des groupes (« Messagerie et intranet », « Infrastructure »), on y glisse les sondes, on donne un titre et on publie. Elle peut aussi annoncer un incident en cours.

5.3 La maintenance planifiée

Une mise à jour ou un redémarrage prévu provoque une coupure normale. Sans précaution, elle déclenche une alerte et dégrade le taux de disponibilité. Une maintenance planifiée (menu Maintenance) désigne les sondes concernées et une période (une fois, tous les dimanches, selon une expression cron) : pendant ce temps, l'état passe en bleu, aucune alerte ne part et l'arrêt n'est pas compté comme une panne.

6. Installer, publier et sécuriser Uptime Kuma

Uptime Kuma est une application web (Node.js) qui s'installe très simplement dans un conteneur. Docker Compose décrit ce conteneur dans un fichier compose.yaml : quelle image, quel volume, quel port. L'image officielle est louislam/uptime-kuma ; la version 2 est la version actuelle (2.5 à la rédaction de cette fiche) et l'étiquette :2 suit ses mises à jour correctives. La fiche B2-23 approfondit Docker et Compose ; ici, il suffit de connaître trois idées.

• imageLe modèle figé de l'application, téléchargé depuis un dépôt public. L'étiquette :2 choisit la version majeure.
• volumeUn espace de stockage géré par Docker, qui survit à la suppression du conteneur. Les sondes, l'historique et le compte admin vivent dans /app/data : sans volume, tout disparaît à la recréation.
• portsLe port 3001 du conteneur est publié sur la VM. En le limitant à 127.0.0.1, seul Traefik, installé sur la même VM, peut le joindre. Sans Traefik (TP de SIO1), on écrit "3001:3001" : Kuma répond en HTTP sur http://IP-de-la-VM:3001, à réserver au réseau du labo.

6.1 Le fichier Compose

services:
  kuma:
    image: louislam/uptime-kuma:2        # version 2, mises à jour correctives comprises
    container_name: kuma
    restart: unless-stopped              # redémarre avec la VM
    ports:
      - "127.0.0.1:3001:3001"            # joignable seulement depuis la VM elle-même
    volumes:
      - kuma_data:/app/data              # sondes, historique, compte admin

volumes:
  kuma_data:

6.2 La publication derrière Traefik (option, Traefik est vu en SIO2)

Comme dans la fiche B2-12, Traefik est configuré avec des fichiers dynamiques : un fichier par service publié, jamais d'étiquettes (labels) Docker. Le fichier déclare un routeur, un service qui pointe vers 127.0.0.1:3001, et le certificat.

http:
  routers:
    kuma:
      rule: "Host(`kuma.broceliande.lan`)"
      entryPoints: [websecure]
      service: kuma
      tls: {}
  services:
    kuma:
      loadBalancer:
        servers:
          - url: "http://127.0.0.1:3001"

tls:
  certificates:
    - certFile: /etc/traefik/certs/kuma.crt
      keyFile: /etc/traefik/certs/kuma.key

6.3 Premier démarrage et sécurisation

Pour mettre à jour, on lance sudo docker compose pull puis sudo docker compose up -d : les données du volume sont conservées. Pour sauvegarder, on arrête brièvement le conteneur puis on archive le volume, car la base ne doit pas être copiée en cours d'écriture.

7. Dépanner : fausses alertes et alertes manquées

Une supervision n'est utile que si l'on peut lui faire confiance. Deux défauts la ruinent : les faux positifs (alerte alors que tout va bien) et les faux négatifs (aucune alerte alors que le service est cassé).

7.1 Entraîne-toi : les tickets du support

Tu es de permanence au support de Brocéliande Logistique. Cinq tickets arrivent les uns après les autres : lis le message, observe le relevé, puis choisis la cause.

Heartbeat Interval  : 20
Retries             : 0
Request Timeout     : 16
Journal 02:00:41    : Down - timeout of 16000ms exceeded
Journal 02:01:01    : Up - 200 - OK

Type                : HTTP(s) - Keyword
URL                 : https://intranet.broceliande.lan
Keyword             : Accueil
Journal             : Down - but keyword is not in [Erreur de connexion à la base de données]
Code de réponse     : 200

[intranet.broceliande.lan] [TLS Certificate Expiry]
Certificate will expire in 6 days
Date d'expiration : 24/10/2026

SRV-01 ping            : Up   (1 ms)
SRV-01 port 3389       : Up
SRV-01 DNS             : Down - queryA ECONNREFUSED 172.16.50.10:53
(serveur DNS interrogé : 172.16.50.10)

$ curl -fsS "https://kuma.broceliande.lan/api/push/aB3dE9?status=up&msg=OK"
curl: (60) SSL certificate problem: self-signed certificate

8. À l'examen et en entreprise

9. 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.

Les commandes clés

Tout cela tient sur une page : utilise le bouton Mémo à imprimer en haut de la fiche.

10. Quiz noté

11. Exercices : à toi de répondre

Écris ta réponse sous chaque énoncé et envoie-la à ton professeur. Quand il l'a validée, le corrigé s'affiche à la place du cadenas ; s'il te la renvoie « à revoir », lis son commentaire et corrige. Montre tes calculs, pas seulement le résultat.

12. Au labo : superviser les VM de ton pool avec Uptime Kuma