Gateway

Перевірки працездатності

Короткий посібник із перевірки підключення каналів без припущень.

Швидкі перевірки

openclaw status — локальне зведення: доступність/режим Gateway, підказка щодо оновлення, вік автентифікації підключеного каналу, сеанси й нещодавня активність.
openclaw status --all — повна локальна діагностика (лише читання, кольоровий вивід, безпечно вставляти для налагодження).
openclaw status --deep — запитує запущений Gateway для виконання оперативної перевірки (health з probe:true), зокрема перевірок каналів для кожного облікового запису, якщо вони підтримуються.
openclaw status --usage — показує знімки використання/квоти постачальника моделей.
openclaw health — запитує знімок стану справності запущеного Gateway (лише через WS; без прямих сокетів каналів із CLI).
openclaw health --verbose (псевдонім --debug) — примусово виконує оперативну перевірку справності та виводить відомості про підключення до Gateway.
openclaw health --json — машиночитаний вивід знімка стану справності.
Надішліть /status як окрему команду чату в будь-якому каналі, щоб отримати відповідь зі станом без виклику агента.
Журнали: відстежуйте /tmp/openclaw/openclaw-*.log і фільтруйте за web-heartbeat, web-reconnect, web-auto-reply, web-inbound.

Для Discord та інших постачальників чатів рядки сеансів не відображають активність сокета. openclaw sessions, Gateway sessions.list та інструмент агента sessions_list читають збережений стан розмови. Постачальник може повторно підключитися та показати справний стан каналу ще до появи нового рядка сеансу. Для оперативної перевірки підключення використовуйте наведені вище команди стану та справності каналів.

Поглиблена діагностика

Облікові дані на диску: ls -l ~/.openclaw/credentials/whatsapp/<accountId>/creds.json (час зміни має бути нещодавнім).
Сховище сеансів: ls -l ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite. Кількість і нещодавні одержувачі відображаються через status.
Процедура повторного підключення: openclaw channels logout && openclaw channels login --verbose, коли в журналах з’являються коди стану 409-515 або loggedOut. Після сполучення процедура входу за QR-кодом автоматично перезапускається один раз для стану 515.
Діагностику ввімкнено за замовчуванням (diagnostics.enabled: false вимикає її). Події пам’яті записують кількість байтів RSS/купи та тиск порогових значень/зростання; критичний тиск пам’яті реєструється через журнал Gateway і, коли встановлено diagnostics.memoryPressureSnapshot: true, також записує пакет стабільності перед OOM (статистику купи V8, лічильники cgroup Linux за наявності, кількість активних ресурсів, найбільші файли сеансів/транскриптів за відредагованим відносним шляхом). Попередження про працездатність записують затримку/використання циклу подій, співвідношення використання ядер ЦП і кількість активних/очікуваних/поставлених у чергу сеансів, коли процес працює, але перевантажений. Події завеликого корисного навантаження записують, що було відхилено/обрізано/розбито на частини, а також розміри й обмеження, але ніколи не записують текст повідомлень, вміст вкладень, тіла webhook, необроблені тіла запитів/відповідей, токени, файли cookie чи секретні значення.
Той самий Heartbeat керує обмеженим засобом запису стабільності: openclaw gateway stability (або RPC Gateway diagnostics.stability). Фатальні завершення Gateway, перевищення часу очікування під час завершення роботи, збої запуску після перезапуску та (коли diagnostics.memoryPressureSnapshot: true) критичний тиск пам’яті зберігають останній знімок у ~/.openclaw/logs/stability/. Перегляньте найновіший пакет за допомогою openclaw gateway stability --bundle latest.
Для звітів про помилки виконайте openclaw gateway diagnostics export і прикріпіть створений ZIP-файл: зведення Markdown, найновіший пакет стабільності, очищені метадані журналів, очищені знімки стану/справності Gateway і структуру конфігурації. Текст чату, тіла webhook, вивід інструментів, облікові дані, файли cookie, ідентифікатори облікових записів/повідомлень і секретні значення вилучаються або редагуються. Див. Експорт діагностики.

Конфігурація монітора справності

gateway.channelHealthCheckMinutes: як часто Gateway перевіряє справність каналів. Типове значення: 5. Установіть 0, щоб глобально вимкнути перезапуски монітора справності.
gateway.channelStaleEventThresholdMinutes: як довго підключений канал може залишатися неактивним, перш ніж монітор справності вважатиме його застарілим і перезапустить. Типове значення: 30. Це значення має бути більшим або дорівнювати gateway.channelHealthCheckMinutes.
gateway.channelMaxRestartsPerHour: ковзне обмеження кількості перезапусків монітора справності за одну годину для кожного каналу/облікового запису. Типове значення: 10.
channels.<provider>.healthMonitor.enabled: вимикає перезапуски монітора справності для певного каналу, залишаючи глобальний моніторинг увімкненим.
channels.<provider>.accounts.<accountId>.healthMonitor.enabled: перевизначення для кількох облікових записів, яке має перевагу над налаштуванням рівня каналу.
Ці перевизначення для окремих каналів застосовуються до вбудованих каналів, які наразі їх надають: Discord, Google Chat, iMessage, IRC, Microsoft Teams, Signal, Slack, Telegram і WhatsApp.

Моніторинг часу безперервної роботи

Зовнішні служби моніторингу часу безперервної роботи мають використовувати спеціальну кінцеву точку /health, а не /v1/chat/completions.

ВИКОРИСТОВУЙТЕ: GET /health — миттєва відповідь, сеанс не створюється, LLM не викликається, повертає {"ok":true,"status":"live"}
НЕ ВИКОРИСТОВУЙТЕ: /v1/chat/completions для перевірок справності — кожен запит створює повний сеанс агента зі знімком Skills, формуванням контексту та викликами LLM

Якщо не надано заголовок x-openclaw-session-key або поле user, /v1/chat/completions створює новий випадковий сеанс для кожного запиту. Служби моніторингу, які надсилають запит кожні 15 хвилин, створюють приблизно 96 сеансів на день, кожен із яких займає 4-22KB. З часом це спричиняє розростання сховища сеансів і може призвести до переповнення контекстного вікна.

Приклади налаштування служб моніторингу

BetterStack: установіть URL-адресу перевірки справності на https://<your-gateway-host>:<port>/health
UptimeRobot: додайте новий монітор HTTP з URL-адресою https://<your-gateway-host>:<port>/health
Загальний варіант: будь-який HTTP GET-запит до /health повертає 200 з {"ok":true}, коли Gateway справний

Якщо щось не працює

logged out або стан 409-515 → повторно підключіть за допомогою openclaw channels logout, а потім openclaw channels login.
Gateway недоступний → запустіть його: openclaw gateway --port 18789 (використовуйте --force, якщо порт зайнятий).
Немає вхідних повідомлень → переконайтеся, що підключений телефон у мережі, а відправник дозволений (channels.whatsapp.allowFrom); для групових чатів переконайтеся, що список дозволених користувачів і правила згадок узгоджені (channels.whatsapp.groups, agents.list[].groupChat.mentionPatterns).

Спеціальна команда «health»

openclaw health запитує знімок стану справності запущеного Gateway (без прямих сокетів каналів із CLI). За замовчуванням вона повертає свіжий кешований знімок Gateway, а Gateway оновлює цей кеш у фоновому режимі; --verbose натомість примусово виконує оперативну перевірку. Команда повідомляє вік підключених облікових даних/автентифікації, якщо він доступний, зведення перевірок для кожного каналу, зведення сховища сеансів і тривалість перевірки. Вона завершується з ненульовим кодом, якщо Gateway недоступний або перевірка завершується помилкою чи перевищує час очікування.

Параметри:

--json: машиночитаний вивід JSON
--timeout <ms>: перевизначає типовий 10-секундний час очікування перевірки
--verbose: примусово виконує оперативну перевірку та виводить відомості про підключення до Gateway
--debug: псевдонім для --verbose

Знімок стану справності містить: ok (логічне значення), ts (мітка часу), durationMs (час перевірки), стан кожного каналу, доступність агента та зведення сховища сеансів.

Пов’язані матеріали

Was this useful?