🩺 Monitoring des noeuds et des services - 1ère partie
Introduction
Nous avons vu dans les précédent chapitres comment renforcer la sécurité avec notamment la mise en place de Crowdsec et la sauvegarde.
Nous allons maintenant monter un service de monitoring basique dont l'objectif principal est de nous signaler si un service ou un noeud est down.
Pour cela, nous utiliserons Uptime-Kuma qui est léger, facile à installer et à prendre en main. Il permet de déployer rapidement un monitoring efficace basé sur des sondes configurables utilisant différents protocoles (ICMP, TCP, HTTP...) et un système d'alerting (mail, sms,...) en cas de défaillance remontée par une sonde.
À partir de là, nous pourrons commencer à installer des services.
Limites de Uptime-Kuma
L'application présente quelques limites :
- On ne peut pas récupérer l'état des conteneurs en interrogeant directement la socket interne de Docker.
- L'affichage de l'historique de disponibilté remonte uniquement sur 30 jours même si on le règle sur 360 jours.
Installation de Uptime-Kuma
olivier@ds01:~$ sudo mkdir -p /mnt/nfsdatas/uptime-kuma/uptime-kuma-data
olivier@ds01:~$ sudo chown -R olivier: /mnt/nfsdatas/uptime-kuma
olivier@ds01:~$ cd /mnt/nfsdatas/uptime-kuma
olivier@ds01:/mnt/nfsdatas/uptime-kuma$ vim docker-stack.yml
services:
uptime-kuma:
image: louislam/uptime-kuma:1
volumes:
- ./uptime-kuma-data:/app/data
networks:
- web
environment:
PUID: 1001
GID: 1001
deploy:
placement:
constraints:
- node.role == worker
restart_policy:
condition: on-failure
replicas: 1
labels:
- "traefik.enable=true"
- "traefik.docker.network=web"
- "traefik.http.routers.uptime-kuma.rule=Host(`uk.dev.quercylibre.fr`)"
- "traefik.http.routers.uptime-kuma.tls=true"
- "traefik.http.routers.uptime-kuma.tls.certresolver=letsencrypt"
- "traefik.http.routers.uptime-kuma.middlewares=uptime-kuma-admin-ipallowlist,crowdsec@file"
# Seul mon LAN a accès à l'application
- "traefik.http.middlewares.uptime-kuma-admin-ipallowlist.ipallowlist.sourcerange=127.0.0.1/32, 192.168.1.0/24"
- "traefik.http.services.uptime-kuma.loadbalancer.server.port=3001"
- "traefik.http.routers.uptime-kuma.service=uptime-kuma"
networks:
web:
external: true
olivier@ds01:/mnt/nfsdatas/uptime-kuma$ docker stack deploy -c docker-stack.yml -d uptime-kuma
olivier@ds01:/mnt/nfsdatas/uptime-kuma$ docker stack ps uptime-kuma
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
g1upi0qqzaqn uptime-kuma_uptime-kuma.1 louislam/uptime-kuma:1 ds04 Running Running 16 minutes ago
Configuration du monitoring
Une fois le service démarré, il suffit de se rendre sur l'URL définie.
Configuration de base
La première étape consiste à paraméter le reverse-proxy afin que les IP réelles des clients soient prises en compte par Uptime-Kuma dans ses logs.
Rendez-vous sur "Paramètres"
Cliquez sur "Proxy inverse" puis cochez "oui" dans la partie "En-têtes HTTP / Proxy de confiance" puis sauvegardez.
Ajout d'une sonde
Nous allons ajouter des sondes pour vérifier l'état des noeuds en s'appuyant sur le protocole ICMP, autrement dit : ping.
Cliquez sur "Ajouter une sonde" puis configuez comme ceci :
Vous devriez voir alors apparaître la sonde comme ci-dessous :
Faites de même avec les autres noeuds.
Pour finir, nous allons ajouter un test sur le dashboard de Traefik. Si nous créons une sonde basée sur HTTPS, nous aurons une erreur 403 (filtrage IP oblige) et cela aura pour conséquence d'identifier le service comme "down". Nous allons donc créer une sonde basée sur TCP pour interroger le port 443.
Configuration des notifications
Nous avons maintenant quelques sondes pour notre PoC. Comme dit en introduction, nous devons être notifié en cas de souci. Rien de plus simple, il vous suffit de vous rendre dans les paramètres puis de créer une alerte par mail en choisissant "Courriel (SMTP)". Renseignez les informations concernant le serveur mail et les adresses mails (expéditeur/destinataire(s)). Testez et si OK, appliquez cette notification à toutes les sondes existantes.
Conclusion
Uptime Kuma est basique mais c'est du "quick-win" sans se prendre la tête. Maintenant pour bien faire, il faudra compléter par des outils de monitoring plus avancés et hébergés en dehors du cluster Swarm. C'est ce que nous verrons dans une deuxième partie.
Pour le moment, seul l'admin (ou les admins) ont accès au statut des services. En même temps cela n'est pas génant puisque nous n'avons déployé aucun service applicatif pour les utilisateurs. Cependant nous verrons plus tard comment mettre en place une page publique indiquant uniquement l'état des services applicatifs.