Перейти до основного вмісту
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. Використовуйте це, коли помилка сталася в реальній розмові й вам потрібен один звіт для підтримки, який можна скопіювати та вставити:
  1. Надішліть /diagnostics у розмові, де ви помітили проблему. Додайте коротку примітку, якщо це допоможе, наприклад /diagnostics bad tool choice.
  2. OpenClaw надсилає преамбулу діагностики й просить одне явне схвалення виконання exec. Схвалення запускає openclaw gateway diagnostics export --json. Не схвалюйте діагностику через правило дозволити все.
  3. Після схвалення OpenClaw відповідає звітом, який можна вставити, з локальним шляхом до пакета, підсумком маніфесту, примітками щодо приватності та відповідними ідентифікаторами сеансів.
У групових чатах власник усе ще може запустити /diagnostics, але OpenClaw не публікує діагностичні подробиці назад у спільний чат. Він надсилає преамбулу, запити на схвалення, результат експорту Gateway і розбивку сеансів/потоків Codex власнику через приватний маршрут схвалення. Група отримує лише коротке повідомлення про те, що діагностичний процес було надіслано приватно. Якщо OpenClaw не може знайти приватний маршрут до власника, команда завершується закрито й просить власника запустити її з DM. Коли активний сеанс OpenClaw використовує нативний harness OpenAI Codex, те саме схвалення exec також покриває завантаження відгуку OpenAI для потоків виконання Codex, про які знає OpenClaw. Це завантаження окреме від локального zip-архіву Gateway і з’являється лише для сеансів harness Codex. Перед схваленням запит пояснює, що схвалення діагностики також надішле відгук Codex, але він не перелічує ідентифікатори сеансів або потоків Codex. Після схвалення відповідь у чаті перелічує канали, ідентифікатори сеансів OpenClaw, ідентифікатори потоків Codex і локальні команди відновлення для потоків, які було надіслано на сервери OpenAI. Якщо ви відхилите або проігноруєте схвалення, OpenClaw не запускає експорт, не надсилає відгук Codex і не виводить ідентифікатори Codex. Це робить типовий цикл налагодження Codex коротким: помітьте неправильну поведінку в Telegram, Discord або іншому каналі, запустіть /diagnostics, схваліть один раз, поділіться звітом із підтримкою, а потім запустіть надруковану команду codex resume <thread-id> локально, якщо хочете самостійно переглянути нативний потік Codex. Див. harness Codex для цього робочого процесу перевірки.

​
Що містить експорт

Zip-архів містить:
  • summary.md: зручний для читання огляд для підтримки.
  • diagnostics.json: машиночитаний підсумок конфігурації, журналів, статусу, стану здоров’я і даних стабільності.
  • manifest.json: метадані експорту та список файлів.
  • Очищену форму конфігурації та несекретні деталі конфігурації.
  • Очищені підсумки журналів і нещодавні відредаговані рядки журналу.
  • Найкращі можливі знімки статусу та стану здоров’я Gateway.
  • stability/latest.json: найновіший збережений пакет стабільності, якщо доступний.
Експорт корисний навіть тоді, коли Gateway несправний. Якщо Gateway не може відповісти на запити статусу або стану здоров’я, локальні журнали, форма конфігурації та найновіший пакет стабільності все одно збираються, коли доступні.

​
Модель приватності

Діагностика спроєктована так, щоб нею можна було ділитися. Експорт зберігає операційні дані, які допомагають у налагодженні, наприклад:
  • назви підсистем, ідентифікатори plugin, ідентифікатори провайдерів, ідентифікатори каналів і налаштовані режими
  • коди статусу, тривалості, кількість байтів, стан черги та показники пам’яті
  • очищені метадані журналів і відредаговані операційні повідомлення
  • форму конфігурації та несекретні налаштування функцій
Експорт пропускає або редагує:
  • текст чату, prompts, інструкції, тіла webhook і виводи інструментів
  • облікові дані, ключі API, токени, cookies і секретні значення
  • сирі тіла запитів або відповідей
  • ідентифікатори облікових записів, ідентифікатори повідомлень, сирі ідентифікатори сеансів, імена хостів і локальні імена користувачів
Коли повідомлення журналу схоже на текст користувача, чату, промпта або корисного навантаження інструмента, експорт зберігає лише те, що повідомлення було пропущено, і кількість байтів.

​
Записувач стабільності

Gateway за замовчуванням записує обмежений потік стабільності без корисного навантаження, коли діагностику ввімкнено. Він призначений для операційних фактів, а не для вмісту. Той самий діагностичний Heartbeat записує зразки живучості, коли Gateway продовжує працювати, але цикл подій Node.js або CPU виглядає перевантаженим. Ці події diagnostic.liveness.warning містять затримку циклу подій, використання циклу подій, співвідношення ядер CPU, кількість активних/очікуваних/поставлених у чергу сеансів, поточну фазу запуску/виконання, коли вона відома, нещодавні проміжки фаз і обмежені мітки активної/поставленої в чергу роботи. Зразки простою залишаються в телеметрії на рівні info. Зразки живучості стають попередженнями Gateway лише тоді, коли робота очікує або поставлена в чергу, або коли активна робота перетинається зі сталою затримкою циклу подій. Тимчасові піки максимальної затримки під час інакше здорової фонової роботи залишаються в журналах налагодження. Вони самі по собі не перезапускають Gateway. Фази запуску також випромінюють події diagnostic.phase.completed із часом настінного годинника та CPU. Діагностика завислого вбудованого запуску позначає terminalProgressStale=true, коли останній прогрес bridge виглядав термінальним, наприклад сирий елемент відповіді або подія завершення відповіді, але Gateway все ще вважає вбудований запуск активним. Перегляньте живий записувач: 
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>: WebSocket URL Gateway для знімків стану та справності.
  • --token <token>: токен Gateway для знімків стану та справності.
  • --password <password>: пароль Gateway для знімків стану та справності.
  • --timeout <ms>: тайм-аут знімка стану та справності.
  • --no-stability-bundle: пропустити пошук збереженого пакета стабільності.
  • --json: вивести метадані експорту в машинозчитуваному форматі.

​
Вимкнення діагностики

Діагностику ввімкнено за замовчуванням. Щоб вимкнути записувач стабільності та збирання діагностичних подій: 
{
  diagnostics: {
    enabled: false,
  },
}
Вимкнення діагностики зменшує деталізацію звіту про помилку. Це не впливає на звичайне журналювання Gateway. Знімки критичного тиску памʼяті за замовчуванням вимкнені. Щоб зберегти події діагностики й також захоплювати знімок стабільності перед OOM: 
{
  diagnostics: {
    memoryPressureSnapshot: true,
  },
}
Використовуйте це лише на хостах, які можуть витримати додаткове сканування файлової системи та запис знімка під час критичного тиску памʼяті. Звичайні події тиску памʼяті все одно записують факти RSS, heap, порогу та зростання, коли знімок вимкнено.

​
Пов’язане