Monitoring et alertes

Contexte

Le monitoring repond a une question simple : est-ce que tout tourne ? Et si non, depuis quand et pourquoi ? Sans monitoring, vous decouvrez les pannes quand vos utilisateurs vous ecrivent. Avec monitoring, vous les decouvrez avant eux.

Trois niveaux. Commencez par le premier. Montez quand le besoin se manifeste.

Niveau 1 : simple (cron + Telegram)

C'est le health check de la section 5.1 sur un cron, avec alerte Telegram. Zero infrastructure supplementaire.

Ce que ca couvre

• Services up/down.
• Espace disque.
• PostgreSQL accessible.
• Certificats SSL valides.

Ce que ca ne couvre pas

• Historique des metriques (pas de graphes).
• Temps de reponse.
• Metriques applicatives (requetes/seconde, erreurs).
• Monitoring depuis l'exterieur (si le serveur tombe completement, le cron ne s'execute pas).

Mise en place

Voir section 5.1. Resume :

# Cron toutes les 4 heures
0 */4 * * * /opt/scripts/health-check.sh --quiet

# Alerte Telegram si KO

Temps de mise en place : 30 minutes. Cout : 0 EUR.

Niveau 2 : intermediaire (Uptime Kuma)

Uptime Kuma est un outil de monitoring self-hosted. Interface web, historique, notifications multiples.

Installation

# Via Docker (la methode recommandee)
docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 3001:3001 \
  -v uptime-kuma-data:/app/data \
  louislam/uptime-kuma:1

# Ou dans docker-compose.yml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma-data:/app/data

volumes:
  uptime-kuma-data:

Configuration

1. Ouvrez http://votre-ip:3001.
2. Creez un compte admin.
3. Ajoutez des moniteurs :

1. Configurez les notifications : Telegram, email, ou Slack.

Ce que ca ajoute

• Historique d'uptime (graphes).
• Temps de reponse moyen.
• Notifications flexibles (multi-canal).
• Page de statut publique (optionnel).
• Monitoring depuis le meme serveur (limitation : si le serveur tombe, Uptime Kuma tombe aussi).

Temps de mise en place : 1 heure. Cout : 0 EUR (self-hosted).

Niveau 3 : avance (Grafana + Prometheus)

Pour ceux qui ont besoin de metriques detaillees, de dashboards personnalises, et de monitoring distribue.

Stack

Prometheus : collecte les metriques (CPU, RAM, disque, requetes).
Node Exporter : expose les metriques systeme pour Prometheus.
Grafana : affiche les dashboards.
AlertManager : gere les alertes.

Installation (Docker Compose)

services:
  prometheus:
    image: prom/prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    ports:
      - "9090:9090"

  node-exporter:
    image: prom/node-exporter
    ports:
      - "9100:9100"
    pid: host
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro

  grafana:
    image: grafana/grafana
    ports:
      - "3002:3000"
    volumes:
      - grafana-data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=changeme

volumes:
  prometheus-data:
  grafana-data:

Quand c'est justifie

• Vous gerez 3+ services avec des SLA.
• Vous avez besoin de correler CPU/memoire/reseau avec les performances applicatives.
• Vous avez une equipe qui consulte les dashboards.
• Vous facturez de l'uptime a vos clients.

Quand c'est du over-engineering

• Vous etes seul avec 2 containers.
• Personne ne regarde les dashboards.
• Un cron + Telegram suffit pour votre usage.

Temps de mise en place : 4-8 heures. Cout : 0 EUR (self-hosted) + temps de maintenance.

Niveau 0 : le gateway lui-meme (avant tout outil)

Avant d'installer le moindre outil de monitoring, exploitez ce que le gateway fait deja nativement. Voir la section 5.15 (Diagnostiquer et monitorer le gateway) pour les details.

En resume : openclaw gateway status + openclaw health + un cron qui alerte via Telegram si le health check echoue. C'est le monitoring le plus fiable avec zero outil supplementaire.

# Cron toutes les 5 minutes — zero outil, zero container
*/5 * * * * curl -sf http://127.0.0.1:3000/health > /dev/null || /chemin/alerte-telegram.sh "Gateway KO"

Passez au niveau 1 uniquement quand le niveau 0 ne suffit plus (par exemple, vous voulez surveiller d'autres services que le gateway).

Recommandation

Commencez par le niveau 0 (gateway natif). Si ca suffit, arretez-vous la. Beaucoup de setups solo n'ont jamais besoin d'aller plus loin.

Passez au niveau 1 quand : - Vous avez d'autres services a surveiller (hors gateway). - Vous voulez un script centralise.

Passez au niveau 2 quand : - Vous voulez un historique d'uptime avec des graphes. - Vous avez 5+ services a surveiller. - Vous voulez une page de statut publique.

Passez au niveau 3 quand : - Vous avez des SLA contractuels a respecter. - Vous avez une equipe ops dediee qui consulte des dashboards. - Vous gerez 10+ services sur plusieurs serveurs.

Realite : La plupart des setups solo et petites equipes n'auront jamais besoin du niveau 3. Prometheus + Grafana sont des outils puissants, mais leur cout de maintenance est significatif. N'installez pas un outil de monitoring qui demande plus de maintenance que les services qu'il surveille. Voir la section 3.20 (Choisir sa stack) pour savoir quel niveau vous correspond.

Erreurs courantes

Installer Grafana + Prometheus pour 2 containers. Over-engineering. Vous passez plus de temps a maintenir le monitoring qu'a maintenir l'application.

Pas de monitoring externe. Tout votre monitoring tourne sur le meme serveur. Si le serveur tombe, le monitoring aussi. Solution niveau 1 : un service externe gratuit (UptimeRobot, Hetrixtools) pour le ping basique.

Trop d'alertes. Vous recevez 20 alertes par jour. Vous les ignorez toutes. Finissez par ignorer la vraie panne. Reglez les seuils pour n'alerter que sur les vrais problemes.

Pas d'alerte du tout. Le monitoring tourne, les logs se remplissent, mais personne n'est notifie. Un monitoring sans alerte est un monitoring sans valeur.

Etapes

1. Installez le niveau 1 (section 5.1 : health-check.sh + cron + Telegram).
2. Utilisez pendant 2 semaines.
3. Evaluez : est-ce suffisant ?
4. Si non, installez Uptime Kuma (niveau 2).
5. Ajoutez un ping externe gratuit pour couvrir la panne complete du serveur.

Verification

• [ ] Un monitoring est actif (au minimum niveau 1).
• [ ] Les alertes fonctionnent (testees avec une panne simulee).
• [ ] Le nombre d'alertes par jour est raisonnable (< 3 en temps normal).
• [ ] Un monitoring externe ping votre serveur.
• [ ] Vous savez en moins de 5 minutes si un service est down.