Au cours des trois premiers mois de l’exploitation d’OpenClaw, ma stratégie de surveillance était : vérifier le terminal toutes les quelques heures et espérer que rien ne brûlait. Spoiler : il y avait parfois des incendies, et je ne le savais pas jusqu’à ce que quelqu’un me le dise.
Ensuite, j’ai mis en place 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 — le tout à un seul endroit, en temps réel, avec de jolis graphiques qui me font sentir comme si je pilotais un vaisseau spatial.
Voici comment je l’ai construit, ce que je suis en train de suivre, et pourquoi cela compte plus que vous ne le pensez.
Pourquoi s’embêter avec un tableau de bord
“Les journaux suffisent” est ce que je me suis dit avant le tableau de bord. Ce n’est pas suffisant. Les journaux vous disent ce qui s’est passé après que quelqu’un se soit plaint. Un tableau de bord vous indique ce qui se passe avant que quiconque ne s’en rende compte.
Trois choses que mon tableau de bord a repérées que les journaux à eux seuls n’auraient pas captées :
Diminution progressive du temps de réponse. En deux semaines, le temps de réponse moyen a glissé de 2,3 secondes à 4,8 secondes. L’augmentation était trop graduelle pour être remarquée lors des interactions individuelles, mais la ligne de tendance sur le tableau de bord était manifestement erronée. Cause profonde : un contexte de conversation croissant qui n’était pas élagué.
Pointe des coûts des jetons. Un mardi, mon utilisation quotidienne des jetons a triplé. Ce n’était pas à cause de plus de demandes — mais à cause de réponses plus longues. Un changement d’invite que j’avais fait la veille faisait que le modèle générait des sorties beaucoup plus verbeuses que prévu. Le tableau de bord l’a détecté en quelques heures ; sinon, je ne l’aurais remarqué que lorsque la facture mensuelle serait arrivée.
Échecs silencieux des tâches cron. Deux tâches planifiées échouaient silencieusement depuis une semaine. Le tableau de bord montrait que le modèle attendu (pics d’exécution quotidiens à des moments précis) avait des lacunes. Sans le modèle visuel, je n’aurais peut-être pas remarqué cela avant une semaine supplémentaire.
La configuration
Stack : Prometheus pour la collecte de métriques, Grafana pour la visualisation, Node Exporter pour les métriques système. Temps total de configuration : 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 exécutez 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 de performance notable.
Obtenir des métriques d’OpenClaw : Les journaux d’OpenClaw sont la source de données principale. J’ai écrit un script simple qui analyse les fichiers journaux et expose les métriques comme un point de terminaison Prometheus. Les métriques clés à extraire :
– Compte des demandes (total et par type)
– Temps de réponse (moyenne, p95, p99)
– Utilisation des jetons (entrée et sortie, par demande)
– Nombre d’erreurs (par type)
– Sessions actives
– État d’exécution des tâches cron
La mise en page de mon tableau de bord
J’ai quatre lignes :
Ligne 1 : État de santé en un coup d’œil. Quatre grands chiffres : temps de réponse actuel, demandes dans la dernière heure, taux d’erreur, et coût quotidien estimé. Vert quand tout est normal, jaune quand c’est élevé, rouge quand quelque chose nécessite une attention. Je regarde cette ligne 10 fois par jour.
Ligne 2 : Tendances. Graphiques chronologiques pour le temps de réponse, le volume des demandes, et l’utilisation des jetons au cours des 24 dernières heures et 7 jours. C’est ici que je repère la dégradation progressive et les motifs inhabituels.
Ligne 3 : Coûts. Utilisation des jetons ventillée par modèle, par type de tâche, et par heure. Un total cumulé quotidien comparé au budget. Cette ligne m’a économisé des centaines de dollars en détectant tôt des anomalies de coût.
Ligne 4 : Activité des agents. Quels agents sont actifs, sur quoi ils travaillent, historique d’exécution des tâches cron, et erreurs récentes avec des détails. C’est la ligne de débogage — je ne la consulte que lorsque quelque chose ne va pas.
Les alertes qui comptent vraiment
J’ai configuré 6 alertes. Après un mois de réglages, j’en ai supprimé 2 qui étaient trop bruyantes et ajusté les seuils sur les 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 période de 5 minutes. Cela signifie généralement que l’API de l’IA rencontre des problèmes, ou que mon contexte est trop large.
Alerte 2 : Taux d’erreur > 5 %. Plus de 5 % des demandes échouées signifie que quelque chose ne va pas de manière systématique, pas juste des ratés occasionnels de l’API.
Alerte 3 : Coût quotidien dépasse 2x la moyenne. Cela 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 tâche cron manquée. Si une tâche cron attendue ne s’exécute pas dans les 30 minutes suivant son heure prévue, quelque chose ne va pas.
Ces quatre alertes sont le bon équilibre pour ma configuration. Suffisamment pour détecter de véritables problèmes. Pas trop nombreuses pour que je commence à les ignorer.
Ce que je sauterais
Tableaux de bord par demande. J’ai initialement construit un panneau montrant chaque demande 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 des points de données individuels pour la surveillance.
Panneaux de comparaison de modèles. J’ai construit des panneaux comparant Claude et GPT-4 sur la qualité des scores. Les données étaient intéressantes mais pas exploitables — j’avais déjà décidé quel modèle utiliser, et le tableau de bord n’a pas changé cette décision.
Visualisations élaborées. Grafana peut créer de magnifiques tableaux de bord avec des jauges, des cartes thermiques, et des diagrammes de flux. Résistez à l’envie. Des graphiques en ligne simples et de grands chiffres sont plus lisibles d’un coup d’œil, ce qui est tout l’intérêt.
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ésultant de la détection précoce des problèmes : estimées entre 200 et 300 $ par mois en coûts imprévus évités et en temps d’arrêt réduit.
Le tableau de bord s’est rentabilisé dès le premier mois. Si vous utilisez OpenClaw (ou tout système d’IA) sans visibilité, vous naviguez à l’aveugle. Vous pouvez naviguer sans problème. Mais quand vous ne le faites pas, vous ne le saurez pas avant d’avoir déjà eu un accident.
🕒 Published: