Monitoring serveur avec l'IA : alertes intelligentes
Votre serveur tourne 24h/24. Mais qui le surveille vraiment ? Les outils de monitoring classiques vous envoient des alertes quand le CPU dépasse 90%... même si c'est juste une mise à jour apt qui tourne. Résultat : vous recevez 15 notifications par jour, vous les ignorez toutes, et le jour où un vrai problème survient, vous le ratez.
Le monitoring par IA change complètement la donne. Au lieu de seuils bêtes, un agent intelligent comprend le contexte, distingue un pic normal d'une anomalie réelle, et ne vous alerte que quand ça compte vraiment.
Dans ce guide, on va mettre en place un système de monitoring intelligent avec OpenClaw qui surveille votre serveur et vous envoie des alertes Telegram pertinentes — pas du spam.
🔍 Monitoring classique vs monitoring IA
Le problème des seuils fixes
Le monitoring traditionnel fonctionne avec des règles simples :
SI cpu > 90% ALORS alerte
SI ram > 85% ALORS alerte
SI disque > 80% ALORS alerte
Ça paraît logique. En pratique, c'est inutilisable :
| Situation | Seuil classique | Monitoring IA |
|---|---|---|
apt upgrade qui tourne |
🔴 ALERTE CPU 95% ! | ✅ Processus connu, ignoré |
| Backup nocturne | 🔴 ALERTE disque I/O ! | ✅ Tâche planifiée, normal |
| Pic CPU à 3h du matin sans raison | ✅ Alerte (si > seuil) | 🔴 ALERTE : activité anormale |
| RAM qui monte lentement sur 3 jours | ❌ Jamais détecté (sous le seuil) | 🔴 ALERTE : fuite mémoire probable |
| Service qui redémarre 5 fois en 1h | ❌ Pas de règle pour ça | 🔴 ALERTE : instabilité service |
Ce que l'IA apporte
L'IA ne remplace pas la collecte de métriques — elle remplace l'interprétation humaine. Un agent IA peut :
- Comprendre le contexte : un pic CPU pendant un cron job, c'est normal
- Détecter des patterns : "ce service a redémarré 3 fois en 2h, ça n'est jamais arrivé"
- Corréler les métriques : RAM + CPU + I/O qui montent ensemble = problème différent de CPU seul
- Adapter sa sensibilité : alerter plus vite la nuit (personne ne devrait utiliser le serveur)
- Résumer intelligemment : au lieu de 10 alertes, un seul message contextuel
📊 Les métriques essentielles à surveiller
Avant de configurer l'agent, définissons ce qu'on surveille et pourquoi.
CPU
# Utilisation CPU instantanée
top -bn1 | grep "Cpu(s)" | awk '{print $2}'
# Load average (1, 5, 15 minutes)
cat /proc/loadavg
# Nombre de cœurs (pour interpréter le load)
nproc
Ce que l'IA doit savoir : un load average de 4.0 sur une machine 4 cœurs = 100% utilisé. Sur une machine 8 cœurs = 50%.
RAM
# Mémoire utilisée/disponible
free -h
# Détail avec buffers/cache
free -m | awk 'NR==2{printf "Used: %sMB / %sMB (%.1f%%)\n", $3, $2, $3*100/$2}'
Piège classique : Linux utilise la RAM libre comme cache disque. Une RAM "utilisée à 90%" n'est pas forcément un problème si 40% est du cache.
Disque
# Espace disque
df -h /
# Inodes (souvent oublié, peut bloquer même avec de l'espace libre)
df -i /
# I/O en cours
iostat -x 1 3 2>/dev/null || echo "iostat non disponible"
Services et uptime
# Services critiques
systemctl is-active nginx postgresql docker openclaw
# Uptime serveur
uptime -p
# Ports en écoute
ss -tlnp | grep -E ':(80|443|5432|8080|3000)'
Logs récents
# Erreurs système récentes
journalctl -p err -n 20 --no-pager
# Tentatives SSH échouées
journalctl -u sshd -n 50 --no-pager | grep -i "failed\|invalid"
# OOM killer (processus tués par manque de RAM)
dmesg | grep -i "oom\|killed process" | tail -5
🛠️ Script de collecte des métriques
On crée un script qui collecte tout et produit un rapport structuré que l'agent IA pourra interpréter.
#!/bin/bash
# /root/scripts/server-health.sh
# Collecte les métriques serveur pour analyse IA
echo "=== SERVER HEALTH REPORT ==="
echo "Date: $(date -u +'%Y-%m-%d %H:%M UTC')"
echo "Hostname: $(hostname)"
echo "Uptime: $(uptime -p)"
echo ""
# CPU
echo "--- CPU ---"
echo "Load average: $(cat /proc/loadavg | awk '{print $1, $2, $3}')"
echo "Cores: $(nproc)"
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}')
echo "CPU usage: ${CPU_USAGE}%"
echo ""
# RAM
echo "--- MEMORY ---"
free -m | awk 'NR==2{printf "Total: %sMB\nUsed: %sMB\nFree: %sMB\nBuffers/Cache: %sMB\nAvailable: %sMB\nUsage: %.1f%%\n", $2, $3, $4, $6, $7, $3*100/$2}'
echo ""
# Disque
echo "--- DISK ---"
df -h / | tail -1 | awk '{printf "Total: %s\nUsed: %s\nAvailable: %s\nUsage: %s\n", $2, $3, $4, $5}'
echo "Inodes: $(df -i / | tail -1 | awk '{print $5}') used"
echo ""
# Services
echo "--- SERVICES ---"
for svc in nginx postgresql docker; do
STATUS=$(systemctl is-active $svc 2>/dev/null || echo "not-found")
echo "$svc: $STATUS"
done
echo ""
# Ports
echo "--- LISTENING PORTS ---"
ss -tlnp 2>/dev/null | grep -E 'LISTEN' | awk '{print $4}' | sort -u
echo ""
# Erreurs récentes
echo "--- RECENT ERRORS (last 30 min) ---"
journalctl -p err --since "30 min ago" --no-pager -q 2>/dev/null | tail -10
echo ""
# Sécurité
echo "--- SECURITY ---"
FAILED_SSH=$(journalctl -u sshd --since "1 hour ago" --no-pager 2>/dev/null | grep -c "Failed\|Invalid" || echo "0")
echo "Failed SSH attempts (1h): $FAILED_SSH"
# Docker (si disponible)
if command -v docker &>/dev/null; then
echo ""
echo "--- DOCKER ---"
docker ps --format "{{.Names}}: {{.Status}}" 2>/dev/null
STOPPED=$(docker ps -a --filter "status=exited" --format "{{.Names}}" 2>/dev/null | wc -l)
echo "Stopped containers: $STOPPED"
fi
Rendez-le exécutable :
chmod +x /root/scripts/server-health.sh
Testez-le :
/root/scripts/server-health.sh
Vous devriez voir un rapport structuré complet. C'est ce rapport que l'agent IA va interpréter.
⚙️ Configuration OpenClaw : heartbeat + cron
OpenClaw offre deux mécanismes pour les tâches périodiques : le heartbeat et les cron jobs. Pour le monitoring, on va utiliser les deux.
Le heartbeat : surveillance continue légère
Le heartbeat d'OpenClaw s'exécute à intervalles réguliers (configurable). C'est parfait pour une vérification rapide.
Dans votre configuration OpenClaw, ajoutez au heartbeat :
# Dans votre HEARTBEAT.md ou configuration heartbeat
## 📊 Monitoring serveur
- Vérifier la santé du serveur via /root/scripts/server-health.sh
- Si anomalie détectée, alerter via Telegram
- Ne PAS alerter pour : pics CPU courts (<5min), usage RAM <85%, cron jobs connus
Le cron job : rapport détaillé planifié
Pour un rapport plus approfondi (analyse de tendances, comparaison avec la veille), configurez un cron OpenClaw :
# Rapport de santé toutes les 6 heures
0 */6 * * * Exécute /root/scripts/server-health.sh, analyse les résultats, compare avec les rapports précédents. Si anomalie, envoie un résumé Telegram. Sinon, log silencieusement.
Stocker l'historique
Pour que l'IA puisse comparer, stockez les rapports :
# Créer le dossier d'historique
mkdir -p /root/monitoring/history
# Script wrapper qui stocke + analyse
#!/bin/bash
# /root/scripts/monitor-and-store.sh
REPORT_DIR="/root/monitoring/history"
TIMESTAMP=$(date +%Y%m%d_%H%M)
REPORT_FILE="$REPORT_DIR/health_${TIMESTAMP}.txt"
# Collecter
/root/scripts/server-health.sh > "$REPORT_FILE"
# Garder seulement les 7 derniers jours
find "$REPORT_DIR" -name "health_*.txt" -mtime +7 -delete
# Afficher pour l'agent
cat "$REPORT_FILE"
L'agent peut alors comparer le rapport actuel avec les précédents :
# Comparer l'usage disque avec hier
grep "Usage:" /root/monitoring/history/health_$(date -d yesterday +%Y%m%d)*.txt
🤖 L'agent monitoring intelligent
Voici le cœur du système : le prompt qui transforme des métriques brutes en analyse intelligente.
Pour aller plus loin sur ce sujet, consultez notre guide Cron + IA : automatiser des tâches intelligentes 24/7.
Prompt pour le heartbeat OpenClaw
Pour aller plus loin sur ce sujet, consultez notre guide Générer du contenu automatiquement avec l'IA.
## 📋 Tâche : Monitoring serveur intelligent
Exécute `/root/scripts/server-health.sh` et analyse les résultats.
### Règles d'alerte
**NE PAS alerter si :**
- CPU < 85% (usage normal)
- RAM < 80% (en comptant les buffers/cache)
- Disque < 75%
- Load average < nombre_de_coeurs × 0.8
- Les processus gourmands sont des tâches connues (apt, backup, cron)
**ALERTER si :**
- Un service critique est down (nginx, postgresql, docker)
- CPU > 90% pendant plus de 5 minutes sans raison identifiable
- RAM disponible < 500MB
- Disque > 85% ou inodes > 80%
- Plus de 50 tentatives SSH échouées en 1h
- Un conteneur Docker est stopped alors qu'il devrait tourner
- Des erreurs OOM dans les logs
### Format d'alerte Telegram
Si alerte nécessaire, envoie UN SEUL message structuré :
🚨 **Alerte serveur [hostname]**
**Problème :** [description courte]
**Détail :** [explication contextuelle]
**Impact :** [ce que ça affecte]
**Action suggérée :** [quoi faire]
### Si tout va bien
Ne rien envoyer. Log silencieusement.
Exemple concret d'analyse
Imaginons ce rapport :
--- CPU ---
Load average: 3.8 2.1 1.5
Cores: 4
CPU usage: 92%
--- MEMORY ---
Usage: 78.5%
--- SERVICES ---
nginx: active
postgresql: active
docker: active
Monitoring classique : 🔴 ALERTE CPU 92% !
Monitoring IA :
- Load average 3.8 sur 4 cœurs = 95% de charge
- MAIS le load 5min est à 2.1 et 15min à 1.5
- → Le pic est récent et transitoire (probablement un déploiement)
- RAM et services OK
- → Pas d'alerte, on surveille au prochain cycle
📱 Alertes Telegram : qualité vs quantité
Le problème du spam d'alertes
Tout système de monitoring qui envoie plus de 2-3 alertes par jour en moyenne finit ignoré. C'est la "fatigue d'alerte" — un vrai problème en ops.
Stratégie anti-spam
| Technique | Comment | Pourquoi |
|---|---|---|
| Cooldown | Pas plus d'1 alerte par heure pour le même problème | Éviter les rafales |
| Agrégation | Regrouper les problèmes liés en 1 message | Moins de notifs |
| Escalade | 1ère occurrence = log, 2ème = alerte, 3ème = alerte urgente | Filtrer les faux positifs |
| Résolution auto | Envoyer "✅ Résolu" quand le problème disparaît | Réduire le stress |
| Digest quotidien | Résumé journalier même si tout va bien | Confirmer que ça marche |
Implémenter le cooldown
# /root/scripts/alert-cooldown.sh
# Vérifie si une alerte a déjà été envoyée récemment
ALERT_TYPE="$1" # ex: "cpu_high", "disk_full"
COOLDOWN_DIR="/root/monitoring/cooldowns"
COOLDOWN_SECONDS=3600 # 1 heure
mkdir -p "$COOLDOWN_DIR"
LAST_ALERT_FILE="$COOLDOWN_DIR/$ALERT_TYPE"
if [ -f "$LAST_ALERT_FILE" ]; then
LAST_TIME=$(cat "$LAST_ALERT_FILE")
NOW=$(date +%s)
DIFF=$((NOW - LAST_TIME))
if [ "$DIFF" -lt "$COOLDOWN_SECONDS" ]; then
echo "COOLDOWN_ACTIVE"
exit 1
fi
fi
# Enregistrer cette alerte
date +%s > "$LAST_ALERT_FILE"
echo "ALERT_OK"
exit 0
Le digest quotidien
Même quand tout va bien, un message quotidien rassure :
📊 **Rapport serveur quotidien**
📅 2025-01-15
✅ Tous les services opérationnels
💻 CPU moyen : 23% | Max : 67%
🧠 RAM : 4.2GB / 8GB (52%)
💾 Disque : 34GB / 80GB (42%)
🔒 12 tentatives SSH bloquées
🐳 5 conteneurs Docker actifs
Prochaine vérification dans 24h.
Ce genre de message, vous le lisez. Et le jour où il dit "⚠️ Disque à 78%, +3% en 24h", vous agissez.
🔧 Configuration avancée
Surveiller des services spécifiques
Adaptez le script pour vos services :
# Ajouter au script server-health.sh
# Vérifier qu'un site répond
echo "--- WEB CHECK ---"
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:80 2>/dev/null)
echo "Nginx HTTP: $HTTP_CODE"
# Vérifier la taille de la base de données
echo "--- DATABASE ---"
if command -v psql &>/dev/null; then
DB_SIZE=$(psql -U postgres -t -c "SELECT pg_size_pretty(pg_database_size('main'));" 2>/dev/null)
echo "DB size: $DB_SIZE"
fi
# Vérifier les certificats SSL
echo "--- SSL ---"
DOMAIN="votre-domaine.com"
EXPIRY=$(echo | openssl s_client -servername $DOMAIN -connect $DOMAIN:443 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
echo "SSL expiry: $EXPIRY"
Surveiller les logs applicatifs
# Erreurs dans les logs de votre app
echo "--- APP LOGS ---"
if [ -f /var/log/myapp/error.log ]; then
ERRORS_1H=$(find /var/log/myapp/error.log -newer <(date -d "1 hour ago" +%Y%m%d%H%M) 2>/dev/null | wc -l)
echo "App errors (1h): $ERRORS_1H"
# Dernières erreurs
tail -5 /var/log/myapp/error.log
fi
Intégration avec Docker
Si vous utilisez Docker (voir notre guide conteneuriser ses services), surveillez aussi vos conteneurs :
# Conteneurs qui consomment trop
docker stats --no-stream --format \
"{{.Name}}: CPU={{.CPUPerc}} MEM={{.MemUsage}}" 2>/dev/null
# Conteneurs qui ont redémarré récemment
docker ps --format "{{.Names}} {{.Status}}" | grep -i "restarting"
# Logs d'erreur des conteneurs
for container in $(docker ps -q); do
NAME=$(docker inspect --format '{{.Name}}' $container | tr -d '/')
ERRORS=$(docker logs --since 1h $container 2>&1 | grep -ci "error\|fatal\|panic")
if [ "$ERRORS" -gt 0 ]; then
echo "⚠️ $NAME: $ERRORS errors in last hour"
fi
done
📈 Aller plus loin : tendances et prédictions
Détecter les tendances
Le vrai pouvoir de l'IA, c'est de voir ce qu'un humain ne remarquerait pas :
# Extraire l'usage disque des 7 derniers jours
for f in /root/monitoring/history/health_*.txt; do
DATE=$(echo $f | grep -oP '\d{8}')
USAGE=$(grep "Usage:" $f | head -1 | grep -oP '\d+' | head -1)
echo "$DATE $USAGE"
done
L'agent peut alors dire : "Le disque gagne 0.5% par jour. À ce rythme, il sera plein dans 52 jours. Pensez à nettoyer les vieux logs."
Corrélation multi-métriques
Demandez à l'agent de chercher des patterns :
## 📈 Analyse de tendance
Compare les 5 derniers rapports dans /root/monitoring/history/
Cherche :
- Métriques qui augmentent régulièrement (fuite mémoire, disque qui se remplit)
- Corrélations (CPU + RAM qui montent ensemble)
- Patterns temporels (problèmes toujours à la même heure)
🚀 Mise en place complète en 15 minutes
Récapitulatif pour tout installer :
# 1. Créer les dossiers
mkdir -p /root/scripts /root/monitoring/{history,cooldowns}
# 2. Créer le script de collecte
# (copier server-health.sh ci-dessus)
nano /root/scripts/server-health.sh
chmod +x /root/scripts/server-health.sh
# 3. Créer le wrapper
# (copier monitor-and-store.sh ci-dessus)
nano /root/scripts/monitor-and-store.sh
chmod +x /root/scripts/monitor-and-store.sh
# 4. Tester
/root/scripts/server-health.sh
# 5. Configurer le cron système (backup)
crontab -e
# Ajouter : */30 * * * * /root/scripts/monitor-and-store.sh > /dev/null 2>&1
# 6. Configurer OpenClaw heartbeat
# (ajouter les instructions monitoring au heartbeat)
| Étape | Temps | Difficulté |
|---|---|---|
| Créer les scripts | 5 min | Copier-coller |
| Configurer OpenClaw | 5 min | Éditer la config |
| Tester et ajuster | 5 min | Vérifier les alertes |
| Total | 15 min | Facile |
⚠️ Erreurs courantes à éviter
- Trop d'alertes : commencez avec des seuils élevés, réduisez progressivement
- Pas assez de contexte : donnez à l'agent l'historique, pas juste l'instantané
- Oublier les inodes : votre disque peut être "plein" avec 50% d'espace libre
- Ignorer les logs : les erreurs applicatives sont souvent plus critiques que les métriques système
- Pas de test : testez vos alertes ! Simulez un problème pour vérifier que la notification arrive
📚 Articles liés
- Qu'est-ce qu'OpenClaw ? — Découvrez l'agent IA qui rend ce monitoring possible
- Installer OpenClaw sur un VPS — Prérequis pour mettre en place le monitoring
- Configurer OpenClaw — Paramétrer le heartbeat et les cron jobs
- Automatiser sa vie numérique avec l'IA — Le monitoring n'est que le début
- Sécuriser son serveur OpenClaw — Protéger le serveur que vous surveillez
- Docker + IA : conteneuriser ses services — Surveiller aussi vos conteneurs Docker
- Hébergez votre agent sur Hostinger — VPS fiable avec 20% de remise