Gateway
Експорт діагностики
OpenClaw може створити локальний діагностичний zip-архів для звітів про помилки. Він об’єднує очищені від чутливих даних статус Gateway, стан працездатності, журнали, форму конфігурації та нещодавні події стабільності без корисного навантаження.
Ставтеся до діагностичних пакетів як до секретів, доки не переглянете їх. Вони розроблені так, щоб пропускати або редагувати корисні навантаження та облікові дані, але все одно підсумовують локальні журнали Gateway і стан виконання на рівні хоста.
Швидкий старт
openclaw gateway diagnostics export
Команда виводить шлях до записаного zip-архіву. Щоб вибрати шлях:
openclaw gateway diagnostics export --output openclaw-diagnostics.zip
Для автоматизації:
openclaw gateway diagnostics export --json
Команда чату
Власники можуть використовувати /diagnostics [note] у чаті, щоб запросити локальний експорт Gateway. Використовуйте це, коли помилка сталася в реальній розмові й вам потрібен один звіт для підтримки, який можна скопіювати та вставити:
- Надішліть
/diagnosticsу розмові, де ви помітили проблему. Додайте коротку примітку, якщо це допоможе, наприклад/diagnostics bad tool choice. - OpenClaw надсилає вступ до діагностики та просить одне явне підтвердження exec. Підтвердження запускає
openclaw gateway diagnostics export --json. Не підтверджуйте діагностику через правило allow-all. - Після підтвердження OpenClaw відповідає звітом, який можна вставити, з локальним шляхом до пакета, підсумком маніфесту, примітками щодо приватності та відповідними ідентифікаторами сесій.
У групових чатах власник усе ще може запускати /diagnostics, але OpenClaw не публікує діагностичні подробиці назад у спільний чат. Він надсилає вступ, запити підтвердження, результат експорту Gateway і розбивку сесії/потоку Codex власнику через приватний маршрут підтвердження. Група отримує лише коротке повідомлення, що діагностичний процес було надіслано приватно. Якщо OpenClaw не може знайти приватний маршрут до власника, команда безпечно завершується помилкою та просить власника запустити її з DM.
Коли активна сесія OpenClaw використовує нативний OpenAI Codex harness, те саме підтвердження exec також охоплює завантаження відгуку OpenAI для runtime-потоків Codex, про які знає OpenClaw. Це завантаження відокремлене від локального zip-архіву Gateway і з’являється лише для сесій Codex harness. Перед підтвердженням запит пояснює, що підтвердження діагностики також надішле відгук Codex, але не перелічує ідентифікатори сесій або потоків Codex. Після підтвердження відповідь у чаті перелічує канали, ідентифікатори сесій OpenClaw, ідентифікатори потоків Codex і локальні команди відновлення для потоків, які було надіслано на сервери OpenAI. Якщо ви відхилите або проігноруєте підтвердження, OpenClaw не запускає експорт, не надсилає відгук Codex і не виводить ідентифікатори Codex.
Це робить типовий цикл налагодження Codex коротким: помітьте неправильну поведінку в Telegram, Discord або іншому каналі, запустіть /diagnostics, підтвердьте один раз, поділіться звітом із підтримкою, а потім запустіть виведену команду codex resume <thread-id> локально, якщо хочете самостійно перевірити нативний потік Codex. Див. Codex harness для цього процесу перевірки.
Що містить експорт
Zip-архів містить:
summary.md: зрозумілий для людини огляд для підтримки.diagnostics.json: машиночитаний підсумок конфігурації, журналів, статусу, стану працездатності та даних стабільності.manifest.json: метадані експорту та список файлів.- Очищену від чутливих даних форму конфігурації та несекретні подробиці конфігурації.
- Очищені від чутливих даних підсумки журналів і нещодавні відредаговані рядки журналів.
- Найкращі можливі знімки статусу та стану працездатності Gateway.
stability/latest.json: найновіший збережений пакет стабільності, коли доступний.
Експорт корисний навіть тоді, коли Gateway несправний. Якщо Gateway не може відповідати на запити статусу або стану працездатності, локальні журнали, форма конфігурації та найновіший пакет стабільності все одно збираються, коли доступні.
Модель приватності
Діагностика розроблена так, щоб нею можна було ділитися. Експорт зберігає операційні дані, які допомагають у налагодженні, зокрема:
- назви підсистем, ідентифікатори Plugin, ідентифікатори провайдерів, ідентифікатори каналів і налаштовані режими
- коди статусу, тривалості, кількість байтів, стан черги та показники пам’яті
- очищені від чутливих даних метадані журналів і відредаговані операційні повідомлення
- форму конфігурації та несекретні налаштування функцій
Експорт пропускає або редагує:
- текст чату, підказки, інструкції, тіла Webhook і результати інструментів
- облікові дані, ключі API, токени, cookies і секретні значення
- сирі тіла запитів або відповідей
- ідентифікатори облікових записів, ідентифікатори повідомлень, сирі ідентифікатори сесій, імена хостів і локальні імена користувачів
Коли повідомлення журналу схоже на текст користувача, чату, підказки або корисного навантаження інструмента, експорт зберігає лише факт, що повідомлення було пропущено, і кількість байтів.
Записувач стабільності
Gateway за замовчуванням записує обмежений потік стабільності без корисного навантаження, коли діагностику ввімкнено. Він призначений для операційних фактів, а не для вмісту.
Той самий діагностичний Heartbeat записує зразки активності, коли Gateway продовжує працювати, але цикл подій Node.js або CPU виглядає перевантаженим. Ці події diagnostic.liveness.warning містять затримку циклу подій, використання циклу подій, співвідношення CPU-ядер, кількість активних/очікуваних/поставлених у чергу сесій, поточну фазу запуску/runtime, коли відома, нещодавні проміжки фаз і обмежені мітки активної/поставленої в чергу роботи. Зразки простою залишаються в телеметрії на рівні info. Зразки активності стають попередженнями Gateway лише тоді, коли робота очікує або перебуває в черзі, або коли активна робота збігається зі сталою затримкою циклу подій. Тимчасові піки максимальної затримки під час загалом здорової фонової роботи залишаються в журналах налагодження. Самі по собі вони не перезапускають Gateway.
Фази запуску також генерують події diagnostic.phase.completed з часом за настінним годинником і CPU. Діагностика застряглих вбудованих запусків позначає terminalProgressStale=true, коли останній прогрес bridge виглядав термінальним, наприклад сирий елемент відповіді або подія завершення відповіді, але Gateway усе ще вважає вбудований запуск активним.
Перевірте live recorder:
openclaw gateway stability
openclaw gateway stability --type payload.large
openclaw gateway stability --json
Перевірте найновіший збережений пакет стабільності після фатального завершення, тайм-ауту вимкнення або помилки запуску після перезапуску:
openclaw gateway stability --bundle latest
Створіть діагностичний zip-архів із найновішого збереженого пакета:
openclaw gateway stability --bundle latest --export
Збережені пакети розміщуються в ~/.openclaw/logs/stability/, коли події існують.
Корисні параметри
openclaw gateway diagnostics export \
--output openclaw-diagnostics.zip \
--log-lines 5000 \
--log-bytes 1000000
--output <path>: записати до конкретного шляху zip-архіву.--log-lines <count>: максимальна кількість очищених від чутливих даних рядків журналу для включення.--log-bytes <bytes>: максимальна кількість байтів журналу для перевірки.--url <url>: URL WebSocket Gateway для знімків статусу та стану працездатності.--token <token>: токен Gateway для знімків статусу та стану працездатності.--password <password>: пароль Gateway для знімків статусу та стану працездатності.--timeout <ms>: тайм-аут знімків статусу та стану працездатності.--no-stability-bundle: пропустити пошук збереженого пакета стабільності.--json: вивести машиночитані метадані експорту.
Вимкнення діагностики
Діагностику ввімкнено за замовчуванням. Щоб вимкнути записувач стабільності та збір діагностичних подій:
{
diagnostics: {
enabled: false,
},
}
Вимкнення діагностики зменшує деталізацію звітів про помилки. Це не впливає на звичайне журналювання Gateway.
Пов’язане
- Перевірки стану працездатності
- CLI Gateway
- Протокол Gateway
- Журналювання
- Експорт OpenTelemetry — окремий процес для потокової передачі діагностики до збирача