Мониторинг: самодиагностика, health, ready и метрики

Главная / Документация / НаблюдениеМониторинг: самодиагностика, health, ready и метрикиКак следить за установкой volrix.pm: самодиагностика в интерфейсе, проверки health и ready, метрики для своего Prometheus и что искать в журналах.Обновлено 29.10.2026Стек мониторинга (Prometheus и экспортеры) в поставку не входит с версии 0.38.0, прежний раздел с графиками убран. За состоянием установки следят четырьмя средствами: самодиагностикой в интерфейсе, HTTP-проверками health и ready, эндпоинтом /metrics для вашего Prometheus и журналами контейнеров.«Администрирование» → «Наблюдение» → «Автотесты и диагностика», вкладка «Самодиагностика». Пункт меню виден с правом tests.run.Самодиагностика в интерфейсеВкладка «Самодиагностика» проверяет компоненты и базовые настройки безопасности при каждом открытии и по кнопке «Обновить». Результаты разбиты на группы «ИТ-инфраструктура» и «Информационная безопасность», у каждой проверки состояние «OK», «Внимание» или «Ошибка» и колонка «Подробности». Мониторинг: доступность, готовность и фоновые работы. Пример экрана настройки.

Мониторинг: доступность, готовность и фоновые работы. Пример экрана настройки.

Проверка

Когда не «OK»

База данных

«Ошибка»: backend не может выполнить запрос к PostgreSQL.

Хранилище файлов

«Ошибка»: не читается таблица файлов в PostgreSQL. В «Подробностях» - число файлов.

Диск (контейнер)

«Внимание» от 85% занятости, «Ошибка» от 95%. Пороги меняются в Пределах и порогах.

Миграции БД

«Внимание»: схема базы не на последней ревизии этой версии.

Бэкапы

«Внимание»: копий нет («Бэкапов нет») или последняя старше 48 часов (порог «Копия считается свежей»).

Режим DEBUG

«Ошибка»: в окружении включен DEBUG.

SECRET_KEY

«Ошибка»: ключ по умолчанию или короче 32 символов.

Лицензия

«Внимание» в льготном периоде или при несовпадении, «Ошибка» - истекла, отсутствует или недействительна.

CORS

«Внимание»: в переменной CORS_ORIGINS разрешены любые источники.

TLS почты

«Внимание»: проверка сертификата SMTP выключена. Смотрит переменную SMTP_VERIFY_TLS в .env, а не переключатель на странице SMTP; установщик ставит в ней false.

Админы без 2FA

«Внимание»: есть активные администраторы системы без двухфакторной аутентификации.

Счетчики пользователей, проектов и действий за сутки, а с версии 1.1.12 и состояние контейнеров (работают ли, здоровы ли, процессор, память, перезапуски) показывает «Наблюдение» → «Состояние системы» - см. Системный дашборд. Технические ошибки backend собирает «Журналы» → «Ошибки» - см. Журнал ошибок. Схему серверов, роли базы данных и предупреждения в кластере показывает «Наблюдение» → «Кластер» - см. Кластер.Проверки health и ready

Адрес

Что проверяет

Ответ

/api/v1/health

Процесс backend запущен и отвечает. Базу данных не трогает.

200 {"status": "ok"}

/api/v1/ready

База данных отвечает не дольше 5 секунд, и ее схема совпадает с последней миграцией этой версии.

200 {"status": "ready"} или 503 {"status": "not_ready"}

Оба адреса не требуют входа и доступны по тому же адресу, что и система. На самом сервере backend слушает только 127.0.0.1:8000. Этой же проверкой ready Docker каждые 15 секунд определяет состояние контейнера volrix-backend - оно видно в docker ps как healthy или unhealthy. В кластере по этой же проверке HAProxy на балансировщиках выводит неготовый узел приложения из ротации.curl --fail -sS https://pm.company.ru/api/v1/health curl --fail -sS https://pm.company.ru/api/v1/ready # на самом сервере curl --fail -sS http://127.0.0.1:8000/api/v1/ready docker ps --filter name=volrixДля внешнего мониторинга опрашивайте ready раз в одну-пять минут и поднимайте тревогу после двух-трех неудач подряд. Пара health и ready сразу отличает «процесс не отвечает» от «процесс жив, но нет базы».Метрики для своего Prometheus

**Адрес.** /metrics на backend, без префикса /api. Внешний прокси пропускает к backend только /api/, поэтому по адресу системы /metrics недоступен - собирайте метрики с сервера: http://127.0.0.1:8000/metrics или по имени backend:8000 из docker-сети установки.

**Токен.** Если задана переменная METRICS_TOKEN, запрос должен нести заголовок Authorization: Bearer <токен>, иначе ответ 401 «Требуется токен метрик». В текущей сборке у переменной есть значение по умолчанию, то есть проверка включена всегда - задайте свой секрет. Пустое значение снимает проверку.

**Состав.** По умолчанию отдаются только метрики процесса Python: процессор, память, открытые файлы, сборщик мусора. Метрики HTTP-запросов (http_requests_total, http_request_duration_seconds по маршрутам) включаются переменной METRICS_ENABLED=true. По умолчанию они выключены: сбор добавляет работу на каждый запрос.

**Как задать переменные.** В схеме docker-compose.release.yml контейнер backend получает только перечисленные в его разделе environment переменные, METRICS_TOKEN и METRICS_ENABLED среди них нет. Добавьте их туда и пересоздайте контейнер; после обновления продукта проверьте, что правка сохранилась.

**Нагрузку на сервер** (процессор, память и диск хоста) и метрики PostgreSQL продукт не собирает - для этого нужны ваши агенты, например node_exporter и postgres_exporter.

# .env METRICS_TOKEN=<длинная случайная строка> # docker-compose.release.yml, сервис backend environment: METRICS_TOKEN: ${METRICS_TOKEN} METRICS_ENABLED: "true" # prometheus.yml scrape_configs: - job_name: volrix metrics_path: /metrics authorization: type: Bearer credentials: ВАШ_METRICS_TOKEN static_configs: - targets: ["127.0.0.1:8000"]docker compose -f docker-compose.release.yml up -d backend curl -sS -H "Authorization: Bearer ВАШ_METRICS_TOKEN" http://127.0.0.1:8000/metrics | headФоновые задачи и журналыВ стандартной установке работают контейнеры volrix-postgres, volrix-backend, volrix-scheduler и volrix-frontend. Фоновые задачи - ночная копия, опрос почты, напоминания, актуализация графиков - выполняет volrix-scheduler. У него нет порта и проверки состояния, поэтому следите за ним по статусу контейнера и журналу.Процессов backend может быть несколько (переменная WEB_WORKERS), планировщик тоже можно запустить в нескольких процессах: задачи выполняет один ведущий, остальные ждут в резерве. В кластере контейнера volrix-scheduler нет - планировщик работает в volrix-backend каждого узла приложения. Подробнее - Эксплуатация нескольких процессов и серверов.docker ps --filter name=volrix docker logs --since 24h volrix-backend docker logs --since 24h volrix-scheduler

Строка в журнале

Что значит

«Scheduler process started (standalone), waiting for leadership»

Контейнер volrix-scheduler запустился и ждет, пока станет ведущим.

«Планировщик: этот процесс стал ведущим»

Этот процесс выполняет фоновые задачи.

«Планировщик: ведущий работает в другом процессе, этот в резерве»

Норма, если кандидатов в планировщики несколько.

«Расписание применено: задач 7, пояс Europe/Moscow»

Время задач прочитано из раздела Расписание задач.

«Daily backup completed successfully»

Ночная копия создана.

«Daily backup completed with errors: ...»

Копия создана с ошибками - разберите текст и место на диске.

«Daily backup skipped - schedule_enabled=false»

Автокопирование выключено в разделе «Резервные копии».

«IMAP fetch failed»

Общий ящик не забирается - см. Общий ящик (IMAP).

«Уведомление: ошибка отправки email»

Письмо об уведомлении не ушло - проверьте SMTP.

«SMTP verify_tls отключен - сертификат сервера не проверяется»

Предупреждение при каждой отправке письма без проверки сертификата.

«База недоступна: GET /api/v1/... - ...»

Запрос получил ответ 503 «База данных переключается на резервный сервер. Повторите через несколько секунд.»: база была недоступна несколько секунд (переключение основного сервера в кластере, перезапуск volrix-postgres, нет свободных соединений). Единичные строки - не авария, поток таких строк - проверяйте базу.

Что поставить на контроль

/api/v1/ready - доступность приложения и базы.

Статус контейнеров volrix-backend (healthy) и volrix-scheduler (Up, без перезапусков). То же видно без входа на сервер: «Состояние системы» → блок «Контейнеры».

В кластере - предупреждения на экране «Кластер»: основной сервер БД, синхронная реплика, кворум etcd, ведущий планировщик.

Свободное место на диске сервера: база, файлы и каталог backups растут.

Возраст последней резервной копии - проверка «Бэкапы» в самодиагностике или файлы в каталоге backups установки.

Срок действия сертификата HTTPS - см. HTTPS и сертификаты.

Если не получается

Что видно

Причина и что сделать

health отвечает 200, ready - 503

Нет связи с базой или схема базы не совпадает с версией (обновление не завершило миграции). Смотрите docker logs volrix-backend и состояние volrix-postgres.

Пользователи видят «База данных переключается на резервный сервер. Повторите через несколько секунд.»

Ответ 503: база недоступна. В кластере это переключение основного сервера, обычно до 30 секунд. Если дольше - на экране Кластер ищите «Нет основного сервера PostgreSQL» или «etcd без кворума». На одном сервере проверьте docker ps (volrix-postgres в состоянии healthy) и docker logs volrix-postgres.

/metrics по адресу системы отдает HTML-страницу

Прокси не пропускает /metrics. Собирайте с 127.0.0.1:8000 на сервере или из docker-сети.

401 «Требуется токен метрик»

В Prometheus не задан Bearer-токен или он не совпадает с METRICS_TOKEN контейнера.

В метриках нет http_requests_total

Не включен METRICS_ENABLED=true или контейнер не пересоздан после правки.

«Бэкапы» - «Внимание»

Копий нет или последняя старше порога. Проверьте volrix-scheduler, расписание и раздел Резервные копии.

«TLS почты» - «Внимание», хотя на странице SMTP проверка включена

Проверка читает SMTP_VERIFY_TLS из .env. Поставьте true и пересоздайте контейнеры backend и scheduler.

В меню нет прежнего раздела «Мониторинг» с графиками

Он убран в 0.38.0 вместе с Prometheus в поставке. Графики строит ваш Prometheus по /metrics.

Журнал ошибок

Резервные копии

Кластер

Технические ошибки backend в интерфейсе.Создание, проверка и восстановление копий.Схема серверов, роли PostgreSQL и предупреждения

Администрирование: обзор области