Solution communautaire

Installer Uptime Kuma sur CasaOS pour surveiller vos services auto-hébergés

A September 2023 CasaOS post introducing Uptime Kuma as a self-hosted availability monitor. The forum body contains little installation detail, so current Uptime Kuma Docker settings are needed for a durable setup page.

Le fil de discussion IceWhale de 2023 consacré à Uptime Kuma ressemble davantage à une introduction qu'à un guide d'installation. Le billet indique que le tutoriel couvre l'installation sur CasaOS, tandis que les réponses s'intéressent surtout aux raisons pour lesquelles les utilisateurs apprécient Uptime Kuma : notifications en cas de panne, surveillance en production de services non critiques et moniteurs push. Le texte du forum ne conserve pas la configuration détaillée de l'installateur, étape par étape.

Une page actuelle devrait donc conserver le contexte CasaOS et les cas d'utilisation de la communauté, tout en s'appuyant sur les exigences Docker maintenues d'Uptime Kuma pour le déploiement proprement dit.

Ce qu'Uptime Kuma apporte à un serveur domestique

Uptime Kuma est un tableau de bord de surveillance auto-hébergé. Il peut vérifier l'état d'un site web, d'un service TCP, d'un point de terminaison DNS, d'une cible ping, d'un service lié à Docker ou d'une tâche utilisant un mécanisme push, et envoyer des notifications lorsque l'état change.

Les réponses d'origine mettaient régulièrement en avant les notifications comme principal avantage pratique. Un tableau de bord est utile, mais le bénéfice essentiel est de savoir qu'un service est hors ligne avant qu'un membre du foyer ne le signale.

Utiliser le conteneur Uptime Kuma actuel

Les instructions actuelles de déploiement d'Uptime Kuma utilisent l'image maintenue louislam/uptime-kuma:2. L'application web écoute sur le port 3001 et stocke sa base de données persistante ainsi que sa configuration dans /app/data.

Pour créer une application personnalisée actuelle dans CasaOS, reportez les paramètres d'installation Docker maintenus d'Uptime Kuma dans le formulaire d'application CasaOS, plutôt que d'utiliser une ancienne balise d'image provenant d'une vidéo de 2023.

Exposer le tableau de bord sur le port 3001

Le service web du conteneur utilise le port TCP 3001. Si ce port est déjà occupé sur l'hôte, mappez un autre port hôte vers le port 3001 du conteneur, puis ouvrez l'application CasaOS via le port hôte choisi.

Modifier le port hôte ne nécessite pas de modifier le port interne d'Uptime Kuma, sauf si l'application en amont prend explicitement en charge ce changement et en a besoin.

Conserver /app/data

Mappez un dossier hôte CasaOS ou un volume Docker vers /app/data. Il s'agit de la principale cible de sauvegarde, car ce répertoire contient la configuration de surveillance, les données utilisateur et la base de données SQLite.

Recréer le conteneur sans ce volume persistant revient à démarrer une nouvelle installation d'Uptime Kuma.

Conserver la base de données sur un système de fichiers offrant un verrouillage fiable

Les recommandations actuelles d'Uptime Kuma indiquent que la base de données SQLite nécessite un verrouillage fiable des fichiers POSIX et mettent spécifiquement en garde contre les systèmes de fichiers tels que de nombreuses configurations NFS pour son répertoire de données.

Sur un serveur domestique, conserver /app/data sur un stockage local est le choix le plus simple. Vous pourrez ensuite sauvegarder ce répertoire local sur un autre disque ou une cible distante.

Choisir des moniteurs adaptés à l'expérience utilisateur

Un moniteur ping prouve seulement qu'une machine répond à l'ICMP. Si le véritable besoin est de vérifier que « Jellyfin doit se charger », un moniteur HTTP ciblant le point de terminaison Jellyfin est plus pertinent.

Un ensemble pratique peut inclure :

  • des vérifications HTTP pour les applications web ;
  • des vérifications TCP pour les services dépourvus de point de terminaison web utile ;
  • des vérifications DNS pour Pi-hole ou AdGuard Home ;
  • des vérifications ping pour contrôler la joignabilité de base des hôtes ;
  • des moniteurs push pour les tâches planifiées qui doivent signaler leur achèvement.

Pourquoi le moniteur push mentionné dans le fil est important

Un participant de la communauté a indiqué utiliser fréquemment des moniteurs push. Au lieu qu'Uptime Kuma interroge un service, un script de sauvegarde ou une tâche planifiée appelle une URL unique lorsqu'il réussit. Si ce signal n'arrive pas dans le délai prévu, Uptime Kuma marque le moniteur comme défaillant.

Cela est utile pour les tâches où « le serveur est en ligne » ne prouve pas que le travail a réellement été exécuté.

Tester les notifications avant la première panne

Configurez au moins un canal de notification et déclenchez volontairement une alerte de test. Un système de surveillance qui échoue silencieusement à envoyer des notifications n'est qu'un tableau de bord historique.

Pour les services domestiques, tenez également compte de la fatigue liée aux alertes. Surveiller chaque point de terminaison mineur avec des notifications immédiates peut rendre les véritables pannes plus faciles à ignorer.

Garder le tableau de bord de surveillance privé, sauf si l'accès distant est intentionnel

Uptime Kuma peut révéler des noms d'hôtes internes, des noms de services, des adresses réseau et l'historique des pannes. Ne l'exposez pas directement à Internet simplement parce que la surveillance à distance est utile. Utilisez un VPN, un réseau superposé privé ou un proxy inverse authentifié si un accès distant est nécessaire.

Ne pas considérer le fil CasaOS de 2023 comme une version actuelle à figer

La discussion source fait l'éloge d'une application bien maintenue, mais ne conserve pas de version d'image. C'est préférable : utilisez la version actuelle publiée en amont plutôt que d'essayer de recréer exactement le conteneur qui existait en septembre 2023.

FAQ sur Uptime Kuma sur CasaOS

Quel port la version actuelle d'Uptime Kuma utilise-t-elle ?

Le port 3001 pour l'interface web.

Quel répertoire doit être conservé ?

/app/data.

Pourquoi le répertoire de données doit-il rester sur un stockage local ?

La base de données SQLite nécessite un verrouillage fiable des fichiers, et les recommandations actuelles du projet mettent en garde contre les systèmes de fichiers réseau inadaptés.

Qu'est-ce que la communauté d'origine appréciait le plus ?

Les notifications et la fonctionnalité de moniteur push ont été mises en avant à plusieurs reprises dans les réponses.