Votre propre supervision : Uptime Kuma

Le panneau de votre machine affiche des graphiques de CPU, de trafic et de mémoire, mais il n'a aucune idée de si votre site répond ou si la base de données est vivante. Pour cela, il vous faut votre propre surveillant. Uptime Kuma est l'option la plus simple : un conteneur, une interface web, des dizaines de méthodes de notification.

Installation

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"

docker compose up -d

Le port est lié à l'interface locale volontairement : le panneau de supervision ne doit pas être exposé à l'extérieur. Ouvrez-le soit via un serveur web avec un certificat et un mot de passe, soit via un tunnel SSH :

ssh -L 3001:127.0.0.1:3001 root@<machine-address>

Rendez-vous ensuite sur http://localhost:3001 dans votre navigateur ; le premier utilisateur devient l'administrateur.

Quoi surveiller

Commencez petit, sinon vous vous noierez dans le bruit :

• Vérification HTTP de la page d'accueil de chaque site — code de réponse et temps.
• Vérification HTTP d'une API clé avec un contrôle de mot-clé dans la réponse. Une page peut renvoyer 200 et afficher une erreur malgré tout.
• Port TCP de la base de données ou du serveur de jeu.
• Expiration du certificat — Kuma vous préviendra N jours avant l'expiration.
• Vérification push pour les tâches planifiées : après une exécution réussie, le script contacte une adresse unique, et s'il ne le fait pas, vous recevez une alerte. Fonctionne bien avec les tâches planifiées.

Un intervalle de 60 secondes suffit presque toujours. Réessais — 2-3, sinon un seul paquet réseau perdu déclenchera une fausse alerte.

Ne placez pas la supervision d'un site sur la même machine que ce site. Si la machine tombe, le surveillant tombe avec elle, et vous ne le saurez jamais. Pour les sites externes, gardez Kuma sur une machine séparée, et sur celle-ci — uniquement les vérifications des services internes.

Notifications

Configurez un bot Telegram ou un webhook Discord et ajoutez-le dans la section des notifications. N'utilisez pas le canal e-mail : les connexions sortantes de la machine vers les ports 25, 465 et 587 sont fermées tant qu'elles ne sont pas ouvertes sur demande, et les e-mails de Kuma ne partiront tout simplement pas — voir Serveur mail.

Bonnes habitudes :

• Des canaux séparés pour « panne » et « certificat qui expire ». Le premier exige une réaction immédiate, le second — dans la semaine.
• Notifications de rétablissement activées. Sans elles, impossible de savoir si la panne est terminée.
• Un message de test envoyé pendant la configuration. La moitié des problèmes viennent d'un mauvais token, et vous ne le découvrez qu'en pleine panne.

Ressources et maintenance

Le conteneur tient dans 150-250 Mo de mémoire et tourne confortablement sur VDS-1. La base de données grossit avec l'historique des vérifications : réglez la rétention sur 90-180 jours dans les paramètres, sinon en un an le fichier atteindra plusieurs gigaoctets — voir espace disque.

Le répertoire ./data contient tout l'état du service. Incluez-le dans votre sauvegarde : restaurer trois douzaines de vérifications à la main n'a rien d'amusant.

Erreurs courantes

• Vérifier par adresse IP au lieu du domaine. Le certificat et l'hôte virtuel ne sont pas vérifiés, et une panne DNS passe inaperçue.
• Seuils trop sensibles. Une alerte à chaque dépassement de 2 secondes signifie que les gens arrêtent de lire les notifications.
• Panneau exposé à l'extérieur sans mot de passe. Il montre toute votre infrastructure : adresses, ports, noms de services.