Skip to main content
OpenClaw puede crear un .zip de diagnóstico local para informes de errores: estado y salud del Gateway, registros, estructura de configuración y eventos recientes de estabilidad sin cargas útiles, todo ello sanitizado. Trate los paquetes de diagnóstico como secretos hasta que se revisen. Las cargas útiles y las credenciales se ocultan por diseño, pero el paquete sigue resumiendo los registros locales del Gateway y el estado del entorno de ejecución a nivel del host.

​
Inicio rápido

Imprime la ruta del archivo zip generado. Para elegir una ruta de salida:
Para automatización:

​
Comando de chat

Los propietarios pueden ejecutar /diagnostics [note] en cualquier conversación para solicitar una exportación local del Gateway como un único informe de soporte que se puede copiar y pegar:
  1. Envíe /diagnostics, opcionalmente con una nota breve (/diagnostics bad tool choice).
  2. OpenClaw envía un preámbulo y solicita una única aprobación explícita de ejecución, que ejecuta openclaw gateway diagnostics export --json. No apruebe los diagnósticos mediante una regla de autorización total.
  3. Tras la aprobación, OpenClaw responde con la ruta del paquete local, un resumen del manifiesto, notas de privacidad e identificadores de sesión relevantes.
En los chats grupales, un propietario puede seguir ejecutando /diagnostics, pero OpenClaw envía de forma privada al propietario el resultado de la exportación, las solicitudes de aprobación y el desglose de sesiones/hilos de Codex. El grupo solo ve un aviso breve de que los diagnósticos se enviaron de forma privada. Si no existe una ruta privada hacia el propietario, el comando falla de forma segura y solicita al propietario que lo ejecute desde un mensaje directo. Cuando la sesión activa utiliza el arnés nativo de OpenAI Codex, la misma aprobación de ejecución también cubre el envío de comentarios a OpenAI para los hilos de Codex que OpenClaw conoce. Ese envío es independiente del archivo zip local del Gateway y solo se produce en sesiones del arnés de Codex. La solicitud de aprobación indica que la aprobación también envía comentarios de Codex, sin enumerar los identificadores de sesión ni de hilo de Codex. Tras la aprobación, la respuesta enumera los canales, los identificadores de sesión de OpenClaw, los identificadores de hilo de Codex y los comandos locales para reanudar los hilos que se enviaron a OpenAI. Rechazar o ignorar la aprobación omite la exportación, el envío de comentarios de Codex y la lista de identificadores de Codex. Esto acorta el ciclo de depuración de Codex: detecte un comportamiento incorrecto en un canal, ejecute /diagnostics, apruebe una vez, comparta el informe y, a continuación, ejecute localmente el comando codex resume <thread-id> impreso si desea inspeccionar el hilo personalmente. Consulte arnés de Codex.

​
Contenido de la exportación

  • summary.md: resumen legible para el equipo de soporte.
  • diagnostics.json: resumen procesable por máquinas de la configuración, los registros, el estado, la salud y los datos de estabilidad.
  • manifest.json: metadatos de la exportación y lista de archivos.
  • Estructura de configuración sanitizada y detalles de configuración no secretos.
  • Resúmenes de registros sanitizados y líneas de registro recientes con datos ocultos.
  • Instantáneas del estado y la salud del Gateway obtenidas con el mejor esfuerzo posible.
  • stability/latest.json: paquete de estabilidad persistente más reciente, cuando esté disponible.
La exportación sigue siendo útil cuando el Gateway no funciona correctamente: si fallan las solicitudes de estado o salud, se siguen recopilando los registros locales, la estructura de configuración y el paquete de estabilidad más reciente cuando están disponibles.

​
Modelo de privacidad

Se conservan: nombres de subsistemas, identificadores de plugins, identificadores de proveedores, identificadores de canales, modos configurados, códigos de estado, duraciones, recuentos de bytes, estado de las colas, lecturas de memoria, metadatos de registros sanitizados, mensajes operativos con datos ocultos, estructura de configuración y ajustes de funciones no secretos. Se omiten o se ocultan: texto de chats, prompts, instrucciones, cuerpos de webhooks, salidas de herramientas, credenciales, claves de API, tokens, cookies, valores secretos, cuerpos sin procesar de solicitudes/respuestas, identificadores de cuentas, identificadores de mensajes, identificadores de sesión sin procesar, nombres de host y nombres de usuario locales. Cuando un mensaje de registro parece contener texto de una carga útil de usuario, chat, prompt o herramienta, la exportación solo conserva que se omitió un mensaje y su recuento de bytes.

​
Registrador de estabilidad

De forma predeterminada, el Gateway registra un flujo de estabilidad acotado y sin cargas útiles cuando los diagnósticos están habilitados. Captura datos operativos, no contenido. El mismo Heartbeat también muestrea la capacidad de respuesta cuando el bucle de eventos o la CPU parecen saturados y emite eventos diagnostic.liveness.warning con el retraso del bucle de eventos, la utilización del bucle de eventos, la proporción de núcleos de CPU, los recuentos de sesiones activas/en espera/en cola, la fase actual de inicio/ejecución (cuando se conoce), los intervalos de fases recientes y etiquetas de trabajo acotadas. Estos se convierten en líneas de registro del Gateway de nivel warn solo cuando hay trabajo en espera o en cola, o cuando el trabajo activo coincide con un retraso sostenido del bucle de eventos; de lo contrario, se registran en debug. Las muestras de capacidad de respuesta en reposo se siguen registrando como eventos de diagnóstico, pero nunca se elevan por sí mismas al nivel de advertencia. Las fases de inicio emiten eventos diagnostic.phase.completed con tiempos de reloj de pared y de CPU. Los diagnósticos de ejecuciones integradas bloqueadas marcan terminalProgressStale=true cuando el último progreso del puente parecía terminal (por ejemplo, un elemento de respuesta sin procesar o un evento de finalización de respuesta), pero el Gateway todavía considera activa la ejecución integrada. Para inspeccionar el registrador en directo:
Para inspeccionar el paquete persistente más reciente después de una salida fatal, un tiempo de espera agotado durante el apagado o un fallo de inicio tras un reinicio:
Para crear un archivo zip de diagnóstico a partir del paquete persistente más reciente:
Los paquetes persistentes se almacenan en ~/.openclaw/logs/stability/ cuando existen eventos.

​
Opciones útiles

​
Desactivar los diagnósticos

Los diagnósticos están habilitados de forma predeterminada. Para desactivar el registrador de estabilidad y la recopilación de eventos de diagnóstico:
Desactivar los diagnósticos reduce el nivel de detalle de los informes de errores, pero no afecta al registro normal del Gateway. Los eventos de presión de memoria registran datos de RSS, heap, umbral y crecimiento (rss_threshold, heap_threshold, rss_growth) sin realizar un análisis del sistema de archivos ni escribir una instantánea previa a una falta de memoria.

​
Contenido relacionado