Monitoring et observabilité : voir vraiment ce que fait OpenClaw

Si tu fais tourner OpenClaw en continu, le vrai sujet n’est pas seulement “est-ce que le gateway répond ?”.
Le vrai sujet, c’est : est-ce que les messages entrent, est-ce que les runs sortent, et est-ce que tu peux comprendre rapidement pourquoi ça coince quand ça coince.

OpenClaw a déjà une base solide pour ça. Mais il faut bien distinguer trois couches : status, logs et diagnostics.

1) Commencer par le minimum vital : health, status, logs

Le trio de base côté CLI est déjà là :

• openclaw health pour un snapshot de santé du gateway
• openclaw status pour les diagnostics canaux + sessions
• openclaw logs --follow pour lire le journal du gateway en temps réel

Ce n’est pas cosmétique. C’est la différence entre “j’ai l’impression que Telegram ne répond plus” et “je vois précisément si le souci vient du canal, de la file d’attente ou d’une session coincée”.

Les logs fichier sont écrits par défaut en JSONL dans /tmp/openclaw/openclaw-YYYY-MM-DD.log, puis consommés par la CLI et l’UI de contrôle. Autrement dit : les logs restent la première source de vérité opérationnelle.

Si tu démarres tout juste ton infra, je te recommande de cadrer ça en amont avec un socle propre côté machine — on l’avait déjà détaillé dans Choisir et paramétrer son VPS OpenClaw de façon béton.

2) Les logs ne suffisent plus dès que l’instance devient “vivante”

Dès que tu as plusieurs canaux, des crons, des sessions qui durent, ou des runs détachés, les logs seuls deviennent vite pénibles à corréler.

C’est exactement là qu’OpenClaw pousse une autre surface : les diagnostics.

La doc officielle est claire sur le point important :

• les logs servent à lire ce qui se passe,
• les diagnostics servent à émettre des événements structurés exploitables par une stack d’observabilité.

Aujourd’hui, OpenClaw expose déjà des événements pour :

• l’usage modèle (model.usage),
• la réception et le traitement des webhooks,
• la mise en file des messages,
• l’état des sessions,
• les sessions bloquées,
• les tentatives de run,
• et un heartbeat de diagnostic agrégé.

En clair : si ton besoin est “avoir des signaux exploitables dans Grafana, Datadog ou un collector OTel”, ce n’est pas le flux de logs qu’il faut regarder en premier, c’est la couche diagnostics.

3) Oui, OpenClaw parle déjà OpenTelemetry

C’est probablement le point le plus sous-estimé du moment.

OpenClaw peut exporter ses diagnostics via le plugin diagnostics-otel, en OTLP/HTTP, avec support des trois signaux utiles :

• metrics,
• traces,
• logs.

La doc logging.md liste déjà des métriques exportées comme :

• openclaw.tokens
• openclaw.cost.usd
• openclaw.run.duration_ms
• openclaw.webhook.received
• openclaw.message.processed
• openclaw.queue.depth
• openclaw.session.state
• openclaw.session.stuck

Donc non, l’observabilité OpenClaw ne se résume plus à “tail -f sur le log du gateway”.

Et ça bouge encore : la PR ouverte #21290 pousse l’extension diagnostics-otel vers des spans et métriques alignés avec les conventions GenAI d’OpenTelemetry, avec notamment des spans par inférence modèle, exécution d’outil et run complet.

Autrement dit, OpenClaw commence à devenir observable non seulement comme un bot, mais comme un runtime agentique.

4) Ce qui manque encore : une observabilité plus “opérateur”

Il faut aussi rester honnête : tout n’est pas encore au niveau d’un produit d’infra mature.

Côté besoins terrain, on voit bien les trous qui remontent dans le repo :

• l’issue #13608 demande un support métriques/observabilité plus standardisé,
• la PR #43618 ajoute un snapshot de diagnostics de queue pour mieux voir backlog, lanes actives et sessions coincées,
• l’issue #47876 réclame une vue plus session-centric pour les cas “l’agent bosse mais le chat n’a rien reçu”.

C’est intéressant parce que ça révèle la vraie maturité du sujet :

OpenClaw a déjà de bons primitives techniques, mais l’expérience opérateur est encore en train de se construire.

Dit autrement :

• pour un maker solo, l’existant est déjà largement exploitable ;
• pour une instance always-on multi-canaux, tu voudras rapidement compléter avec ton propre collector, des dashboards et quelques alertes ciblées.

5) Ma stack minimale recommandée aujourd’hui

Si je devais monter une observabilité OpenClaw sans sur-ingénierie, je ferais simple :

Niveau 1 — indispensable

• openclaw health
• openclaw status
• openclaw logs --follow
• rotation et centralisation des logs gateway

Niveau 2 — dès que ça tourne en continu

• diagnostics.enabled: true
• plugin diagnostics-otel activé
• export OTLP vers un collector ou backend compatible
• dashboards sur tokens, coût, durée de run, messages traités, sessions coincées

Niveau 3 — pour les setups sérieux

• alertes sur session.stuck
• suivi des files/lanes
• corrélation canal → session → run → tool
• runbook clair pour distinguer : problème de canal, problème de queue, problème de provider, ou session perdue

Ce troisième niveau devient particulièrement pertinent si tu exploites beaucoup d’automatisation avec cron et délégation de tâches. À ce sujet, l’article Task Flow vs Sub-Agents : quand utiliser quoi dans OpenClaw aide aussi à anticiper où la complexité opérationnelle apparaît vraiment.

6) Le bon modèle mental

Le mauvais réflexe, c’est de chercher “le dashboard magique”.

Le bon réflexe, c’est de penser OpenClaw comme un système à trois plans :

1. Santé immédiate → health et status
2. Forensics / debug → logs JSONL
3. Pilotage temps réel → diagnostics + OTel

Si tu gardes cette séparation, l’observabilité d’OpenClaw devient beaucoup plus lisible.

Et c’est aussi ce qui évite de tomber dans le piège classique des agents : croire que tout va bien parce que le process tourne encore, alors que le vrai problème est ailleurs — canal qui n’ingère plus, file qui s’allonge, session qui dérive, ou run qui n’émet plus rien.

En bref : OpenClaw dispose déjà des briques nécessaires pour une observabilité sérieuse, surtout via status, logs et diagnostics-otel. Ce n’est pas encore un Prometheus/Grafana packagé clé en main, mais ce n’est plus du tout une boîte noire non plus.

Pour aller plus loin :

• Choisir et paramétrer son VPS OpenClaw de façon béton
• OpenClaw : quand rester en session main, quand isoler un run
• Task Flow vs Sub-Agents : quand utiliser quoi dans OpenClaw

Sources primaires : documentation officielle OpenClaw (logging.md, cli/health.md, cli/logs.md, cli/status.md) et discussions/PR GitHub ouvertes #13608, #21290, #43618, #47876, consultées le 20 avril 2026.