Vous faites déjà tourner OpenClaw Gateway et stdio MCP, mais en production vous voyez une lente hausse du nombre de sous-processus, une montée du RSS ou des OOM ponctuels, sans savoir s'il faut ajuster la config ou l'architecture. Cet article complète dépannage handshake MCP stdio/HTTP et blocages et observabilité Gateway en production : d'abord sept règles de périmètre, puis un tableau stdio vs HTTP, un runbook en six étapes de reclaim et de limitation, et des notes systemd/Docker ; en fin de page, liens vers la catégorie OpenClaw et les scénarios de calcul.
Pour stdio MCP, handshake de connexion, blocages, refus d'autorisation : voir d'abord handshake ; pour listes d'autorisation et politique d'outils : liste blanche MCP ; pour healthchecks, logs, upgrade/rollback : observabilité. Ici, nous ne traitons que : lorsque le Gateway accepte déjà les sessions de façon stable mais que les sous-processus et les courbes mémoire restent inacceptables, comment gouverner par couches.
Échec du premier handshake : transport MCP et chemins exécutables aval ; non développé ici.
Jeton / scope et gateway closed (1000) : article dédié closed(1000), pas les scripts de reclaim.
Politique de sécurité pure : changements dmPolicy / networkPolicy vers l'article durcissement.
Gateway qui ne démarre pas / not ready : ports, mémoire, ordre compose dans l'article not ready.
Timeouts du backend modèle côté applicatif : peut coexister avec la gouvernance MCP, la cause peut être le routage.
Fuites ponctuelles dues à des bugs MCP tiers : correctif amont ou épinglage de version ; le reclaim atténue seulement.
Prendre le « nettoyage » pour remède universel : des kills sans niveau d'eau ni journal de versions masquent les vraies fuites.
Dans la communauté open source, stdio MCP en tant que sous-processus Gateway sur des sessions longues peut faire gonfler le pool avec les sessions ; le comportement varie selon les versions. Il faut inscrire « plafond de processus acceptable + politique de reclaim » dans le runbook plutôt que de compter sur les défauts. D'abord le modèle isolation des sessions → accumulation prévisible, puis le tableau.
Avec l'article handshake : les échecs apparaissent comme erreurs de connexion/handshake dans les journaux ; les signaux typiques ici sont nombre de processus monotone, montée en marches de la mémoire, OOM sur un rythme fixe. Lors du diagnostic, vérifier la relation parent-enfant Gateway/MCP (ps / pstree dans le conteneur) pour ne pas compter backends modèle ou canaux comme MCP.
Si vous exécutez plusieurs chaînes d'outils (scripts locaux et agents persistants sur un Mac distant), esquissez la topologie : quel hôte porte le Gateway et le MCP lourd ? La marge mémoire du nœud Gateway plafonne les sessions stdio parallèles. Capacité et accès : croiser tarifs de location et exigences réseau du centre d'aide.
Côté observabilité, collectez au moins trois séries : nombre de processus, RSS Gateway et MCP, QPS d'appels d'outils et nombre de sessions. Sans dimension session, impossible de distinguer accumulation de pic métier ou reclaim manquant. Alignez les champs de logs sur observabilité, puis comparez semaine à semaine dans les tableaux de bord.
Autre erreur : « beaucoup d'enfants = passer à HTTP ». Si les outils sont très légers et la concurrence faible, le problème est souvent des sessions non fermées ou un binaire aval bloquant ; resserrer d'abord le cycle de vie côté client avant d'estimer une migration de transport.
Le transport stdio exécute le serveur MCP comme sous-processus fortement couplé au cycle de vie du Gateway ; HTTP ressemble plutôt à un point de terminaison indépendant, avec d'autres chemins de mise à l'échelle et de santé. Le tableau aide à trancher « continuer à optimiser stdio » ou « monter en HTTP ».
| Dimension | stdio MCP | HTTP MCP |
|---|---|---|
| Couplage processus | Les enfants suivent le modèle Gateway/sessions ; l'accumulation se ressent vite | Souvent processus séparé, le Gateway est client |
| Mise à l'échelle horizontale | Souvent besoin d'étendre le Gateway ou de limiter les sessions | Réplicas du service MCP indépendants |
| Healthchecks | Dépend des logs Gateway et de la table des processus | Sondes HTTP et SLO dédiés |
| Rayon d'explosion | Les problèmes enfants ralentissent le Gateway sur la même machine | Meilleure isolation, saut réseau en plus |
| Cas d'usage | Outils légers, faible concurrence, confiance même hôte | Outils lourds, forte charge, rythme de release indépendant |
La gouvernance n'est pas d'empiler des machines à l'infini : c'est un contrat sur les courbes processus et mémoire ; au-delà, limiter, reclaim ou changer de transport.
Si stdio/HTTP handshake valide la configuration mais que la ligne rouge mémoire persiste, inscrivez « passer en HTTP » dans la revue d'architecture plutôt que d'agrandir sans fin l'hôte.
Ordre : « preuves d'abord, limitation ensuite, architecture en dernier ». Aligner les champs de logs sur observabilité, éviter les kills aveugles.
Établir une baseline : sous charge stable, noter processus, RSS, version Gateway et packages MCP dans le registre des changements.
Séparer pics et fuites : les pics suivent souvent les sessions parallèles ; une croissance monotone suggère reclaim manquant ou aval bloqué—capturer des stacks.
Resserrez concurrence et timeouts : dans les limites de config, baisser les appels d'outils parallèles et raccourcir les timeouts d'inactivité ; observer les courbes.
Reclaim planifié : fenêtre de maintenance, redémarrage rolling du Gateway ou isolement de nœud, drain des sessions d'abord.
Conteneurs et systemd : vérifier que les variables d'environnement atteignent le runtime réel (piège fréquent : daemon vs shell interactif).
Évaluer la migration HTTP : pour les MCP lourds ou les services à scaler séparément, déployer avec healthchecks et basculer le Gateway vers le transport HTTP.
ps -axo pid,ppid,rss,comm | grep -E 'openclaw|mcp|node' | head -n 50 # Dans le conteneur, avec pstree -p 1 pour parent/enfant
Astuce : après modification de openclaw.json, exécuter la validation recommandée (ex. config:validate / doctor), puis redémarrage rolling, pour éviter « config censée appliquée, processus sur anciennes valeurs ».
Des issues publiques signalent des sous-processus stdio MCP non récupérés lors du renouvellement de session ; traitez reclaim périodique + suivi de version comme atténuation temporaire en attendant le correctif amont. Ne dépendez pas longtemps d'un kill manuel non documenté.
Avec orchestration externe (timer systemd, CronJob k8s) pour un reclaim sidecar, alignez utilisateur Gateway, environnement et limites mémoire cgroup ; sinon l'arbre vu par le script diverge de la production. Sur petit nœud unique, mieux vaut d'abord ramener concurrence et timeouts dans le contrat contractuel.
Enfin, liez chaque changement de reclaim ou de limitation à un numéro de version ; le comportement stdio peut varier entre mineures du Gateway.
Les services systemd n'héritent pas du ~/.zshrc interactif. Sous Docker Compose, chemins MCP et montages en lecture seule peuvent faire boucler les enfants. Avec Docker production, vérifier Environment=, WorkingDirectory=, volumes nommés et digest d'image.
Attention : redémarrer souvent avec docker compose restart sans code de sortie confond erreur de configuration et fuite mémoire.
À lire avec dépannage not ready : sous pression mémoire, le Gateway peut ne pas atteindre une phase MCP stable ; traiter d'abord ressources et ordre de démarrage.
Les chiffres ci-dessous sont des points de départ courants ; ajustez à votre charge.
Empiler Agent et Gateway sur un petit nœud instable produit une « double instabilité » outillage et modèle ; ajouter des machines sans changer le modèle de session fait croître le coût linéairement. Pour une puissance prévisible en ligne sur le long terme sur macOS et de la marge pour l'écosystème OpenClaw, la location cloud Mac Mini NodeMini avec SSH fixe et specs claires surpasse souvent le bricolage. Voir tarifs et centre d'aide pour le réseau et l'accès.
Opérationnalisez « plafond de sessions stdio + politique de reclaim + déclencheurs de migration HTTP » sur une même page de contrat pour que dev et SRE partagent les mêmes métriques.
Pour les post-mortems externes, joindre instantanés de processus et extraits de logs afin de séparer erreur de config et défaut amont.
Pas nécessairement. Séparez croissance attendue par isolation des sessions et accumulation de type fuite, puis confrontez RSS et version du Gateway ; montez en version corrigée plutôt que d'ajouter seulement du cron.
Lorsque la durée de vie des sous-processus s'aligne mal avec le modèle de sessions sur le long terme, ou que la marge mémoire reste insuffisante sans scale-out, HTTP MCP facilite souvent scale et healthchecks indépendants. Voir aussi la catégorie OpenClaw.
Ouvrez d'abord les tarifs de location pour comparer les offres, puis le centre d'aide pour réseau et accès afin de construire le tableau de capacité.