05 - Monitoring serveur avec l'IA : alertes intelligentes

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 :

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

Pour récupérer l'utilisation CPU instantanée et le load average, vous pouvez utiliser les commandes natives top ou cat /proc/loadavg, couplées à nproc pour connaître le nombre de cœurs de la machine.

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

L'outil free -h permet d'obtenir un aperçu rapide de la mémoire disponible et utilisée, en incluant les buffers et le cache.

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

La commande df -h / donne l'espace disque, df -i / le nombre d'inodes (souvent oublié, peut bloquer même avec de l'espace libre), et iostat permet d'analyser les entrées/sorties en cours.

Services et uptime

Il est possible de vérifier l'état des services critiques (comme nginx, postgresql, docker) via systemctl is-active, d'obtenir l'uptime avec uptime -p, et de lister les ports en écoute avec la commande ss -tlnp.

Logs récents

Les logs systèmes récents avec les erreurs se consultent via journalctl -p err, les tentatives SSH échouées via journalctl -u sshd, et les processus tués par manque de RAM (OOM killer) se retrouvent dans les sorties de dmesg.

🛠️ 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. Ce script va rassembler les informations de CPU, RAM, disque, services, ports, erreurs récentes et sécurité dans un seul rapport textuel formaté, facile à lire pour un agent IA. Il inclut également une vérification des conteneurs Docker si l'outil est présent sur le serveur, en listant les noms des conteneurs actifs avec leur statut, ainsi que le nombre de conteneurs arrêtés. Rendez ce script exécutable avec chmod +x, puis testez-le pour vérifier que vous obtenez bien 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 dans un dossier dédié (par exemple /root/monitoring/history) via un script wrapper qui exécute la collecte, sauvegarde le résultat avec un timestamp, et supprime automatiquement les fichiers de plus de 7 jours pour éviter de saturer l'espace. L'agent peut alors comparer le rapport actuel avec les précédents en cherchant les métriques d'utilisation dans les fichiers de l'historique.

🤖 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 l'automatisation périodique, consultez notre guide sur le Cron + IA : automatiser des tâches intelligentes 24/7.

Prompt pour le heartbeat OpenClaw

## 📋 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, souligné par une étude de PagerDuty en 2023 montrant que 74% des équipes IT ont déjà manqué une alerte critique à cause du bruit de fond.

Stratégie anti-spam

Implémenter le cooldown

Pour éviter les rafales d'alertes, mettez en place un mécanisme de cooldown simple : un script vérifie si un fichier temporaire correspondant au type d'alerte existe et a été créé il y a moins d'une heure. Si c'est le cas, l'alerte est bloquée. Sinon, le script crée ou met à jour ce fichier et autorise l'envoi de la notification.

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 en ajoutant des vérifications ciblées : tester le code HTTP renvoyé par votre site avec curl, interroger la taille de votre base de données via psql, ou encore vérifier la date d'expiration de vos certificats SSL avec openssl.

Surveiller les logs applicatifs

Intégrez la surveillance de vos logs applicatifs en cherchant les erreurs récentes (par exemple avec un grep sur les dernières heures ou via l'option de filtrage par date) et en affichant les dernières lignes d'erreur de votre application.

Intégration avec Docker

Si vous utilisez Docker, surveillez aussi vos conteneurs en vérifiant leurs consommations CPU et mémoire via docker stats, en listant ceux qui redémarrent anormalement, et en scrutant leurs logs pour détecter les erreurs, fatal ou panic sur la dernière heure. Pour approfondir l'intégration de vos services, vous pouvez aussi consulter notre guide sur le Scraping intelligent : enrichir ses données avec Hunter, Phantombuster et l'IA.

📈 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. En extrayant l'usage disque des 7 derniers jours depuis les rapports stockés dans l'historique, l'agent peut identifier une croissance régulière et pré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 : commencez par créer les dossiers nécessaires pour vos scripts et l'historique. Copiez ensuite le script de collecte et le script wrapper d'historisation dans le dossier adéquat, puis rendez-les exécutables. Testez le script de santé pour vérifier le bon fonctionnement. Enfin, configurez le cron système pour exécuter le wrapper toutes les 30 minutes, et ajoutez les instructions de monitoring dans la configuration du heartbeat OpenClaw.

⚠️ Erreurs courantes à éviter

1. Trop d'alertes : commencez avec des seuils élevés, réduisez progressivement
2. Pas assez de contexte : donnez à l'agent l'historique, pas juste l'instantané
3. Oublier les inodes : votre disque peut être "plein" avec 50% d'espace libre
4. Ignorer les logs : les erreurs applicatives sont souvent plus critiques que les métriques système
5. Pas de test : testez vos alertes ! Simulez un problème pour vérifier que la notification arrive
   ```