La première fois qu’un de mes agents a silencieusement cessé de fonctionner, je ne l’ai pas remarqué pendant trois jours. Trois jours de rapports prévus manqués. Trois jours de messages automatisés sans réponse. Trois jours d’un travail de surveillance qui ne surveillait rien.
Mon client l’a remarqué avant moi. C’était embarrassant.
Alors, j’ai configuré Grafana pour surveiller mes agents comme mes agents surveillent tout le reste. Maintenant, je sais dans les minutes qui suivent quand quelque chose ne va pas, et je sais généralement pourquoi avant même d’ouvrir un terminal.
Ce qu’il faut surveiller (et ce qu’il ne faut pas)
Lorsque j’ai d’abord mis en place la surveillance, je surveillais tout. Les temps de réponse par requête, le nombre de tokens par message, les scores de confiance des modèles, l’utilisation de la mémoire par session, les taux d’erreur par type, les histogrammes de latence… 47 métriques sur 12 panneaux.
J’ai regardé ce tableau de bord pendant une semaine. Puis je me suis rendu compte que je ne regardais jamais que quatre choses :
Est-ce que ça fonctionne ? Vérification simple en marche/arrêt. Point vert = le processus est en vie et répond. Cela permet de détecter les crashs, les blocages et les pannes d’infrastructure.
Est-ce que c’est lent ? Temps de réponse moyen sur les 5 dernières minutes. Normalement 2-3 secondes. Quand ça dépasse 8 secondes, quelque chose ne va pas — généralement une surcharge de contexte ou des problèmes avec le fournisseur d’API.
Est-ce que ça échoue ? Taux d’erreur en pourcentage du total des requêtes. En dessous de 2 %, c’est normal (timeouts API occasionnels). Au-dessus de 5 %, cela signifie des problèmes systémiques.
Est-ce que c’est coûteux ? Coût de fonctionnement pour la journée en cours comparé à la moyenne quotidienne. Un pic de 2x signifie que quelque chose génère des requêtes anormalement longues ou fréquentes.
J’ai réduit mon tableau de bord à ces quatre métriques. Une ligne, quatre grands chiffres avec un code couleur. C’est ce que je regarde 10 fois par jour. Tout le reste se trouve sur une page « détails » que je consulte uniquement lors du débogage.
La configuration
Collecte de données : J’ai écrit un petit script qui analyse les journaux OpenClaw et expose les métriques au format Prometheus. Il s’exécute comme un processus annexe et extrait le fichier journal toutes les 30 secondes. Environ 50 lignes de code. Rien de fancy.
Les métriques qu’il expose :
– openclaw_requests_total (compteur, étiqueté par type)
– openclaw_response_seconds (histogramme)
– openclaw_errors_total (compteur, étiqueté par type d’erreur)
– openclaw_tokens_used (compteur, étiqueté par direction : entrée/sortie)
– openclaw_process_up (gauge, 1 ou 0)
Prometheus extrait ces métriques toutes les 15 secondes. La rétention par défaut est de 15 jours, ce qui est suffisant pour mes besoins. Prometheus fonctionne sur le même serveur que OpenClaw — il utilise environ 100 Mo de RAM pour cette petite charge de travail.
Grafana visualise les métriques. J’utilise le niveau gratuit de Grafana Cloud (10 000 métriques, ce qui est largement suffisant). Vous pouvez également auto-héberger Grafana sur le même serveur — c’est léger.
Temps total de configuration : environ 2 heures la première fois. La majorité du temps a été consacrée à l’écriture du parseur de journaux.
Les alertes qui fonctionnent
J’ai quatre alertes. J’ai ajusté leurs seuils pendant trois mois pour minimiser les faux positifs :
Processus à l’arrêt pendant > 2 minutes. S’active si la vérification marche/arrêt échoue pendant deux minutes consécutives. Deux minutes donnent suffisamment de marge pour les redémarrages et les petites coupures réseau. Cela envoie une notification push à mon téléphone.
Temps de réponse p95 > 15 secondes pendant 5 minutes. Une seule réponse lente n’a pas d’importance. Cinq minutes de réponses lentement constantes signifie que quelque chose ne va pas systématiquement. Cela se publie sur mon canal d’alertes Slack.
Taux d’erreur > 10 % pendant 3 minutes. J’ai fixé cela plus haut que ce à quoi vous pourriez vous attendre (10 % au lieu de 5 %) car de brèves explosions de timeout API sont normales pendant la maintenance du fournisseur. Trois minutes d’erreurs élevées soutenues signifient que ce n’est pas un simple incident. Notification sur le téléphone.
Coût quotidien > 3x la moyenne mobile. Vérifié toutes les heures. Attrape les boucles indésirables et les schémas d’utilisation inattendus avant qu’ils ne deviennent coûteux. Alerte Slack uniquement — cela est informatif, pas urgent.
J’ai supprimé deux alertes qui étaient trop bruyantes : « toute requête unique > 30 secondes » (cela arrivait trop souvent lors de tâches complexes d’agent) et « utilisation de la mémoire > 80 % » (sans intérêt — Node.js gère sa propre collecte des déchets et de brèves poussées sont normales).
Le tableau de bord qui a détecté de vrais problèmes
Février : Gonflement graduel du contexte. Les temps de réponse ont grimpé de 2,5 s à 7 s en l’espace de deux semaines. La courbe de tendance était évidente sur le tableau de bord — les requêtes individuelles semblaient correctes, mais la moyenne quotidienne augmentait. Cause racine : les contextes de conversation grandissaient car la compaction ne se déclenchait pas correctement. Un correctif de configuration a remis les temps de réponse à la normale en une heure.
Mars : Pic de coût dû à une boucle. Un job cron avait un mécanisme de réessai qui, à cause d’un bogue, continuait à réessayer indéfiniment lorsque l’API renvoyait un code d’erreur spécifique. L’alerte de coût quotidien s’est déclenchée à 2x la moyenne. Je l’ai attrapée en moins de 2 heures. Sans l’alerte, cela aurait continué jusqu’à ce que la clé API atteigne sa limite de dépense.
Mars : Échec silencieux du cron. Mon job de rapport quotidien a cessé de s’exécuter. Pas d’erreur — il n’a tout simplement pas été exécuté. Le tableau de bord a montré que le pic d’activité quotidien attendu à 8h était manquant. Le planificateur cron avait planté après une mise à jour. Le redémarrer a résolu le problème, et j’ai ajouté l’alerte de processus à l’arrêt pour le planificateur spécifiquement.
Ce que je dirais à mon moi du passé
Commencez par les quatre métriques de base. Ajoutez de la complexité uniquement lorsque vous avez un besoin spécifique de débogage. La plupart des tableaux de bord de surveillance échouent parce qu’ils sont trop complexes — vous construisez 20 panneaux, êtes submergé par les données et arrêtez complètement de regarder le tableau de bord.
Le tableau de bord que vous utilisez réellement est meilleur que le tableau de bord qui suit tout. Rendez-le rapide à lire, faites en sorte que les alertes soient exploitables, et passez en revue les seuils chaque mois. Voilà toute la stratégie.
🕒 Published: