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, критическое давление памяти также записывает pre-OOM stability bundle со статистикой V8 heap, счетчиками Linux cgroup при наличии, количеством активных ресурсов и крупнейшими файлами сеансов/транскриптов по отредактированному относительному пути. Предупреждения живости записывают задержку event loop, утилизацию event loop, отношение CPU-core и количество активных/ожидающих/поставленных в очередь сеансов, когда процесс работает, но перегружен. События слишком крупных payload записывают, что было отклонено, усечено или разбито на части, а также размеры и лимиты при наличии. Они не записывают текст сообщения, содержимое вложений, тело вебхука, исходное тело запроса или ответа, токены, cookies или секретные значения. Тот же Heartbeat запускает ограниченный stability recorder, доступный через openclaw gateway stability или Gateway RPC diagnostics.stability. Фатальные выходы Gateway, таймауты завершения работы и сбои запуска при перезапуске сохраняют последний снимок recorder в ~/.openclaw/logs/stability/, когда события существуют; критическое давление памяти делает это тоже только при заданном diagnostics.memoryPressureSnapshot: true. Просмотрите самый новый сохраненный bundle с помощью openclaw gateway stability --bundle latest.
  • Для отчетов об ошибках выполните openclaw gateway diagnostics export и приложите созданный zip. Экспорт объединяет сводку Markdown, самый новый stability bundle, очищенные метаданные логов, очищенные снимки статуса/работоспособности Gateway и форму конфигурации. Он предназначен для передачи: текст чатов, тела вебхуков, выводы инструментов, учетные данные, 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.

Мониторинг uptime

Внешние сервисы мониторинга uptime должны использовать выделенный endpoint /health, а не /v1/chat/completions.

  • ИСПОЛЬЗУЙТЕ: GET /health — мгновенный ответ, сеанс не создается, вызов LLM не выполняется, возвращает {"ok":true,"status":"live"}
  • НЕ ИСПОЛЬЗУЙТЕ: /v1/chat/completions для проверок работоспособности — каждый запрос создает полноценный сеанс агента со снимком Skills, сборкой контекста и вызовами LLM

Когда заголовок x-openclaw-session-key или поле user не предоставлены, /v1/chat/completions создает новый случайный сеанс для каждого запроса. Сервисы мониторинга, которые отправляют ping каждые 15 минут, создают примерно 96 сеансов в день, каждый из которых потребляет 4–22 КБ. Со временем это раздувает хранилище сеансов и может привести к переполнению окна контекста.

Примеры настройки сервисов мониторинга

  • 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>: переопределяет стандартный таймаут проверки 10 с
  • --verbose: принудительно запускает оперативную проверку и выводит сведения о подключении к Gateway
  • --debug: псевдоним для --verbose

Снимок работоспособности включает: ok (boolean), ts (timestamp), durationMs (время проверки), статус по каналам, доступность агента и сводку хранилища сеансов.

Связанные материалы

Was this useful?
On this page

On this page