Les métriques Prometheus d’OpenClaw

Faire tourner un assistant en production finit par devenir une question d’exploitation plutôt qu’une question de modèle. On veut savoir combien d’exécutions se sont terminées, combien de temps ont pris les appels au fournisseur, ce qu’ils ont coûté, si la file s’accumule et si la boucle d’événements se bloque. OpenClaw répond avec un plugin de diagnostics officiel qui rend le format texte standard d’exposition Prometheus sur une route de la passerelle, de sorte qu’une pile Prometheus ou Grafana existante peut la collecter directement. Il n’y a pas de collecteur à déployer, mais il n’y a pas non plus de port de métriques public, car la route est une surface opérateur et reste derrière l’authentification.

Ce qui est exporté

• Le plugin écoute les diagnostics de confiance ainsi que des événements internes marqués appartenant au répartiteur, qui couvrent les signaux de file, de mémoire et de récupération de session, et les rend au format texte standard d’exposition Prometheus sur une route de diagnostics de la passerelle.
• Les compteurs et les histogrammes couvrent les requêtes RPC de la passerelle avec des mesures distinctes de première réponse, de gestionnaire, d’admission et d’attente en file, les exécutions terminées et leur durée, les appels de modèle répartis par fournisseur et par transport, les bascules, les totaux de jetons, le coût en dollars américains, les activations de compétences, les exécutions d’outils y compris celles qui sont bloquées, les exécutions de harnais, les webhooks et toute la chaîne de messages.
• La santé d’exécution est exportée elle aussi, avec la taille et l’attente des files, l’état des sessions, les compteurs de blocage et de récupération, les maxima de retard de la boucle d’événements et les secondes observées, des mesures de vivacité dont un ratio de cœurs processeur qui peut dépasser un, la mémoire et la pression mémoire, les charges utiles trop grandes, la durée du ramasse-miettes et deux compteurs d’abandon.
• Pour les métriques d’appel de modèle, une unité d’observation mesure une seule requête de fournisseur observable tandis que l’autre mesure un tour d’agent synthétique de Claude Code ou de Codex en ligne de commande qui peut contenir plusieurs requêtes de fournisseur cachées, si bien que les deux séries ne doivent pas être comparées comme si elles décrivaient la même latence.

Les étiquettes Prometheus restent bornées et de faible cardinalité.

La cardinalité comme budget

L’exportateur conserve au plus 2 048 séries temporelles en mémoire, compteurs, jauges et histogrammes confondus, et tout ce qui dépasse est abandonné pendant qu’un compteur dédié s’incrémente d’une unité à chaque fois. Ce compteur est le signal à surveiller, car la limite n’est jamais relevée automatiquement et une valeur qui monte signifie qu’un attribut en amont laisse fuir des valeurs à forte cardinalité, et non que l’exportateur manque de place. Le détail du calcul mérite d’être connu, puisque chaque méthode RPC de la passerelle dotée des quatre mesures occupe cinq échantillons agrégés, et qu’un histogramme de durée prend un seul échantillon mais se déploie en 19 séries au moment de la collecte, si bien que couvrir toutes les méthodes du cœur peut remplir le budget à lui seul. Les étiquettes sont expurgées et doivent respecter une politique de caractères à faible cardinalité, les valeurs non conformes étant remplacées par inconnu, autre ou aucun selon la métrique, et tout ce qui ressemble à une clé de session d’agent est remplacé également. Les identifiants de diagnostic bruts ne sont jamais émis, ce qui exclut les identifiants d’exécution, les clés et identifiants de session, les identifiants d’appel et d’appel d’outil, les identifiants de message, les identifiants de conversation et les identifiants de requête de fournisseur. Le texte des invites et des réponses, les entrées et sorties d’outils, les invites système, les transcriptions vocales et les charges audio, les noms d’hôte, les chemins de fichiers et les valeurs secrètes n’apparaissent jamais. La file de diagnostic asynchrone peut elle aussi abandonner des observations en cas de saturation, et elle le signale par son propre compteur. Entre ces deux compteurs, on peut savoir si un tableau de bord silencieux traduit un système calme ou une chaîne qui perd des données.

Obtenir une première collecte

• Installez et activez le plugin, laissez les diagnostics activés, puis redémarrez la passerelle, car la route HTTP est enregistrée au démarrage du plugin et un processus déjà lancé ne la prendra pas en compte.
• Collectez avec les mêmes identifiants que vos clients opérateurs utilisent déjà, puisque la route exige la portée opérateur de la passerelle et un appelant dont les portées effectives incluent la lecture opérateur, impliquée aussi bien par l’écriture que par l’administration.
• Attendez-vous à un corps vide avant tout trafic, car les compteurs et les histogrammes n’émettent des lignes qu’après au moins un événement, et attendez-vous à des compteurs remis à zéro après un redémarrage de la passerelle puisque le plugin ne garde son état qu’en mémoire.

Si la première collecte revient vide ou refusée, les deux sujets à examiner sont l’authentification de la passerelle et les notes de dépannage de l’exportateur, car un corps vide, un code 401 et un code 403 pour portée de lecture manquante sont trois problèmes différents avec trois corrections différentes.

Pourquoi des métriques seules

Le plugin fait une seule chose, et la référence dit clairement que c’est un choix et non un manque. C’est une surface en mode tirage, sans collecteur externe, sans traces et sans journaux, ce qui convient à une pile déjà normalisée sur Prometheus et Grafana, tandis que l’exportateur OpenTelemetry existe pour tout le reste et que les deux peuvent tourner ensemble, séparément ou pas du tout. La même retenue façonne la collecte elle-même. Les fenêtres de boucle d’événements et les entrées de ramasse-miettes ne sont recueillies que lorsque quelque chose s’y intéresse, si bien que des compteurs d’exécutions, d’appels de modèle et de le travail en file peuvent déjà exister pendant qu’un consommateur ajouté plus tard attend encore que le battement de diagnostic le remarque au prochain battement. Les observations antérieures à ce moment ne sont pas rattrapées, et une réinitialisation volontaire du moniteur jette la fenêtre inachevée. Cela rend les chiffres honnêtes sur leur propre couverture, ce qui est plus utile qu’un tableau de bord qui invente silencieusement une continuité. Cela signifie aussi que le compteur de durée représentée et les compteurs d’abandon font partie de la lecture des données plutôt que d’être des extras facultatifs.

Sur Diali

Sur Diali, chaque client fait tourner son propre assistant, et la configuration d’exécution est générée depuis le tableau de bord puis remplacée à chaque version, si bien que le câblage opérationnel n’est pas à entretenir à la main. L’état vit sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). OpenClaw hébergé sur Diali décrit la forme hébergée et La sécurité Diali couvre le reste.

• La route exige la lecture opérateur, pas un port public.
• Surveillez le compteur de séries abandonnées avant tout graphique.
• Les compteurs repartent de zéro après un redémarrage.