Uptime Kuma fait partie des outils de surveillance auto-hébergés les plus utilisés dans la communauté homelab, et la version 2.5.0 vient de sortir. La release est signée et publiée sur la page GitHub officielle du projet. Et malgré un numéro de version qui a l’air anodin, le changement est loin d’être cosmétique : un nouveau type de moniteur, un plafond d’intervalle de vérification qui saute, et une refonte de la façon dont le projet récupère ses propres dépendances, pensée directement pour limiter le risque de chaîne d’approvisionnement. L’outil reste sous licence MIT, se lance toujours depuis un conteneur Docker unique ou directement via Node.js, et continue de surveiller sites web, ports TCP, enregistrements DNS, conteneurs Docker, et même des serveurs de jeu Steam, avec une alerte dès qu’un service cesse de répondre. Près de 90 000 étoiles et plus de 8 000 forks sur GitHub plus tard, Uptime Kuma est devenu quasiment le choix par défaut pour qui veut une page de statut qu’il contrôle vraiment.
Un nouveau type de moniteur : NTP
Uptime Kuma 2.5.0 ajoute un moniteur NTP (Network Time Protocol) dédié, pour surveiller directement un serveur de temps plutôt que la simple machine qui l’héberge. C’est un vrai manque comblé. Quand une source de temps dérive ou tombe, les vérifications de certificats TLS commencent à échouer et les horodatages de logs sur l’ensemble du parc cessent silencieusement d’être cohérents entre eux. Deux problèmes qui, en général, ne se remarquent que lorsqu’autre chose casse à cause d’eux. Avant cette version, la meilleure approche possible restait de surveiller l’hôte qui fait tourner le service NTP, pas le protocole lui-même.
Fini le plafond de 24 jours sur les intervalles
Les intervalles de vérification plafonnaient jusqu’ici autour de 24 jours. Cette limite disparaît avec la 2.5.0. Vérification trimestrielle, date d’expiration d’un certificat, renouvellement de nom de domaine : peu importe le besoin, plus la peine de simuler un intervalle plus court juste pour rester sous l’ancien plafond.
Nouveaux canaux de notification
La liste des intégrations s’allonge encore avec cette version : Plivo (SMS et appels vocaux), Ooredoo (SMS, pour les numéros aux Maldives), WxPusher SPT et Flowtriq pour la détection DDoS, plus le tracking rybbit sur les pages de statut publiques et quelques en-têtes SMTP supplémentaires pour les alertes par e-mail. Uptime Kuma comptait déjà environ 90 intégrations avant cette sortie, donc il y a de bonnes chances que votre canal d’alerte préféré soit déjà couvert.
Le vrai changement : un délai de sécurité de 14 jours sur les mises à jour npm
Le changement qui a la portée la plus large dans la 2.5.0 ne touche pourtant jamais à l’interface. Uptime Kuma attend désormais 14 jours avant d’adopter une nouvelle version d’un paquet npm, un changement que le changelog du projet classe lui-même dans sa section Security Fixes plutôt que dans les nouveautés. Le raisonnement se tient : quand une version malveillante d’une dépendance se glisse sur npm, elle est généralement repérée et retirée en quelques jours, et c’est donc le logiciel qui récupère la mise à jour dès sa sortie qui encaisse le plus de dégâts. Uptime Kuma tourne dans des réseaux domestiques et de petites entreprises, et détient des identifiants pour des dizaines de services de notification, ce qui rend son arbre de dépendances intéressant à attaquer. Un délai de deux semaines signifie que la grande majorité des installations ne touchera tout simplement jamais aux paquets qui finissent retirés. Help Net Security a d’ailleurs pointé ce changement comme l’élément le plus marquant de la version, devant le moniteur NTP et le déplafonnement des intervalles.
Aussi dans cette version
La 2.5.0 ajoute un sélecteur PM2 ou plateforme pour les installations en service système, ainsi qu’un tag Docker « next-rootless » pour qui préfère que le conteneur ne tourne pas en root. Une série de corrections de bugs accompagne la release : une URL de génération de badge cassée par un double slash, les moniteurs MQTT qui acceptent enfin les adresses mqtts://, les moniteurs de serveurs de jeu Steam qui résolvent désormais les noms d’hôte au lieu d’exiger une IP brute, un moniteur DNS qui n’ajoute plus le port du resolver à l’URL du service, et les notifications Discord qui affichent enfin les horodatages dans le bon fuseau horaire. Une correction côté base de données passe facilement inaperçue mais mérite d’être connue : les colonnes de compteurs up et down de la table stat_daily passent d’un SMALLINT signé, plafonné à 32 767, à un entier non signé. Sur une installation qui surveille beaucoup d’hôtes à intervalles courts, un compteur journalier pouvait dépasser cet ancien plafond, ce que le projet cite comme explication possible si votre historique de disponibilité a déjà affiché des trous ou des valeurs bizarres lors de journées chargées.
Faut-il mettre à jour ?
Pour qui fait déjà tourner Uptime Kuma, la 2.5.0 est une mise à jour à faible risque : un nouveau type de moniteur, de nouveaux fournisseurs de notification, un plafond d’intervalle relevé, et une série de corrections de bugs, sans rien signalé comme cassant dans les notes de version. Si vous n’avez pas encore mis en place de moniteur de disponibilité auto-hébergé, notre fiche Uptime Kuma détaille l’installation Docker, la surveillance HTTP/TCP/ping et les pages de statut publiques en partant de zéro. Et si vous cherchez à situer Uptime Kuma face aux outils plus orientés métriques, notre comparatif du monitoring self-hosted le met face à Netdata et Prometheus/Grafana.
Sources : les notes de version d’Uptime Kuma 2.5.0 sur GitHub, et l’article de Help Net Security sur le délai de sécurité npm.