Reprendre le contrôle de son monitoring : Pourquoi et comment nous avons migré vers Uptime Kuma et Docker

1. Pourquoi Uptime Kuma ? La fin des compromis SaaS

Uptime Kuma s’est imposé en quelques années comme l’alternative open-source incontournable aux solutions de monitoring traditionnelles.

2. Le choix de l’architecture : L’efficacité du couple Docker & Caddy

Pour garantir une maintenance sans friction et un niveau de sécurité optimal, nous avons articulé notre stack autour de trois briques complémentaires :

1. Docker & Docker Compose : Isolation totale du service, reproductibilité immédiate et mise à jour transparente sans polluer l’hôte.
2. Caddy Server (Reverse Proxy) : Gestion entièrement automatisée des certificats TLS/SSL (Let’s Encrypt), zéro configuration complexe pour le renouvellement HTTPS, et performances HTTP/3 natives.
3. Volume monté persistant (bind mount) : Stockage direct des données applicatives dans un dossier d’hôte (uptime-data) pour simplifier les opérations d’audit et les sauvegardes à chaud.

Le fichier docker-compose.yml

Voici la structure de notre stack de production :

version: "3.8"

services:
  caddy:
    image: caddy:2-alpine
    container_name: caddy-proxy
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - uptime-network

  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    restart: always
    volumes:
      - ./uptime-data:/app/data
    networks:
      - uptime-network

networks:
  uptime-network:
    driver: bridge

volumes:
  caddy_data:
  caddy_config:

La configuration du reverse proxy (Caddyfile)

Caddy s’occupe de router les requêtes du sous-domaine dédié vers le conteneur Node.js en gérant le WebSocket en temps réel :

status.votre-domaine.com {
    reverse_proxy uptime-kuma:3001
}

Déploiement en une seule commande :

docker compose up -d

3. Guide de configuration : Sécurisation et pages de statut

Une fois l’instance déployée, deux étapes sont indispensables avant d’ajouter vos sondes :

3.1 Sécuriser l’accès d’administration

• Création du compte initial : À la première visite sur votre URL, définissez un mot de passe robuste.
• Activer la double authentification (2FA / TOTP) : Rendez-vous dans Paramètres > Sécurité et activez le TOTP. La clé secrète peut être stockée dans votre gestionnaire d’équipe (Bitwarden, KeePass) pour autoriser plusieurs administrateurs.
• Masquer le dashboard aux visiteurs : Dans Paramètres > Général, configurez la page d’accueil par défaut pour qu’elle pointe vers votre page de statut publique plutôt que sur le formulaire de connexion technique.

3.2 Personnaliser la page de statut client

Uptime Kuma intègre un éditeur Markdown/HTML pour personnaliser l’en-tête de vos pages de statut. Cela permet d’afficher directement vos coordonnées d’assistance technique ou vos liens contractuels, avec un rendu responsive adapté aux modes clair et sombre :

Besoin d'assistance ? [eoxia.com](https://eoxia.com/) · Standard : [04 11 93 00 20](tel:+33411930020) · Support tech : [04 11 93 00 21](tel:+33411930021)

4. Sauvegarde automatique et résilience de la base SQLite

Uptime Kuma enregistre toutes ses données, alertes et historiques dans un fichier unique : kuma.db (SQLite).

Une erreur fréquente consiste à simplement compresser le dossier pendant que le conteneur tourne. Cela risque de corrompre la base si une transaction SQLite Write-Ahead Log (.db-wal) est en cours.

Notre stratégie d’automatisation avec rotation à 7 jours

Nous avons mis en place un script bash qui ordonne à SQLite de faire un instantané propre (.backup), compresse le dossier et purge les archives de plus de 7 jours :

#!/usr/bin/env bash
set -euo pipefail

DATA_DIR="/home/ubuntu/uptime-stack/uptime-data"
BACKUP_DIR="/home/ubuntu/backups/uptime-kuma"
DATE=$(date +'%Y-%m-%d_%H%M%S')
ARCHIVE_NAME="uptime-kuma-backup-${DATE}.tar.gz"

mkdir -p "${BACKUP_DIR}"

# 1. Sauvegarde SQLite intègre à chaud sans couper le service
docker exec uptime-kuma sqlite3 /app/data/kuma.db ".backup '/app/data/kuma.db.bak'"

# 2. Archivage compressé
tar -czf "${BACKUP_DIR}/${ARCHIVE_NAME}" -C "$(dirname "${DATA_DIR}")" "$(basename "${DATA_DIR}")"

# 3. Nettoyage du snapshot temporaire
docker exec uptime-kuma rm -f /app/data/kuma.db.bak

# 4. Rotation automatique sur 7 jours
find "${BACKUP_DIR}" -type f -name "uptime-kuma-backup-*.tar.gz" -mtime +7 -delete

echo "[$(date)] Sauvegarde validée : ${ARCHIVE_NAME}"

Ce script est exécuté chaque nuit à 03h00 du matin via crontab -e :

0 3 * * * /home/ubuntu/scripts/backup-uptime.sh >> /home/ubuntu/backups/uptime-kuma/backup.log 2>&1

En cas de défaillance matérielle ou de réinstallation sur une nouvelle machine, la restauration s’exécute en moins de deux minutes : décompression de l’archive tar -xzf, assignation des droits chown -R 1000:1000 et démarrage du conteneur.

En conclusion

En reprenant la main sur notre infrastructure de monitoring avec Uptime Kuma et Docker, nous avons gagné sur tous les tableaux :

• Zéro abonnement récurrent superflu.
• Maîtrise totale de nos données et de la disponibilité de nos clients.
• Déploiement reproductible et résilient avec une stratégie de backup testée.

Vous souhaitez déployer une architecture similaire pour vos applications ou fiabiliser la supervision de vos plateformes web ? Contactez l’équipe Eoxia pour échanger sur vos projets DevOps et open-source.

Les ressources

• https://github.com/louislam/uptime-kuma
• https://github.com/louislam/uptime-kuma/pkgs/container/uptime-kuma
• Les dons : https://opencollective.com/uptime-kuma