Диагностические флаги
Диагностические флаги позволяют включать целевые журналы отладки без активации подробного логирования повсюду. Флаги работают по принципу явного согласия и не оказывают эффекта, пока подсистема их не проверит.
Как это работает
- Флаги — это строки (без учёта регистра).
- Вы можете включить флаги в конфигурации или через переопределение переменной окружения.
- Поддерживаются шаблоны (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 для изменения назначения логов, уровней и правил сокрытия данных.