Introduction
Avoir un Homelab, c'est avant tout un équilibre entre l'expérimentation et la stabilité. Avec une infrastructure composée de trois serveurs physiques sous Proxmox chez moi, deux VPS dans le cloud et plus d'une trentaine de services auto-hébergés (allant du serveur mail jusqu'aux conteneurs Docker critiques), la moindre panne peut vite devenir un casse-tête. Surtout quand j'effectue des modifications à mon Homelab, car le risque de causer une interruption de service est réel.
Il me fallait donc une solution de supervision capable de m'alerter en temps réel : c'est là qu'Uptime Kuma intervient. Je vais présenter pourquoi j'ai choisi cette solution pour garantir la disponibilité de mes services et comment je l'ai installée dans mon Homelab.
Présentation d'Uptime Kuma
Face à la complexité de mon infrastructure (plusieurs serveurs Proxmox chez moi et des VPS distants dans le cloud), j'avais besoin d'un outil centralisé. Bien qu'il existe des solutions comme Nagios ou Zabbix, leur complexité de mise en œuvre et leurs fonctionnalités surdimensionnées sont les raisons pour lesquelles je ne les utilise pas.
Uptime Kuma présente plusieurs avantages :
- Une interface moderne : Elle est très réactive et claire, ce qui permet de visualiser l'état des services monitorés très rapidement.
- Des sondes polyvalentes : On peut monitorer un serveur avec un simple Ping jusqu'à un serveur SQL (PostgreSQL, MariaDB, MySQL, Microsoft SQL, etc.).
- Des notifications étendues : Les options sont nombreuses (Email, SMS, Discord, Teams, etc.), ce qui me permet d'être notifié sur mon téléphone dès qu'un service est en panne.
- Les pages de statut : La possibilité de créer des pages de statut publiques est un atout pour communiquer l'état des services accessibles aux utilisateurs.
Installation avec Docker
Avant d'installer Uptime Kuma, je recommande fortement d'utiliser un serveur dédié. En effet, si Uptime Kuma est hébergé sur le même serveur que celui que vous surveillez et que ce dernier tombe en panne, vous ne recevrez pas de notifications.
Dans mon cas, j'ai préparé un nouveau serveur sous Debian 13 sur lequel j'ai installé Docker. Il est possible d'installer Uptime Kuma sans Docker, mais la procédure est plus complexe.
L'installation via Docker est extrêmement simple : il suffit d'enregistrer la configuration suivante dans un fichier nommé compose.yaml.
services:
uptime-kuma:
image: louislam/uptime-kuma:2
restart: unless-stopped
volumes:
- ./data:/app/data
ports:
- "3001:3001"
Puis de rentrer la commande suivante :
docker compose up -d
Une fois que c'est fait, Docker va télécharger l'image d'Uptime Kuma, puis lancer le conteneur.
On peut désormais se rendre sur http://<IP_DE_VOTRE_SERVEUR>:3001/. Une interface nous invite ensuite à choisir la base de données que l'on souhaite utiliser. Les possibilités sont les suivantes :
- SQLite : Stocke toute la configuration et les données de monitoring dans un fichier local. Aucune configuration n'est nécessaire.
- MariaDB / MySQL : Stocke toute la configuration et les données de monitoring dans une base de données externe.
- MariaDB intégrée (L'option par défaut) : Une solution intermédiaire ne nécessitant pas de gestion complexe.
Dans mon cas, j'ai choisi l'option MariaDB intégrée pour sa simplicité.
Après la sélection, la base de données s'initialise. On est ensuite invité à créer un compte administrateur.
Une fois le compte créé, on atterrit sur l'interface principale d'Uptime Kuma. C'est ici qu'il est possible de configurer toutes nos sondes et nos notifications, mais surtout de visualiser si tous nos services sont en ligne.
Pour créer une sonde, il suffit de cliquer sur le bouton "Add New Monitor" qui se trouve en haut à gauche de la page principale. On est ensuite présenté à de nombreuses options. Dans mon cas, je vais par exemple créer une sonde Ping afin de monitorer mon point d'accès Wi-Fi et être averti s'il tombe en panne.
Je sélectionne donc le "Monitor Type" Ping, je lui donne un nom, j'indique l'adresse IP de mon point d'accès, et enfin je clique sur Save.
Il est aussi possible de configurer d'autres options comme :
- L'intervalle entre chaque Ping (Heartbeat Interval).
- Le nombre de tentatives avant de confirmer qu'un Ping a échoué (Retries).
- Un rappel toutes les X fois que le Ping échoue (Notification resend).
Une fois la sonde créée, on constate qu'elle est fonctionnelle. On peut alors visualiser la latence actuelle, la latence moyenne des dernières 24 heures et, surtout, le taux de disponibilité sur 24 heures, 30 jours et 1 an.
Cependant, si mon point d'accès Wi-Fi tombe en panne, je ne le saurai qu'en consultant cette page. Pour recevoir un avertissement en temps réel, il est nécessaire de configurer les notifications. Dans mon cas, je les configure via Discord.
Pour commencer, il faut disposer d'un serveur Discord où l'on possède les droits d'administration. Je crée d'abord un salon textuel dédié à Uptime Kuma.
Je recommande fortement cette pratique : si plusieurs services tombent en panne simultanément, cela évite de "spammer" les salons de discussion généraux avec des alertes techniques.
Ensuite, je configure le Webhook en me rendant dans les paramètres du salon, onglet Intégrations, puis en cliquant sur "Créer un Webhook". Une fois généré, je copie son URL (lien).
De retour dans Uptime Kuma, je clique sur mon profil en haut à droite, puis je me rends dans les "Settings". On y trouve la catégorie "Notifications" qui permet de configurer les alertes.
Je clique ensuite sur "Setup Notification" et je renseigne les paramètres suivants :
- Notification Type : Discord
- Friendly Name : Serveur Discord (ou tout autre nom de votre choix)
- Discord Webhook URL: Le lien du Webhook copié precedemment
- Bot Display Name : Laisser par défaut
- Prefix Custom Message : <@VOTRE ID DISCORD>
- Select message type : Send to channel
- Disable URL in notifications : (Non coché)
- Default enabled : (Coché)
- Apply on all existing monitors : (Coché)
Astuce : Pour récupérer son ID Discord, il suffit de faire un clic droit sur son profil puis de sélectionner "Copier l'identifiant utilisateur" (Copy User ID). L'ajout de cet ID dans le champ Prefix Custom Message permet d'être mentionné (ping) personnellement lors d'une alerte.
Il ne reste plus qu'à cliquer sur le bouton Test. Si la configuration est bonne, un message de test apparaît instantanément dans le salon Discord, on peut donc sauvegarder la configuration.
Pour l'exemple, je vais intentionnellement modifier l'adresse IP de la sonde de mon point d'accès Wi-Fi afin de simuler une panne.
On constate bien que je suis notifié sur Discord lorsque la sonde n'arrive plus à pinger le point d'accès. De même, lorsque je rétablis la bonne configuration, je reçois une seconde notification m'indiquant que le service est de retour. Le système d'alerte est donc parfaitement fonctionnel.
Conclusion
Pour conclure, Uptime Kuma est une véritable plus-value pour mon Homelab, non seulement cette solution est simple à déployer grâce à Docker, mais il apporte surtout une couche de professionnalisme nécessaire quand on héberge autant de services.
Je n'ai plus besoin de vérifier manuellement si mon serveur mail ou mes conteneurs fonctionnent : Uptime Kuma me prévient instantanément via Discord, c'est un gain de temps et de sérénité considérable qui me permet de continuer à expérimenter sur mes serveurs sans crainte de passer à côté d'une panne critique.