rf4-spotter/docs/production-monitoring.md

Мониторинг открытой альфы

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 и поэтому обнаруживает как истечение, так и выдачу сертификата для неверного домена.

Ручная проверка

./deploy/monitor.sh
echo $?

Первый успешный запуск следует сделать только после появления DNS, TLS и первой резервной копии. До этого CRITICAL для этих компонентов ожидаем.

systemd timer

Шаблоны рассчитаны на пользователя rf4spotter и каталог /opt/rf4-spotter. При другом размещении измените оба пути в service-файле.

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; не отключать проверку сертификата.