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

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

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

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

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

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

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

# Файловий logger

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

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

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

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

openclaw logs --follow

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

• Файлові журнали керуються виключно logging.level.
• --verbose впливає лише на докладність консолі (і стиль журналів WS); він не підвищує рівень файлового журналювання.
• Щоб записувати у файлові журнали деталі, доступні лише в докладному режимі, встановіть logging.level у debug або trace.
• 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: масив рядків regex (перевизначає типові значення)
  • Використовуйте сирі рядки regex (автоматично 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

Приклади:

# 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-aware і друкує узгоджені рядки з префіксами. Logger підсистем утримують вивід згрупованим і зручним для перегляду.

Поведінка:

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

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

# Пов’язане

• Журналювання
• Експорт OpenTelemetry
• Експорт діагностики