Flags de diagnóstico

Los flags de diagnóstico permiten habilitar logs de depuración dirigidos sin activar el logging verboso en todas partes. Los flags son opcionales y no tienen efecto a menos que un subsistema los verifique.

Cómo funciona

Los flags son cadenas de texto (sin distinción entre mayúsculas y minúsculas).
Puedes habilitar flags en la configuración o mediante una variable de entorno.
Se soportan comodines:
- telegram.* coincide con telegram.http
- * habilita todos los flags

Habilitar vía configuración

{
  "diagnostics": {
    "flags": ["telegram.http"]
  }
}

Múltiples flags:

{
  "diagnostics": {
    "flags": ["telegram.http", "gateway.*"]
  }
}

Reinicia el gateway después de cambiar los flags.

Variable de entorno (uso puntual)

OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload

Deshabilitar todos los flags:

OPENCLAW_DIAGNOSTICS=0

Dónde van los logs

Los flags emiten logs en el archivo de diagnóstico estándar. Por defecto:

/tmp/openclaw/openclaw-YYYY-MM-DD.log

Si configuras logging.file, usa esa ruta en su lugar. Los logs están en formato JSONL (un objeto JSON por línea). La redacción sigue aplicándose según logging.redactSensitive.

Extraer logs

Seleccionar el archivo de log más reciente:

ls -t /tmp/openclaw/openclaw-*.log | head -n 1

Filtrar diagnósticos HTTP de Telegram:

rg "telegram http error" /tmp/openclaw/openclaw-*.log

O hacer tail mientras reproduces:

tail -f /tmp/openclaw/openclaw-$(date +%F).log | rg "telegram http error"

Para gateways remotos, también puedes usar openclaw logs --follow (consulta /cli/logs).

Notas

Si logging.level está configurado por encima de warn, estos logs pueden ser suprimidos. El valor por defecto info está bien.
Es seguro dejar los flags habilitados; solo afectan el volumen de logs del subsistema específico.
Usa /logging para cambiar destinos de logs, niveles y redacción.