Gateway

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

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

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

openclaw status — локальний підсумок: доступність/режим Gateway, підказка щодо оновлення, вік авторизації пов’язаного каналу, сеанси + нещодавня активність.
openclaw status --all — повна локальна діагностика (лише читання, з кольорами, безпечно вставляти для налагодження).
openclaw status --deep — запитує в запущеного Gateway живу перевірку справності (health з probe:true), зокрема поканальні перевірки для кожного облікового запису, якщо підтримується.
openclaw health — запитує в запущеного Gateway його знімок справності (лише WS; без прямих сокетів каналів із CLI).
openclaw health --verbose — примусово запускає живу перевірку справності й друкує деталі підключення Gateway.
openclaw health --json — машинозчитуваний вивід знімка справності.
Надішліть /status як окреме повідомлення в WhatsApp/WebChat, щоб отримати відповідь зі статусом без виклику агента.
Журнали: переглядайте хвіст /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 (mtime має бути нещодавнім).
Сховище сеансів: ls -l ~/.openclaw/agents/<agentId>/sessions/sessions.json (шлях можна перевизначити в конфігурації). Кількість і нещодавні отримувачі відображаються через status.
Потік повторного прив’язування: openclaw channels logout && openclaw channels login --verbose, коли в журналах з’являються коди стану 409–515 або loggedOut. (Примітка: потік входу через QR автоматично перезапускається один раз для стану 515 після спарювання.)
Діагностику ввімкнено за замовчуванням. Gateway записує операційні факти, якщо не встановлено diagnostics.enabled: false. Події пам’яті записують кількість байтів RSS/heap, пороговий тиск і тиск зростання. Критичний тиск пам’яті журналюється через журналер Gateway. Коли встановлено diagnostics.memoryPressureSnapshot: true, критичний тиск пам’яті також записує стабілізаційний пакет перед OOM зі статистикою heap V8, лічильниками Linux cgroup, якщо доступні, кількістю активних ресурсів і найбільшими файлами сеансів/транскриптів за редагованим відносним шляхом. Попередження живості записують затримку циклу подій, використання циклу подій, співвідношення CPU-core і кількість активних/очікувальних/поставлених у чергу сеансів, коли процес працює, але насичений. Події завеликих payload записують, що було відхилено, обрізано або поділено на частини, а також розміри й обмеження, якщо доступні. Вони не записують текст повідомлення, вміст вкладень, тіло Webhook, сире тіло запиту чи відповіді, токени, cookies або секретні значення. Той самий Heartbeat запускає обмежений записувач стабільності, доступний через openclaw gateway stability або Gateway RPC diagnostics.stability. Фатальні виходи Gateway, тайм-аути завершення роботи та збої запуску після перезапуску зберігають останній знімок записувача в ~/.openclaw/logs/stability/, якщо події існують; критичний тиск пам’яті робить це також лише коли встановлено diagnostics.memoryPressureSnapshot: true. Перегляньте найновіший збережений пакет за допомогою openclaw gateway stability --bundle latest.
Для звітів про помилки запустіть openclaw gateway diagnostics export і прикріпіть згенерований zip. Експорт поєднує Markdown-підсумок, найновіший стабілізаційний пакет, очищені метадані журналів, очищені знімки стану/справності Gateway і форму конфігурації. Він призначений для спільного використання: текст чату, тіла Webhook, виводи інструментів, облікові дані, cookies, ідентифікатори облікових записів/повідомлень і секретні значення пропускаються або редагуються. Див. Експорт діагностики.

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

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, Microsoft Teams, Signal, Slack, Telegram і WhatsApp.

Моніторинг безвідмовної роботи

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

ВИКОРИСТОВУЙТЕ: GET /health — миттєва відповідь, сеанс не створюється, LLM-виклик не виконується, повертає {"ok":true,"status":"live"}
НЕ ВИКОРИСТОВУЙТЕ: /v1/chat/completions для перевірок справності — кожен запит створює повний сеанс агента зі знімком skill, складанням контексту та 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); для групових чатів переконайтеся, що allowlist + правила згадок збігаються (channels.whatsapp.groups, agents.list[].groupChat.mentionPatterns).

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

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

Параметри:

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

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

Пов’язане

Was this useful?