Мониторинг

Раздел описывает контроль доступности и состояния Energoskan Development Portal: веб-панели, системных служб, Docker-контейнеров, ресурсов сервера, дискового пространства, журналов и AI-интеграций.

Цели мониторинга

• обнаруживать недоступность портала;
• выявлять остановленные и аварийные службы;
• контролировать загрузку процессора и памяти;
• предотвращать переполнение диска;
• проверять состояние пользовательских контейнеров;
• отслеживать ошибки AI-шлюза и внешних провайдеров;
• сохранять данные для диагностики инцидентов.

Быстрая проверка портала

curl -I http://127.0.0.1:3020/
curl -I https://energoskandev.ru/
curl -s http://127.0.0.1:3020/api/version

Ожидаемый результат:

• локальная панель отвечает без ошибки соединения;
• внешний HTTPS-адрес возвращает успешный HTTP-статус;
• /api/version возвращает корректный JSON;
• версия соответствует текущей ветке разработки.

Проверка системных служб

systemctl status vibe-panel.service
systemctl status anthropic-shim.service
systemctl status nginx.service
systemctl status docker.service
systemctl status privoxy.service
systemctl --failed

Службы панели, Nginx и Docker должны находиться в состоянии active (running).

Журналы панели

journalctl -u vibe-panel.service -n 100 --no-pager
journalctl -u vibe-panel.service -f

Следует проверять:

• ошибки запуска Node.js;
• конфликты портов;
• не найденные файлы;
• ошибки чтения пользовательских данных;
• необработанные исключения;
• повторяющиеся перезапуски службы.

Журналы AI-шлюза

journalctl -u anthropic-shim.service -n 100 --no-pager
journalctl -u anthropic-shim.service -f

Основные типы ошибок:

• 401 — недействительный токен или ошибка авторизации;
• 404 — неправильный маршрут, модель или провайдер;
• 429 — превышение лимита запросов;
• 502 — ошибка шлюза или внешнего провайдера;
• тайм-аут соединения;
• ошибка прокси;
• недоступность внешнего API.

Проверка Nginx

nginx -t
systemctl status nginx.service
journalctl -u nginx.service -n 100 --no-pager
tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/nginx/access.log

Перед перезапуском Nginx обязательно выполнять проверку конфигурации командой nginx -t.

Мониторинг ресурсов сервера

uptime
free -h
df -h
lsblk
top
ps aux --sort=-%mem | head
ps aux --sort=-%cpu | head

Следует контролировать:

• среднюю нагрузку;
• свободную оперативную память;
• использование swap;
• заполнение системного диска;
• процессы с высокой загрузкой CPU;
• процессы с высоким потреблением памяти.

Дисковое пространство

df -h
du -sh /opt/dev-portal
du -sh /data/vibe-students
du -sh /data/config
du -sh /opt/backups
du -xh /var/log | sort -h | tail

Особое внимание необходимо уделять пользовательским проектам, резервным копиям, Docker-образам и системным журналам.

Мониторинг Docker

docker ps
docker ps -a
docker stats --no-stream
docker system df
docker images

Для отдельного контейнера:

docker inspect vibe-admin
docker logs --tail 100 vibe-admin
docker top vibe-admin

Проверяется:

• состояние контейнера;
• время последнего запуска;
• причина остановки;
• использование памяти и процессора;
• проброс портов;
• подключённые каталоги;
• ошибки code-server и пользовательских приложений.

Проверка портов

ss -lntp
docker ps --format 'table {{.Names}}\t{{.Ports}}'

Основные точки контроля:

• 80 и 443 — Nginx;
• 127.0.0.1:3020 — панель;
• 8190 — AI-шлюз при текущей конфигурации;
• 8118 — Privoxy;
• порты пользовательских контейнеров.

Проверка пользовательского рабочего пространства

docker exec vibe-admin sh -c 'pwd'
docker exec vibe-admin sh -c 'ls -la /home/student/workspace'
docker exec vibe-admin sh -c 'ps aux'
docker logs --tail 100 vibe-admin

Проверка выполняется отдельно для каждого пользователя, если поступила жалоба на VS Code, Claude Code или запуск проекта.

Контроль версии портала

curl -s http://127.0.0.1:3020/api/version
cat /opt/dev-portal/VERSION
git -C /opt/dev-portal branch --show-current
git -C /opt/dev-portal status --short

Версия на портале, файл VERSION и активная ветка не должны противоречить друг другу.

Ежедневная проверка

1. Проверить внешний адрес портала.
2. Проверить /api/version.
3. Проверить аварийные systemd-службы.
4. Проверить свободное место на диске.
5. Проверить состояние Docker-контейнеров.
6. Просмотреть последние ошибки панели и AI-шлюза.

Еженедельная проверка

1. Проверить размер пользовательских проектов.
2. Проверить размер резервных копий.
3. Проверить использование Docker-диска.
4. Проверить срок действия HTTPS-сертификата.
5. Проверить повторяющиеся ошибки в журналах.
6. Проверить возможность восстановления резервной копии.

Порядок реакции на ошибку

1. Зафиксировать время и симптомы ошибки.
2. Определить затронутый компонент.
3. Проверить состояние соответствующей службы.
4. Изучить последние журналы.
5. Проверить ресурсы сервера и свободное место.
6. Создать резервную копию перед изменением.
7. Внести одно контролируемое исправление.
8. Проверить локальный и внешний адреса.
9. Зафиксировать причину и решение в документации.

Правила администратора

1. Не перезапускать все службы без определения причины ошибки.
2. Не удалять журналы до завершения диагностики.
3. Не очищать Docker без проверки используемых данных.
4. Не игнорировать повторяющиеся ошибки.
5. Не вносить несколько изменений одновременно.
6. После исправления обязательно повторять проверку.