La première fois qu’un de mes agents a cessé de fonctionner silencieusement, je ne l’ai pas remarqué pendant trois jours. Trois jours de rapports programmés 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 de la même manière que mes agents surveillent tout le reste. Maintenant, je sais en quelques minutes 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, j’ai tout suivi. Temps de réponse par demande, nombre de tokens par message, scores de confiance des modèles, utilisation de la mémoire par session, taux d’erreurs par type, histogrammes de latence… 47 métriques sur 12 panneaux.
J’ai regardé ce tableau de bord pendant une semaine. Puis j’ai réalisé que je ne regardais jamais que 4 choses :
Est-ce que c’est en cours d’exécution ? Vérification simple de l’état. Point vert = le processus est actif et répond. Cela détecte les plantages, 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 — en général, un gonflement du contexte ou des problèmes avec le fournisseur d’API.
Est-ce que ça échoue ? Taux d’erreur en pourcentage du total des demandes. En dessous de 2% est normal (quelques délais d’attente d’API occasionnels). Au-dessus de 5% signifie des problèmes systématiques.
Est-ce que c’est coûteux ? Coût de fonctionnement pour la journée en cours comparé à la moyenne quotidienne. Un pic à 2x signifie que quelque chose génère des demandes longuement ou fréquemment inattendues.
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 est sur une page « détails » que je visite uniquement lorsque je débogue.
La Configuration
Collecte de données : J’ai écrit un petit script qui analyse les journaux d’OpenClaw et expose les métriques au format Prometheus. Il fonctionne comme un processus auxiliaire et scrute le fichier journal toutes les 30 secondes. Environ 50 lignes de code. Rien de spécial.
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 scrute 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 qu’OpenClaw — il utilise environ 100 Mo de RAM pour cette petite charge de travail.
Grafana visualise les métriques. J’utilise l’offre gratuite de Grafana Cloud (10 000 métriques, ce qui est largement suffisant). Vous pouvez également auto-héberger Grafana sur le même serveur — il est léger.
Temps total de configuration : environ 2 heures la première fois. La majeure partie du temps a été consacrée à l’écriture de l’analyseur de journaux.
Les Alertes Qui Fonctionnent
J’ai quatre alertes. J’ai ajusté leurs seuils pendant trois mois pour minimiser les faux positifs :
Processus hors service pendant plus de 2 minutes. Se déclenche si la vérification de l’état échoue pendant deux minutes consécutives. Deux minutes donnent suffisamment de temps pour les redémarrages et les brèves perturbations réseau. Cela envoie une notification push sur 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 systématiquement lentes signifie qu’il y a quelque chose de systématiquement faux. Cela se publie sur mon canal d’alertes Slack.
Taux d’erreur > 10% pendant 3 minutes. J’ai fixé cela plus haut que vous pourriez l’attendre (10% au lieu de 5%) car de brèves poussées de délais d’attente d’API sont normales pendant la maintenance du fournisseur. Trois minutes d’erreurs élevées soutenues signifient que ce n’est pas juste un pic. Notification sur le téléphone.
Coût quotidien > 3x la moyenne mobile. Vérifié toutes les heures. Détecte les boucles runaway et les modèles d’utilisation inattendue avant qu’ils ne deviennent coûteux. Alerte Slack uniquement — c’est informatif, pas urgent.
J’ai supprimé deux alertes qui étaient trop bruyantes : « une seule demande > 30 secondes » (arrivait trop souvent lors de tâches complexes d’agents) et « utilisation de la mémoire > 80% » (non pertinent — Node.js gère sa propre collecte des ordures et de brèves augmentations 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 sont passés de 2,5s à 7s en deux semaines. La ligne de tendance était évidente sur le tableau de bord — les demandes individuelles semblaient correctes, mais la moyenne quotidienne augmentait. Cause profonde : les contextes de conversation grossissaient car la compactage ne se déclenchait pas correctement. Un correctif de configuration a ramené les temps de réponse à la normale en une heure.
Mars : Pic de coût dû à une boucle. Un travail cron avait un mécanisme de réessai qui, en raison d’un bug, continuait à réessayer indéfiniment lorsque l’API renvoyait un code d’erreur spécifique. L’alerte de coût quotidien se déclenchait à 2x la moyenne. Je l’ai détectée en 2 heures. Sans l’alerte, cela aurait fonctionné jusqu’à ce que la clé API atteigne sa limite de dépenses.
Mars : Échec silencieux du cron. Mon travail de rapport quotidien a cessé de fonctionner. Pas d’erreur — il ne s’est tout simplement pas exécuté. Le tableau de bord a montré que le pic quotidien attendu d’activité à 8h manquait. Le planificateur cron avait échoué après une mise à jour. Le redémarrage a résolu le problème, et j’ai ajouté l’alerte de processus hors service spécifiquement pour le planificateur.
Ce Que Je Dirais à Mon Moi Passé
Commencez avec 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 cessez 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 facilement lisible, rendez les alertes exploitables et passez en revue les seuils chaque mois. C’est toute la stratégie.
🕒 Published: