CLI commands

Журналы

`openclaw logs`

Просматривает в реальном времени файловые журналы Gateway через RPC. Работает в удалённом режиме.

Параметры

--limit <n>: максимальное количество возвращаемых строк журнала (по умолчанию 200)
--max-bytes <n>: максимальное количество байтов, считываемых из файла журнала (по умолчанию 250000)
--follow: отслеживать поток журнала
--interval <ms>: интервал опроса при отслеживании (по умолчанию 1000)
--json: выводить события JSON, разделённые строками
--plain: выводить простой текст без стилизованного форматирования
--no-color: отключить цвета ANSI
--local-time: отображать метки времени в вашем локальном часовом поясе (по умолчанию)
--utc: отображать метки времени в UTC

Общие параметры RPC Gateway

--url <url>: URL WebSocket Gateway
--token <token>: токен Gateway
--timeout <ms>: время ожидания в мс (по умолчанию 30000)
--expect-final: ожидать окончательного ответа, когда вызов Gateway обслуживается агентом

Передача --url отключает автоматическое применение учётных данных из конфигурации; явно укажите --token, если целевой Gateway требует аутентификации.

Примеры

bash

openclaw logsopenclaw logs --followopenclaw logs --follow --interval 2000openclaw logs --limit 500 --max-bytes 500000openclaw logs --jsonopenclaw logs --plainopenclaw logs --no-coloropenclaw logs --utcopenclaw logs --follow --local-timeopenclaw logs --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"

Резервное поведение и восстановление

Если неявно используемый локальный Gateway с адресом обратной связи запрашивает сопряжение, закрывает соединение во время подключения или время ожидания истекает до ответа logs.tail, команда openclaw logs автоматически переключается на настроенный файловый журнал Gateway. Для явно заданных целей --url это резервное поведение никогда не применяется.
--follow не переключается на этот настроенный файл после сбоя RPC неявно используемого локального Gateway — устаревший параллельно существующий файл может создать ложное представление при просмотре журнала в реальном времени. В Linux вместо этого используется журнал активного пользовательского сервиса Gateway в systemd по PID, если он доступен (выбранный источник выводится на экран); в противном случае попытки подключения к работающему Gateway продолжаются.
Во время --follow временные разрывы соединения (закрытие WebSocket, истечение времени ожидания, потеря подключения) запускают автоматическое повторное подключение с экспоненциальной задержкой: до 8 попыток с интервалом не более 30 с. При каждой повторной попытке в stderr выводится предупреждение, а после успешного опроса один раз выводится уведомление [logs] gateway reconnected. В режиме --json оба сообщения выводятся в stderr как записи {"type":"notice"}. При неисправимых ошибках (сбой аутентификации, неверная конфигурация) процесс по-прежнему завершается немедленно.
В режиме --follow --json переходы между источниками журналов выводятся как записи {"type":"meta"}. Отслеживайте курсоры отдельно для каждого sourceKind: поток может переключаться с вывода файла журнала Gateway (sourceKind: "file") на резервный локальный журнал (sourceKind: "journal", localFallback: true, с service.pid/service.unit), а после восстановления — обратно на вывод файла журнала Gateway. Не полагайтесь на один неизменный источник или курсор в течение всего сеанса и допускайте повторяющиеся строки, когда при восстановлении повторно воспроизводятся данные с позиции курсора файла Gateway.

См. также

Was this useful?