Files
rf4-spotter/docs/production-monitoring.md
T

51 lines
4.5 KiB
Markdown

# Мониторинг открытой альфы
`deploy/monitor.sh` — host-side проверка production-контура. Она не изменяет данные и не печатает секреты. Успех возвращает exit code `0` и одну строку `OK`; любая проблема возвращает `1`/`2` и строку `CRITICAL`.
Проверяются:
- контейнеры `proxy`, `db`, `minio`, `api`, `web` находятся в running;
- публичный `https://rf4spotter.ru/ready` сообщает `ready`;
- файловая система проекта заполнена менее чем на 85%;
- база PostgreSQL занимает менее 2 ГБ, а данные MinIO — менее 10 ГБ;
- последняя полная резервная копия не старше 26 часов и проходит проверку `SHA256SUMS`;
- TLS-сертификат домена действует ещё минимум 14 дней.
Пороги задаются в `.env.production`: `BACKUP_ROOT`, `MONITOR_DISK_MAX_PERCENT`, `MONITOR_DB_MAX_MB`, `MONITOR_MINIO_MAX_MB`, `MONITOR_BACKUP_MAX_HOURS`, `MONITOR_TLS_MIN_DAYS`. Значения объёма задаются в МБ и для открытой альфы по умолчанию равны 2048/10240. Проверка TLS использует SNI и поэтому обнаруживает как истечение, так и выдачу сертификата для неверного домена.
## Ручная проверка
```bash
./deploy/monitor.sh
echo $?
```
Первый успешный запуск следует сделать только после появления DNS, TLS и первой резервной копии. До этого `CRITICAL` для этих компонентов ожидаем.
## systemd timer
Шаблоны рассчитаны на пользователя `rf4spotter` и каталог `/opt/rf4-spotter`. При другом размещении измените оба пути в service-файле.
```bash
sudo cp deploy/systemd/rf4spotter-monitor.service /etc/systemd/system/
sudo cp deploy/systemd/rf4spotter-monitor.timer /etc/systemd/system/
sudo cp deploy/systemd/rf4spotter-maintenance.service /etc/systemd/system/
sudo cp deploy/systemd/rf4spotter-maintenance.timer /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now rf4spotter-monitor.timer rf4spotter-maintenance.timer
systemctl list-timers 'rf4spotter-*'
journalctl -u rf4spotter-monitor.service -n 20 --no-pager
```
Monitor timer записывает результат в journal. Maintenance timer ежедневно сначала создаёт backup, затем выполняет retention и не допускает параллельных запусков. Для реального оповещения подключите failed unit к существующему серверному мониторингу либо настройте внешний HTTPS-monitor на `/ready`; уведомления должны приходить минимум по состояниям readiness, disk, backup и TLS. Не передавайте `.env.production` или вывод `docker compose config` внешнему сервису.
## Реакция
1. `service:*` — посмотреть `docker compose ... ps` и логи конкретного контейнера; не выполнять `down -v`.
2. `readiness` — проверить `/ready`, PostgreSQL и MinIO; на время сбоя остановить приём пользовательских заявок.
3. `disk:*` — сначала перенести старые backup во внешнее хранилище; не удалять Docker volumes вслепую.
4. `postgresql-size:*` — проверить рост таблиц и выполнение retention; перед очисткой сделать backup и не выполнять ручное удаление строк без плана.
5. `minio-size:*` — сверить объекты с заявками и политикой retention; не удалять volume или бакет целиком.
6. `backup:*` — запустить `deploy/backup.sh`, проверить `SHA256SUMS` и устранить причину пропуска расписания.
7. `tls:*` — проверить DNS, доступность портов 80/443 и логи Caddy; не отключать проверку сертификата.