Окружение и отладка

Диагностические флаги

Диагностические флаги позволяют включать целевые журналы отладки без активации подробного логирования повсюду. Флаги работают по принципу явного согласия и не оказывают эффекта, пока подсистема их не проверит.

Как это работает

  • Флаги — это строки (без учёта регистра).
  • Вы можете включить флаги в конфигурации или через переопределение переменной окружения.
  • Поддерживаются шаблоны (wildcards):
    • telegram.* соответствует telegram.http
    • * включает все флаги

Включение через конфигурацию

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

Несколько флагов:

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

Перезапустите шлюз после изменения флагов.

Переопределение через переменную окружения (разовое)

OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload

Отключить все флаги:

OPENCLAW_DIAGNOSTICS=0

Куда попадают логи

Флаги отправляют записи в стандартный диагностический файл журнала. По умолчанию:

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

Если вы установили logging.file, используйте этот путь. Логи записываются в формате JSONL (один объект JSON на строку). Сокрытие чувствительных данных всё ещё применяется на основе logging.redactSensitive.

Извлечение логов

Выберите последний файл журнала:

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

Отфильтруйте для диагностики Telegram HTTP:

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

Или отслеживайте в реальном времени при воспроизведении проблемы:

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

Для удалённых шлюзов также можно использовать openclaw logs --follow (см. /cli/logs).

Примечания

  • Если logging.level установлен выше, чем warn, эти логи могут быть подавлены. Значение по умолчанию info подходит.
  • Флаги безопасно оставлять включёнными; они влияют только на объём логов для конкретной подсистемы.
  • Используйте /logging для изменения назначения логов, уровней и правил сокрытия данных.

Сбой Node + tsxNode.js