Fraîche Flow

Linux · Infrastructure · Réseaux · Virtualisation

docs/Supervision centrale avec Uptime Kuma
72 lignes3,24 KB

Supervision centrale avec Uptime Kuma

MILOUD NECILI

Fraîche Flow · Intégration de systèmes informatiques

Objectif du projet

Superviser centralement l’infrastructure du laboratoire et créer les moniteurs automatiquement plutôt qu’individuellement dans l’interface.

Ma réalisation

  • Exploité Uptime Kuma 2.5.8 avec une MariaDB distincte dans le projet Compose.
  • Utilisé AutoKuma 2.0.0 avec des labels Docker pour créer automatiquement les moniteurs.
  • Configuré des tests HTTP, de ports TCP et ping pour 15 points de terminaison.
  • Isolé les erreurs Socket.IO, de base et de joignabilité à l’aide des journaux et des signaux de présence.

Cadre technique

Conteneurs uptime-kuma, kuma-db, autokuma
Projet ~/docker/uptime-kuma
Accès Termius : local 13001 → interne 3001
Vue finale 15 en ligne · 0 hors ligne · 0 inconnu

Résultat

La vue finale jointe montre 15 moniteurs en ligne et 0 hors ligne. Cinq signaux de présence successifs de System MariaDB indiquaient status=1. Certaines disponibilités historiques restaient inférieures à 100 %.

Vérification et preuves de fonctionnement

docker ps --filter name=uptime-kuma --filter name=kuma-db --filter name=autokuma
docker logs --tail 40 autokuma
curl --max-time 10 -sS "http://127.0.0.1:3001/socket.io/?EIO=4&transport=polling"

Pile de supervision avec Uptime Kuma, MariaDB, AutoKuma et réponse Socket.IO réussie

Dépannage en pratique

L’indentation YAML, les erreurs initiales EngineIO et les interruptions Socket.IO ont été examinées. ER_DUP_ENTRY est apparu dans stat_daily et stat_hourly ; aucune correction durable de ce problème statistique n’est attestée.

Sécurité et mise en contexte technique

Les tests TCP sur 443 et 9443 ne valident ni les certificats TLS ni la connexion. Le ping vers DNS et Chrony ne teste pas leurs protocoles respectifs. Le socket Docker et l’accès administrateur nécessitent une protection particulière.

Compétences acquises

Observabilité, création déclarative des moniteurs, corrélation des journaux et interprétation de la disponibilité.

Preuve finale : supervision

Tableau de bord Uptime Kuma avec services d’infrastructure et applicatifs supervisés

L’historique indique 39,13 % pour System MariaDB et 50 % pour TrueNAS. La joignabilité actuelle est verte ; cela n’implique pas une disponibilité historique continue de 100 %.

Points de terminaison supervisés

  • HTTP : Uptime Kuma, Nextcloud Docker, Docker Webserver.
  • Port TCP : Apache HTTP, Nextcloud HTTPS, Portainer HTTPS, System MariaDB, Kuma MariaDB, Docker MariaDB, Redis Container.
  • Ping : Application ff-app-01, Chrony Container, DNS ff-core-01, Gateway ff-edge-01, TrueNAS ff-store-01.

Les noms des moniteurs sont des noms du projet. Un test de port TCP HTTPS ne remplace pas la validation du certificat ; un ping DNS ou Chrony ne remplace pas un test fonctionnel DNS ou NTP.

État du projet

Terminé selon la confirmation du responsable du projet.