Сервер DataHUB

Сервер DataHUB — основной серверный компонент платформы. Реализует транспортный REST API, выполняет авторизацию интегрируемых систем и пользователей, автоматически конфигурирует RabbitMQ (точки обмена, очереди, привязки), маршрутизирует сообщения между подключёнными системами, ведёт журнал событий обмена, отправляет email- и SMS-нотификации. В кодовой базе — модуль backend-mono (Spring Boot 3.5.5 / Java 21). В Docker Compose поставке — блок backend.

Эта статья описывает конфигурацию блока backend и порядок генерации его секретов. Архитектура самого backend (controller/service/repository, обработчики RabbitMQ) — в Архитектура / Архитектура сервиса. Сквозные аспекты безопасности (TLS, mTLS, парольная политика, rate-limiting) — в Настройке безопасности.

Структура блока

Каталог блока — /etc/datahub/backend/:

/etc/datahub/backend/
├── docker-compose.yml   # описание контейнера
├── .env.template        # шаблон переменных окружения
├── .env                 # реальные значения (создаётся при установке)
├── scripts/             # скрипты генерации секретов
│   ├── generate_pepper.sh
│   ├── generate_keys.sh
│   └── generate_service_token.sh
├── certs/               # секреты (генерируются скриптами выше)
│   ├── pepper.txt
│   ├── private_key.pem
│   ├── public_key.pem
│   └── service_token.jwt
├── templates/           # шаблоны email-уведомлений (HTML/TXT)
└── log/                 # логи приложения (bind-mount)

Файл docker-compose.yml:

services:
  backend:
    image: registry.gitlab.com/datahub/v3/services/backend-mono:dev
    container_name: backend
    hostname: backend
    volumes:
      - ./certs:/datahub/backend/secrets:rw
      - ./log/:/var/log/nginx/:rw
      - ./templates:/datahub/backend/resources/templates:ro
    expose:
      - "80"
    env_file:
      - .env
    restart: always
    networks:
      - dh_network

Ключевые особенности:

• expose: 80 без ports — backend виден только внутри dh_network. Внешние запросы приходят через nginx, который проксирует на http://backend:80.
• ./certs:/datahub/backend/secrets:rw — секреты (см. ниже) монтируются read-write, потому что Spring может пересоздавать service_token при истечении срока.
• ./templates:/datahub/backend/resources/templates:ro — шаблоны email-уведомлений монтируются read-only. Их можно править на хосте; backend перечитывает их при рендеринге.
• ./log/:/var/log/nginx/:rw — путь внутри контейнера /var/log/nginx/ исторический (раньше шёл общий формат логов с nginx). По факту туда пишутся прикладные логи backend.
• Все настройки — через переменные окружения, никаких хост-файлов с конфигурацией Spring не подкладывается.

Конфигурация (.env)

Шаблон .env.template объёмный (~120 строк) — большая часть параметров закомментирована и используется только при тонкой настройке. Ниже — обязательные группы.

Базовая конфигурация приложения

SPRING_PROFILES_ACTIVE=dev               # prod | dev | test (см. раздел про профили)
SECRETS=/datahub/backend/secrets         # путь к каталогу секретов внутри контейнера
SERVER_PORT=80                           # порт backend внутри контейнера
DATAHUB_PUBLIC_URL=https://lk.<your-domain>   # публичный URL личного кабинета (для CORS и ссылок в письмах)

DATAHUB_ADMIN_USERNAME=admin
DATAHUB_ADMIN_PASSWORD={{DATAHUB_ADMIN_PASSWORD}}
DATAHUB_ADMIN_EMAIL=admin@<your-domain>

Переменная	Назначение
SPRING_PROFILES_ACTIVE	Профиль Spring. На production-стенде должен быть prod.
SECRETS	Путь к каталогу секретов внутри контейнера. Соответствует bind-mount тома ./certs. Не менять.
SERVER_PORT	Порт HTTP-сервера внутри контейнера. По умолчанию 80, согласован с expose:.
DATAHUB_PUBLIC_URL	Внешний URL личного кабинета. Используется для CORS и для генерации ссылок в письмах-нотификациях.
DATAHUB_ADMIN_USERNAME/PASSWORD/EMAIL	Учётная запись администратора, создаётся при первом старте. Меняется потом через UI.

Подключение к PostgreSQL

POSTGRES_HOST=postgres
POSTGRES_PORT=5432
POSTGRES_DB=DataHUB
POSTGRES_USER={{POSTGRES_USER}}
POSTGRES_PASSWORD={{POSTGRES_PASSWORD}}
# POSTGRES_CONNECTION_TIMEOUT=5000

Значения должны совпадать с .env блоков postgres и flyway. См. PostgreSQL.

Подключение к RabbitMQ

RABBITMQ_HOST=rabbitmq
RABBITMQ_PORT=5672
RABBITMQ_USER={{RABBITMQ_USER}}
RABBITMQ_PASSWORD={{RABBITMQ_PASSWORD}}
RABBITMQ_VHOST=/
RABBITMQ_MANAGEMENT_URL=http://rabbitmq:15672

Значения должны совпадать с .env блока rabbitmq (RABBITMQ_USER соответствует RABBITMQ_DEFAULT_USER в брокере). См. RabbitMQ.

RABBITMQ_MANAGEMENT_URL — отдельный URL Management API, через который backend программно создаёт exchange и queue. См. Архитектура / Работа с очередями.

Email и SMS

NOTIFICATION_EMAIL_HOST=smtp.<your-domain>
NOTIFICATION_EMAIL_PORT=465
NOTIFICATION_EMAIL_USERNAME=noreply@<your-domain>
NOTIFICATION_EMAIL_PASSWORD={{NOTIFICATION_EMAIL_PASSWORD}}
NOTIFICATION_EMAIL_SSL_ENABLE=true
NOTIFICATION_EMAIL_FROM=noreply@<your-domain>

NOTIFICATION_SMS_ENABLED=false
# NOTIFICATION_SMS_API_URL=https://smsc.ru/sys/send
# NOTIFICATION_SMS_API_LOGIN=...
# NOTIFICATION_SMS_API_PASSWORD=...
# NOTIFICATION_SMS_SENDER=...

Развёрнуто — в Настройке уведомлений.

Опциональные тонкие настройки

В шаблоне .env.template дополнительно закомментированы группы переменных для тонкой настройки. Все интервалы времени — в миллисекундах, если не указано иначе. Чтобы переопределить значение, раскомментируйте строку в .env и задайте новое значение, затем перезапустите backend.

Времена жизни токенов авторизации

JWT-токены, которыми backend авторизует HTTP-запросы.

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
ACCESS_TOKEN_VALIDITY_TIME	900000 (15 мин)	Срок жизни access-токена пользователя. По истечении нужен refresh.	300000–3600000 (5 мин – 1 ч). Меньшее значение безопаснее, но требует чаще обновлять токен — нагрузка на эндпоинт refresh.
REFRESH_TOKEN_VALIDITY_TIME	604800000 (7 дней)	Срок жизни refresh-токена. После истечения — повторный логин.	86400000–2592000000 (1 день – 30 дней). Для production — 7–14 дней. Для систем с повышенными требованиями — 1–3 дня.
SERVICE_TOKEN_VALIDITY_TIME	31536000000 (1 год)	Срок жизни service-token (внутренний JWT для сервисных вызовов). Автоматически перевыпускается backend.	Менять обычно не нужно. Снизить только при политике частой ротации (квартал — 7776000000).

Токены подтверждения Email

OTP-коды, отправляемые на email при регистрации и смене email.

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
EMAIL_VERIFICATION_TOKEN_VALIDITY_TIME	3600000 (1 ч)	Сколько действителен OTP-код.	600000–3600000 (10 мин – 1 ч). Меньше — безопаснее, но пользователь может не успеть.
EMAIL_VERIFICATION_TOKEN_LENGTH	6	Длина OTP-кода.	4–8. Согласовать с VERIFICATION_TOKEN_LENGTH в .env frontend.
EMAIL_VERIFICATION_TOKEN_CHARSET	A-Za-z0-9	Набор символов OTP.	Латиница и цифры. Если хотите сделать читаемее голосом — оставить только цифры (0123456789).
EMAIL_VERIFICATION_TOKEN_MAX_ATTEMPTS	5	Сколько раз можно ввести неверный код до блокировки.	3–10. Меньше — жёстче защита от подбора.

Токены сброса пароля

OTP-коды, отправляемые при сбросе пароля. Структурно идентичны email-токенам, но независимы по настройкам.

Переменная	По умолчанию	Назначение
RESET_PASSWORD_BY_EMAIL_TOKEN_VALIDITY_TIME	3600000 (1 ч)	Срок действия кода сброса
RESET_PASSWORD_BY_EMAIL_TOKEN_LENGTH	6	Длина кода
RESET_PASSWORD_BY_EMAIL_TOKEN_CHARSET	A-Za-z0-9	Набор символов
RESET_PASSWORD_BY_EMAIL_TOKEN_MAX_ATTEMPTS	5	Максимум попыток ввода

Рекомендации — те же, что и для email-токенов выше.

Токены подтверждения телефона (SMS)

OTP-коды для подтверждения номера телефона и 2FA по SMS. Используются только при NOTIFICATION_SMS_ENABLED=true.

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
PHONE_VERIFICATION_TOKEN_VALIDITY_TIME	3600000 (1 ч)	Срок действия SMS-кода.	300000–3600000 (5 мин – 1 ч). Для 2FA лучше короче — 5–10 мин.
PHONE_VERIFICATION_TOKEN_LENGTH	6	Длина кода.	4–8. На SMS обычно 4–6.
PHONE_VERIFICATION_TOKEN_CHARSET	0123456789	Только цифры.	Менять не рекомендуется — буквы в SMS затрудняют ввод с клавиатуры телефона.
PHONE_VERIFICATION_TOKEN_MAX_ATTEMPTS	5	Максимум попыток.	3–10.

Политика паролей

Серверная валидация при регистрации и смене пароля. Подробнее — в Настройке безопасности / Парольная политика.

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
PASSWORD_COMPLEXITY	^(?=.*[A-Za-z])(?=.*\d)[A-Za-z\d!@#$%^&*()_+\-=\[\]{};':"\\|,.<>/?]{12,}$	Regex требований к сложности пароля: буква + цифра + спецсимвол + ≥ 12 знаков.	Любой совместимый Java regex. Минимум 12 символов рекомендуется НИСТ. Для жёстких политик — поднять до 14–16 и добавить требование смешанного регистра.
PASSWORD_COMPLEXITY_DESCRIPTION	(англ. описание)	Текст, показываемый пользователю при некорректном пароле.	Любой текст. Согласовать с локализацией UI.
PASSWORD_POLICY_HISTORY_SIZE	24	Сколько последних паролей запрещено повторять.	0–24. 0 — отключить проверку повторения (не рекомендуется).
PASSWORD_POLICY_VALIDITY_DAYS	60	Через сколько дней пароль становится истёкшим.	0–365. 0 — бессрочный (не рекомендуется). 30–90 — типичный диапазон для корпоративных систем.

Rate-limiting логин

Защита от перебора паролей.

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
RATE_LIMIT_LOGIN_ATTEMPTS	5	Сколько неудачных попыток входа до блокировки аккаунта.	3–10. Меньше — жёстче, риск ложных блокировок.
RATE_LIMIT_LOGIN_LOCK_TIME	1800000 (30 мин)	На сколько блокируется аккаунт после превышения попыток.	300000–86400000 (5 мин – 1 день).

Rate-limiting API (Bucket4j)

Защита эндпоинтов от DoS и перегрузки. Реализация — Bucket4j поверх Caffeine cache.

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
API_AUTH_RATE_LIMIT_REQUESTS_CAPACITY	20	Burst-ёмкость для /api/auth/* (одного IP).	5–50. На production обычно жёстче — 10–20.
API_AUTH_RATE_LIMIT_REQUESTS_CAPACITY_REFILL	20	Сколько токенов пополняется в минуту.	Равно или меньше capacity.
API_RATE_LIMIT_REQUESTS_CAPACITY	200	Burst-ёмкость для остальных API.	50–1000. Зависит от характера нагрузки.
API_RATE_LIMIT_REQUESTS_CAPACITY_REFILL	100	Сколько токенов пополняется в минуту.	Половина или треть от capacity — типичное правило.

Rate-limiting отправки OTP

Защита от спама отправки email/SMS кодов через формы регистрации/сброса.

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
RATE_EMAIL_SENDING_VERIFICATION_TOKEN_CAPACITY	3	Сколько отправок OTP за период.	1–5.
RATE_EMAIL_SENDING_VERIFICATION_TOKEN_PERIOD	3 (минут)	Период учёта.	1–60 минут.
RATE_EMAIL_SENDING_VERIFICATION_TOKEN_RETRY_AFTER_SECONDS	60	Через сколько секунд после превышения можно попробовать снова.	30–300.
RATE_SMS_SENDING_VERIFICATION_TOKEN_CAPACITY	3	Аналогично для SMS.	1–5. Помните: SMS стоит денег, оставьте жёстко.
RATE_SMS_SENDING_VERIFICATION_TOKEN_PERIOD	3 (минут)	Период учёта SMS.	1–60.
RATE_SMS_SENDING_VERIFICATION_TOKEN_RETRY_AFTER_SECONDS	60	Пауза перед повторной отправкой SMS.	30–600.

Async executor

Spring TaskExecutor для обработки асинхронных HTTP-запросов (@Async, long-polling exchange API).

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
ASYNC_EXECUTOR_CORE_POOL_SIZE	10	Базовое число потоков в пуле (всегда живых).	5–50. Зависит от характера нагрузки и числа vCPU.
ASYNC_EXECUTOR_MAX_POOL_SIZE	50	Максимум потоков.	core × 2–core × 10. На больших нагрузках поднимать.
ASYNC_EXECUTOR_QUEUE_CAPACITY	100	Очередь задач между core и max.	50–1000. Большое значение «гасит» всплески, но скрывает деградацию.
ASYNC_EXECUTOR_KEEP_ALIVE_SECONDS	60	Сколько времени неиспользуемый поток держится после превышения core.	30–300.
ASYNC_EXECUTOR_AWAIT_TERMINATION_SECONDS	30	Сколько ждать завершения задач при остановке backend.	10–120.
ASYNC_REQUEST_TIMEOUT	120000 (120 с)	Таймаут на обработку асинхронного HTTP-запроса. Должен быть больше EXCHANGE_POLLING_TIMEOUT.	60000–300000.

Long-polling exchange API

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
EXCHANGE_POLLING_TIMEOUT	90000 (90 с)	Сколько backend держит подключение, ожидая сообщение в очереди для клиента. Должен быть меньше ASYNC_REQUEST_TIMEOUT и proxy_read_timeout nginx (120 с).	30000–120000. Большее значение — меньше TCP-handshake'ов, но больше «висящих» соединений.

Подключение к RabbitMQ (низкоуровневые тайминги)

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
RABBITMQ_CONNECTION_TIMEOUT	5000 (5 с)	Таймаут установки TCP-соединения с брокером.	2000–30000.
RABBITMQ_HEARTBEAT	30 (секунд)	Heartbeat-интервал AMQP. Рекомендация RabbitMQ — 30–60.	0 — отключить (не рекомендуется), иначе — 15–60.
RABBITMQ_NETWORK_RECOVERY_INTERVAL	5000 (5 с)	Интервал повторного подключения после разрыва.	1000–30000.
RABBITMQ_CHANNEL_RPC_TIMEOUT	5000 (5 с)	Таймаут на RPC-операции канала.	2000–30000.
RABBITMQ_AUTOMATIC_RECOVERY_ENABLED	true	Автоматически восстанавливать AMQP-соединение после разрыва.	true (рекомендуется) / false.
RABBITMQ_TOPOLOGY_RECOVERY_ENABLED	false	Восстанавливать exchange/queue клиентом. Должно быть false — топологию пересоздаёт backend через Management API.	false. Включение приведёт к гонкам.

Тайминги обмена (специфика DataHUB)

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
RABBITMQ_SYNC_INTERVAL_MS	60000 (60 с)	Как часто backend сверяет топологию RMQ с конфигурацией в БД.	30000–300000.
RABBITMQ_ACK_TTL_SECONDS	120 (с)	TTL подтверждения сообщения — после возврат в очередь.	60–600. Должен быть больше типового времени обработки сообщения адаптером.
RABBITMQ_MAX_IN_FLIGHT_MESSAGES	5	Максимум одновременно обрабатываемых сообщений на один шаблон.	1–50. Большее значение — выше пропускная способность, но и риск перегрузки получателя.

Прочие

Переменная	По умолчанию	Назначение	Возможные значения / рекомендации
SERVER_PORT	80	Порт HTTP-сервера внутри контейнера.	1024–65535. Согласован с expose: в docker-compose.yml.
POSTGRES_CONNECTION_TIMEOUT	5000 (5 с)	Таймаут ожидания свободного соединения из Hikari-пула.	2000–30000. Если упирается в таймаут — увеличить maximum-pool-size, а не таймаут.
USERNAME_VALIDATION_PATTERN	(regex, 3–255 символов, начинается с буквы, см. application.yml)	Валидация имени пользователя при регистрации.	Любой Java regex. Изменение влияет только на новые регистрации.
EMAIL_VALIDATION_PATTERN	(regex стандартного формата email)	Валидация email.	Любой regex. Расширенные формы (name+tag@domain) — поддерживаются по умолчанию.
PHONE_VALIDATION_PATTERN	^\+\d{11}$	Валидация телефона. Дефолт — + плюс 11 цифр (РФ).	Любой regex. Для международной поддержки — ^\+\d{7,15}$.

Секреты

Сервер DataHUB использует четыре файла-секрета в каталоге certs/. Все они генерируются один раз при первичной установке и далее переживают рестарт и обновление контейнера.

Файл	Назначение
pepper.txt	Дополнительная серверная соль для хеширования паролей пользователей.
private_key.pem	RSA приватный ключ для подписи JWT-токенов.
public_key.pem	RSA публичный ключ для проверки подписи JWT (используется самим backend и отдельными адаптерами).
service_token.jwt	Долгоживущий JWT-токен для внутренних вызовов между сервисами.

Pepper

«Перец» — серверная константа, которая добавляется к каждому паролю перед хешированием. В отличие от соли (хранится рядом с хешем), перец хранится отдельно от БД и одинаков для всех паролей. Утечка БД без перца не позволяет восстановить пароли даже грубым перебором.

Генерация (выполняется один раз при первой установке):

cd /etc/datahub/backend/scripts
sudo chmod +x ./*.sh
sudo ./generate_pepper.sh

Скрипт создаёт ../certs/pepper.txt (32 байта случайных данных в base64url). Файл должен быть 0600, владелец — root.

Перец — критичный секрет

Замена перца на работающей платформе обесценивает все ранее сохранённые хеши паролей. Все пользователи окажутся не в состоянии войти, потребуется массовый сброс паролей. Меняйте перец только при компрометации (утечка из /etc/datahub/backend/certs/), и только с предварительным планом действий.

JWT-ключи

Пара RSA-ключей (2048 бит) для подписи и проверки JWT-токенов авторизации. Backend подписывает access-токены приватным ключом, клиент (или сам backend) проверяет публичным.

Генерация:

cd /etc/datahub/backend/scripts
sudo ./generate_keys.sh

Создаёт два файла в ../certs/:

• private_key.pem — приватный ключ в формате PKCS#8 (2048 бит). Права 0600.
• public_key.pem — публичный ключ. Права 0644.

JWT-ключи — критичный секрет

Замена приватного ключа на работающей платформе аннулирует все ранее выпущенные access- и refresh-токены. Пользователи будут принудительно разлогинены, придётся заново войти. Для интегрируемых систем (которые держат service-token) — заодно перевыпустить service-token (см. ниже).

Service token

Долгоживущий JWT-токен для вызовов между сервисами платформы (когда backend сам делегирует часть запросов другим компонентам). Подписывается тем же приватным ключом, что и обычные JWT, и имеет payload {"sub":"service"}. По умолчанию срок жизни — 1 год (SERVICE_TOKEN_VALIDITY_TIME).

Генерация (выполняется ПОСЛЕ generate_keys.sh, т.к. требует приватный ключ):

cd /etc/datahub/backend/scripts
sudo ./generate_service_token.sh

Создаёт ../certs/service_token.jwt. Скрипт выводит на экран расшифрованные header и payload — для проверки.

При истечении срока действия backend перевыпустит токен автоматически (поэтому том ./certs смонтирован rw).

Сводный порядок генерации

Порядок важен: generate_keys.sh создаёт ключи, на которых generate_service_token.sh подписывает токен. generate_pepper.sh независим, можно выполнять в любой момент.

cd /etc/datahub/backend/scripts
sudo chmod +x ./*.sh
sudo ./generate_pepper.sh
sudo ./generate_keys.sh
sudo ./generate_service_token.sh

После генерации проверьте права и владельца:

sudo chown -R root:root /etc/datahub/backend/certs
sudo chmod 600 /etc/datahub/backend/certs/pepper.txt
sudo chmod 600 /etc/datahub/backend/certs/private_key.pem
sudo chmod 644 /etc/datahub/backend/certs/public_key.pem
sudo chmod 600 /etc/datahub/backend/certs/service_token.jwt

Сами секреты внутри контейнера читаются из путей, заданных в application.yml:

datahub.backend.security.auth:
  private-key-path: "${SECRETS}/private_key.pem"
  public-key-path: "${SECRETS}/public_key.pem"
  service-token-path: "${SECRETS}/service_token.jwt"
  password-pepper-file: "${SECRETS}/pepper.txt"

Переменная SECRETS в .env указывает на /datahub/backend/secrets (что соответствует bind-mount ./certs).

Профили Spring

Backend поддерживает три профиля Spring: dev, prod, test. Выбирается через переменную SPRING_PROFILES_ACTIVE.

Профиль	Назначение	Ключевые отличия
dev	Локальная разработка, dev-стенд	Включён Swagger UI (/docs/swagger), включены DEBUG-логи com.datahub, разрешены дополнительные origin'ы CORS (для отладки с локального фронта).
prod	Production	Swagger UI выключен (springdoc.swagger-ui.enabled: false), Swagger API spec (/v3/api-docs) выключен. Только базовый набор endpoints.
test	Юнит-тесты	Используется CI; не предназначен для запуска на сервере.

На production-стенде обязательно должно быть SPRING_PROFILES_ACTIVE=prod — это закрывает Swagger UI, через который можно изучить структуру API и подобрать атаки.

Подключения и пулы

Backend держит два активных пула соединений:

Пул	Что	Параметры по умолчанию
Hikari (PostgreSQL)	JDBC-соединения к БД	maximum-pool-size: 5, minimum-idle: 1, connection-timeout: 5000ms, validation-timeout: 3000ms
Spring AMQP listener (RabbitMQ)	AMQP-каналы для подписки на очереди	acknowledge-mode: auto, retry: enabled, max-attempts: 3, initial-interval: 2000ms, multiplier: 2.0

Тонкая настройка под нагрузку — см. Архитектура / Масштабирование.

Healthcheck и Spring Actuator

Backend публикует все эндпоинты Spring Actuator. Основные:

Эндпоинт	Назначение
/actuator/health	Общее состояние приложения. На prod-стенде доступен через https://lk.<your-domain>/api/actuator/health.
/actuator/info	Метаданные приложения (версия, профиль).
/actuator/metrics	Метрики JVM, Hikari, кэши, request-rate (Micrometer).
/actuator/mappings	Список всех зарегистрированных REST-эндпоинтов.

В docker-compose шаблоне backend нет собственного HEALTHCHECK — это сделано осознанно: статус приложения определяется через actuator-эндпоинт, который доступен из nginx и из систем мониторинга. См. Мониторинг и логи.

Кэширование

Backend использует Caffeine (in-memory cache, JCache provider). Размер по умолчанию — 100 000 записей с TTL 10 минут. Кэшируются:

• DTO клиентов и клиентских систем (для быстрой авторизации входящих запросов);
• маршруты сообщений (для быстрой маршрутизации);
• bucket'ы rate-limiting (для эффективного подсчёта запросов с одного IP).

Полный список кэшей — в application.yml секция spring.cache.cache-names. Конфигурация Caffeine: spec: maximumSize=100000,expireAfterWrite=10m.

Логирование

По умолчанию backend пишет логи через стандартный logback-spring.xml Spring Boot — в stdout/stderr контейнера. Логи доступны через docker logs backend и попадают в Docker json-file driver (ротация 100 МБ × 10 файлов).

Уровни логирования (профиль prod):

logging.level:
  root: INFO
  com.datahub: INFO
  org.springframework.web: INFO

В dev-профиле дополнительно включён DEBUG на com.datahub. На production-стенде не включайте DEBUG надолго — он шумный.

Подавлены избыточные warnings Hibernate и Spring AMQP:

logging.level:
  org.hibernate.engine.jdbc.spi.SqlExceptionHelper: WARN
  org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator: ERROR
  org.springframework.amqp.rabbit.listener.BlockingQueueConsumer: OFF

Если нужны более детальные логи конкретной подсистемы — добавить переменную в .env. Spring Boot применяет «relaxed binding»: имя переменной в формате LOGGING_LEVEL_<PACKAGE> автоматически конвертируется в свойство logging.level.<package> (буквы в нижний регистр, _ → .). Например:

LOGGING_LEVEL_COM_DATAHUB_BACKEND_API=DEBUG

Эквивалентно logging.level.com.datahub.backend.api: DEBUG — задаёт уровень для пакета и всех его подпакетов.

Допустимые уровни: TRACE, DEBUG, INFO, WARN, ERROR, OFF.

Полезные пакеты для адресной диагностики:

Переменная	Подсистема
LOGGING_LEVEL_COM_DATAHUB_BACKEND_API_CONTROLLER	Контроллеры REST API — входящие HTTP-запросы, маршрутизация
LOGGING_LEVEL_COM_DATAHUB_BACKEND_API_SECURITY	JWT, ServiceTokenManager, авторизация и аутентификация
LOGGING_LEVEL_COM_DATAHUB_BACKEND_API_ERRORS	Обработка ошибок и исключений на уровне API
LOGGING_LEVEL_COM_DATAHUB_BACKEND_DB_REPOSITORY	JPA-репозитории, обращения к PostgreSQL на уровне приложения
LOGGING_LEVEL_COM_DATAHUB_BACKEND_DB_HEALTH	Проверки доступности БД (health-indicators)
LOGGING_LEVEL_COM_DATAHUB_BACKEND_NOTIFICATION	Email- и SMS-нотификации (отправка, шаблоны)
LOGGING_LEVEL_COM_DATAHUB_BACKEND_NOTIFICATION_RABBITMQ	Внутренняя постановка нотификаций в очередь
LOGGING_LEVEL_COM_DATAHUB_BACKEND_NOTIFICATION_SENDER	Низкоуровневые SMTP/SMS-вызовы
LOGGING_LEVEL_COM_DATAHUB_BACKEND_SERVICE	Бизнес-сервисы (логика обмена, маршрутизация на уровне бизнес-правил)
LOGGING_LEVEL_COM_DATAHUB_EXCHANGE	Подсистема обмена: работа с RabbitMQ, синхронизация топологии
LOGGING_LEVEL_ORG_SPRINGFRAMEWORK_AMQP	Spring AMQP — низкоуровневый AMQP-протокол
LOGGING_LEVEL_ORG_HIBERNATE_SQL	SQL-запросы Hibernate (полные тексты запросов)
LOGGING_LEVEL_ORG_HIBERNATE_TYPE_DESCRIPTOR_SQL_BASICBINDER	Параметры биндинга в SQL-запросы (значения переменных)
LOGGING_LEVEL_ORG_SPRINGFRAMEWORK_WEB	Spring MVC — обработка HTTP-запросов на уровне фреймворка

DEBUG/TRACE на production

Уровни DEBUG и TRACE существенно увеличивают объём логов и могут раскрывать чувствительные данные (значения параметров запросов, SQL-параметры с данными). Включайте только на время диагностики, после — возвращайте INFO. Особенно осторожно с LOGGING_LEVEL_ORG_HIBERNATE_TYPE_DESCRIPTOR_SQL_BASICBINDER — он показывает значения, передаваемые в SQL.

Запуск и проверка

После генерации секретов и заполнения .env:

cd /etc/datahub/backend
sudo docker compose up -d

Просмотр лога старта (дождаться сообщения Started BackendApplication in X seconds):

sudo docker logs -f --tail 200 backend

Проверка healthcheck. Прямого доступа к порту backend с хоста нет (expose: 80 без ports: — порт виден только внутри dh_network). Два рабочих способа:

Изнутри контейнера (работает даже когда nginx ещё не настроен):

sudo docker exec backend curl -fsS http://localhost/api/actuator/health

Снаружи через nginx (production-проверка, требует поднятого nginx с TLS):

curl -fkS https://lk.<your-domain>/api/actuator/health

Оба должны вернуть JSON с "status":"UP".

Что дальше

• Frontend — следующий по порядку запуска блок.
• Настройка безопасности — выпуск TLS, mTLS, политика паролей, rate-limiting, ротация секретов.
• Настройка уведомлений — детали SMTP и SMS.
• Архитектура / Архитектура сервиса — внутреннее устройство backend (controller/service/repository, обработка очередей).
• Архитектура / Транспортный API — REST-эндпоинты, через которые работают подключённые системы.