NetBird daemon на Server1C (Windows) регулярно flap-ает — известная проблема. Watchdog v2 решает по level только по ping public + RDP 3389. NetBird-уровень логируется в state.json для информации, но не порождает алерты. Параллельно: primary model openclaw переключен с Opus 4.7 (Max-биллинг закончился) на Sonnet 4.5 free (Kiro), Opus оставлен в fallbacks. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6.4 KiB
date, type, tags
| date | type | tags | ||||||
|---|---|---|---|---|---|---|---|---|
| 2026-05-14 | decision |
|
2026-05-14: Watchdog Бужарово — только публичный канал, NetBird вынесен из alert level
Контекст
Олег в Египте, прислал что бот "сыпал ошибками вчера, попросил отключить мониторинг". Разведка:
- Все сервисы на LXC 139 живы (
openclaw-gateway,buzharovo-watchdog.timer,netbird-watchdog.timer,netbird.service—active+enabled). Олег ничего не отключал. - Watchdog v1 правильно держал
WARNING_NETBIRD(последний алерт 13 мая ~19:32 МСК), антиспам корректный — повторных алертов не слал. - Истинный источник "ошибок" —
openclaw primary model = omniroute/cc/claude-opus-4-7упёрся в лимит Max-подписки:Каждое сообщение в боте + каждое ночноеomniroute (cc/claude-opus-4-7) returned a billing error — your API key has run out of credits 400 [400]: You're out of extra usage. Add more at claude.ai/settings/usage and keep going.memory-core dreaming(cron 03:00) → billing 400 → failover наkr/claude-sonnet-4.5. На клиенте часть запросов могла отдаться с ошибкой раньше чем failover отработал. - Server1C NetBird daemon (Windows) регулярно flap'ает,
last_seen=2026-05-13T08:24:26— > 25 часов вне mesh, хотя сервер сам публично жив (ping + RDP 3389 OK).
Решения
Фикс 1: primary model → free Sonnet 4.5
/root/.openclaw/openclaw.json:
{
"primary": "omniroute/kr/claude-sonnet-4.5",
"fallbacks": [
"omniroute/cc/claude-sonnet-4-6",
"omniroute/gh/claude-sonnet-4.5",
"omniroute/cc/claude-opus-4-7"
]
}
Hot-reload подхватился. Backup конфига — /root/.openclaw/openclaw.json.bak.opus-billing-<ts>.
Возврат на Opus как primary — только после пополнения Max или подключения второго конектора в OmniRoute.
Фикс 2: watchdog v2 — только публичный канал
Переписан /usr/local/bin/buzharovo-watchdog.sh. Логика alert-level больше не учитывает NetBird-проверки:
OK—ping 185.13.47.2✓ +TCP 3389(RDP) ✓DEGRADED— один из публичных упалCRITICAL— оба публичных упали
NetBird-уровень (ping 100.70.75.103 + TCP 5985) только логируется в state.json (ping_nb, winrm_nb), но не меняет level и не порождает алерт.
При первом алерте в новую сессию (prev_level=INIT) добавляется пометка:
NetBird до сервера сейчас лежит — это известная регулярная проблема со стороны Windows-сервера, не влияет на работу 1С для пользователей. Watchdog проверяет только публичный канал.
Почему так: NetBird daemon на Server1C (Windows 2012 R2) теряет mesh-сессию регулярно (memory feedback_netbird_watchdog). Лечится Restart-Service netbird через RDP — но это ручная операция, и поток алертов из-за этого был шумом, а не сигналом. Сервер для пользователей в Бужарово при этом работает — 1С локально доступна.
Что теряем: WinRM-actions (check_1c_service.py, check_rmngr_cpu.py, restart_1c_agent.py, sql_native_backup.py) идут через NetBird (100.70.75.103:5985). Когда NetBird падает — эти actions недоступны. Бот в группе об этом честно скажет: "Не могу проверить состояние службы 1С — туннель до сервера временно лежит". Восстанавливается после Restart-Service netbird на server1c через RDP.
Что НЕ теряем: алерты о реально критичных событиях (сервер физически лёг публично, сеть провайдера упала, RDP закрылся).
Деплой
pct push 139 wd.sh /usr/local/bin/buzharovo-watchdog.sh
chmod +x /usr/local/bin/buzharovo-watchdog.sh
chown root:root /usr/local/bin/buzharovo-watchdog.sh
echo "{}" > /var/lib/severny-les/state.json # force re-evaluate
# Manual run → level=OK, alert "Мониторинг включён" ушёл в группу
Обновления в vault и persona
/root/clawd/MEMORY.mdна LXC 139 — добавлены уроки про Opus billing + watchdog v2- projects/buzharovo/severny-les-bot — обновить ссылку на watchdog v2 (TODO)
- Этот decision-файл
NetBird route 10.0.0.0/24 — попутно
Существующий route Dom (cud7q73l0ubs73dr3gc0) advertised через peer pve 100.70.121.235 (Эстония), disconnected. Переключил routing peer на openclaw (d79s9g2fadhs739mihkg) через PUT /api/routes/cud7q73l0ubs73dr3gc0. Mac получил доступ к 10.0.0.0/24 через NetBird → openclaw → LAN.
TODO (опционально, не сейчас)
- Reverse SSH-туннель server1c → severny-les для WinRM-actions без зависимости от NetBird. Server1C сам делает outbound SSH → LXC 139 пробрасывает 127.0.0.1:55985 → server1c:5985. WinRM-скрипты целятся в
localhost:55985. Решает проблему "NetBird лёг — WinRM недоступен". - HTTPS WinRM (5986) публично с certificate-pin'ом — альтернатива через интернет, но требует настройки SSL и хорошего firewall.
- Ночной cron sql_native_backup.py — автоматизация ежедневных бэкапов БД (TODO от 2026-05-08, см. соответствующий decision).