Маршруты администрирования volrix.pm: настройки, копии, журналы, лицензия, API-ключи, LDAP и OIDC, мониторинг, кластер и автотесты.
Обновлено 16.10.2026
Группа для администраторов и систем эксплуатации: почта и системные настройки, журналы аудита и ошибок, резервные копии, автотесты, очистка данных, расписание, хранилище файлов, LDAP, OIDC, HTTPS, лицензия, API-ключи, каталог прав, конструктор документов, оформление, мониторинг и состояние кластера.
**Что принимает API-ключ.** Почти все маршруты группы - по скоупам из таблиц. Операции здесь меняют доступ и данные всей установки: восстановление из копии, очистка данных, смена хранилища. Давайте ключам этой группы только скоупы чтения, а изменения выполняйте в интерфейсе или на тестовом стенде.
Базовый адрес, формат ответов и коды ошибок описаны в статье API: адрес, первый запрос и ответы, выпуск ключа и вход под пользователем - в статье API: вход, токен и API-ключи. В примерах ключ лежит в переменной окружения VOLRIX_API_KEY, токен пользователя - в VOLRIX_TOKEN.
Резервное копирование по расписанию настраивается в PUT /admin/backups/settings; ручной запуск - POST /admin/backups/run (backups:create), проверка копии - POST /admin/backups/{filename}/verify (backups:verify).
Проверка доступности для внешнего мониторинга:
curl -sS -o /dev/null -w "%{http_code}\n" https://ваш-адрес/api/v1/ready
Вход пользователей за сутки из журнала аудита по ключу (скоуп audit_log:read). Ответ AuditLogList: items, total, page, page_size, pages:
curl --fail-with-body -sS \ -H "X-Api-Key: $VOLRIX_API_KEY" \ "https://ваш-адрес/api/v1/admin/audit-log?action_type=login&date_from=2026-09-26&date_to=2026-09-26&page_size=200"
Как читать колонку «Доступ»: **скоуп вида users:read** - маршрут принимает API-ключ, если в ключе есть этот скоуп, а у сотрудника, выпустившего ключ, есть такое же право в роли (users.read). Если скоупов несколько через «+», нужны все. **Только сессия** - нужен заголовок Authorization: Bearer, API-ключ получит 403. **Без авторизации** - заголовки не нужны. Доступ к конкретному объекту (участие в проекте, права на папку Диска) сервер проверяет дополнительно. Пути в таблицах указаны полностью, от корня сервера.
**GET /admin/cluster.** Схема кластера для экрана «Администрирование» → «Наблюдение» → «Кластер»; право то же, что у состояния системы, ничего не меняется. Снимок собирает ведущий планировщик раз в 20 секунд и кладет в общее хранилище, поэтому ответ одинаков с любого узла и маршрут не опрашивает кластер на каждый запрос. Если свежего снимка еще нет, он собирается при обращении.
Что превращается в предупреждение: меньше трех узлов, не отвечает виртуальный адрес (danger), нет основного сервера PostgreSQL или синхронной реплики (danger), отставание реплики больше 16 МБ, etcd без кворума (danger), разные версии приложения на узлах, нет ведущего планировщика (фоновые задачи не выполняются). Тот же список читайте на экране «Кластер».
**GET /admin/tests/available.** Возвращает {"available": true | false}: есть ли в этой установке набор pytest. В комплект установки тесты не входят, поэтому на такой установке экран «Автотесты» вместо кнопки запуска объясняет, что тестов нет, а вкладки «Самодиагностика», «Безопасность» и «API и Swagger» (маршруты selfcheck, security и api-coverage) работают. Если вызвать POST /admin/tests/run при available=false, run_id вернется как обычно, но GET /admin/tests/run/{run_id} сразу отдаст status=done, ok=false и в error - причину: «Автотесты не входят в этот комплект установки». Перед запуском прогона из скрипта спросите этот маршрут.
Поля JSON и форм multipart из схемы сервера. «Да» - поле обязательно. Ссылка на другую схему (например, array[QCApproverInput]) означает вложенный объект с теми же полями.
Доступность, готовность и фоновые работы
Создать, проверить и восстановить
Найти действие и восстановить последовательность