Gateway

Журналювання Gateway

Журналювання

Огляд для користувачів (CLI + Control UI + конфігурація) див. у /logging.

OpenClaw має дві «поверхні» журналів:

Консольний вивід (те, що ви бачите в терміналі / Debug UI).
Файлові журнали (рядки JSON), які записує реєстратор Gateway.

Під час запуску Gateway журналює розв’язану стандартну модель агента разом із типовими режимами, що впливають на нові сеанси, наприклад:

text

agent model: openai/gpt-5.5 (thinking=medium, fast=on)

thinking береться зі стандартного агента, параметрів моделі або глобального стандарту агента; коли його не задано, підсумок запуску показує medium. fast береться зі стандартного агента або параметрів моделі fastMode.

Файловий реєстратор

Стандартний файл журналу з ротацією розміщено в /tmp/openclaw/ (один файл на день): openclaw-YYYY-MM-DD.log
- Дата використовує локальний часовий пояс хоста Gateway.
Активні файли журналів ротуються при logging.maxFileBytes (за замовчуванням: 100 MB), зберігаючи до п’яти нумерованих архівів і продовжуючи запис у новий активний файл.
Шлях до файлу журналу та рівень можна налаштувати через ~/.openclaw/openclaw.json:
- logging.file
- logging.level

Формат файлу — один об’єкт JSON на рядок.

Шляхи коду для розмов, голосу в реальному часі та керованих кімнат використовують спільний файловий реєстратор для обмежених записів життєвого циклу. Ці записи призначені для операційного налагодження та експорту журналів OTLP; текст транскрипту, аудіодані, ідентифікатори ходів, ідентифікатори викликів та ідентифікатори елементів провайдера не копіюються до запису журналу.

Вкладка журналів Control UI відстежує цей файл через Gateway (logs.tail). CLI може робити те саме:

bash

openclaw logs --follow

Докладність і рівні журналювання

Файлові журнали керуються виключно logging.level.
--verbose впливає лише на докладність консолі (і стиль журналів WS); він не підвищує рівень файлового журналювання.
Щоб записувати деталі, доступні лише в докладному режимі, у файлові журнали, встановіть logging.level у debug або trace.
Журналювання трасування також включає діагностичні підсумки часу для вибраних гарячих шляхів, як-от підготовка фабрики інструментів Plugin. Див. /tools/plugin#slow-plugin-tool-setup.

Захоплення консолі

CLI захоплює console.log/info/warn/error/debug/trace і записує їх у файлові журнали, водночас продовжуючи друкувати у stdout/stderr.

Докладність консолі можна налаштувати окремо через:

logging.consoleLevel (за замовчуванням info)
logging.consoleStyle (pretty | compact | json)

Редагування чутливих даних

OpenClaw може маскувати чутливі токени до того, як вивід журналу або транскрипту залишить процес. Ця політика редагування журналів застосовується до консолі, файлових журналів, записів журналу OTLP і текстових приймачів транскриптів сеансів, тож відповідні секретні значення маскуються до запису рядків JSONL або повідомлень на диск.

logging.redactSensitive: off | tools (за замовчуванням: tools)
logging.redactPatterns: масив рядків регулярних виразів (перевизначає стандартні)
- Використовуйте сирі рядки регулярних виразів (автоматично gi) або /pattern/flags, якщо потрібні власні прапорці.
- Збіги маскуються зі збереженням перших 6 + останніх 4 символів (довжина >= 18), інакше ***.
- Стандартні значення охоплюють поширені присвоєння ключів, прапорці CLI, поля JSON, заголовки bearer, блоки PEM, популярні префікси токенів і назви полів платіжних облікових даних, як-от номер картки, CVC/CVV, спільний платіжний токен і платіжні облікові дані.

Деякі межі безпеки завжди редагують чутливі дані незалежно від logging.redactSensitive. Це включає події викликів інструментів Control UI, вивід інструмента sessions_history, експорти діагностичної підтримки, спостереження помилок провайдера, відображення команди схвалення exec і журнали протоколу WebSocket Gateway. Ці поверхні все ще можуть використовувати logging.redactPatterns як додаткові шаблони, але redactSensitive: "off" не змушує їх виводити необроблені секрети.

Журнали WebSocket Gateway

Gateway друкує журнали протоколу WebSocket у двох режимах:

Звичайний режим (без --verbose): друкуються лише «цікаві» результати RPC:
- помилки (ok=false)
- повільні виклики (стандартний поріг: >= 50ms)
- помилки розбору
Докладний режим (--verbose): друкує весь трафік запитів/відповідей WS.

Стиль журналів WS

openclaw gateway підтримує перемикач стилю для окремого Gateway:

--ws-log auto (за замовчуванням): звичайний режим оптимізований; докладний режим використовує компактний вивід
--ws-log compact: компактний вивід (парні запит/відповідь) у докладному режимі
--ws-log full: повний покадровий вивід у докладному режимі
--compact: псевдонім для --ws-log compact

Приклади:

bash

# optimized (only errors/slow)openclaw gateway # show all WS traffic (paired)openclaw gateway --verbose --ws-log compact # show all WS traffic (full meta)openclaw gateway --verbose --ws-log full

Форматування консолі (журналювання підсистем)

Форматер консолі враховує TTY і друкує узгоджені рядки з префіксами. Реєстратори підсистем тримають вивід згрупованим і зручним для перегляду.

Поведінка:

Префікси підсистем у кожному рядку (наприклад, [gateway], [canvas], [tailscale])
Кольори підсистем (стабільні для кожної підсистеми) плюс забарвлення рівнів
Колір, коли вивід є TTY або середовище схоже на багатий термінал (TERM/COLORTERM/TERM_PROGRAM), з урахуванням NO_COLOR
Скорочені префікси підсистем: відкидає початкові gateway/ + channels/, зберігає останні 2 сегменти (наприклад, whatsapp/outbound)
Підреєстратори за підсистемами (автоматичний префікс + структуроване поле { subsystem })
logRaw() для виводу QR/UX (без префікса, без форматування)
Стилі консолі (наприклад, pretty | compact | json)
Рівень журналювання консолі окремий від рівня файлового журналювання (файл зберігає повну деталізацію, коли logging.level встановлено в debug/trace)
Тіла повідомлень WhatsApp журналюються на рівні debug (використовуйте --verbose, щоб побачити їх)

Це зберігає наявні файлові журнали стабільними й водночас робить інтерактивний вивід зручним для перегляду.

Пов’язане

Was this useful?