OpenClaw Runbook эксплуатации: проверки работоспособности Gateway 18789, поэтапные обновления & планирование дискового пространства (2026)

Эта статья отвечает на один вопрос

После того как скрипт установки OpenClaw завершился и Gateway 18789 впервые загорелся зелёным, команды нередко переходят в режим «работает — не трогай»: спорадические 401, один узел ведёт себя по-другому после обновления, или Gateway молча завершается из-за заполненного корневого диска. Всё это выходит за рамки руководства по установке.

Эта статья отвечает на один вопрос: как стандартизировать ежедневные операции OpenClaw в повторно используемый Runbook, которым любой член команды сможет воспользоваться для проверки работоспособности или отката за 15 минут? Охват: зонды работоспособности Gateway → стратегия поэтапного обновления → процедура отката → выбор Tailscale / SSH → планирование дискового пространства для логов.

1. Зонды работоспособности Gateway 18789

«Проверка работоспособности» во многих командах сводится к одному вызову curl — этого недостаточно. Если порт занят остаточным процессом или launchd не перезапустил сервис корректно, curl зависнет вместо немедленного отказа. Правильный зонд проверяет одновременно HTTP-ответ и владельца порта.

# 1. HTTP-liveness: ожидаем 200, при ошибке — предупреждение
curl -fsS --max-time 3 http://127.0.0.1:18789/health \
  && echo "gateway OK" || echo "GATEWAY FAIL"

# 2. Проверка владельца порта: PID должен принадлежать node/openclaw
lsof -nP -iTCP:18789 -sTCP:LISTEN

# 3. Последние строки ошибок (скорректировать путь под установку)
tail -n 50 ~/.openclaw/logs/gateway.log | grep -i "error\|warn\|exit"

Если curl возвращает 200, но Dashboard тормозит, сначала проверьте дисковый I/O: iostat -d 1 5. Путать пик записи логов со сбоем Gateway — самая частая ложная тревога. Держите выделенный «золотой узел» на той же версии, что и продакшн, чтобы сразу сравнивать при аномалиях.

2. Три шага перед каждым обновлением

OpenClaw регулярно выпускает обновления. Слепое следование каждой версии создаёт два риска: изменения ключей конфигурации препятствуют запуску Gateway, или новая версия несовместима с существующей конфигурацией каналов. Поэтапные обновления — стандартный подход, но многие команды понимают «поэтапно» как «сначала попробовать на одной машине», пропуская фиксацию версии и проверку дискового пространства.

# Записать текущую версию
npm list -g openclaw --depth=0 > .upgrade-memo

# Архивировать конфигурацию
tar czf openclaw-config-$(date +%Y%m%d).tar.gz \
  ~/.openclaw/config/ \
  ~/Library/LaunchAgents/com.openclaw.gateway.plist

# Проверить свободное место ≥ 15 %
df -h / | awk 'NR==2 {print "Свободно:"$4, "Использовано:"$5}'

3. Откат: двухэтапное восстановление tarball + plist

Самая частая причина неудачного отката — не версия бинарного файла, а несовместимость ключей конфигурации. Новая версия могла добавить обязательные поля; откат бинарного файла при оставшейся новой конфигурации вызовет ошибку запуска Gateway. Правильный порядок: bootout → восстановить tarball → откатить бинарный файл → bootstrap.

# Шаг 1: остановить сервис
launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/com.openclaw.gateway.plist

# Шаг 2: восстановить tarball конфигурации
tar xzf openclaw-config-20260604.tar.gz -C /

# Шаг 3: откатить npm-пакет
npm install -g openclaw@1.x.x   # заменить на зафиксированный тег версии

# Шаг 4: перезапустить сервис
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.openclaw.gateway.plist

# Шаг 5: проверка (~10 с на запуск)
sleep 10 && curl -fsS http://127.0.0.1:18789/health && echo "Откат OK"

Следите за смещением пути plist: если установщик новой версии перезаписал ProgramArguments, bootout нужно выполнить с новым путём plist, а bootstrap — с восстановленным старым. Эти пути могут различаться — именно поэтому diff старого и нового plist перед обновлением должен входить в Runbook.

4. Tailscale против SSH/rsync: что когда использовать

Вечный командный спор «Tailscale или прямой SSH?» — ложная дилемма. Каждый инструмент оптимален в своём сценарии. Tailscale незаменим для многоустройственного и межрегионального постоянного доступа без правил брандмауэра. SSH/rsync — правильный выбор для массовых передач, где узким местом является исходящая полоса пропускания, а не накладные расходы протокола.

# Получить архивы логов с канадского узла, лимит 50 МБ/с, возобновление
rsync -avz --bwlimit=50000 --partial \
  user@canada-m4.hashvps.com:~/.openclaw/logs/archive/ \
  ./local-logs/

# Убедиться, что Tailscale использует прямое соединение (не DERP-ретранслятор)
tailscale ping canada-m4 --until-direct

5. Планирование дискового пространства: конфигурация logrotate и советы по разделам

Удивительно большая доля неожиданных завершений Gateway объясняется переполненным корневым диском. По умолчанию OpenClaw пишет логи в домашнюю директорию пользователя — тот же том, что и глобальный npm-кэш. Добавьте экспорты Xcode или временные файлы CI, и 512 ГБ диск может молча заполниться за несколько недель. Правильное решение — logrotate, а не периодический rm.

/Users/mac/.openclaw/logs/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    dateext
    copytruncate
}

# Добавить в crontab (ежедневно в 03:00):
# crontab -e, затем добавить:
# 0 3 * * * /usr/local/bin/logrotate /Users/mac/.openclaw/logrotate.conf

Для npm-кэша: npm config set cache-max 10240 ограничивает его 10 ГБ; после каждого обновления выполняйте npm cache clean --force. На узле 1 ТБ рекомендуется перенести ~/.openclaw/logs и npm-кэш на отдельный том — при резком росте логов это не повлияет ни на корневой диск, ни на процесс Gateway.

6. FAQ: шесть частых вопросов об эксплуатации

Проверка работоспособности Gateway 18789 возвращает не 200 — где смотреть в первую очередь?

Выполните lsof -nP -iTCP:18789 -sTCP:LISTEN, чтобы проверить, слушает ли что-то порт. Нет вывода — процесс не запущен: проверьте launchd через launchctl list | grep openclaw, затем последние 50 строк ~/.openclaw/logs/gateway.log. Порт слушает, но HTTP возвращает 500 — вероятно, ошибка ключа конфигурации: сравните с tarball до обновления.

После отката нужно ли вручную исправлять путь plist?

Только если установщик новой версии изменил ProgramArguments. При чистом обновлении npm-пакета без изменений установщика восстановление tarball оставит plist нетронутым. Если путь к бинарному файлу изменился, перед bootstrap обновите ProgramArguments в plist, указав старый путь к бинарному файлу — именно поэтому diff старого и нового plist перед обновлением входит в Runbook.

Обновлять несколько узлов одновременно или по одному?

Всегда по одному. Сначала обновить «золотой узел»; наблюдать за работоспособностью Gateway и SLA каналов в течение 24 часов. Затем развёртывать продакшн-узлы с интервалом не менее 30 минут. Одновременное обновление означает: при возникновении проблемы нет эталона для сравнения, и все узлы падают вместе.

Dashboard показывает 100 % CPU — это баг OpenClaw?

Не обязательно. Используйте top -o cpu или Activity Monitor, чтобы найти реально потребляющий PID. Здоровый процесс Gateway OpenClaw в штатном режиме должен потреблять 1–5 % CPU. Если пикирует процесс node, проверьте накопленные запросы каналов или аномальную запись логов. На выделенном Mac mini используйте renice, чтобы снизить приоритет процессов сборки Xcode и устранить конкуренцию с OpenClaw.

Tailscale подключён, но Dashboard недоступен — почему?

Проверьте в политике ACL Tailscale, что порт 18789 разрешён для данного устройства. Затем получите tailnet IP через tailscale ip -4 и протестируйте напрямую: curl http://<tailnet-ip>:18789/health. Если IP работает, а имя хоста MagicDNS нет — это проблема разрешения DNS, а не проблема Gateway.

После выполнения logrotate Gateway продолжает писать в правильный файл?

При использовании copytruncate logrotate копирует файл и усекает оригинал на месте — файловый дескриптор Gateway остаётся действительным. При стандартном режиме create нужно отправить Gateway сигнал SIGHUP или выполнить launchctl kickstart через скрипт postrotate, чтобы переоткрыть дескриптор лога. copytruncate проще и не прерывает сервис.