Installer Uptime Kuma sur Synology et surveiller ses services
Déployer Uptime Kuma avec Container Manager, configurer le pare-feu et le proxy inverse de DSM, puis créer les premiers moniteurs et notifications.
Uptime Kuma transforme un NAS Synology en poste de supervision autonome. Tant que le NAS et son réseau fonctionnent, il vérifie en continu les sites Web, serveurs, bases de données et autres services que vous lui confiez, conserve leur historique et vous prévient rapidement lorsqu’un contrôle échoue.
Pourquoi utiliser Uptime Kuma
Uptime Kuma est une application open source de surveillance de disponibilité. Elle joue le rôle d’une alarme personnelle : elle contrôle qu’un site, un serveur ou un service réseau répond encore et déclenche une notification dès que son état change.
Le besoin est simple : savoir à quel moment un site ne répond plus, surveiller la qualité d’une connexion Internet ou mesurer la disponibilité d’un équipement chez un opérateur. Au lieu de découvrir la panne par hasard, vous recevez immédiatement une alerte par messagerie, courrier électronique ou l’un des nombreux services compatibles.
Uptime Kuma réunit notamment les fonctions suivantes :
- contrôle des domaines HTTP et HTTPS, avec recherche facultative d’un mot-clé dans la page ;
- surveillance des enregistrements DNS, des conteneurs Docker et de bases de données telles que MySQL, MariaDB ou Microsoft SQL Server ;
- interface réactive, claire et rapide à parcourir ;
- mode sombre manuel ou synchronisé avec le thème du système ;
- graphiques de latence et statistiques de disponibilité dans le temps ;
- alertes vers de nombreux services, par exemple Telegram, Slack, Discord, Microsoft Teams, Signal, Gotify, Ntfy, Opsgenie ou PagerDuty ;
- prise en charge d’un proxy pour les contrôles qui doivent sortir par un intermédiaire ;
- intervalle de contrôle descendant à 20 secondes lorsque le type de moniteur le permet ;
- interface traduite dans de nombreuses langues, dont le français ;
- pages de statut publiques pour informer des utilisateurs ou annoncer une maintenance ;
- suivi de l’expiration des certificats TLS et protection du compte par authentification à deux facteurs.
Je cherchais depuis longtemps une solution de ce type. Les services hébergés étaient soit payants, soit trop limités pour mon usage. Ici, le nombre de moniteurs dépend surtout des ressources du NAS et de la fréquence choisie, tandis que les modes de contrôle et de notification couvrent la plupart des besoins d’un petit réseau ou d’un laboratoire domestique.
Préparer les dossiers persistants
Dans le partage docker, créez un dossier uptime-kuma, puis un sous-dossier data. La base de données, les réglages, les certificats suivis et la configuration de l’instance y seront conservés hors du conteneur.
Créer le projet dans Container Manager
Ouvrez Container Manager → Projet → Créer. Nommez le projet kuma, sélectionnez le chemin /docker/uptime-kuma, choisissez la création d’un fichier docker-compose.yml, puis saisissez la configuration suivante :
services:
uptime-kuma:
image: louislam/uptime-kuma:2
restart: unless-stopped
volumes:
- ./data:/app/data
ports:
# <Port du NAS>:<Port du conteneur>
- "3005:3001"
environment:
TZ: Europe/BrusselsLe tag majeur :2 suit la branche stable d’Uptime Kuma 2. Lors de cette vérification, la version stable publiée est la 2.5.3. Si vous préférez valider manuellement chaque mise à jour, remplacez le tag majeur par une version précise, puis revenez au tag :2 lorsque votre procédure de test est prête.
Validez le projet. Container Manager télécharge l’image, crée le réseau Docker et démarre le service. Le message Exit Code: 0 signifie que la création s’est achevée sans erreur. Contrôlez ensuite que le conteneur apparaît bien à l’état actif.
Configurer le pare-feu DSM
Si le pare-feu DSM est activé, le conteneur doit pouvoir joindre les cibles à surveiller. Dans Container Manager → Réseau, développez kuma_default et relevez son sous-réseau. La capture montre 172.18.0.0/16 ; le masque /16 correspond à 255.255.0.0.
Ajoutez une règle DSM adaptée à ce sous-réseau et aux destinations nécessaires, puis placez-la avant les règles de refus. Ne recopiez pas aveuglément 172.18.0.0/16 : Docker peut choisir une autre plage si elle est déjà occupée. Évitez aussi d’autoriser tous les ports vers tout le réseau lorsque Kuma n’a besoin que de quelques services internes.
Publier Kuma avec le proxy inverse
Pour accéder à Uptime Kuma par un nom de domaine, ouvrez Panneau de configuration → Portail de connexion → Avancé → Proxy inversé, puis créez une règle. L’article d’origine mentionnait ici Joplin par erreur : la destination est bien le serveur Uptime Kuma.
- Source : protocole HTTPS, nom d’hôte tel que
kuma.exemple.be, port443. - Destination : protocole HTTP, nom d’hôte
localhost, port3005. - En-tête personnalisé : choisissez Créer → WebSocket pour ajouter automatiquement
UpgradeetConnection.
Créez au préalable l’enregistrement DNS de kuma.exemple.be et affectez au proxy un certificat TLS valide pour ce sous-domaine. Uptime Kuma utilise WebSocket : sans les deux en-têtes affichés dans la capture, l’interface peut charger tout en restant incapable de se connecter au serveur. Utilisez un sous-domaine dédié plutôt qu’un chemin comme /uptime-kuma, qui n’est pas officiellement pris en charge.
Effectuer la configuration initiale
Ouvrez https://kuma.exemple.be. Tant que le port 3005 est accessible depuis votre réseau d’administration, vous pouvez aussi utiliser http://IP-DU-NAS:3005 pour le premier diagnostic. L’URL Joplin présente dans l’article source était une coquille et a été corrigée ici.
Au premier démarrage, choisissez la langue française puis le moteur de base de données. SQLite reste le choix le plus simple pour une petite installation et celui utilisé dans cette configuration. Uptime Kuma 2 propose également MariaDB embarquée ou un serveur MariaDB/MySQL externe. Choisissez dès le départ en connaissance de cause : la migration directe d’une base SQLite existante vers MariaDB n’est pas officiellement prise en charge.
Créez ensuite le premier compte administrateur. Utilisez un identifiant qui ne soit pas évident, un mot de passe unique stocké dans un gestionnaire, puis activez l’authentification à deux facteurs dans les paramètres dès que l’accès est validé.
Ajouter des moniteurs et notifications
Cliquez sur Nouveau moniteur, choisissez le type de contrôle et renseignez la cible. Pour un site Web, commencez par HTTP(s), indiquez son URL, sélectionnez un intervalle et conservez des délais raisonnables. Le mode « mot-clé » est utile lorsqu’un simple code HTTP 200 ne suffit pas à prouver que la bonne page est servie.
Vous pouvez ensuite créer des contrôles Ping, TCP, DNS, Docker, MQTT, gRPC, SNMP ou bases de données selon vos besoins. Organisez-les par groupes et tags, nommez-les clairement, puis créez une page de statut distincte si des utilisateurs doivent consulter la disponibilité sans accéder au tableau de bord d’administration.
Dans Paramètres → Notifications, ajoutez au moins un canal et envoyez une alerte de test. Telegram, Signal, Slack, Teams, Gotify, Ntfy, Pushover et de nombreux autres fournisseurs sont disponibles. Associez ensuite la notification aux moniteurs concernés ; créer le fournisseur ne l’active pas automatiquement partout.
Testez enfin une vraie transition : arrêtez brièvement un service non critique, attendez l’alerte d’indisponibilité, redémarrez-le et vérifiez la notification de retour à la normale. Ce contrôle évite de découvrir, pendant une panne réelle, qu’un jeton ou une adresse de destination était incorrect.
Limites et maintenance
Cette installation fonctionne depuis longtemps avec plusieurs dizaines de services et consomme peu de ressources. La capture finale indique environ 180 Mo de mémoire et moins de 1 % de CPU à cet instant ; les besoins varient toutefois selon le nombre de contrôles, leur fréquence, les notifications et la durée de conservation.
Sauvegardez le dossier data avant toute mise à jour. Dans Container Manager, récupérez la nouvelle image puis recréez le projet avec le même volume. Consultez les notes de version, vérifiez le tableau de bord et déclenchez une notification de test après chaque changement.
Conclusion
Uptime Kuma est maintenant installé sur le NAS Synology, accessible en HTTPS derrière le proxy inverse et prêt à surveiller vos services. Il reste à créer les contrôles utiles, à régler leur fréquence, à associer les alertes et à vérifier régulièrement que les sauvegardes et notifications fonctionnent réellement.
Discussion
Commentaires
Aucun commentaire pour le moment. Vous pouvez ouvrir la discussion avec une question ou un retour d’expérience.
La connexion protège les échanges du spam et évite de publier votre adresse e-mail.
Se connecter pour commenter →