Управление сервером

Сервер ERP запускается и управляется одним классом ru.bgcrm.Server: в дистрибутиве его вызывает start.sh, при локальном запуске — ru.bgcrm.app.MainKt. Первый аргумент — команда. start поднимает сервер в текущем процессе, остальные команды отправляются уже запущенному серверу через админ-порт.

Админ-порт слушает только 127.0.0.1, поэтому команды выполняются с того же хоста или из того же контейнера. Номер порта задаёт server.port.admin (по умолчанию 8005).

java -cp "/opt/erp/:/opt/erp/lib/ext/*:/opt/erp/lib/app/*" ru.bgcrm.Server status

Запуск

Запуск идёт по шагам в фиксированном порядке. Первым шагом проверяется, что свободны порты HTTP (server.port.http), админ-порт и порт метрик (server.telemetry.port), и что никакие два из них не совпадают. Если порт занят, сервер завершается сразу, не дожидаясь подключения к БД и загрузки плагинов, с одной строкой в журнале:

Порты сервера недоступны: HTTP 8080 занят; admin 2010 занят; telemetry 9090 занят

Ошибка любого шага, кроме записи отметки о запуске в историю релизов, останавливает запуск с кодом выхода 1. Неудача записи отметки только попадает в журнал, сервер продолжает работу.

Плагины загружаются в начале запуска, а начинают работу отдельным шагом — после компиляции динамического кода. Ошибка запуска одного плагина попадает в журнал строкой Не удалось запустить плагин <id> и не мешает остальным плагинам и серверу.

Длительность каждого шага записывается в журнал на уровне DEBUG, а итог — на уровне INFO:

BGCRM started in 23.8 s; slowest steps: mbeans 14.1 s, plugins 6.0 s, tomcat start 4.2 s

Тот же список с длительностями показывается на экране Статус сервера в блоке Приложение по кнопке Шаги запуска.

Остановка

Команда stop отказывается останавливать сервер, пока выполняются задачи планировщика, и печатает ответ сервера. Иначе она дожидается фактического завершения процесса, но не дольше 60 секунд, и печатает итог:

OK stopping..
Server stopped

Если за 60 секунд процесс не завершился, выводится Server is still running after 60 s.

Коды выхода

Код Когда

0

Команда выполнена, в том числе stop дождался остановки. Без аргументов выводится справка, тоже с кодом 0.

1

Команда не выполнена: админ-порт недоступен или сервер не ответил.

2

stop не остановил сервер: выполняются задачи планировщика или процесс не завершился за 60 секунд.

Ошибки внутри самой команды (неверный аргумент, неизвестный уровень логирования) сервер возвращает текстом, код выхода при этом 0.

Команды админ-порта

Полный список с кратким описанием выводит команда help.

Команда Что делает

status

Версия, время с запуска JVM, память и пулы соединений.

status --json

Тот же снимок, что на экране Статус сервера, одной строкой JSON. Подходит для внешнего мониторинга и скриптов.

stop

Остановка сервера, см. выше.

gc

Принудительная сборка мусора.

threads

Полный дамп потоков в файл log/thread-dump-<дата>-<время>.txt рабочего каталога. В ответ выводятся путь к файлу, число потоков по состояниям и число потоков во взаимной блокировке. Старые файлы автоматически не удаляются.

loglevel

Уровни логирования, заданные в конфигурации log4j.

loglevel <logger> <LEVEL>

Меняет уровень логгера до перезапуска, например loglevel ru.bgcrm.dao DEBUG. Для корневого логгера указывается root. Допустимые уровни: OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE, ALL.

reload-config

Перечитывает bgcrm.properties и активную конфигурацию из БД так же, как сохранение конфигурации в интерфейсе администратора.

reload-config <configId>

То же для конкретной конфигурации. Плагины, которые хранят настройки в отдельной конфигурации, перечитывают их только при её коде; так, reload-config 47 переинициализирует Camel, если его конфигурация имеет код 47.

tasks

Число выполняемых задач планировщика и время их запуска. Полезно проверить перед stop.

sessions

Число HTTP-сессий и авторизованных пользователей.

runclass <class>

Запуск класса динамического кода, реализующего Runnable. Класс выполняется в фоне через AsyncWorker с контекстом сервера, поэтому ему доступны соединения с БД и сервисы ядра.

pswdGen

Генерация секретного ключа и зашифрованного пароля администратора.

Все аргументы командной строки передаются серверу одной строкой:

java ... ru.bgcrm.Server loglevel ru.bgcrm.dao DEBUG

Пробы здоровья

Для оркестратора и балансировщика сервер отвечает на два адреса без авторизации:

Адрес Что проверяет Ответ

/health/live

Нет ли потоков во взаимной блокировке.

200, если процесс жив; 503, если есть взаимная блокировка.

/health/ready

Запуск завершён полностью и пул соединений с основной БД не исчерпан.

200, если сервер готов принимать запросы; 503 во время запуска, после неудачного запуска и при исчерпанном пуле.

Тело ответа — JSON с итогом и результатом каждой проверки:

{"status":"UP","checks":[{"name":"startup","status":"UP","detail":"completed"},{"name":"connectionPool","status":"UP","detail":"active 1 of 300"}]}

Проверка готовности не берёт соединение из пула: при исчерпанном пуле запрос соединения блокируется, и проба зависла бы вместе с ним. Поэтому доступность самой БД проба не проверяет, только заполненность пула.

Пример проверки здоровья для Docker:

HEALTHCHECK --interval=30s --timeout=5s --start-period=120s \
  CMD curl -fsS http://localhost:8080/health/ready || exit 1

Пробы не требуют авторизации и раскрывают число занятых соединений, поэтому не публикуйте /health/* наружу через прокси.

Связанные настройки

Параметр По умолчанию Назначение

server.port.http

8080

Порт HTTP. Может быть задан переменной окружения с тем же именем.

server.port.admin

8005

Админ-порт сервера. Может быть задан переменной окружения с тем же именем; клиент командной строки читает значение только из файла настроек.

server.telemetry.port

9090

Порт метрик Prometheus.

server.ssl.trust.all

1

Отключение проверки SSL-сертификатов для исходящих HTTPS-соединений, см. Конфигурация.