Pour les trois premiers mois de fonctionnement d’OpenClaw, ma stratégie de surveillance était : vérifier le terminal toutes les quelques heures et espérer que rien ne soit en feu. Spoiler : des choses étaient parfois en feu, et je ne le savais pas tant que quelqu’un ne me l’a pas dit.
Ensuite, j’ai configuré un tableau de bord Grafana, et c’était comme mettre des lunettes pour la première fois. Soudain, je pouvais tout voir — temps de réponse, utilisation des jetons, taux d’erreur, activité des agents — tout en un seul endroit, en temps réel, avec de jolis graphiques qui me donnent l’impression de piloter un vaisseau spatial.
Voici comment je l’ai construit, ce que je surveille, et pourquoi c’est plus important que vous ne le pensez.
Pourquoi s’embêter avec un tableau de bord
« Les journaux suffisent » est ce que je m’étais dit avant le tableau de bord. Ce n’est pas suffisant. Les journaux vous disent ce qui s’est passé après qu’une personne se soit plainte. Un tableau de bord vous dit ce qui se passe avant que quiconque ne le remarque.
Trois choses que mon tableau de bord a détectées que les journaux seuls n’auraient pas :
Dégradation progressive des temps de réponse. Sur deux semaines, le temps de réponse moyen a grimpé de 2,3 secondes à 4,8 secondes. L’augmentation était trop progressive pour être remarquée dans des interactions individuelles, mais la ligne de tendance sur le tableau de bord était clairement incorrecte. Cause profonde : un contexte de conversation grandissant qui n’était pas taillé.
Pointe de coût des jetons. Un mardi, mon utilisation quotidienne de jetons a triplé. Pas à cause de plus de requêtes — à cause de réponses plus longues. Un changement de prompt que j’avais effectué la veille faisait en sorte que le modèle génère des sorties beaucoup plus verbeuses que prévu. Le tableau de bord l’a détecté en quelques heures ; sinon, je l’aurais remarqué lorsque la facture mensuelle serait arrivée.
Échecs silencieux de cron job. Deux tâches planifiées échouaient silencieusement depuis une semaine. Le tableau de bord montrait que le schéma attendu (pics d’exécution quotidienne à des moments spécifiques) avait des lacunes. Sans le modèle visuel, je ne l’aurais peut-être pas remarqué pendant une autre semaine.
La configuration
Pile : Prometheus pour la collecte de métriques, Grafana pour la visualisation, Node Exporter pour les métriques système. Temps de configuration total : environ 3 heures. Coût total : gratuit (auto-hébergé) ou 15 $/mois (le niveau gratuit de Grafana Cloud couvre la plupart des besoins).
Si vous utilisez déjà un VPS pour OpenClaw, vous pouvez faire fonctionner Grafana sur le même serveur. Ma configuration exécute Prometheus et Grafana sur le même VPS à 20 $/mois qu’OpenClaw, sans impact notable sur les performances.
Extraction des métriques d’OpenClaw : Les journaux d’OpenClaw sont la principale source de données. J’ai écrit un simple script qui analyse les fichiers journaux et expose les métriques en tant que point de terminaison Prometheus. Les principales métriques à extraire :
– Nombre de requêtes (total et par type)
– Temps de réponse (moyenne, p95, p99)
– Utilisation des jetons (entrée et sortie, par requête)
– Nombre d’erreurs (par type)
– Sessions actives
– État d’exécution des cron jobs
La mise en page de mon tableau de bord
J’ai quatre lignes :
Ligne 1 : Santé en un coup d’œil. Quatre grands chiffres : temps de réponse actuel, requêtes dans la dernière heure, taux d’erreur, et coût quotidien estimé. Vert quand normal, jaune quand élevé, rouge quand quelque chose nécessite de l’attention. Je regarde cette ligne 10 fois par jour.
Ligne 2 : Tendances. Graphiques temporels pour le temps de réponse, le volume des requêtes, et l’utilisation des jetons au cours des dernières 24 heures et des 7 jours. C’est ici que je repère la dégradation progressive et les schémas inhabituels.
Ligne 3 : Coûts. Utilisation des jetons détaillée par modèle, par type de tâche, et par heure. Un total cumulé quotidien comparé au budget. Cette ligne m’a fait économiser des centaines de dollars en détectant des anomalies de coût rapidement.
Ligne 4 : Activité des agents. Quels agents sont actifs, sur quoi ils travaillent, historique d’exécution des cron jobs, et erreurs récentes avec détails. C’est la ligne de débogage — je ne la regarde que quand quelque chose ne va pas.
Les alertes qui comptent vraiment
J’ai configuré 6 alertes. Après un mois de réglage, j’en ai supprimé 2 qui étaient trop bruyantes et ajusté les seuils des 4 restantes.
Alerte 1 : Temps de réponse > 10 secondes. Cela se déclenche lorsque le temps de réponse p95 dépasse 10 secondes sur une fenêtre de 5 minutes. Ça veut généralement dire que l’API AI a des problèmes, ou que mon contexte est trop grand.
Alerte 2 : Taux d’erreur > 5%. Plus de 5 % des requêtes échouant signifie qu’il y a quelque chose de systématiquement mal, et pas seulement des pépins occasionnels de l’API.
Alerte 3 : Coût quotidien dépasse 2x la moyenne. Détecte les boucles incontrôlées et les pics d’utilisation inattendus avant qu’ils ne deviennent coûteux.
Alerte 4 : Exécution de cron job manquée. Si un cron job attendu ne s’exécute pas dans les 30 minutes suivant son heure prévue, quelque chose ne va pas.
Ces quatre alertes constituent le bon équilibre pour ma configuration. Assez pour attraper de réels problèmes. Pas tant qu’il y en ait suffisamment que je commence à les ignorer.
Ce que j’éviterais
Tableaux de bord par requête. J’ai d’abord construit un panneau montrant chaque requête individuelle. C’était intéressant pendant environ un jour, puis cela est devenu du bruit. Les métriques agrégées sont plus utiles que les données individuelles pour la surveillance.
Panneaux de comparaison de modèles. J’ai construit des panneaux comparant les scores de qualité de Claude et GPT-4o. Les données étaient intéressantes mais non exploitables — j’avais déjà décidé quel modèle utiliser, et le tableau de bord n’a pas changé cette décision.
Visualisations compliquées. Grafana peut créer de beaux tableaux de bord avec des jauges, des cartes thermiques, et des diagrammes de flux. Résistez à la tentation. Les graphiques linéaires simples et les grands chiffres sont plus lisibles d’un coup d’œil, ce qui est le but.
Le calcul du ROI
Temps de configuration : 3 heures.
Maintenance mensuelle : 30 minutes (mise à jour des tableaux de bord, réglage des alertes).
Économies réalisées en détectant les problèmes tôt : estimés à 200-300 $/mois en coûts évités et réduction des temps d’arrêt.
Le tableau de bord s’est rentabilisé au cours du premier mois. Si vous utilisez OpenClaw (ou tout système d’IA) sans observabilité, vous volez à l’aveugle. Vous pourriez voler correctement. Mais quand ce n’est pas le cas, vous ne le saurez pas tant que vous n’aurez pas déjà percuté.
🕒 Published: