Приложение Г. Реестр сервисов и компонентов¶

Реестр фиксирует состав Docker Compose-сервисов решения BOX5-DIT-MGSN для продуктового контура.

В состав продуктового контура решения входят 9 compose-доменов и 96 уникальных сервисов и компонентов. Отдельный compose-проект jmeter-script относится к нагрузочным проверкам и в состав решения не включается.

Группы сервисов¶

Группа	Compose-проект	Назначение	Уникальных сервисов
Пользовательский интерфейс	`ui-rest`	Web UI, внешний Nginx и REST-to-gRPC шлюз	3
Статистика и события	`statistics`	авторизация, камеры, события, отчёты и аудит	30
Инференс	`inference`	NRI runtime, медиасервер, балансировка камер, мониторинг, хранилище изображений	17
Расширенное управление инференсом	`extended-inference`	управление версиями сценариев и резервированием GPU-ресурсов	3
Интеграционный контур с системами заказчика	`severstal`	АСУ ТП, NiFi, оргструктура, сценарии, активы, запуски, реестры моделей	25
Событийная шина	`kafka-domain`	основной Kafka-брокер решения	1
Хранилище данных	`data-storage`	временное хранилище данных, MinIO и доменный шлюз	4
Наблюдаемость	`elk-log`	Prometheus, Loki	2
Песочница Node-RED	`node-red-sandbox`	изолированная среда разработки и проверки NRI-сценариев	11

Основной пользовательский поток проходит через ui-rest к доменам statistics, severstal и inference. Сервисные события передаются через kafka-domain; общие файлы и объектные данные размещаются в data-storage; метрики и логи собираются в elk-log. Домен node-red-sandbox используется как отдельный контур подготовки NRI-сценариев перед переносом в основной инференс.

Реестр по доменам¶

`ui-rest`¶

Назначение: внешний слой решения, web-интерфейс и gateway для вызовов внутренних сервисов.

`ui-react`¶

Поле	Описание
Название сервиса	`ui-react` (`box-ui/box-react-ui`)
Назначение	Статический React SPA-интерфейс BOX5-DIT-MGSN для пользователей. Сервис отдаёт HTML/CSS/JS и локальные статические ресурсы; backend/gateway-функции выполняет не он, а `ui-rest-to-gprc` за внешним `ui-nginx`.
Подсистема	`ui-rest`, домен `ui`. Работает за `ui-nginx` вместе с API-шлюзом `ui-rest-to-gprc`.
Основные функции	Загружает основное SPA-приложение; отдаёт статические бандлы, favicon и manifest; поддерживает fallback на `index.html` для клиентской маршрутизации; отдаёт статический раздел `/docs/`. В функциональном составе React UI отвечает за экраны входа, список и формы камер/объектов, карточки мониторинга с видеооверлеем, настройку пресетов, ленту и карточку нарушений.
Входящие вызовы	Основной входящий поток: `ui-nginx` проксирует HTTP-запросы корневого UI на `ui-react:8000`. В конфигурации продуктового контура контейнер не публикует host-порты, а внешний `/login` доступен через `ui-nginx`.
Исходящие вызовы	Сам контейнер не выполняет runtime-вызовы в PostgreSQL, Redis, Kafka, gRPC или HTTP API других сервисов. После загрузки SPA браузер вызывает same-origin пути `/api/` и `/api/ws/` через `ui-nginx` к `ui-rest-to-gprc`, а также получает статическую конфигурацию и брендинг у внешнего `ui-nginx` (`/config.json`, `/settings.json`, `/logo/`).
Протоколы	Внутри Docker-сети активен HTTP на `8000`; образ также экспонирует `80/tcp`, compose-конфигурация направляет `ui-nginx` на `8000`. Внешний HTTP/HTTPS, REST и WebSocket относятся к связке браузер -> `ui-nginx` -> `ui-rest-to-gprc`, а не к серверной части `ui-react`.
Хранилища	Серверные БД, кэш и persistent volume у сервиса не используются. Статические файлы приложения находятся в образе в `/react/build`, статический раздел документации — в `/react/docs`. Токены авторизации после входа хранятся клиентским кодом на стороне браузера.
Конфигурация	В compose используется образ `docker.vizorlabs.ru/box-ui/box-react-ui:${BOX_UI_VERSION}`; в конфигурации продуктового контура используется тег `severstal-14.05.2026`. Активный nginx-конфиг внутри контейнера — `/etc/nginx/conf.d/nginx.conf`: `listen 8000`, `root /react/build/`, `try_files $uri $uri/ /index.html`, отдельный alias `/docs/`. Bind mounts у контейнера не предусмотрены; service spec фиксирует только базовые переменные Nginx-образа (`NGINX_VERSION`, `NJS_VERSION`, `PKG_RELEASE`, `PATH`).
Логирование	Nginx `access.log` направлен в `/dev/stdout`, `error.log` — в `/dev/stderr`; в конфигурации продуктового контура для контейнера настроен Docker log driver `loki` с ротацией. Отдельные логи frontend-приложения на стороне контейнера не ведутся.
Мониторинг	Docker healthcheck не задан, endpoint метрик не предусмотрен. Практический контроль — состояние контейнера `ui-rest-ui-react-1`, доступность внутреннего `http://127.0.0.1:8000/` из контейнера и внешняя доступность UI через `ui-nginx`.
Критичность	Высокая для работы пользователей: при отказе сервиса web-приложение не загружается или теряет статические assets. При этом API-шлюз и backend-сервисы могут оставаться работоспособными независимо от `ui-react`.
Эксплуатационные особенности и известные ограничения	Сервис выполняет только выдачу статического SPA и не содержит собственного backend-кода, server-side API, healthcheck, метрик и постоянного хранилища. Маршруты `/api/*`, websocket-обновления и выдача `/config.json` относятся к зоне ответственности `ui-nginx` и `ui-rest-to-gprc`.

`ui-rest-to-gprc`¶

Поле	Описание
Название сервиса	`ui-rest-to-gprc`
Назначение	Основной API-шлюз web-интерфейса BOX5-DIT-MGSN: принимает запросы от браузера через `ui-nginx` и адаптирует их к внутренним gRPC/HTTP-сервисам, Kafka и вспомогательным хранилищам.
Подсистема	`ui-rest`, домен `ui`. Находится между `ui-react`/`ui-nginx` и доменами `statistics`, `inference`, `data-storage` и предметными сервисами `severstal`.
Основные функции	Отдаёт REST API под `/api/*`; публикует GraphQL endpoint `/api/graphql`; поддерживает WebSocket endpoint `/api/ws/`; выполняет локальную проверку JWT для защищённых маршрутов; проксирует операции авторизации, камер, событий, аудита, отчётов, инференса, временных файлов и customer-domain маршрутов `severstal`.
Входящие вызовы	Основной источник — `ui-nginx`, который проксирует запросы web UI. Входящие поверхности: REST `/api/*`, GraphQL `/api/graphql`, WebSocket `/api/ws/`, служебный ping `/api/base/ping/`, маршруты синхронизации с заголовком `sync-key` и optional customer-domain деревья из `CUSTOM_DOMAINS`. В конфигурации продуктового контура публичный `GET /api/base/ping/` возвращает `{"result":"pong"}`.
Исходящие вызовы	gRPC/HTTP к сервисам статистики и событий (`st-auth`, `st-audit`, `st-camera-storage`, `st-event-storage`, `st-event-statistic`, `st-report-`, `st-comments` и др.); gRPC/HTTP к inference/media/storage сервисам (`inf-load-balancer`, `inf-monitoring`, `inf-flows-manager`, `ds-data-temporary-storage`); customer-domain вызовы к `svr-`; Kafka produce/consume для аудита и WebSocket-уведомлений; прямые обращения к ClickHouse, MinIO/S3 и Consul KV.
Протоколы	Входящие: HTTP/REST FastAPI, GraphQL, WebSocket. Исходящие: HTTP/gRPC, HTTP/REST, Kafka, ClickHouse client, S3 API, Consul HTTP API. Базовый HTTP-порт сервиса — `8000`; в конфигурации продуктового контура контейнер `ui-rest-ui-rest-to-gprc-1` в compose-проекте `ui-rest` экспонирует `3000/tcp` за `ui-nginx`.
Хранилища	Собственной БД нет. Использует локальные файлы `config/config.json` и `config/config.json.demo` для gateway/UI-config; читает и пишет Consul KV `ui-config/config`; напрямую читает ClickHouse `st-event-storage-clickhouse` и `st-event-statistic-clickhouse`; загружает файлы в MinIO/S3 `ds-minio`.
Конфигурация	Ключевые группы переменных: режим и порт (`PORT`, `SETTINGS_FILE`, `DEBUG`), аутентификация (`JWT_SECRET`, `JWT_REFRESH_SECRET`, `DISABLE_AUTH`, `AUTH_ROLE_`), синхронизация (`SYNC_KEY`), включение customer-domain маршрутов (`CUSTOM_DOMAINS`), endpoint-переменные внутренних сервисов, `KAFKA_`, `EVENT_STORAGE_CH_`, `EVENT_STATISTIC_CH_` и `MINIO_*`. Значения параметров доступа в документации не приводятся.
Логирование	Приложение пишет runtime-логи в `stdout`/`stderr`, в конфигурации продуктового контура они доступны как Docker logs контейнера `ui-rest-ui-rest-to-gprc-1`. Дополнительно пользовательские действия и часть gateway-событий отправляются как audit-сообщения в Kafka topic `KAFKA_TOPIC_ADD_AUDIT_RECORD`. Отдельный файловый лог не ведётся.
Мониторинг	Базовая проверка живости — `GET /api/base/ping/`. В конфигурации продуктового контура Docker healthcheck у контейнера не задан, `RestartCount=0`. Отдельный `/metrics` endpoint в текущей спецификации не предусмотрен; состояние также косвенно видно по WebSocket/Kafka событиям и доступности upstream-сервисов.
Критичность	Высокая. Отказ сервиса блокирует основную browser-facing API поверхность, GraphQL, WebSocket-уведомления и большинство пользовательских действий в UI; при этом уже запущенные backend/inference процессы могут продолжить работу без интерактивного управления через web-интерфейс.
Эксплуатационные особенности и известные ограничения	Сервис имеет широкий радиус отказа и зависит от большого числа downstream сервисов. Несовпадение `JWT_SECRET` с `st-auth` ломает проверку токенов в gateway; недоступность Kafka ухудшает audit и WebSocket-прогресс даже при работоспособных синхронных REST/gRPC вызовах. Набор customer-domain маршрутов зависит от `CUSTOM_DOMAINS` и версий соответствующих `svr-*` сервисов. Sync ingress маршруты используют общий `sync-key`, а не bearer JWT. Собственный Docker healthcheck и `/metrics` endpoint не предусмотрены.

`ui-nginx`¶

Поле	Описание
Название сервиса	`ui-nginx`
Назначение	Внешний Nginx edge для web-интерфейса BOX5-DIT-MGSN: публикует SPA `ui-react`, проксирует браузерные API/WebSocket-запросы к `ui-rest-to-gprc` и отдаёт статические конфигурационные файлы UI.
Подсистема	`ui-rest`; относится к домену `ui`. В конфигурации продуктового контура развёрнут compose-сервисом `ui-nginx` в проекте `ui-rest`.
Основные функции	Reverse proxy для `/` в `ui-react:8000`; проксирование `/api` и `/api/ws/` в `ui-rest-to-gprc:8000`; отдача `/config.json`, `/settings.json` и `/logo/` из `/config`; публикация файловых маршрутов `/files/`, `/vc-videos/`, `/DATA/`; проксирование MinIO-маршрутов `/api/s3*`; проксирование дополнительных UI-разделов контура.
Входящие вызовы	HTTP-запросы браузеров пользователей к опубликованному UI. Сервис является edge для портов `80` и `443`; в конфигурации продуктового контура контейнер публикует `80` и `443`, а активная конфигурация Nginx слушает `80` (`443 ssl` закомментирован).
Исходящие вызовы	HTTP к `ui-react:8000`, `ui-rest-to-gprc:8000`, `ds-minio:9000`; в конфигурации продуктового контура также настроен прокси `/sandbox/` на контур `node-red-sandbox-nginx`.
Протоколы	HTTP reverse proxy; WebSocket upgrade для `/api/ws/`; отдача статических файлов через Nginx. TLS-терминация предусмотрена edge-контрактом, но в конфигурации продуктового контура активные `listen`-директивы без `ssl`.
Хранилища	Собственная БД, Redis, Kafka и объектное хранилище не используются. Контейнер работает с bind mount: `/config`, `/files`, `/vc_videos`, `/DATA`, `/etc/letsencrypt`, `/etc/nginx/htpasswd`, `/etc/nginx/conf.d/default.conf`. MinIO используется как проксируемый upstream, а не как прямое хранилище `ui-nginx`.
Конфигурация	Образ `docker.vizorlabs.ru/box-ui/nginx-entrypoint:master`. Рабочий контракт задаётся смонтированным `/etc/nginx/conf.d/default.conf`; он переопределяет fallback-конфигурацию из образа. Контейнер подключён к сети `bx_default`, restart policy `always`; Docker healthcheck не задан.
Логирование	Стандартные access/error логи Nginx: `/var/log/nginx/access.log` и `/var/log/nginx/error.log`; в конфигурации продуктового контура читаются через `docker logs ui-rest-ui-nginx-1`. В access-логах фиксируются HTTP-метод, путь, код ответа и user agent; ошибки upstream видны как записи error log и HTTP `502`.
Мониторинг	Собственные `/metrics` и Docker healthcheck не предусмотрены. Базовая эксплуатационная проверка: контейнер `Up`, доступность `GET /login`, `GET /config.json` и `/api/base/ping/`; в конфигурации продуктового контура эти запросы вернули успешные ответы.
Критичность	Высокая. Отказ `ui-nginx` блокирует доступ пользователей к web-интерфейсу, браузерным API/WebSocket, статической конфигурации UI и файловым маршрутам, хотя внутренние backend-сервисы могут продолжать работать.
Эксплуатационные особенности и известные ограничения	Фактические маршруты зависят от смонтированного Nginx-конфига конкретного контура, поэтому образ сам по себе не описывает runtime-контракт. В конфигурации продуктового контура порт `443` опубликован Docker Compose, но `listen 443 ssl` в конфигурации закомментирован. Нет собственного healthcheck и метрик. Доступ к `/DATA/` зависит от корректного файла `/etc/nginx/htpasswd`; содержимое файла в документации не раскрывается.

`statistics`¶

Назначение: домен прикладных данных, событий, отчётности, аудита и аналитических представлений.

`st-auth`¶

Поле	Описание
Название сервиса	`st-auth`
Назначение	Сервис управления пользователями, ролями и аутентификацией домена статистики. Хранит пользователей типов `NATIVE`, `KEYCLOAK` и `AD`, историю входов, настройки политики паролей и выпускает локальные JWT access/refresh-токены.
Подсистема	`statistics`; в конфигурации продуктового контура запущен как контейнер `statistics-st-auth-1`.
Основные функции	CRUD и поиск пользователей; вход пользователя и обновление токенов; вход через Keycloak/OpenID Connect по authorization code; сброс и смена пароля для локальных пользователей; управление политикой паролей; управление ролями; выдача истории входов; необязательная синхронизация пользователей из Active Directory; публикация изменений пользователей в Kafka.
Входящие вызовы	HTTP/gRPC на порту `3000`, путь `/grpc/box.statistic.auth.Auth/<Method>`; `GET /metrics` для Prometheus. Фактический образ в конфигурации продуктового контура содержит методы `GetKeyCloakInfo` и `LoginKeyCloak`; browser-facing REST-маршруты `/api/statistics/auth/keycloak/info/` и `/api/statistics/auth/keycloak/login/` проксируются через `ui-rest-to-gprc`. Прямые клиенты также включают `st-audit`, `st-auth-report-pdf-xlsx-generator` и `st-report-pdf-xlsx-generator`.
Исходящие вызовы	PostgreSQL `st-auth-postgres:5432`; Redis `st-auth-redis:6379` для startup-координации и блокировки создания superuser; Kafka `inf-kafka:9092` с топиками `statistic_register_user`, `statistic_update_user`, `statistic_delete_user`; Keycloak/OpenID Connect при включённом `OPEN_ID_ENABLE`; LDAP/Active Directory при включённой AD-интеграции; SMTP при сценарии сброса пароля.
Протоколы	HTTP/gRPC, Prometheus text exposition, PostgreSQL, Redis, Kafka, OpenID Connect/OAuth2 authorization code, LDAP/AD, SMTP; JWT подписывается локально сервисом.
Хранилища	Основное состояние хранится в PostgreSQL БД `auth`: пользователи типов `NATIVE`, `KEYCLOAK` и `AD`, роли, домены AD при включённой AD-интеграции, история входов, постоянные login-токены, политика и история паролей, состояние Aerich-миграций. Redis не используется как session store для JWT.
Конфигурация	В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `DEPENDS=["inf-kafka:9092", "st-auth-postgres:5432"]`, `POSTGRES_HOST=st-auth-postgres`, `POSTGRES_DATABASE=auth`, `POSTGRES_USER=auth`, `REDIS_HOST=st-auth-redis`, `KAFKA_HOST=inf-kafka:9092`, `AD_DO_USERS_LOAD=False`, `OPEN_ID_ENABLE=false`, `OPEN_ID_TEST=true`; в БД есть агрегированные типы пользователей `NATIVE`, `KEYCLOAK` и `AD`. Ключевые группы параметров: `POSTGRES_`, `REDIS_`, `KAFKA_`, `JWT_`, `PASSWORD_`, `SU_`, `OPEN_ID_`, `AD_`, `SMTP_*`.
Логирование	Логи пишутся в `stdout`/`stderr` через приложение и Uvicorn; в конфигурации продуктового контура доступны через Docker logs контейнера `statistics-st-auth-1`. В логах фиксируются gRPC-метод, время обработки, HTTP-метод, путь и код ответа. Отдельный файловый лог в текущей конфигурации не предусмотрен.
Мониторинг	`GET /metrics` на порту `3000` возвращает метрики запросов, трафика, длительности, ошибок, CPU, памяти и uptime. В конфигурации продуктового контура контейнер имеет состояние `running`, Docker healthcheck для него не задан.
Критичность	Высокая. Отказ блокирует вход пользователей, обновление токенов и администрирование пользователей/ролей; потребители Kafka не получают изменения учётных записей. Уже выпущенные access-токены остаются stateless JWT до истечения срока действия.
Эксплуатационные особенности и известные ограничения	В текущем compose `DEPENDS` не проверяет доступность Redis, хотя сервис использует Redis при bootstrap superuser. Redis не хранит серверные сессии и не позволяет централизованно отозвать уже выданные JWT. Сброс пароля через сервис относится к локальным пользователям; AD-пользователи меняют пароль во внешнем каталоге. Keycloak/OpenID-контур включается отдельно через `OPEN_ID_ENABLE`; в конфигурации продуктового контура внешний провайдер не активирован, а `OPEN_ID_TEST управляет режимом симуляции входа. Docker healthcheck не задан.

`st-auth-postgres`¶

Поле	Описание
Название сервиса	`st-auth-postgres`
Назначение	PostgreSQL-хранилище сервиса `st-auth`: источник данных по пользователям, ролям, истории входов, типам пользователей `NATIVE`/`KEYCLOAK`/`AD`, доменам AD, токенам постоянного входа, политикам и истории паролей.
Подсистема	`statistics`, контур авторизации.
Основные функции	Хранение схемы `st-auth`; приём SQL-запросов и миграций от `st-auth`; предоставление данных для резервного копирования через `st-auth-postgres-backup`.
Входящие вызовы	`st-auth` подключается по PostgreSQL для миграций, CRUD пользователей, входа и токенов; `st-auth-postgres-backup` выполняет `pg_dump`.
Исходящие вызовы	Прикладных сетевых вызовов нет; контейнер только записывает состояние PostgreSQL в подключённый `PGDATA`.
Протоколы	PostgreSQL wire protocol, TCP `5432` во внутренней compose-сети. В конфигурации продуктового контура порт наружу не опубликован. HTTP, REST, gRPC и Kafka интерфейсов у контейнера нет.
Хранилища	Данные PostgreSQL в `PGDATA`; в спецификации указан bind mount `${COMPOSE_DATA}/statistics/st-auth-postgres` на `/var/lib/postgresql/data`.
Конфигурация	Переменные `POSTGRES_DB`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `PGDATA`; в конфигурации продуктового контура используется образ `docker.vizorlabs.ru/vizorlabs/postgres:13.1`.
Логирование	Штатные логи PostgreSQL в stdout/stderr контейнера; отдельного прикладного логирования у sidecar нет.
Мониторинг	Отдельные health/API endpoint не предусмотрены; базовая проверка — наличие контейнера и доступность TCP `5432` для `st-auth`.
Критичность	Высокая: отказ блокирует вход пользователей, работу ролей, Keycloak/OpenID-login, refresh/permanent-login токены, историю входов, AD-синхронизацию и операции `st-auth`, завязанные на БД.
Эксплуатационные особенности и известные ограничения	Схемой и миграциями управляет `st-auth` через Aerich; сам контейнер не содержит бизнес-логики и не предоставляет публичный API.

`st-auth-postgres-backup`¶

Поле	Описание
Название сервиса	`st-auth-postgres-backup`
Назначение	Вспомогательный контейнер резервного копирования PostgreSQL-базы сервиса `st-auth`. Выполняет регламентный `pg_dump` и сохраняет сжатые архивы в смонтированный каталог `/backup`.
Подсистема	`statistics`; сервисный helper рядом с `st-auth` и `st-auth-postgres`.
Основные функции	Ожидает доступность `st-auth-postgres`; запускает `pg_dump` по расписанию через `go-crond`; создаёт архивы `*.psql.gz`; обновляет ссылку `latest.psql.gz`; удаляет старые архивы по лимиту `MAX_BACKUPS`. Образ также поддерживает ручные режимы `make_backup` и `restore <archive>`, но это не публичный API.
Входящие вызовы	Сетевых входящих вызовов нет: HTTP, gRPC и Kafka API не предоставляются, порты не опубликованы. Входной контракт ограничен командой контейнера (`service`, `make_backup`, `restore <archive>`) и переменными окружения.
Исходящие вызовы	TCP-проверка доступности `PG_HOST:PG_PORT`; PostgreSQL-клиентские подключения к `st-auth-postgres:5432` для `pg_dump`. В режиме восстановления дополнительно выполняются `dropdb`, `createdb` и `psql` к той же БД.
Протоколы	PostgreSQL wire protocol к целевой БД; локальный cron внутри контейнера. Сетевой API и опубликованные Docker-порты отсутствуют.
Хранилища	Собственной БД нет. Источник данных - `st-auth-postgres`. Результаты пишутся в `/backup`; в конфигурации продуктового контура это bind mount `/data/compose-data2-no-swarm/backups/st-auth`. Также монтируется `/etc/timezone`.
Конфигурация	Env-only конфигурация: `CRON_TIME`, `PG_HOST`, `PG_PORT`, `PG_DB`, `PG_USER`, параметр доступа `PG_PASS`, `MAX_BACKUPS`, `UID`, `GID`, `DEBUG`. В конфигурации продуктового контура контейнер запущен из `docker.vizorlabs.ru/deploy-utils/pg-backup:master`; в логах `go-crond` зафиксировано расписание `0 1 * * *`.
Логирование	Логи пишутся в `stdout`/`stderr` контейнера и доступны через Docker logs. В них фиксируются старт режима `service`, запуск `go-crond`, добавленное cron-задание, запуск `make_backup`, имя создаваемого архива и удаление старых архивов.
Мониторинг	Docker healthcheck, `/metrics` и сетевой health endpoint не заданы. Практические проверки: контейнер `statistics-st-auth-postgres-backup-1` в состоянии `Up`; наличие свежего `latest.psql.gz`; проверка gzip-целостности архива; контроль логов cron-заданий. Запись `Backup succeeded` подтверждает только завершение команды резервного копирования; пригодность дампа нужно проверять тестовым восстановлением или контрольным чтением архива.
Критичность	Средняя. Отказ helper-контейнера не останавливает авторизацию и работу `st-auth`, но снижает возможность восстановления БД авторизации после сбоя.
Эксплуатационные особенности и известные ограничения	Нет публичного API, healthcheck и метрик. При отсутствии долговечного mount `/backup` архивы теряются вместе с контейнером. `PG_PASS` обязателен. Режим `restore <archive>` разрушительный: пересоздаёт целевую БД и должен использоваться только как ручная операция восстановления. В текущем `deploy-utils/pg-backup` переменная `EXTRA_OPTS` описана, но не добавляется к фактическому `pg_dump`; сообщение `Backup succeeded` может быть недостоверным при ошибке `pg_dump`.

`st-auth-redis`¶

Поле	Описание
Название сервиса	`st-auth-redis`
Назначение	Redis 6 sidecar для `st-auth`; используется как координационное хранилище для distributed lock при bootstrap/reconciliation default superuser. Не является session store, refresh-token store или хранилищем политики паролей.
Подсистема	`statistics`, контур авторизации; в конфигурации продуктового контура запущен как контейнер `statistics-st-auth-redis-1`.
Основные функции	Принимает Redis-команды от `st-auth`; обслуживает логическую БД `db=0`; хранит краткоживущую lock-запись `auth` для стартовой задачи `st-auth`. Бизнес-логики и прикладных методов не содержит.
Входящие вызовы	Redis RESP/TCP на `6379` из внутренней compose-сети. Аудированный клиент - `st-auth` с `REDIS_HOST=st-auth-redis` и `REDIS_PORT=6379`. HTTP, gRPC, Kafka и публичный REST API отсутствуют.
Исходящие вызовы	Сервис-специфичных исходящих HTTP/Kafka/gRPC/SQL вызовов нет; контейнер только отвечает клиентам Redis в рамках входящего TCP-соединения и пишет состояние в локальный `/data`.
Протоколы	Redis RESP поверх TCP `6379`; stdout/stderr для логов контейнера. TLS, Redis ACL/password auth, Pub/Sub, streams и Lua-script контракт в текущей конфигурации не предусмотрен.
Хранилища	Docker volume на `/data`, объявленный базовым Redis-образом. Данные относятся к координационному состоянию и не являются источником истины: пользователи, роли, токены постоянного входа, история входов и парольные политики хранятся в `st-auth-postgres`.
Конфигурация	В compose для контейнера не предусмотрены runtime env overrides, кастомный `redis.conf`, command override или bind mount конфигурации. В конфигурации продуктового контура используется `docker.vizorlabs.ru/docker-images/redis-6:master`, внутри Redis `6.0.9`, `restart: always`, host-порт не опубликован.
Логирование	Штатные логи Redis пишутся в stdout/stderr и доступны через Docker logs контейнера. В конфигурации продуктового контура лог старта показывает режим `standalone`, порт `6379`, отсутствие пользовательского config file и готовность принимать подключения.
Мониторинг	Собственного HTTP endpoint, Prometheus-метрик и Docker healthcheck нет. Базовая проверка - состояние контейнера и Redis `PING`; в конфигурации продуктового контура Redis `PING` возвращает `PONG`.
Критичность	Средняя: отказ влияет на корректный старт или рестарт `st-auth` и блокировку создания/сверки default superuser. Проверка уже выпущенных JWT и хранение пользователей не зависят от Redis.
Эксплуатационные особенности и известные ограничения	Redis не включён в `DEPENDS` entrypoint-а `st-auth`, поэтому доступность проверяется только при обращении приложения. Нет публичного API, healthcheck, выделенных метрик, TLS/auth/ACL и кастомной конфигурации. Данные `/data` нельзя трактовать как долговременное бизнес-хранилище.

`st-auth-report-pdf-xlsx-generator`¶

Поле	Описание
Название сервиса	`st-auth-report-pdf-xlsx-generator`
Назначение	Генератор отчётов по истории авторизации пользователей. По запросу UI получает логи входов из `st-auth` и возвращает готовый PDF-документ или XLSX-файл для скачивания.
Подсистема	`statistics`; вспомогательный сервис отчётности auth-подсистемы в потоке `auth-login-history-to-report-download`.
Основные функции	Принимает фильтр периода, пользователей, часового пояса и языка; запрашивает отфильтрованные login logs в `st-auth`; локально форматирует время; собирает локализацию; рендерит PDF по HTML-шаблону через `pdfkit` и XLSX через `openpyxl`; отдаёт Prometheus-метрики.
Входящие вызовы	`HTTP/gRPC` на порту `3000`: `/grpc/box.statistic.auth_report_pdf_xlsx_generator.AuthReportPdfXlsxGenerator/<Method>`. Методы `GetLoginReportPDF` и `GetLoginReportXSLX` принимают `ReportFilters { timestamp_from, timestamp_to, users_ids[], timezone, language }` и возвращают `ReportDoc { mime_type, content }`. Известный внешний вызывающий сервис - `ui-rest-to-gprc`, который публикует REST-маршруты `POST /api/statistics/auth-report-pdf-xlsx-generator/login-report/pdf/` и `POST /api/statistics/auth-report-pdf-xlsx-generator/login-report/xlsx/`. Дополнительно доступен `GET /metrics`.
Исходящие вызовы	`HTTP/gRPC` к `st-auth` по адресу `AUTH`: `AuthClientAsync.GetUsersLoginLogs` с `LoginLogsFilters { ids[], timestamp_from, timestamp_to }`. Также читает локальные файлы шаблона и локализации из контейнера. Вызовов к PostgreSQL, Redis, Kafka или MinIO в текущем контракте не предусмотрено.
Протоколы	HTTP/gRPC для бизнес-API; HTTP text format для Prometheus `/metrics`; локальное чтение HTML/JSON-файлов; бинарная выдача PDF и XLSX внутри ответа gRPC.
Хранилища	Собственного постоянного хранилища нет. Источник данных - `st-auth` и его история входов. Локально используются файлы `app/usecases/templates/<LOGIN_PDF_TEMPLATE_NAME>`, `config/ui_config/config.json` и опциональный `translations/translations.json`.
Конфигурация	Основные переменные: `PORT` (по умолчанию `3000`), `SETTINGS_FILE`, `DEBUG`, `DEPENDS`, `AUTH`, `TIME_ZONE`, `LOGIN_PDF_TEMPLATE_NAME`, `LOGIN_XLSX_TITLE`. Локализация берётся из `LOCALIZATION.report.auth-report-pdf-xlsx-generator` в `config.json` с опциональным overlay из `translations.json`.
Логирование	Штатные логи приложения пишутся в `stdout`/`stderr` контейнера и доступны через Docker logs. В логах фиксируются ошибки чтения локализации/переводов и сбои выполнения запросов или рендеринга.
Мониторинг	Prometheus-метрики доступны по `GET /metrics` на порту `3000`; в конфигурации продуктового контура endpoint внутри контейнера отвечает `200 text/plain`. Дополнительные операционные проверки - статус контейнера и Docker logs.
Критичность	Средняя. Отказ сервиса не блокирует вход пользователей и работу `st-auth`, но блокирует выгрузку отчётов по истории авторизации из интерфейса.
Эксплуатационные особенности и известные ограничения	Сервис не хранит данные и зависит от доступности `st-auth`. PDF-рендеринг зависит от HTML-шаблона и наличия бинарей, используемых `pdfkit`/`wkhtmltopdf`, в образе. При отсутствии файлов локализации сервис логирует ошибку и использует встроенные в код fallback-подписи; `UI_LANG_UNSPECIFIED` нормализуется в английский язык. Для XLSX в текущем коде используется `mime_type=application/vnd.ms-excel`.

`st-access`¶

Поле	Описание
Название сервиса	`st-access`
Назначение	Сервис управления правами доступа пользователей к камерам и наблюдаемым объектам. Хранит простые выдачи и группы доступа, формирует плоский список привилегий пользователя и рассылает его другим сервисам статистики. Не выполняет вход пользователей и не выпускает JWT.
Подсистема	`statistics`, контур прикладных прав доступа; в конфигурации продуктового контура запущен как контейнер `statistics-st-access-1`.
Основные функции	Создание и удаление простых доступов; создание, изменение, получение и удаление групп доступа; массовая установка одинаковых доступов для нескольких пользователей; получение доступов пользователя и пользователей с доступом; очистка прав при удалении камер или наблюдаемых объектов; пересборка и публикация плоского списка привилегий.
Входящие вызовы	HTTP/gRPC на порту `3000`, путь `/grpc/box.statistic.audit.Access/<Method>`; основные методы: `CreateSimpleAccess`, `DeleteSimpleAccess`, `SetSameUserAccesses`, `GetSameUserAccesses`, `CreateGroup`, `UpdateGroup`, `DeleteGroup`, `GetGroup`, `GetGroupList`, `UserAccess`, `GetAccessedUsers`, `DeleteCamera`, `DeleteObjectObservation`, `FlushPrivileges`, `FlushDb`. Штатные прямые клиенты: `ui-rest-to-gprc`, `st-camera-storage`, `st-report-pdf-xlsx-generator`. Также потребляет Kafka-топики удаления камер и наблюдаемых объектов.
Исходящие вызовы	PostgreSQL `st-access-postgres:5432` для чтения и записи источника прав; Kafka `inf-kafka:9092` как producer в `statistic_access` с сообщениями `UserAccessList` после старта, изменений прав и cleanup-операций. Прямые исходящие HTTP/REST/gRPC вызовы не предусмотрены.
Протоколы	HTTP/gRPC, PostgreSQL wire protocol, Kafka, Prometheus text exposition для заявленного `/metrics`.
Хранилища	Основное состояние хранится в PostgreSQL БД `access`: `access_group`, `group_user`, `access_object`, `privilege`, `access_group_access_group`, `aerich`. Таблица `privilege` используется как плоский кэш прав, пересобираемый после изменений. У контейнера приложения в конфигурации продуктового контура постоянные mount не предусмотрены.
Конфигурация	Ключевые параметры: `SETTINGS_FILE`, `DEBUG`, `DEPENDS`, `POSTGRES_*`, `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_STATISTIC_ACCESS`, `KAFKA_TOPIC_STATISTIC_CAMERA_DEL`, `KAFKA_TOPIC_STATISTIC_OBJECT_OBSERVATION_DEL`, `PORT`. В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `DEBUG=false`, `DEPENDS=["st-access-postgres:5432", "inf-kafka:9092"]`, `POSTGRES_HOST=st-access-postgres`, `POSTGRES_USER=access`, `KAFKA_TOPIC_STATISTIC_ACCESS=statistic_access`; образ `docker.vizorlabs.ru/box3/box3-access:1.2.2-dev`.
Логирование	Логи приложения и Uvicorn пишутся в `stdout`/`stderr` контейнера и доступны через Docker logs. В логах фиксируются HTTP/gRPC-метод, путь, код ответа и исключения приложения; отдельный файловый лог в текущей конфигурации не предусмотрен.
Мониторинг	Docker healthcheck не задан, restart policy `always`. Заявлен endpoint `GET /metrics`, но в конфигурации продуктового контура он вернул `500` из-за `AttributeError: 'Access' object has no attribute 'GetPrometheusMetrics'`. Практические проверки: контейнер `Up`, gRPC `POST /grpc/box.statistic.audit.Access/UserAccess` отвечает `200`.
Критичность	Высокая. Отказ не блокирует саму аутентификацию в `st-auth`, но нарушает выдачу и актуализацию прав на камеры/объекты, фильтрацию уведомлений, отчётов и представлений по зонам ответственности.
Эксплуатационные особенности и известные ограничения	`CopyObjectAccesses` присутствует в классе сервиса, но в текущей реализации тело метода пустое. Поля вложенных групп есть в схеме и protobuf, однако текущие `CreateGroup`/`UpdateGroup` их не обрабатывают, а `GetGroup`/`GetGroupList` возвращают `group_ids=[]`. `SetSameUserAccesses` требует хотя бы один доступ типа `CAMERA`. В конфигурации продуктового контура `/metrics` неисправен; healthcheck отсутствует.

`st-access-postgres`¶

Поле	Описание
Название сервиса	`st-access-postgres`
Назначение	PostgreSQL-хранилище сервиса `st-access`: источник данных по группам доступа, членству пользователей в группах, правам на объекты, вычисленному кэшу привилегий и состоянию миграций Aerich.
Подсистема	`statistics`, контур управления доступом.
Основные функции	Хранение схемы `st-access`; приём SQL-запросов и миграций от `st-access`; предоставление данных для резервного копирования через `st-access-postgres-backup`.
Входящие вызовы	`st-access` подключается по PostgreSQL для миграций, CRUD групп и прав, запросов доступа и перестроения таблицы `privilege`; `st-access-postgres-backup` выполняет `pg_dump`.
Исходящие вызовы	Прикладных сетевых вызовов нет; контейнер только записывает состояние PostgreSQL, WAL и служебные файлы в подключённый `PGDATA`.
Протоколы	PostgreSQL wire protocol, TCP `5432` во внутренней compose-сети. В конфигурации продуктового контура порт наружу не опубликован. HTTP, REST, gRPC и Kafka интерфейсов у контейнера нет.
Хранилища	Данные PostgreSQL в `PGDATA`; в конфигурации продуктового контура bind mount `/data/compose-data2-no-swarm/statistics/st-access-postgres` подключён к `/var/lib/postgresql/data`. Основные таблицы: `access_group`, `group_user`, `access_object`, `privilege`, `aerich`, `access_group_access_group`.
Конфигурация	Переменные `POSTGRES_DB`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `PGDATA`; в конфигурации продуктового контура используется образ `docker.vizorlabs.ru/vizorlabs/postgres:13.1` с PostgreSQL `13.1`.
Логирование	Штатные логи PostgreSQL в stdout/stderr контейнера; отдельного прикладного логирования у sidecar нет.
Мониторинг	Отдельный healthcheck, `/metrics` и HTTP health endpoint не заданы. Практические проверки: контейнер `statistics-st-access-postgres-1` в состоянии `Up`, доступность TCP `5432` для `st-access`, успешное подключение к БД `access`.
Критичность	Высокая: отказ БД блокирует управление группами и правами, прямые запросы доступа, delete-sync очистку удалённых камер/объектов и публикацию актуальных `UserAccessList` через `st-access`.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без бизнес-логики и публичного API. Схемой и миграциями управляет `st-access`; таблица `privilege` является производным кэшем, а не нормализованным источником прав.

`st-access-postgres-backup`¶

Поле	Описание
Название сервиса	`st-access-postgres-backup`
Назначение	Вспомогательный контейнер резервного копирования PostgreSQL-базы сервиса `st-access`. Выполняет регламентный `pg_dump` и сохраняет сжатые дампы в смонтированный каталог `/backup`.
Подсистема	`statistics`; backup-helper рядом с `st-access` и `st-access-postgres`.
Основные функции	Ожидает доступность `st-access-postgres`; запускает `pg_dump` по расписанию через `go-crond`; создаёт архивы `*.psql.gz`; обновляет ссылку `latest.psql.gz`; удаляет старые архивы по лимиту `MAX_BACKUPS`. Образ также поддерживает ручные режимы `make_backup` и `restore <archive>`, но это не публичный API.
Входящие вызовы	Сетевых входящих вызовов нет: HTTP, gRPC и Kafka API не предоставляются, порты не опубликованы. Входной контракт ограничен командой контейнера (`service`, `make_backup`, `restore <archive>`) и переменными окружения.
Исходящие вызовы	TCP-проверка доступности `PG_HOST:PG_PORT`; PostgreSQL-клиентские подключения к `st-access-postgres:5432` для `pg_dump`. В режиме восстановления дополнительно выполняются `dropdb`, `createdb` и `psql` к той же БД.
Протоколы	PostgreSQL wire protocol к целевой БД; локальный cron внутри контейнера. Сетевой API и опубликованные Docker-порты отсутствуют.
Хранилища	Собственной БД нет. Источник данных - `st-access-postgres`. Результаты пишутся в `/backup`; в конфигурации продуктового контура это bind mount `/data/compose-data2-no-swarm/backups/st-access`. Также монтируется `/etc/timezone`.
Конфигурация	Env-only конфигурация: `CRON_TIME`, `PG_HOST`, `PG_PORT`, `PG_DB`, `PG_USER`, параметр доступа `PG_PASS`, `EXTRA_OPTS`, `MAX_BACKUPS`, `UID`, `GID`, `DEBUG`. В конфигурации продуктового контура контейнер запущен из `docker.vizorlabs.ru/deploy-utils/pg-backup:master`; в логах `go-crond` зафиксировано расписание `0 1 * * *`.
Логирование	Логи пишутся в `stdout`/`stderr` контейнера и доступны через Docker logs. В них фиксируются старт режима `service`, запуск `go-crond`, добавленное cron-задание, запуск `make_backup`, имя создаваемого архива и удаление старых архивов.
Мониторинг	Docker healthcheck, `/metrics` и сетевой health endpoint не заданы. Практические проверки: контейнер `statistics-st-access-postgres-backup-1` в состоянии `Up`; наличие свежего `latest.psql.gz`; проверка gzip-целостности архива; контроль логов cron-заданий. Запись `Backup succeeded` подтверждает только завершение команды резервного копирования; пригодность дампа нужно проверять тестовым восстановлением или контрольным чтением архива.
Критичность	Средняя. Отказ helper-контейнера не останавливает `st-access`, но снижает возможность восстановления БД прав доступа после сбоя.
Эксплуатационные особенности и известные ограничения	Нет публичного API, healthcheck и метрик. При отсутствии долговечного mount `/backup` архивы теряются вместе с контейнером. `PG_PASS` обязателен. Режим `restore <archive>` разрушительный: пересоздаёт целевую БД и должен использоваться только как ручная операция восстановления. В текущем `deploy-utils/pg-backup` переменная `EXTRA_OPTS` описана, но не добавляется к фактическому `pg_dump`; сообщение `Backup succeeded` может быть недостоверным при ошибке `pg_dump`.

`st-camera-storage`¶

Поле	Описание
Название сервиса	`st-camera-storage`
Назначение	Основной сервис учёта метаданных камер и наблюдаемых объектов BOX5-DIT-MGSN: хранит камеры, объекты, зоны, EX-зоны, пресеты категорий, теги и наборы камер, а также рассылает изменения топологии downstream-сервисам.
Подсистема	`statistics`, контур камер, объектов и топологии для инференса, мониторинга, событий и отчётности. В конфигурации продуктового контура запущен как контейнер `statistics-st-camera-storage-1`.
Основные функции	CRUD камер; CRUD наблюдаемых объектов и дерева объектов; управление зонами, EX-зонами, category presets, тегами и пользовательскими наборами камер; хранение ссылок на изображения объектов и карт; пересчёт object-tree агрегатов; публикация camera/object topology fan-out в Kafka; replay состояния после старта и после `models_storage_ready`.
Входящие вызовы	HTTP/gRPC на порту `3000`, путь `/grpc/box.statistic.camera_storage.CameraStorage/<Method>`; `GET /metrics`; Kafka command topics `statistic_cmd_camera_`, `statistic_cmd_object_observation*`, `models_storage_ready`. Из известных клиентов продуктового контура: `ui-rest-to-gprc`, `svr-models-registry`, `st-report-pdf-xlsx-generator`, `st-report-email`.
Исходящие вызовы	PostgreSQL `st-camera-storage-postgres`; MinIO/S3 `ds-minio` для изображений объектов и карт; Kafka publish в `statistic_camera_add/update/del`, `camera_add/update/del`, `statistic_statistic_object_observation_add`, `statistic_object_observation_update/del`; при включённом ClickHouse-зеркале — `st-event-storage-clickhouse`; при включённой синхронизации доступа — gRPC/HTTP к `st-access`.
Протоколы	HTTP/gRPC, Prometheus text exposition, Kafka, PostgreSQL wire protocol, S3/MinIO API, ClickHouse native TCP для lookup-зеркала.
Хранилища	Основное состояние — PostgreSQL `st-camera-storage-postgres`: камеры, наблюдаемые объекты, зоны, пресеты, связи object tree, теги, наборы камер, EX-зоны, модели и категории. Объектные файлы — bucket MinIO `camera-storage` с URL-префиксом `/api/s3/camera-storage/`. При `IS_USE_CLICKHOUSE=true` поддерживаются lookup-таблицы `object_tree_cameras`, `object_tree_types`, `camera_zones` в ClickHouse.
Конфигурация	Основные переменные: `PORT`, `SETTINGS_FILE`, `DEPENDS`, `POSTGRES_`, `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_`, `MINIO_`, `EVENT_STORAGE_CH_`, `CATEGORIES_SOURCE`, `EX_ZONES_FILE`, feature flags `IS_USE_CLICKHOUSE` и `IS_USE_ACCESS`. В конфигурации продуктового контура задан образ `docker.vizorlabs.ru/box-statistics/camera-storage:severstal-1.0.10-dev`; значения параметров доступа не фиксируются в документации.
Логирование	Приложение и Uvicorn пишут в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver — `loki`. В логах ожидаемы записи gRPC/Kafka/background-задач, миграций Aerich и ошибок rebuild/replay.
Мониторинг	`GET /metrics` на порту `3000` отдаёт Prometheus-метрики gRPC-методов и процесса; в конфигурации продуктового контура видны счётчики `GetCamera`, `UpdateCamera`, `GetCameraList`, `ObjectTree` и др. Docker healthcheck не задан, контейнер в конфигурации продуктового контура был `Up 4 days`, `RestartPolicy=always`.
Критичность	Высокая. Отказ блокирует изменение камер, объектов, зон и пресетов, а также Kafka fan-out топологии для инференса, мониторинга, событий, отчётов и синхронизации; уже запущенные потребители могут продолжить работу только на устаревшем локальном состоянии.
Эксплуатационные особенности и известные ограничения	Kafka-сбой может оставить изменения в PostgreSQL без своевременной доставки downstream-потребителям до replay; ClickHouse и `st-access` являются опциональными контурами и при недоступности дают устаревшие lookup/access-данные без остановки core CRUD; удаления камер и объектов мягкие (`is_deleted=true`); topic `statistic_statistic_object_observation_add` сохраняет дублированный префикс из текущего кода; Docker healthcheck отсутствует.

`st-camera-storage-postgres`¶

Поле	Описание
Название сервиса	`st-camera-storage-postgres`
Назначение	PostgreSQL-хранилище сервиса `st-camera-storage`: источник данных по камерам, наблюдаемым объектам, зонам, EX-зонам, пресетам категорий, дереву объектов, тегам, наборам камер, моделям инференса и состоянию миграций Aerich.
Подсистема	`statistics`, контур камер, объектов и топологии. Sidecar расположен рядом с `st-camera-storage` и обслуживает только его прикладную схему.
Основные функции	Хранение схемы `st-camera-storage`; приём SQL-запросов и Aerich-миграций от родительского сервиса; сохранение protobuf-снимков и служебных связей камер/объектов; предоставление данных для ручных или внешних процедур резервного копирования PostgreSQL.
Входящие вызовы	`st-camera-storage` подключается по PostgreSQL для миграций, CRUD камер, объектов, зон, пресетов, тегов и replay/bootstrap операций; read-only диагностические клиенты могут подключаться вручную из внутренней сети.
Исходящие вызовы	Прикладных сетевых вызовов нет. Контейнер не вызывает REST, gRPC, Kafka, MinIO или ClickHouse; он только записывает состояние PostgreSQL, WAL и служебные файлы в подключённый `PGDATA`.
Протоколы	PostgreSQL wire protocol, TCP `5432` во внутренней compose-сети. В конфигурации продуктового контура host-порты не опубликованы (`5432/tcp` только внутри Docker), HTTP, REST, gRPC и Kafka интерфейсов у контейнера нет.
Хранилища	Данные PostgreSQL в `PGDATA`; в конфигурации продуктового контура bind mount `/data/compose-data2-no-swarm/statistics/pgdata-camera-storage` подключён к `/var/lib/postgresql/data`. Основные семейства таблиц: `camera`, `object_observation`, `object_tree`, `zone`, `zone_group`, `ex_zones`, `camera_ex_zones`, `inference_model`, `inference_zone_config`, таблицы primary/secondary categories и переводов, `categories_presets`, `preset_*_categories`, `camera_categories_presets`, `camera_tags`, `camera_tags_camera`, `cameras_set`, `camera_location_info`, `object_observation_location_info`, `cameras_access`, `aerich`.
Конфигурация	Env-only конфигурация стандартного PostgreSQL-образа: `POSTGRES_DB` (по спецификации `dnn`), `POSTGRES_USER` (по спецификации `dnn`), параметр доступа `POSTGRES_PASSWORD`, `PGDATA` (`/var/lib/postgresql/data`). В конфигурации продуктового контура запущен образ `docker.vizorlabs.ru/vizorlabs/postgres:13.1`, PostgreSQL `13.1`, `RestartPolicy=always`.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера; в конфигурации продуктового контура Docker log driver — `loki`. Отдельного прикладного логирования у sidecar нет, ошибки миграций и бизнес-операций нужно смотреть также в логах `st-camera-storage`.
Мониторинг	Docker healthcheck, `/metrics` и HTTP health endpoint не заданы. Практические проверки: контейнер `statistics-st-camera-storage-postgres-1` в состоянии `Up`, `pg_isready` внутри контейнера возвращает `accepting connections`, PostgreSQL `5432` доступен для `st-camera-storage`.
Критичность	Высокая. Отказ или потеря БД блокирует изменение камер, объектов, зон, пресетов, EX-зон и тегов, ломает bootstrap/replay топологии для downstream-сервисов и делает недоступной авторитетную карту связей камер, объектов, моделей и категорий.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без собственной бизнес-логики и публичного API. Схемой и миграциями управляет `st-camera-storage`; контейнер сам не валидирует доменные правила и не публикует события. Удаления камер и объектов реализуются на уровне приложения как soft delete, поэтому строки остаются в БД. Долговечность зависит от корректного bind mount `PGDATA` и внешних процедур резервного копирования.

`st-event-storage`¶

Поле	Описание
Название сервиса	`st-event-storage`
Назначение	Основное хранилище событий BOX5-DIT-MGSN: принимает события жизненного цикла, сохраняет метаданные и ссылки на медиа, отдаёт события UI, отчётам, синхронизации и интеграциям.
Подсистема	`statistics`; контур событий, нарушений, медиа-доказательств, статусов подтверждения и межконтуровой синхронизации. В конфигурации продуктового контура запущен как контейнер `statistics-st-event-storage-1`.
Основные функции	CRUD и поиск событий; мягкое удаление и восстановление; привязка видео, дополнительных изображений и proof-медиа; завершение события и обновление расширенных параметров; группировка событий; хранение статусов подтверждения и пользовательских полей; синхронизация моделей, камер, подразделений и персон; перенос медиа из временного хранилища в долговременный bucket MinIO; синхронизация PostgreSQL-записей с ClickHouse-зеркалом.
Входящие вызовы	HTTP/gRPC на порту `3000`, путь `/grpc/box.statistic.event_storage.EventStorage/<Method>`, лимит запроса до `50 MiB`; Kafka consumers из `inf-kafka` для событий, видео-вложений, proof/finish-обновлений, камер, моделей, подразделений и объединения персон; `GET /metrics` заявлен контрактом сервиса. Из известных клиентов продуктового контура: `ui-rest-to-gprc`, `st-report-pdf-xlsx-generator`, `st-report-email`, `inf-report-video-extractor`.
Исходящие вызовы	PostgreSQL `st-event-storage-postgres`; MinIO/S3 `ds-minio`; Kafka publish в lifecycle/topics после сохранения, изменения статусов, удаления и websocket fan-out; при включении ClickHouse — запись и пересинхронизация в `st-event-storage-clickhouse`; gRPC к `ds-data-temporary-storage` для получения временных медиа и к `st-event-statistic` для resync/backfill.
Протоколы	HTTP/gRPC, Kafka, PostgreSQL wire protocol, S3/MinIO API, ClickHouse native TCP при `USE_CLICKHOUSE=true`, Prometheus text exposition для `/metrics` по контракту.
Хранилища	Основное состояние — PostgreSQL `st-event-storage-postgres`: события, изображения, категории, камеры, настройки, custom params, группы событий и дополнительные метаданные. Медиа — bucket MinIO `event-storage` с URL-префиксом `/api/s3/event-storage/`. При `USE_CLICKHOUSE=true` поддерживается ClickHouse-зеркало для поиска, аналитики и resync staging.
Конфигурация	Основные переменные: `PORT`, `SETTINGS_FILE`, `DEPENDS`, `POSTGRES_`, `USE_CLICKHOUSE`, `CLICKHOUSE_`, `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_`, `MINIO_`, `DS_DATA_STORAGE_SERVICE`, `EVENT_STATISTICS_URL` и лимиты cleanup/grouping. В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `USE_CLICKHOUSE=True`, `MINIO_BUCKET=event-storage`, `MINIO_PREFIX=/api/s3/event-storage/`, входной topic `KAFKA_TOPIC_STATISTIC_CMD_ADD_EVENT=inference_send_event`; образ контейнера — `docker.vizorlabs.ru/box-statistics/event-storage:severstal-1.0.8-dev`. Значения параметров доступа `POSTGRES_` и `MINIO_` в документации не фиксируются.
Логирование	Приложение, Uvicorn, Kafka handlers, Aerich-миграции и фоновые cleanup/resync-задачи пишут в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver — `loki`. В логах видны gRPC-запросы, время обработки методов, успешное добавление видео к событию и периодические cleanup-сообщения.
Мониторинг	Docker healthcheck не задан; `RestartPolicy=always`. Контракт сервиса предусматривает `GET /metrics`, но в конфигурации продуктового контура запрос возвращает `500 Internal Server Error` из-за отсутствующего метода `GetPrometheusMetrics`, поэтому практический контроль: состояние контейнера, логи, доступность gRPC-методов, наличие записей в PostgreSQL/ClickHouse и объектов в MinIO.
Критичность	Высокая. Отказ блокирует сохранение новых нарушений, привязку медиа, работу карточек событий в UI, отчёты, уведомления, межконтуровую синхронизацию и downstream lifecycle-фан-аут. При отказе PostgreSQL запись событий останавливается; при отказе MinIO события могут сохраниться без части медиа; при отказе Kafka нарушается доставка downstream-уведомлений и обновлений.
Эксплуатационные особенности и известные ограничения	ClickHouse и backfill в `st-event-statistic` зависят от feature flags и фактической конфигурации контура. Полная синхронизация PostgreSQL→ClickHouse временно блокирует `AddEvent`. Websocket fan-out подавляется без свежего `websocket_heartbeat`. На текущих Box-контурах topic visualized video может не совпадать с потребителем `KAFKA_TOPIC_STATISTIC_CMD_ADD_VIDEO_EVENT`, поэтому отложенные визуализированные клипы требуют явного выравнивания topic или bridge. Legacy-переменные `INIT_EVENT_STORAGE_SIZE_SEC_DELAY`, `INIT_EVENT_STORAGE_SIZE_INTERVAL_SEC`, `EVENTS_STORING_DURATION_DAYS` текущим кодом не читаются; retention/cleanup управляются через `AppSettings`.

`st-event-storage-postgres`¶

Поле	Описание
Название сервиса	`st-event-storage-postgres`
Назначение	PostgreSQL sidecar для `st-event-storage`: реляционный источник данных по сохранённым событиям, ссылкам на медиа, состоянию проверки/группировки, пользовательским параметрам и зеркалам камер/категорий. Сам контейнер не реализует REST/API и не содержит бизнес-логики.
Подсистема	`statistics`, контур хранения событий. В конфигурации продуктового контура запущен как контейнер `statistics-st-event-storage-postgres-1` рядом с `st-event-storage` и `st-event-storage-clickhouse`.
Основные функции	Приём SQL-запросов и миграций от `st-event-storage`; хранение основных таблиц событий (`event`, `image`, `bbox`, `additionimage`, `additionvideo`, `eventproof`, `eventfinish`), объектной структуры события, данных нарушителей, моделей/категорий, камер, зон, журналов подтверждения, групп событий, кастомных параметров приложения и состояния Aerich. При `POSTGRES_CREATE_VIEWS=true` родительский сервис создаёт представления `event_full_data` и `event_view`.
Входящие вызовы	PostgreSQL-подключения на `5432` из внутренней compose-сети. Основной клиент - `st-event-storage`, который выполняет миграции, CRUD событий, cleanup, grouping и создание представлений. В конфигурации продуктового контура host-порт не опубликован.
Исходящие вызовы	Прикладных сетевых вызовов нет: контейнер PostgreSQL только отвечает SQL-клиентам и пишет состояние, WAL и служебные файлы в подключённый каталог `PGDATA`. Синхронизацию с ClickHouse, MinIO и Kafka выполняет `st-event-storage`, а не этот sidecar.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`; локальные файловые операции PostgreSQL в `PGDATA`; stdout/stderr для логов контейнера. HTTP, REST, gRPC, Kafka и S3-интерфейсов у контейнера нет.
Хранилища	Данные PostgreSQL в `PGDATA`; в конфигурации продуктового контура bind mount `/data/compose-data2-no-swarm/statistics/pgdata-event-storage` подключён к `/var/lib/postgresql/data`. Бинарные изображения и видео событий в этой БД не хранятся: в PostgreSQL остаются ссылки и метаданные, а сами объекты обслуживает MinIO через `st-event-storage`.
Конфигурация	Env-only конфигурация shared PostgreSQL image: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`. В конфигурации продуктового контура задан образ `docker.vizorlabs.ru/vizorlabs/postgres:13.1`, PostgreSQL `13.1`, `restart=always`, `shm_size=1g`; у `st-event-storage` заданы `POSTGRES_HOST=st-event-storage-postgres`, `POSTGRES_DATABASE=dnn`, `POSTGRES_CREATE_VIEWS=True`.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и доступны через Docker logs; в конфигурации продуктового контура Docker log driver - `loki`. Отдельного прикладного логирования у sidecar нет.
Мониторинг	Docker healthcheck, `/metrics` и HTTP health endpoint не заданы. Практические проверки: контейнер `statistics-st-event-storage-postgres-1` в состоянии `running`, порт `5432/tcp` доступен во внутренней сети для `st-event-storage`, SQL-подключение к БД `dnn` успешно, в схеме `public` присутствуют таблицы событий и представления `event_full_data`, `event_view`.
Критичность	Высокая. Отказ или потеря БД блокирует сохранение и чтение событий, подтверждение и восстановление событий, группировку, кастомные параметры, ретроспективные обновления данных и пересинхронизацию PostgreSQL-to-ClickHouse через `st-event-storage`.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без публичного API, бизнес-методов, метрик и healthcheck. Схемой, миграциями и представлениями управляет `st-event-storage`; сам образ не знает предметную модель событий. Рост БД зависит от retention событий, мягких удалений, журналов проверок и ссылок на медиа. Отдельный backup-helper для этой БД не предусмотрен, поэтому восстановление зависит от внешней политики резервного копирования deployment-а.

`st-event-storage-clickhouse`¶

Поле	Описание
Название сервиса	`st-event-storage-clickhouse`
Назначение	Общий ClickHouse-sidecar для событийного контура: хранит поисковое зеркало событий `st-event-storage`, временные таблицы полной синхронизации PostgreSQL -> ClickHouse, lookup-таблицы топологии от `st-camera-storage` и, при включении в конфигурации продуктового контура, исторические таблицы состояния камер от `inf-monitoring`. Сам контейнер является СУБД и не предоставляет прикладной REST/gRPC API.
Подсистема	`statistics`, контур хранения и быстрых выборок событий. В конфигурации продуктового контура развёрнут как контейнер `statistics-st-event-storage-clickhouse-1`; к нему также обращаются сервисы из `ui-rest` и `inference`.
Основные функции	Запускает ClickHouse Server; принимает SQL-запросы от прикладных сервисов; хранит таблицу `event` и служебную `schema_versions`; поддерживает PostgreSQL-engine bridge `pg_event_view` для resync; хранит lookup-таблицы `object_tree_cameras`, `object_tree_types`, `camera_zones`; в конфигурации продуктового контура также содержит `camera_states` и `camera_nri_state_heartbeats` для истории мониторинга. Создание схем, миграции, вставки, update/delete-mutations и пересинхронизацию выполняют клиентские сервисы, а не сам sidecar.
Входящие вызовы	ClickHouse native TCP на `9000` от `st-event-storage`, `st-camera-storage`, `inf-monitoring` и прямых читателей вроде `ui-rest-to-gprc`; ClickHouse HTTP на `8123` для `/ping` и стандартных инструментов ClickHouse. Опубликованных host-портов в конфигурации продуктового контура нет: в Docker видны только внутренние `8123/tcp`, `9000/tcp`, `9009/tcp`.
Исходящие вызовы	Прикладных исходящих сетевых вызовов нет: контейнер ожидает подключения клиентов и пишет данные в локальное хранилище ClickHouse. Связь с PostgreSQL, Kafka, MinIO и API других сервисов выполняют владельцы схем (`st-event-storage`, `st-camera-storage`, `inf-monitoring`, `ui-rest-to-gprc`).
Протоколы	ClickHouse native TCP, ClickHouse HTTP, межсерверный ClickHouse TCP `9009` внутри контейнерной сети. REST, gRPC и Kafka-контракты сервис не экспонирует.
Хранилища	Основное состояние хранится в `/var/lib/clickhouse`; в конфигурации продуктового контура этот путь смонтирован из `${COMPOSE_DATA}/statistics/event-storage-click-house-data/`. В базе `default` присутствуют таблицы `event`, `schema_versions`, `pg_event_view`, `object_tree_cameras`, `object_tree_types`, `camera_zones`, `camera_states`, `camera_nri_state_heartbeats`.
Конфигурация	В compose для контура указан образ `docker.vizorlabs.ru/docker-images/click-house:24.6.1`, `restart: always` и volume `/var/lib/clickhouse`. В service spec зафиксированы переменные `CLICKHOUSE_CONFIG`, `TZ`, `LANG`, `LANGUAGE`, `LC_ALL`; основной конфиг — `/etc/clickhouse-server/config.xml`, дополнительный фрагмент — `/etc/clickhouse-server/config.d/10-max_concurrent_queries.xml`. У `st-event-storage` в конфигурации продуктового контура включены `CLICKHOUSE_HOST=st-event-storage-clickhouse` и `USE_CLICKHOUSE=True`; `st-camera-storage` использует параметры `EVENT_STORAGE_CH_*`. Значения параметров доступа в документации не приводятся.
Логирование	ClickHouse пишет технологические логи в stdout/stderr контейнера и файловые логи `/var/log/clickhouse-server/clickhouse-server.log` и `.err.log` внутри контейнера; Docker log driver в конфигурации продуктового контура — `loki`. В Docker logs видны старт сервера, загрузка `config.xml` и подключение фрагментов `10-max_concurrent_queries.xml` и `docker_related_config.xml`.
Мониторинг	Docker healthcheck не задан. Практические проверки: контейнер `statistics-st-event-storage-clickhouse-1` в состоянии `Up`; `clickhouse-client` выполняет `SELECT 1`; HTTP `GET /ping` на `127.0.0.1:8123` возвращает `Ok.`; наличие ожидаемых таблиц контролируется через `system.tables`. Отдельный `/metrics` endpoint в текущей конфигурации не предусмотрен.
Критичность	Высокая для поиска и аналитических выборок по событиям: при отказе ClickHouse `st-event-storage` теряет быстрый поисковый контур и resync-зеркало, `ui-rest-to-gprc` не сможет читать прямые event/counter/statistics выборки из этой БД, а `st-camera-storage` и `inf-monitoring` не обновят свои ClickHouse-зеркала. PostgreSQL остаётся первичным хранилищем событий, поэтому часть записи и восстановления зависит от поведения клиентских сервисов и их feature flags.
Эксплуатационные особенности и известные ограничения	Это generic ClickHouse-образ без собственного прикладного API, без Docker healthcheck и без `/metrics`. Таблица `event` является eventually consistent зеркалом PostgreSQL: update/delete выполняются ClickHouse mutations и завершаются асинхронно. Полная resync-операция пересоздаёт bridge/staging-структуры и может временно влиять на доступность свежего зеркала. Lookup-таблицы `st-camera-storage` обновляются truncate/repopulate-подходом, поэтому прямые читатели могут кратко видеть пустое состояние. Потеря volume `/var/lib/clickhouse` требует восстановления зеркал от сервисов-владельцев схем.

`st-event-statistic`¶

Поле	Описание
Название сервиса	`st-event-statistic`
Назначение	Аналитическое зеркало событий нарушений: получает события и справочники из Kafka, денормализует их в ClickHouse и предоставляет служебные gRPC-методы для backfill и настроек хранения статистики.
Подсистема	`statistics`, контур событийной статистики и аналитических выборок. В конфигурации продуктового контура запущен как контейнер `statistics-st-event-statistic-1`.
Основные функции	Инициализация и миграции схемы ClickHouse; загрузка новых `ViolationEvent`; связывание message UUID со stored event id; обновление статусов, finish-времени и soft-delete признаков; синхронизация камер, объектов, персон, моделей, зон, категорий и переводов; пересборка переводов после обновления моделей; хранение настроек retention; периодическое обслуживание TTL системных логов ClickHouse.
Входящие вызовы	HTTP/gRPC на порту `3000`, путь `/grpc/box.statistic.event_statistics.EventStatistics/<Method>`; прямые методы `AddStoredViolationEvents`, `GetAppSettings`, `SetAppSettings`; `GET /metrics`; Kafka consumers в группе `KAFKA_GROUP` для топиков событий, lifecycle-обновлений, камер, объектов, моделей и персон. Прямые клиенты: `st-event-storage`, `ui-rest-to-gprc`.
Исходящие вызовы	ClickHouse `st-event-statistic-clickhouse` по native TCP: создание схемы, вставки, обновления, soft-delete, retention cleanup и lookup-запросы. Исходящие Kafka producers и исходящие gRPC/HTTP-клиенты в текущей спецификации сервиса не предусмотрены.
Протоколы	HTTP/gRPC, Prometheus text exposition, Kafka consumer protocol, ClickHouse native TCP. PostgreSQL напрямую не используется.
Хранилища	Основное состояние хранится в `st-event-statistic-clickhouse`: `schema_versions`, `settings`, `active_inference_model`, `zone`, `category`, `translation`, `camera`, `object`, `person`, `event`, `event_translation`. В конфигурации продуктового контура дополнительно присутствуют проектные таблицы и materialized-view контур: `event_finish`, `event_mv`, `event_severstal_data`, `kafka_event_queue`, `object_tree_departments`, `svr_cameras`, `svr_objects`, `work_zones`. Каноническое хранилище событий остаётся в `st-event-storage`; этот сервис ведёт аналитическую копию.
Конфигурация	Ключевые переменные: `SETTINGS_FILE`, `DEPENDS`, `CLICKHOUSE_HOST`, `CLICKHOUSE_PORT`, `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_`, `DISABLE_KAFKA`, `EVENTS_CLEANUP_STANDBY_INTERVAL_SEC`, `IS_CH_LOGS_CLEANUP_TASK_ENABLED`, `CH_LOGS_CLEANUP_TASK_START_HOUR`, `CH_LOGS_CLEANUP_TASK_START_MINUTE`, `TZ`. В конфигурации продуктового контура заданы env-ключи `SETTINGS_FILE`, `DEPENDS`, `CLICKHOUSE_HOST`, `KAFKA_HOST`, `KAFKA_GROUP` и набор `KAFKA_TOPIC_`; образ `docker.vizorlabs.ru/box-statistics/event-statistic:severstal`, порт `3000/tcp`, restart policy `always`. Значения параметров доступа не фиксируются.
Логирование	Приложение и HTTP-сервер пишут в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver — `loki`. В логах ожидаемы сообщения старта, ClickHouse-миграций, Kafka consumers, gRPC-запросов и фоновых cleanup-задач.
Мониторинг	`GET /metrics` на порту `3000` возвращает Prometheus-метрики запросов, трафика, длительности, ошибок, CPU, памяти и uptime; в конфигурации продуктового контура endpoint вернул HTTP `200`. Docker healthcheck не задан. Практические проверки: состояние контейнера `Up`, доступность `/metrics`, наличие ожидаемых ClickHouse-таблиц и Kafka consumer lag для группы сервиса.
Критичность	Высокая для статистики и отчётности по агрегированным событиям. Отказ не останавливает первичную запись событий в `st-event-storage`, но приводит к отставанию или пустым данным в аналитическом зеркале и блокирует операции backfill/настроек хранения.
Эксплуатационные особенности и известные ограничения	ClickHouse `ALTER UPDATE/DELETE` и retention-операции асинхронны, поэтому изменения статусов и удалений могут появляться в аналитике с задержкой. Kafka backlog напрямую даёт лаг статистики. Refresh моделей очищает и заново заполняет reference-таблицы перед пересчётом переводов. Docker healthcheck отсутствует. Корректность REST-маршрута настроек зависит от правильного endpoint `EVENT_STATISTICS` в `ui-rest-to-gprc`: в кодовых настройках сохранён исторический default `st-event-statistics`, тогда как Docker alias на контурах — `st-event-statistic`.

`st-event-statistic-clickhouse`¶

Поле	Описание
Название сервиса	`st-event-statistic-clickhouse`
Назначение	Stateful ClickHouse sidecar для статистики событий: хранит денормализованное зеркало нарушений, справочники и служебные таблицы, которые заполняет `st-event-statistic` и читают аналитические запросы. Это не самостоятельный REST API-сервис.
Подсистема	`statistics`, контур событийной статистики и legacy-аналитики. В конфигурации продуктового контура развёрнут compose-сервисом `st-event-statistic-clickhouse` в проекте `statistics`, контейнер `statistics-st-event-statistic-clickhouse-1`.
Основные функции	Принимает ClickHouse-подключения от `st-event-statistic`; хранит таблицы событий, переводов, камер, объектов, персон, зон, категорий, настроек и `schema_versions`; предоставляет стандартные ClickHouse HTTP/native/interserver интерфейсы для проверок и администрирования.
Входящие вызовы	ClickHouse native TCP `9000` от `st-event-statistic` для миграций, inserts/updates/deletes и чтения lookup-данных; ClickHouse HTTP `8123` для `wait-depends`/служебных проверок; interserver TCP `9009`, экспонированный образом. В конфигурации продуктового контура native-порт опубликован как `19000:9000`, HTTP и interserver host-портов не имеют.
Исходящие вызовы	Прикладных исходящих сетевых вызовов не предусмотрено: сервис выступает сервером ClickHouse, а создание схемы, мутации и чтение инициируют клиентские сервисы. Запись выполняется только в локальное ClickHouse-хранилище `/var/lib/clickhouse`.
Протоколы	ClickHouse native TCP, ClickHouse HTTP, ClickHouse interserver TCP, файловый ввод-вывод ClickHouse. REST/gRPC/Kafka API у самого sidecar не предусмотрены.
Хранилища	Основное состояние хранится в ClickHouse data directory `/var/lib/clickhouse`; в конфигурации продуктового контура смонтирован bind mount `/data/compose-data2-no-swarm/statistics/event-statistic-clickhouse-data`. Базовая схема включает `schema_versions`, `settings`, `active_inference_model`, `zone`, `category`, `translation`, `camera`, `object`, `person`, `event`, `event_translation`; в конфигурации продуктового контура дополнительно видны customer/project-specific таблицы и объекты `event_finish`, `event_mv`, `kafka_event_queue`, `event_severstal_data`, `svr_cameras`, `svr_objects`, `object_tree_departments`, `work_zones`.
Конфигурация	Для конфигурации продуктового контура закреплён тег `24.6.1`; в конфигурации продуктового контура запущен образ `docker.vizorlabs.ru/docker-images/click-house:24.6.1`, ClickHouse отвечает версией `24.6.1.4423`. Service spec фиксирует `CLICKHOUSE_CONFIG=/etc/clickhouse-server/config.xml`, `TZ`, `LANG`, `LANGUAGE`, `LC_ALL`; значения параметров доступа и полный env не выводились и не фиксируются.
Логирование	Стандартные логи ClickHouse пишутся в `stdout`/`stderr` контейнера; в конфигурации продуктового контура Docker log driver `loki`. При диагностике используются Docker logs контейнера и системные ClickHouse-таблицы/логи, но прикладные события формируются клиентами (`st-event-statistic`).
Мониторинг	Docker healthcheck не задан. Практические проверки: состояние контейнера, доступность ClickHouse native/HTTP, `clickhouse-client SELECT 1`, версия сервера и наличие ожидаемых таблиц. На момент проверки контейнер был `Up 4 days`, запрос `SELECT 1` вернул `1`.
Критичность	Высокая для статистики и аналитики событий. Отказ не останавливает приём событий во всём решении напрямую, но ломает запись/чтение денормализованной статистики `st-event-statistic`, агрегированные аналитические выборки.
Эксплуатационные особенности и известные ограничения	Схемой владеет `st-event-statistic`, поэтому сам sidecar не применяет бизнес-миграции и не валидирует контракт событий. Мутации ClickHouse `ALTER TABLE ... UPDATE/DELETE` асинхронны, из-за чего изменения статусов, удаления и retention-cleanup могут становиться видимыми с задержкой. Отдельный Docker healthcheck отсутствует; мониторинг должен проверять доступность ClickHouse и отставание клиентского ingester. В конфигурации продуктового контура есть project-specific таблицы, которые нельзя считать универсальным публичным API сервиса.

`st-report-email`¶

Поле	Описание
Название сервиса	`st-report-email`
Назначение	Сервис пользовательских настроек уведомлений и доставки отчётов по событиям BOX5-DIT-MGSN. Хранит подписки и расписания пользователей, зеркалирует пользователей, камеры, объекты наблюдения и доступы из Kafka, запрашивает готовые вложения у генератора отчётов и отправляет плановые или мгновенные уведомления по email и, при настройке токена, в Telegram.
Подсистема	`statistics`, контур отчётов и уведомлений по событиям. В конфигурации продуктового контура развёрнут как контейнер `statistics-st-report-email-1`; образ — `docker.vizorlabs.ru/box-statistics/report-email:1.1.4-dev`.
Основные функции	Управление настройками рассылки через legacy v1 и текущий v2 API с несколькими расписаниями; фоновый планировщик v2, который опрашивает `notification_setting.next_notif_date` и сдвигает расписание после попытки доставки; отправка контрольных сообщений; отправка документов и единичных событий; мгновенные уведомления по новым событиям, изменению решения и обновлению статуса; регистрация Telegram chat по `/start`; дедупликация мгновенных отправок; фильтрация отчётов по зеркалу доступных пользователю камер.
Входящие вызовы	HTTP/gRPC на порту `3000`, путь `/grpc/box.statistic.report_email.ReportEmail/<Method>`, лимит входящего сообщения до `50 MiB`; методы `SetNotificationInfo`, `GetNotificationInfo`, `SetNotificationInfo2`, `GetNotificationInfo2`, `TestSending`, `TestSendingTelegram`, `SendDocument`, `SendEventNotification`, `GetTelegramUsers`, `FlushDb`; `GET /metrics` для Prometheus-метрик. Kafka consumers в группе `report-email` читают из `inf-kafka` топики пользователей, камер, объектов наблюдения, access-list, новых событий, изменения решения и обновления статуса. UI-трафик текущей версии идёт через REST-фасад `ui-rest-to-gprc`, включая маршрут `/api/statistics/report-email/notification-info-2/`.
Исходящие вызовы	HTTP/gRPC к `st-report-pdf-xlsx-generator` по `REPORT_GENERATOR_HOST` для PDF/XLSX/DOCX вложений списочных и единичных отчётов; HTTP/gRPC к `st-event-storage` по `EVENT_STORAGE_HOST` для разрешения UUID и загрузки сохранённого события; SMTP к `SMTP_SERVER:SMTP_PORT` для email-канала; Telegram Bot API для регистрации чатов и отправки сообщений/документов; MinIO/S3 на `MINIO_ENDPOINT` только при `TELEGRAM_INSTANT_EVENT_IS_LIGHT=true`; PostgreSQL `st-report-email-postgres` для прикладного состояния. Исходящий Kafka producer в текущей конфигурации не предусмотрен.
Протоколы	HTTP/gRPC, Prometheus text exposition, Kafka consumer protocol, PostgreSQL wire protocol, SMTP/SMTPS/STARTTLS в зависимости от env, HTTPS Telegram Bot API, S3/MinIO API для облегчённых Telegram-уведомлений. В конфигурации продуктового контура host-порт не опубликован: Docker показывает только внутренний `3000/tcp`.
Хранилища	Основное состояние — PostgreSQL `st-report-email-postgres`: `object_observation`, `camera`, `auth_user`, `notification_object_user`, `notification_camera_user`, `user_camera_access`, `notification_setting`, `instant_notification_history`, `telegram_chat`, `aerich`. Файловые bind mount у контейнера приложения в конфигурации продуктового контура не предусмотрены; сам сервис не хранит сгенерированные файлы отчётов, а получает их от `st-report-pdf-xlsx-generator` перед отправкой.
Конфигурация	Ключевые переменные: `PORT`, `SETTINGS_FILE`, `DEBUG`, `DEPENDS`, `TIME_ZONE`, `NOTIFICATION_VERSION_API`, `IS_PROCESS_EVENT_ID_ENABLED`, `USER_CONFIRMATION_STATUSES_FOR_SEND`, `REPORT_GENERATOR_HOST`, `EVENT_STORAGE_HOST`, `REPORT_GENERATOR_PAGE_EVENT`, `REPORT_GENERATOR_PAGE_SIZE`, `DEFAULT_REPORT_FORMAT`, `INSTANT_EVENT_DELAY`, `POSTGRES_`, `SMTP_`, `WITH_SMTP_CREDENTIALS`, `EMAIL_SUBJECT`, `TEST_MESSAGE_TEXT`, `TELEGRAM_`, `MINIO_`, `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_`. В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `DEBUG=false`, `TIME_ZONE=Europe/Moscow`, `NOTIFICATION_VERSION_API=2`, `IS_PROCESS_EVENT_ID_ENABLED=true`, `REPORT_GENERATOR_PAGE_EVENT=1`, `REPORT_GENERATOR_PAGE_SIZE=1000`, `WITH_SMTP_CREDENTIALS=true`; значения паролей, токенов и учётных данных SMTP/MinIO не фиксировались.
Логирование	Приложение, gRPC/Uvicorn-обвязка, Aerich-миграции, Kafka consumers, планировщик рассылок и Telegram polling пишут в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver — `loki`. Отдельный файловый лог и bind mount для логов не используются.
Мониторинг	`GET /metrics` на внутреннем порту `3000` отдаёт Prometheus-метрики request count, request/response traffic, latency, errors, CPU, memory и uptime; в конфигурации продуктового контура endpoint внутри контейнера вернул HTTP `200 text/plain`. Docker healthcheck не задан, `RestartPolicy=always`. Практические проверки — состояние контейнера, доступность `/metrics`, логи Kafka consumers/планировщика и состояние таблиц `notification_setting`, `instant_notification_history`, `telegram_chat` в PostgreSQL.
Критичность	Средняя/высокая для пользовательских отчётов и уведомлений: отказ не останавливает сохранение событий в `st-event-storage`, но отключает плановые отчёты, мгновенные email/Telegram уведомления, контрольные отправки и управление подписками через UI. При недоступности PostgreSQL теряются чтение/запись расписаний и зеркал доступа; при недоступности `st-report-pdf-xlsx-generator` или SMTP/Telegram доставка вложений не выполняется.
Эксплуатационные особенности и известные ограничения	Сервис не рендерит отчёты сам и зависит от `st-report-pdf-xlsx-generator` и `st-event-storage` для вложений по событиям. В текущей конфигурации реализованы только каналы email и Telegram; `REPORT_CHANNEL_VK_TEAMS` есть в общих protobuf/UI схемах, но транспорт возвращает отрицательный статус. При `IS_PROCESS_EVENT_ID_ENABLED=false` сервис ждёт `INSTANT_EVENT_DELAY` перед чтением события из `st-event-storage` и пропускает доставку, если событие ещё не сохранено; в конфигурации продуктового контура включён режим `IS_PROCESS_EVENT_ID_ENABLED=true`. Внешний host-порт не публикуется, доступ предполагается из compose-сети и через `ui-rest-to-gprc`; Docker healthcheck отсутствует.

`st-report-email-postgres`¶

Поле	Описание
Название сервиса	`st-report-email-postgres`
Назначение	PostgreSQL sidecar для `st-report-email`: хранит локальное реляционное состояние сервиса уведомлений и рассылки отчётов. Сам контейнер не формирует отчёты, не отправляет письма/Telegram-сообщения и не предоставляет REST/gRPC/API.
Подсистема	`statistics`, контур уведомлений и регламентной/моментальной отправки отчётов. В конфигурации продуктового контура запущен как контейнер `statistics-st-report-email-postgres-1` рядом с `statistics-st-report-email-1`.
Основные функции	Запускает PostgreSQL; принимает SQL-запросы и миграции Aerich от `st-report-email`; хранит зеркала пользователей, камер, наблюдаемых объектов и доступов, legacy v1 настройки уведомлений, v2 расписания уведомлений, реестр Telegram-чатов и историю дедупликации моментальной отправки.
Входящие вызовы	PostgreSQL-подключения на `5432` из внутренней Docker-сети. Основной клиент — `st-report-email`, который выполняет миграции, читает и изменяет настройки рассылок, использует зеркала доступа и пишет delivery-state. В конфигурации продуктового контура host-порт не опубликован: Docker показывает только внутренний `5432/tcp`.
Исходящие вызовы	Прикладных сетевых вызовов нет. Контейнер не вызывает REST, gRPC, Kafka, SMTP, Telegram, MinIO или генератор отчётов; он только отвечает SQL-клиентам и пишет состояние PostgreSQL в подключённый `PGDATA`.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`, локальные файловые операции PostgreSQL в каталоге данных, `stdout`/`stderr` для технологических логов. HTTP, REST, gRPC и Kafka-интерфейсов у sidecar нет.
Хранилища	Данные PostgreSQL в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/statistics/pgdata-report-email` -> `/var/lib/postgresql/data`. В БД `dnn` присутствуют таблицы `aerich`, `auth_user`, `camera`, `instant_notification_history`, `notification_camera_user`, `notification_object_user`, `notification_setting`, `object_observation`, `telegram_chat`, `user_camera_access`. Вложения отчётов и фактическая отправка хранятся/выполняются не этим контейнером.
Конфигурация	Env-only конфигурация shared PostgreSQL image: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`. В конфигурации продуктового контура заданы образ `docker.vizorlabs.ru/vizorlabs/postgres:13.1`, `RestartPolicy=always`, Docker log driver `loki`, сеть `bx_default`, отсутствие Docker healthcheck и host-публикации порта.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. В этих логах ожидаемы старт PostgreSQL, готовность принимать подключения и ошибки SQL/миграций; бизнес-ошибки расписаний, Kafka-consumer, генерации вложений, SMTP или Telegram нужно смотреть в логах `st-report-email`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck нет. Практические проверки: контейнер `statistics-st-report-email-postgres-1` в состоянии `Up`, `pg_isready` внутри контейнера возвращает `accepting connections`, порт `5432/tcp` доступен во внутренней сети, а в схеме присутствуют таблицы `aerich`, `notification_setting`, `telegram_chat` и `instant_notification_history`.
Критичность	Высокая для уведомлений и рассылки отчётов. Отказ БД блокирует запуск/миграции `st-report-email`, чтение расписаний, выбор получателей, хранение Telegram-чата пользователя и дедупликацию моментальных уведомлений; сами события, медиа и сформированные отчётные вложения остаются в других сервисах.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без публичного API, метрик, healthcheck и собственной доменной логики. Схема и миграции принадлежат `st-report-email`; сам контейнер не потребляет Kafka и не знает правил выбора получателей. Legacy v1 таблицы `notification_object_user`/`notification_camera_user` и current v2 таблица `notification_setting` сосуществуют в одной БД. Отдельный `st-report-email-postgres-backup` sidecar не предусмотрен.

`st-report-pdf-xlsx-generator`¶

Поле	Описание
Название сервиса	`st-report-pdf-xlsx-generator`
Назначение	Генератор событийных отчётов BOX5-DIT-MGSN. По запросу UI, почтового сервиса или другого внутреннего клиента собирает данные событий и справочников, формирует PDF, XLSX, DOCX или HTML-архив и возвращает документ синхронно либо сохраняет его для последующего скачивания.
Подсистема	`statistics`, контур отчётности по событиям. Работает рядом с `st-report-pdf-xlsx-generator-postgres` и участвует в потоке `events-to-statistics`.
Основные функции	Рендерит списочные отчёты по событиям (`GetEventsReportPDF`, `GetEventsReportXSLX`, `GetEventsReportDOCX`, `MakeEventsReport*`); формирует отчёты по одному событию (`GetEventInfoPDF`, `GetEventInfoXLSX`, `GetEventInfoDOCX`); строит XLSX-статистику событий (`GetEventStatXLSX`); формирует отчёт по ответственным за камеры; ведёт список, статус, отмену, удаление и скачивание сохранённых отчётов; отдаёт настройки приложения и Prometheus-метрики.
Входящие вызовы	HTTP/gRPC на порту `3000`, путь `/grpc/box.statistic.report_pdf_xlsx_generator.ReportPdfXlsxGenerator/<Method>`. Известные прямые клиенты: `ui-rest-to-gprc` для browser-facing маршрутов отчётов и скачивания, `st-report-email` для вложений scheduled/instant email-отчётов. Дополнительно сервис отдаёт `GET /metrics`, `GET /api/docs/` и статические скачивания `GET /static/reports/{date}/{report_filename}` после проверки записи в `report_file_infos`.
Исходящие вызовы	HTTP/gRPC к `st-event-storage` (`GetEventsCount`, `GetEvents`, `GetEvent`) за событиями; к `st-camera-storage` за камерами, объектами и путями дерева объектов; к `st-auth` за пользователями; к `st-access` за пользователями с доступом к объектам отчёта; к `svr-models-registry` за модельными категориями и переводами зон. Пишет и читает PostgreSQL `st-report-pdf-xlsx-generator-postgres`, публикует JSON-прогресс в Kafka topic `report_generation_process`, читает медиа по внутренним MinIO URL, сформированным из `MINIO_ENDPOINT` и префиксов event storage.
Протоколы	Входящие: HTTP/gRPC, HTTP для `/metrics`, Swagger UI и статического скачивания отчётов. Исходящие: HTTP/gRPC, PostgreSQL wire protocol, Kafka producer, внутренний HTTP/S3-доступ к MinIO-объектам. Бинарные документы возвращаются как содержимое gRPC-ответа или как файл по static-download маршруту.
Хранилища	Метаданные async/tracked-download отчётов, singleton-настройки и Aerich-состояние хранятся в `st-report-pdf-xlsx-generator-postgres` (`report_file_infos`, `app_settings`, `aerich`). Готовые файлы пишутся в `/reports/YYYY-MM-DD/<report_uuid>.<ext>`; в конфигурации продуктового контура задан mount `/data/compose-data2-no-swarm/report-pdf-xlsx-generator/reports` -> `/reports`. Сырые события, камеры, пользователи, права, модели и медиа не хранятся локально, а читаются из соответствующих сервисов.
Конфигурация	Основные параметры: `PORT`, `SETTINGS_FILE`, `DEBUG`, `DEPENDS`, `TIME_ZONE`, `EVENT_LIST_PAGE_SIZE`, `REPORT_LIST_IMAGE_TYPE`, `MAX_CATEGORIES_PIE_CHART_COUNT`, `DEFAULT_TIME_FMT`, `REPORT_TIME_FMT`, endpoint-переменные `EVENT_STORAGE_URL`, `CAMERA_STORAGE_URL`, `AUTH_URL`, `ACCESSES_URL`, `MODELS_STORAGE_URL`, `POSTGRES_*`, `KAFKA_HOST`, `KAFKA_TOPIC_REPORT_GENERATION_PROCESS`, `MINIO_ENDPOINT`, `MINIO_PREFIX_EVENT_STORAGE`, `EVENT_URL_PREFIX`. В конфигурации продуктового контура запущен образ `docker.vizorlabs.ru/box-statistics/report-pdf-xlsx-generator:severstal-1.0.7-dev`; для этого контура ранее был зафиксирован более старый тег `severstal-1.0.4-dev`, поэтому фактическую версию нужно проверять в конфигурации продуктового контура.
Логирование	Приложение и Uvicorn пишут логи в `stdout`/`stderr`; в конфигурации продуктового контура контейнер использует Docker log driver `loki`. В логах ожидаемы старт миграций Aerich, запуск API, ошибки downstream-вызовов, PostgreSQL, Kafka, чтения медиа и рендеринга документов.
Мониторинг	Prometheus-метрики доступны по `GET /metrics`; в конфигурации продуктового контура endpoint внутри контейнера отвечает `200` и содержит счётчики `request_count_total` по gRPC-методам. Docker healthcheck не задан, restart policy `always`. Практические проверки: контейнер `statistics-st-report-pdf-xlsx-generator-1` в состоянии `Up`, доступность `/metrics`, наличие записей/файлов при tracked-download сценариях и отсутствие ошибок генерации в логах.
Критичность	Средняя. Отказ не останавливает приём, хранение и просмотр событий, но блокирует выгрузку PDF/XLSX/DOCX/HTML-отчётов из UI, вложения отчётов в `st-report-email`, просмотр статуса async-отчётов и скачивание уже сгенерированных файлов через сервисный static-route.
Эксплуатационные особенности и известные ограничения	Async-задачи живут в памяти процесса и не возобновляются после рестарта: в PostgreSQL остаются метаданные `report_file_infos`, но выполнявшуюся генерацию нужно запускать заново. Kafka нужен для async/tracked-download прогресса; при недоступности `inf-kafka` такие сценарии могут завершаться ошибкой. `st-auth` требуется приложению, хотя отсутствует в дефолтном `DEPENDS`; `st-access` нужен для отчёта по ответственным за камеры. Очистка `/reports` ограничена размером хранилища из `app_settings`, а не сроком хранения.

`st-report-pdf-xlsx-generator-postgres`¶

Поле	Описание
Название сервиса	`st-report-pdf-xlsx-generator-postgres`
Назначение	PostgreSQL sidecar для `st-report-pdf-xlsx-generator`. Хранит метаданные отслеживаемых скачиваний и асинхронных отчётов, сохранённые пути к сформированным файлам, singleton-настройки приложения и состояние Aerich-миграций. Сырые события, байты PDF/XLSX/DOCX/HTML-документов и MinIO-объекты в этой БД не хранятся.
Подсистема	`statistics`, контур отчётности по событиям. В конфигурации продуктового контура запущен как контейнер `statistics-st-report-pdf-xlsx-generator-postgres-1` в compose-проекте `statistics`, рядом с приложением `st-report-pdf-xlsx-generator`.
Основные функции	Инициализирует PostgreSQL БД при первом старте; принимает SQL-запросы от `st-report-pdf-xlsx-generator`; хранит таблицы `app_settings`, `report_file_infos` и `aerich`; предоставляет приложению состояние для `GetAppSettings`, `SetAppSettings`, `FlushDb`, листинга, прогресса, отмены и скачивания отчётов. Схему создаёт и обновляет приложение через `aerich upgrade`, сам контейнер не содержит доменной логики генерации отчётов.
Входящие вызовы	PostgreSQL wire protocol на `5432/tcp` из внутренней Docker-сети от `st-report-pdf-xlsx-generator`. В конфигурации продуктового контура host-порт не опубликован: Docker показывает только внутренний `5432/tcp`, контейнер подключён к сети `bx_default` с alias `st-report-pdf-xlsx-generator-postgres`. Инициализация БД управляется стандартными `POSTGRES_DB`, `POSTGRES_USER`, `POSTGRES_PASSWORD`.
Исходящие вызовы	Прикладных исходящих сетевых вызовов нет. Контейнер не вызывает REST, gRPC, Kafka, MinIO/S3, ClickHouse или другие сервисы; он отвечает SQL-клиенту и пишет состояние PostgreSQL в подключённый каталог `PGDATA`.
Протоколы	PostgreSQL wire protocol, TCP `5432` во внутренней compose-сети; файловый ввод-вывод PostgreSQL в `PGDATA`; `stdout`/`stderr` для технологических логов. Публичный REST/API, gRPC, Kafka и S3-контракты у sidecar отсутствуют.
Хранилища	PostgreSQL `13.1` в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/statistics/pgdata-report-pdf-xlsx-generator` -> `/var/lib/postgresql/data`. В рабочей БД присутствуют таблицы `aerich`, `app_settings`, `report_file_infos`; `report_file_infos` хранит UUID/путь отчёта, формат и тип, пользователя запроса, размер, ошибки, счётчики и проценты генерации/сбора событий, lifecycle-флаги, временные границы, фильтры камер/категорий/персон/score/car-number и JSON websocket-прогресса. Готовые файлы отчётов лежат в `/reports` контейнера приложения, а не в этом PostgreSQL.
Конфигурация	Env-only конфигурация shared PostgreSQL image: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`. В конфигурации продуктового контура заданы образ `docker.vizorlabs.ru/vizorlabs/postgres:13.1`, версия PostgreSQL `13.1 (Debian 13.1-1.pgdg100+1)`, `RestartPolicy=always`, Docker log driver `loki`, сеть `bx_default`, отсутствие Docker healthcheck и host-публикации порта; значения параметров доступа не выводились и в документации не фиксируются.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. В этих логах ожидаемы запуск сервера, readiness и SQL/миграционные ошибки; бизнес-логи генерации отчётов, Kafka-прогресса и файловых операций нужно смотреть в `st-report-pdf-xlsx-generator`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck нет. Практические проверки: контейнер `statistics-st-report-pdf-xlsx-generator-postgres-1` в состоянии `Up`, `pg_isready` внутри контейнера возвращает успешный код, а `psql` показывает таблицы `aerich`, `app_settings`, `report_file_infos`.
Критичность	Высокая для асинхронных и tracked-download отчётов: отказ БД ломает сохранение настроек, историю/список отчётов, прогресс, отмену, скачивание и разрешение статических путей `/static/reports/...`. Потеря volume удаляет метаданные отчётов и настройки приложения; уже сгенерированные файлы могут остаться на файловом volume приложения, но без записей БД часть сценариев скачивания и навигации по ним будет недоступна.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без собственного REST/gRPC API, бизнес-валидации, метрик и Docker healthcheck. Схемой и миграциями владеет репозиторий `box-statistics/report-pdf-xlsx-generator`; прямые SQL-клиенты, кроме приложения, не используются. В compose нет отдельного `st-report-pdf-xlsx-generator-postgres-backup` sidecar; для текущих инвентарей предусмотрена централизованная postgres backup-конфигурация для текущих инвентарей.

`st-audit`¶

Поле	Описание
Название сервиса	`st-audit`
Назначение	Сервис хранения и выдачи аудита пользовательских действий в контуре `statistics`. Принимает audit records из Kafka, сохраняет их в `st-audit-postgres`, отдаёт историю и список сервисов через gRPC и формирует CSV-выгрузку для интерфейса.
Подсистема	`statistics`, контур user-action logging. В конфигурации продуктового контура задан контейнер `statistics-st-audit-1` с образом `docker.vizorlabs.ru/box-statistics/audit:1.0.4`, внутренним портом `3000/tcp` и compose-проектом `statistics`.
Основные функции	Запуск `aerich upgrade` при старте; HTTP/gRPC API `AddAuditRecord`, `GetAuditList`, `GetServiceList`, `GetAuditReportCSV` и служебный `FlushDb`; Kafka-consumer топика `add_audit_record` в группе `audit`; запись строк аудита в PostgreSQL; фильтрация истории по дате, пользователю, сервису, сообщению, действию, пагинации и сортировке; генерация UTF-8 CSV с разделителем `;`; фоновая очистка записей старше `STORE_AUDIT_LOGS_DAYS`.
Входящие вызовы	HTTP/gRPC на `:3000` по пути `/grpc/box.statistic.audit.Audit/<Method>` от `ui-rest-to-gprc` и других внутренних клиентов; `GET /metrics` для Prometheus-совместимых метрик; Kafka-consumer из `inf-kafka` для `KAFKA_TOPIC_ADD_AUDIT_RECORD` с payload `audit_pb2.Audit` (`date`, `user.id`, `service`, `message`, `action`, `etc_json`, `ip_address`). Browser-facing REST находится в `ui-rest-to-gprc`: `/api/statistics/audit/logs/`, `/services/`, `/report-csv/`.
Исходящие вызовы	PostgreSQL-подключения к `st-audit-postgres` для миграций, вставки audit rows, выборок, distinct-списка сервисов, CSV-запросов и retention cleanup. HTTP/gRPC-вызов `st-auth` через `AUTH_URL`: `AuthClientAsync.GetUserList` используется при CSV-выгрузке для подстановки человекочитаемых имён пользователей. Исходящие Kafka producers в текущей спецификации сервиса не предусмотрены.
Протоколы	HTTP/gRPC JSON transport, Kafka consumer protocol, PostgreSQL wire protocol, Prometheus text exposition на `/metrics`. Публичный gRPC, REST API за пределами gRPC и S3/MinIO-контракта у сервиса не предусмотрены.
Хранилища	Основное состояние хранится в `st-audit-postgres`: таблицы `audit` и `aerich`. Запись `audit` содержит `insert_date`, `user_id`, `service`, `message`, `action`, `etc_json`, `ip_address`; актуальная модель также предполагает индексы по `insert_date`, `user_id`, `service`, `action`. В конфигурации продуктового контура задан bind mount БД `/data/compose-data2-no-swarm/statistics/st-audit` -> `/var/lib/postgresql/data`.
Конфигурация	Ключевые переменные: `HOST`, `PORT`, `SETTINGS_FILE`, `DEBUG`, `DEPENDS`, `AUTH_URL`, `POSTGRES_HOST`, `POSTGRES_PORT`, `POSTGRES_DATABASE`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_ADD_AUDIT_RECORD`, `CSV_REPORT_PAGE_SIZE`, `STORE_AUDIT_LOGS_DAYS`, `IS_LOCALIZATION_ENABLED`, `TZ`. В Box-деплоях PostgreSQL обычно указывается как `st-audit-postgres`, Kafka как `inf-kafka:9092`; в конфигурации продуктового контура заданы image tag `1.0.4`, `RestartPolicy=always`, Docker log driver `loki`, отсутствие Docker healthcheck.
Логирование	Приложение, Uvicorn/gRPC-сервер, Kafka-consumer, Aerich-миграции и `AuditCleanerTask` пишут в `stdout`/`stderr` контейнера; в конфигурации продуктового контура логи собираются Docker log driver `loki`. В логах ожидаемы ошибки подключения к Kafka/PostgreSQL/`st-auth`, ошибки миграций, gRPC-запросов и фоновой очистки.
Мониторинг	`GET /metrics` на порту `3000` отдаёт Prometheus text metrics; в конфигурации продуктового контура endpoint внутри контейнера вернул HTTP `200` и счётчики `request_count_total`. Docker healthcheck не задан. Практические проверки: контейнер `statistics-st-audit-1` в состоянии `Up`, доступность `/metrics`, успешное подключение к `st-audit-postgres`, наличие потребления Kafka-топика `add_audit_record` группой `audit` и отсутствие необработанного consumer lag.
Критичность	Высокая для аудируемости, расследования действий пользователей и CSV-отчётов. Отказ `st-audit` не останавливает основной видеоаналитический/event pipeline, но ломает чтение истории аудита и CSV-экспорт; при длительном простое Kafka-сообщения могут не попасть в PostgreSQL после истечения retention топика. Потеря `st-audit-postgres` означает потерю сохранённых audit records и блокирует ingestion/read/export.
Эксплуатационные особенности и известные ограничения	CSV-экспорт зависит от доступности `st-auth`: перед формированием файла сервис получает полный список пользователей. `GetAuditList` напрямую не вызывает `st-auth`, но REST-маршрут `/api/statistics/audit/logs/` в `ui-rest-to-gprc` отдельно обогащает ответ пользователями. В текущем коде сортировка фактически приводится к `insert_date`, даже если передан другой `sort_field`; CSV-ответ имеет `mime_type=application/octet-stream`; большие CSV-выгрузки могут содержать пересечения страниц, потому что пагинация использует page index вместо row offset. Сервис не публикует Kafka-сообщения и не имеет Docker healthcheck.

`st-audit-postgres`¶

Поле	Описание
Название сервиса	`st-audit-postgres`
Назначение	PostgreSQL sidecar сервиса `st-audit`: хранит аудит действий пользователей и состояние Aerich-миграций. Контейнер является СУБД, а не прикладным API-сервисом.
Подсистема	`statistics`, контур аудита пользовательских действий. В конфигурации продуктового контура запущен как контейнер `statistics-st-audit-postgres-1` в compose-проекте `statistics`.
Основные функции	Инициализация PostgreSQL БД при первом старте; приём SQL-запросов от `st-audit`; хранение таблиц `audit` и `aerich`; сохранение PostgreSQL data directory, WAL и служебных файлов в подключённом `PGDATA`. Схему и миграции создаёт и обновляет `st-audit` при старте через `aerich upgrade`.
Входящие вызовы	PostgreSQL-подключения от `st-audit` для миграций, записи audit rows, фильтрованных чтений, получения списка уникальных service labels, запросов для CSV-экспорта и retention-cleanup удаления старых строк. В конфигурации продуктового контура порт `5432/tcp` доступен только во внутренней Docker-сети `bx_default`; host-порт не опубликован. Отдельный backup-sidecar для этой БД не предусмотрен.
Исходящие вызовы	Прикладных сетевых вызовов нет. Контейнер не вызывает REST, gRPC, Kafka, S3 или API других сервисов; он отвечает PostgreSQL-клиенту `st-audit` и записывает состояние в подключённый каталог `PGDATA`.
Протоколы	PostgreSQL wire protocol, TCP `5432` во внутренней compose-сети. HTTP, REST, gRPC, Kafka и публичный API у контейнера отсутствуют.
Хранилища	PostgreSQL `13.1` в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/statistics/st-audit` -> `/var/lib/postgresql/data`. В рабочей БД `dnn` присутствуют таблицы `aerich` и `audit`; таблица `audit` содержит `id`, `insert_date`, `user_id`, `service`, `message`, `action`, `etc_json`, `ip_address` и индексы по `insert_date`, `user_id`, `service`, `action`.
Конфигурация	Env-only конфигурация shared PostgreSQL image: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`. Для конфигурации продуктового контура закреплён image tag `13.1`; в конфигурации продуктового контура запущен `docker.vizorlabs.ru/docker-images/postgres:13.1`, restart policy `always`, Docker log driver `loki`, Docker healthcheck отсутствует.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. В логах видны старт PostgreSQL, слушание `0.0.0.0:5432`, готовность принимать подключения и возможные ошибки SQL/миграций; бизнес-логи Kafka-ingest, gRPC и CSV-экспорта нужно смотреть в `st-audit`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck нет. Практические проверки: контейнер `statistics-st-audit-postgres-1` в состоянии `running`, `pg_isready` внутри контейнера возвращает `accepting connections`, порт `5432/tcp` доступен внутри сети, в схеме присутствуют таблицы `aerich` и `audit`.
Критичность	Высокая для аудита: отказ БД не даёт `st-audit` запускать миграции, сохранять новые записи, читать историю, отдавать список сервисов, выполнять retention cleanup и формировать CSV-экспорт. Основной видеоаналитический pipeline может продолжить обработку событий, но аудит пользовательских действий становится недоступен.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без бизнес-логики, публичного REST/gRPC API, собственных метрик и healthcheck. Схемой владеет `box-statistics/audit`, поэтому изменения таблиц происходят через `st-audit`, а не через контейнер БД. В текущей спецификации отдельный контейнер резервного копирования для `st-audit-postgres` не предусмотрен; восстановление зависит от общих процедур работы с PostgreSQL volume/дампами контура.

`st-comments`¶

Поле	Описание
Название сервиса	`st-comments`
Назначение	Сервис потоков комментариев для сущностей контура статистики. Хранит threads/messages, отдаёт CRUD через gRPC и используется `ui-rest-to-gprc` для прямых комментариев и подтверждённого сценария комментариев к событиям.
Подсистема	`statistics`, контур пользовательских комментариев к данным статистики. В конфигурации продуктового контура запущен как контейнер `statistics-st-comments-1` с образом `docker.vizorlabs.ru/box-statistics/comments:1.1.0`.
Основные функции	Создание потока с первым сообщением (`AddThreadWithMessage`); добавление сообщения в существующий поток (`AddMessage`); получение списка сообщений потока; обновление и удаление сообщения; хранение счётчика сообщений в thread; локальное зеркало пользователей с флагом `blocked`, получаемое из Kafka-топиков `st-auth`; запуск Aerich-миграций перед стартом сервера.
Входящие вызовы	HTTP/gRPC на `:3000`, путь `/grpc/box.statistic.comments.Comments/<Method>`; `GET /metrics` для Prometheus-совместимых метрик; Kafka consumers группы `comments` для топиков регистрации, обновления и удаления пользователей. Browser-facing маршруты идут через `ui-rest-to-gprc`: `POST /api/statistics/comments/thread/`, `POST /api/statistics/comments/comment/`, `GET /api/statistics/comments/comments/{thread_id}/`, `PUT /api/statistics/comments/comment/`, `DELETE /api/statistics/comments/comment/{comment_id}/`. Событийный helper: `POST /api/statistics/event-storage/events/{event_id}/comments/`, который создаёт первый thread для события при `comments_thread_id=0` или добавляет сообщение в уже связанный thread.
Исходящие вызовы	PostgreSQL `st-comments-postgres` для миграций, потоков, сообщений и зеркала пользователей. Исходящих HTTP/gRPC-вызовов к другим сервисам и Kafka producers в текущей спецификации сервиса не предусмотрено; связь с событиями выполняет вызывающий `ui-rest-to-gprc` через `st-event-storage`, а не сам `st-comments`.
Протоколы	HTTP/gRPC, Prometheus text exposition на `/metrics`, Kafka consumer protocol, PostgreSQL wire protocol. Публичный REST API предоставляет не сервис напрямую, а `ui-rest-to-gprc`.
Хранилища	Основное состояние хранится в `st-comments-postgres`: таблицы `thread`, `message`, `user`, `aerich`. В конфигурации продуктового контура PostgreSQL контейнер `statistics-st-comments-postgres-1` использует образ `docker.vizorlabs.ru/vizorlabs/postgres:13.1`, bind mount `/data/compose-data2-no-swarm/statistics/pgdata-comments` -> `/var/lib/postgresql/data`; `pg_isready` возвращает `accepting connections`, в БД присутствуют таблицы `aerich`, `message`, `thread`, `user`. У событий указатель на поток хранится отдельно в `st-event-storage.event.comments_thread_id`.
Конфигурация	Ключевые переменные: `PORT`, `SETTINGS_FILE`, `DEBUG`, `DEPENDS`, `POSTGRES_HOST`, `POSTGRES_PORT`, `POSTGRES_DATABASE`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_REGISTER_USER`, `KAFKA_TOPIC_UPDATE_USER`, `KAFKA_TOPIC_DELETE_USER`. В конфигурации продуктового контура заданы безопасные значения `SETTINGS_FILE=config.settings.production`, `DEBUG=False`, `DEPENDS=["inf-kafka:9092","st-comments-postgres:5432"]`, `POSTGRES_HOST=st-comments-postgres`, `KAFKA_HOST=inf-kafka:9092`, `KAFKA_GROUP=comments`, пользовательские топики `statistic_register_user`, `statistic_update_user`, `statistic_delete_user`; значения параметров доступа не фиксируются.
Логирование	Приложение, gRPC/Uvicorn-сервер, Kafka consumers и Aerich-миграции пишут в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver — `loki`, restart policy — `always`. В логах ожидаемы старт сервера, миграции, Kafka-подписки и ошибки обработки gRPC-запросов или подключения к PostgreSQL/Kafka.
Мониторинг	`GET /metrics` внутри контейнера на `127.0.0.1:3000` возвращает HTTP `200` и Prometheus-метрики `request_count_total`, `request_traffic_total`, `response_traffic_total`, `request_duration`. Docker healthcheck у `statistics-st-comments-1` и `statistics-st-comments-postgres-1` не задан. Практические проверки: состояние контейнеров `Up`, доступность `/metrics`, `pg_isready`, наличие таблиц `thread`, `message`, `user`, отсутствие лагов Kafka consumer group `comments`.
Критичность	Средняя. Отказ блокирует создание, чтение и редактирование комментариев, включая комментарии в карточках событий, но не останавливает первичную запись событий, инференс и основные аналитические пайплайны. Отказ PostgreSQL приводит к потере доступности всей истории комментариев; отказ Kafka оставляет CRUD работоспособным, но зеркало пользователей перестаёт обновляться.
Эксплуатационные особенности и известные ограничения	Сервис не владеет комментируемой сущностью: клиенты передают свободные `subsystem` и `subsystem_id`, а связь события с потоком хранится в `st-event-storage.comments_thread_id` без PostgreSQL foreign key. Для событий используется сценарий комментариев; отдельный сценарий комментариев к объектам не предусмотрен. `thread.quantity` увеличивается при `AddMessage`, но удаление сообщений его не уменьшает. Локальный флаг `user.blocked` зеркалируется из `st-auth`, но в CRUD-коде не применяется как запрет на создание или изменение сообщений. Метод `FlushDb` является maintenance-only RPC и не должен использоваться в эксплуатации. REST-маршрут подсчёта `POST /api/statistics/comments/comments/count/` version-sensitive: в аудированном приложении `st-comments` на commit `d05a63a` handler `GetThreadsMessageCount` не реализован.

`st-comments-postgres`¶

Поле	Описание
Название сервиса	`st-comments-postgres`
Назначение	PostgreSQL sidecar сервиса `st-comments`: хранит треды комментариев, сообщения, зеркальный флаг блокировки пользователей и состояние Aerich-миграций. Контейнер является СУБД, а не прикладным API-сервисом.
Подсистема	`statistics`, контур комментариев к объектам статистики. В конфигурации продуктового контура запущен как compose-сервис `st-comments-postgres`, контейнер `statistics-st-comments-postgres-1`, сеть `bx_default`.
Основные функции	Инициализация PostgreSQL БД при первом старте; приём SQL-запросов от `st-comments`; хранение таблиц `thread`, `message`, `user`, `aerich`; сохранение PostgreSQL data directory, WAL и служебных файлов в подключённом `PGDATA`. Схему и миграции создаёт приложение `st-comments` при старте через `aerich upgrade`.
Входящие вызовы	PostgreSQL-подключения от `st-comments` для миграций, создания/чтения/изменения тредов и сообщений, удаления сообщений и обновления зеркала `user.blocked` по данным, полученным приложением из Kafka. Возможны служебные подключения пользователей с правами эксплуатации и диагностических инструментов внутри контура. В конфигурации продуктового контура порт `5432/tcp` доступен только во внутренней Docker-сети; host-порт не опубликован.
Исходящие вызовы	Прикладных сетевых вызовов нет. Контейнер не вызывает REST, gRPC, Kafka, S3/MinIO или API других сервисов; он отвечает PostgreSQL-клиентам и записывает состояние в подключённый каталог `PGDATA`.
Протоколы	PostgreSQL wire protocol, TCP `5432` во внутренней compose-сети, файловый ввод-вывод PostgreSQL. HTTP, REST, gRPC, Kafka и публичный API у sidecar отсутствуют.
Хранилища	PostgreSQL `13.1` в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/statistics/pgdata-comments` -> `/var/lib/postgresql/data`. В рабочей БД `dnn` присутствуют таблицы `aerich`, `thread`, `message`, `user`: `thread` хранит `subsystem`, `subsystem_id`, `create_date`, `quantity`; `message` хранит `thread_id`, `user_id`, `create_date`, `change_date`, текст `message` и `quote`; `user` хранит `id` и `blocked`; `aerich` хранит migration metadata.
Конфигурация	Env-only конфигурация shared PostgreSQL image: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`. По спецификации значения БД/пользователя по умолчанию согласованы с `st-comments` как `dnn`; пароль задаётся deployment-specific и в документации не фиксируется. В конфигурации продуктового контура заданы образ `docker.vizorlabs.ru/vizorlabs/postgres:13.1`, PostgreSQL `13.1 (Debian 13.1-1.pgdg100+1)`, `RestartPolicy=always`, Docker log driver `loki`, отсутствие Docker healthcheck и host-публикации порта.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. В логах ожидаемы старт сервера, readiness, завершение работы, ошибки SQL и миграций; бизнес-логи комментариев, Kafka-consumer зеркала пользователей и gRPC-запросов нужно смотреть в `st-comments`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck нет. Практические проверки: контейнер `statistics-st-comments-postgres-1` в состоянии `running`, `pg_isready` внутри контейнера возвращает `accepting connections`, порт `5432/tcp` открыт внутри сети, `psql` показывает PostgreSQL `13.1` и таблицы `aerich`, `thread`, `message`, `user`.
Критичность	Высокая для функции комментариев: отказ БД блокирует запуск/миграции `st-comments`, создание и чтение тредов, добавление/редактирование/удаление сообщений и хранение зеркала `blocked` для пользователей. Основной event pipeline может продолжить работу, но комментарии к объектам статистики становятся недоступны; потеря volume означает потерю истории комментариев и migration state.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без доменной логики, публичного REST/gRPC API, собственных метрик и healthcheck. Схемой и миграциями владеет репозиторий `box-statistics/comments`, а не контейнер БД. По схеме внешние ключи между `message.thread_id`, `message.user_id` и связанными сущностями не заданы; `thread.quantity` является прикладным счётчиком и не пересчитывается самим PostgreSQL; зеркальный `user.blocked` хранится здесь как локальная копия состояния, но его бизнес-использование определяется `st-comments`. Отдельный backup-sidecar для `st-comments-postgres` не предусмотрен.

`st-ex-statistics`¶

Поле	Описание
Название сервиса	`st-ex-statistics` (`box3/ex-statistics`). В конфигурации продуктового контура задан контейнер `statistics-st-ex-statistics-1`, образ `docker.vizorlabs.ru/box3/ex-statistics:dev`, внутренний порт `3000/tcp`.
Назначение	Legacy-сервис расширенной статистики для stay-zone аналитики: читает из Kafka события пребывания в зоне, камеры, наблюдаемые объекты и сведения о моделях, денормализует их в отдельный ClickHouse-шард `st-ex-statistics-clickhouse` для ad hoc выборок.
Подсистема	`statistics`, контур расширенной статистики по зонам пребывания. Работает рядом с `inf-kafka`, `st-camera-storage`, поставщиком `ModelsInfo` и ClickHouse-sidecar `st-ex-statistics-clickhouse`.
Основные функции	Запуск внутреннего Uvicorn/gRPC-процесса; инициализация и миграции ClickHouse-таблиц `camera`, `object`, `zone`, `category`, `stay_zone_event`; Kafka-ingest топологии камер и наблюдаемых объектов; ingest `StayZoneEvent`; ingest снимков `ModelsInfo`; обогащение stay-zone событий текущими именами камер, объектов, зон, категорий и моделей; дедупликация по `event_uuid`; обновление уже сохранённых строк при переименовании камер/объектов и при смене активного набора моделей.
Входящие вызовы	Внутренний HTTP/gRPC порт `3000`, но в текущем релизе обработчики generated `ExStatistics` не зарегистрированы, а рабочих бизнес-вызовов HTTP/gRPC не предусмотрено. Основной входной поток: Kafka consumers в группе `ex-statistics` для топиков `statistic_camera_add`, `statistic_camera_update`, `statistic_camera_del`, `statistic_statistic_object_observation_add`, `statistic_object_observation_update`, `statistic_object_observation_del`, `statistic_cmd_add_stay_zone_event` и топика моделей, который в конфигурации продуктового контура переопределён в `models_storage_ready`.
Исходящие вызовы	ClickHouse native TCP к `st-ex-statistics-clickhouse` для создания схемы, чтения справочников, вставки stay-zone строк и ClickHouse mutations при обновлении камер, объектов и активных моделей. Исходящие Kafka producers, HTTP/gRPC или gRPC-клиенты в текущей спецификации сервиса не предусмотрены.
Протоколы	Kafka consumer protocol, ClickHouse native TCP, внутренний HTTP/gRPC через ASGI/Uvicorn. Заявленный `/metrics` относится к HTTP-поверхности, но в конфигурации продуктового контура возвращает HTTP `500`, поэтому как рабочий Prometheus endpoint не предусмотрен.
Хранилища	Собственного локального volume у контейнера приложения в конфигурации продуктового контура не предусмотрено. Состояние хранится в `st-ex-statistics-clickhouse`: таблицы `camera`, `object`, `zone`, `category`, `stay_zone_event`. У ClickHouse-sidecar в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/statistics/event-ex-clickhouse-data` -> `/var/lib/clickhouse`, ClickHouse `24.6.1.4423`, движки таблиц `MergeTree`.
Конфигурация	Ключевые переменные: `PORT`, `SETTINGS_FILE`, `DEBUG`, `DEPENDS`, `CLICKHOUSE_HOST`, `CLICKHOUSE_PORT`, `CLICKHOUSE_DATABASE`, `CLICKHOUSE_USER`, `CLICKHOUSE_PASSWORD`, `KAFKA_HOST`, `KAFKA_PORT`, `KAFKA_GROUP`, `KAFKA_IS_DISABLE`, `KAFKA_TOPIC_*`. В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `DEBUG=false`, `DEPENDS=["inf-kafka:9092", "st-ex-statistics-clickhouse:8123"]`, `CLICKHOUSE_HOST=st-ex-statistics-clickhouse`, `KAFKA_HOST=inf-kafka`, `KAFKA_GROUP=ex-statistics`, `KAFKA_TOPIC_STATISTIC_CMD_ADD_OR_UPDATE_MODELS_INFO=models_storage_ready`, `KAFKA_TOPIC_STATISTIC_CMD_ADD_STAY_ZONE_EVENT=statistic_cmd_add_stay_zone_event`; значения параметров доступа не фиксируются.
Логирование	Приложение, Uvicorn, Kafka consumers, ClickHouse-миграции и ошибки API пишут в `stdout`/`stderr`; в конфигурации продуктового контура используется Docker log driver `loki`. При проверке в логах виден сбой `GET /metrics` из-за `ImportError: cannot import name 'service' from 'app.api.grpc'`, что совпадает с ограничением текущей реализации по незарегистрированной gRPC/metrics-поверхности.
Мониторинг	Docker healthcheck не задан, `RestartPolicy=always`. Практические проверки: контейнер `statistics-st-ex-statistics-1` в состоянии `Up`; контейнер `statistics-st-ex-statistics-clickhouse-1` в состоянии `Up`; ClickHouse `GET /ping` возвращает `Ok.`, `clickhouse-client` выполняет запросы и показывает ожидаемые таблицы. Kafka lag группы `ex-statistics` полезен для контроля свежести, но отдельный рабочий `/metrics` endpoint для сервиса в конфигурации продуктового контура не предусмотрен.
Критичность	Высокая для расширенной stay-zone статистики и связанных аналитических витрин. Отказ не останавливает первичное хранение событий в основном событийном контуре, но приводит к отставанию или потере данных в отдельном ClickHouse-шарде расширенной статистики; отказ `st-ex-statistics-clickhouse` блокирует запись и чтение этой витрины.
Эксплуатационные особенности и известные ограничения	Сервис legacy и в текущей конфигурации не имеет рабочей бизнес-поверхности HTTP/gRPC: generated proto содержит `AddStayZoneEvent` и `FlushDb`, но обработчики не зарегистрированы; `/metrics` в конфигурации продуктового контура возвращает HTTP `500`. Производитель `statistic_cmd_add_stay_zone_event` в текущей спецификации не предусмотрен. Обновления камер и объектов меняют уже сохранённые ClickHouse-строки, поэтому историческая аналитика показывает текущие имена, а не исходные значения на момент события. Refresh моделей очищает и заново заполняет `zone` и `category`, затем пересчитывает признаки активных моделей; ClickHouse mutations выполняются асинхронно. Docker healthcheck отсутствует.

`st-ex-statistics-clickhouse`¶

Поле	Описание
Название сервиса	`st-ex-statistics-clickhouse` (`docker-images/click-house`). В конфигурации продуктового контура развёрнут как контейнер `statistics-st-ex-statistics-clickhouse-1` в compose-проекте `statistics`.
Назначение	Stateful ClickHouse sidecar для legacy-контура расширенной статистики `st-ex-statistics`: хранит денормализованные строки аналитики по пребыванию объектов в зонах и справочные таблицы, которыми владеет родительский сервис. Сам контейнер является СУБД и не предоставляет прикладной REST/gRPC API.
Подсистема	`statistics`, контур расширенной статистики и ad hoc-аналитики по stay-zone событиям. Работает в паре с `st-ex-statistics`; optional SQL-чтение возможно со стороны согласованных SQL-инструментов.
Основные функции	Запускает ClickHouse Server; принимает миграции, вставки, lookup-чтения и `ALTER TABLE ... UPDATE/DELETE` mutations от `st-ex-statistics`; хранит таблицы `camera`, `object`, `zone`, `category`, `stay_zone_event`; отдаёт стандартный ClickHouse `/ping` и native/HTTP интерфейсы для служебных проверок. Бизнес-схему и порядок миграций задаёт `st-ex-statistics`, а не sidecar.
Входящие вызовы	ClickHouse native TCP `9000` от `st-ex-statistics` для миграций, inserts, reads и mutations; ClickHouse HTTP `8123` для `/ping`, стандартных инструментов и исторических `wait-depends` проверок; interserver TCP `9009`, экспонированный образом ClickHouse. В конфигурации продуктового контура host-порты не опубликованы: Docker показывает только внутренние `8123/tcp`, `9000/tcp`, `9009/tcp`.
Исходящие вызовы	Прикладных исходящих вызовов не предусмотрено. Контейнер не ходит в REST/gRPC, Kafka, PostgreSQL, MinIO/S3 или другие сервисы; он отвечает SQL-клиентам и пишет состояние в локальное ClickHouse-хранилище.
Протоколы	ClickHouse native TCP, ClickHouse HTTP, ClickHouse interserver TCP, файловый ввод-вывод ClickHouse в data directory, stdout/stderr для логов. Публичных REST, gRPC и Kafka-контрактов у sidecar нет.
Хранилища	Основное состояние хранится в `/var/lib/clickhouse`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/statistics/event-ex-clickhouse-data` -> `/var/lib/clickhouse`. В базе `default` присутствуют таблицы `camera`, `category`, `object`, `stay_zone_event`, `zone`.
Конфигурация	Сервис использует generic image `docker.vizorlabs.ru/docker-images/click-house` с портами `8123`, `9000`, `9009` и переменными `CLICKHOUSE_CONFIG`, `TZ`, `LANG`, `LANGUAGE`, `LC_ALL`. В конфигурации продуктового контура запущен образ `docker.vizorlabs.ru/docker-images/click-house:24.6.1`, ClickHouse отвечает версией `24.6.1.4423`; Docker healthcheck и restart policy не заданы. Значения env и параметры доступа не выводились и не фиксируются.
Логирование	ClickHouse пишет технологические логи в `stdout`/`stderr` контейнера и стандартные файлы `/var/log/clickhouse-server/clickhouse-server.log` / `.err.log` внутри контейнера; в конфигурации продуктового контура Docker log driver — `loki`. Бизнес-логи Kafka ingest, миграционного сценария и обработки stay-zone событий нужно смотреть в `st-ex-statistics`.
Мониторинг	Собственного `/metrics` и Docker healthcheck в текущей конфигурации не предусмотрено. Практические проверки: контейнер `statistics-st-ex-statistics-clickhouse-1` в состоянии `Up`, `GET /ping` на `127.0.0.1:8123` возвращает `Ok.`, `clickhouse-client SELECT version()` возвращает `24.6.1.4423`, а `system.tables` содержит ожидаемые таблицы расширенной статистики.
Критичность	Высокая для расширенной статистики по пребыванию объектов в зонах и связанных SQL-выборок. Отказ sidecar не должен останавливать весь событийный pipeline BOX5-DIT-MGSN, но ломает запись и чтение денормализованного ClickHouse-шарда `st-ex-statistics`; накопленный Kafka backlog и восстановление данных зависят от поведения родительского ingester.
Эксплуатационные особенности и известные ограничения	Это generic ClickHouse sidecar без собственного прикладного API, бизнес-валидации, метрик и healthcheck. `st-ex-statistics` переигрывает SQL-файлы миграций при старте без отдельной таблицы `schema_versions` и advisory lock, поэтому порядок и идемпотентность миграций критичны для запуска. ClickHouse mutations асинхронны: переименования камер/объектов, обновления моделей и удаления могут становиться видимыми в аналитике с задержкой. Потеря volume `/var/lib/clickhouse` означает потерю shard-состояния и требует восстановления из upstream-событий/справочников, если оно поддержано родительским сервисом.

`st-object-visit-zone-counter`¶

Поле	Описание
Название сервиса	`st-object-visit-zone-counter` (`box-statistics/object-vizit-zone-counter`). В конфигурации продуктового контура задан контейнер `statistics-st-object-visit-zone-counter-1` с образом `docker.vizorlabs.ru/box-statistics/object-visit-zone-counter:1.1.1`; сервис доступен только во внутренней Docker-сети на `3000/tcp`.
Назначение	Сервис учёта посещения объектов через зоны входа/выхода. Хранит список отслеживаемых объектов, их привязки к зонам камер, текущую численность людей, расписания сброса и историю событий зон; отдаёт эти данные UI для разделов управления персоналом / объектов посещения и статистики входа-выхода. При превышении заданного максимума на входе может сформировать стандартное событие нарушения для общего событийного контура.
Подсистема	`statistics`, контур счётчиков входа-выхода и объектных посещений. Работает вместе с `inf-kafka`, `st-object-visit-zone-counter-postgres`, `st-camera-storage`, `inf-nri-inference` и REST-шлюзом `ui-rest-to-gprc`; downstream-события далее обрабатываются обычным pipeline событий статистики.
Основные функции	CRUD списка отслеживаемых объектов (`AddObjectVisitList`, `AddObjectVisit`, `GetObjectVisit`, `UpdateObjectVisit`, `DeleteObjectVisit`, `GetObjectVisitList`); настройка расписания сброса (`UpdateObjectVisitResetSchedule`); выдача истории и агрегатов (`GetVisitEventList`, `GetAggregatedObjectVisitData`); зеркалирование камер и зон из Kafka; обработка входа/выхода через `AddEvent`; инкремент/декремент `current_persons_count`; периодический сброс счётчика по расписанию; публикация overflow-события при превышении `max_persons_count`.
Входящие вызовы	HTTP/gRPC на `:3000`, путь `/grpc/box.statistic.object_visit_zone_counter.ObjectVisitZoneCounter/<Method>`, основной синхронный клиент - `ui-rest-to-gprc` для REST-маршрутов статистики. Kafka consumers читают fan-out топики камер `statistic_camera_add`, `statistic_camera_update`, `statistic_camera_del`, топик моделей `models_storage_ready` / `cmd_add_or_update_models_info` и входной поток entry/exit событий `object_visit_zone_event`. `GET /metrics` заявлен как входящая поверхность, но в конфигурации продуктового контура вернул HTTP `500`.
Исходящие вызовы	PostgreSQL `st-object-visit-zone-counter-postgres:5432` для миграций Aerich, чтения и записи объектов посещения, зон, расписаний сброса и истории `zone_events`. Kafka producer публикует превышение вместимости в `KAFKA_TOPIC_ADD_EVENT` с protobuf `ViolationEvent`; в конфигурации продуктового контура переменная задана как `inference_send_event`. Исходящих HTTP/gRPC/MinIO/ClickHouse вызовов в текущей конфигурации не предусмотрено.
Протоколы	HTTP/gRPC, Prometheus text exposition для `/metrics` по контракту, Kafka protobuf-сообщения, PostgreSQL wire protocol через Tortoise ORM/Aerich, stdout/stderr для логов контейнера.
Хранилища	Основное состояние в `st-object-visit-zone-counter-postgres`: `cameras`, `camera_zones`, `object_visits`, `object_visits_camera_zones`, `object_visit_reset_schedules`, `zone_events`, `aerich`. У контейнера приложения в конфигурации продуктового контура постоянные mounts не предусмотрены; runtime-очередь Kafka producer и фоновые задачи живут в процессе.
Конфигурация	Ключевые переменные: `PORT` (дефолт `3000`), `SETTINGS_FILE`, `DEBUG`, `DEPENDS`, `POSTGRES_`, `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_STATISTIC_CAMERA_`, `KAFKA_TOPIC_STATISTIC_CMD_ADD_OR_UPDATE_MODELS_INFO`, `KAFKA_TOPIC_OBJECT_VISIT_ZONE_EVENT`, `KAFKA_TOPIC_ADD_EVENT`, `ENTRANCE_EXIT_ZONE_ZID`, `ENTRANCE_SECONDARY_CATEGORY`, `EXIT_SECONDARY_CATEGORY`, `PERSON_COUNTER_EVENT_SECONDARY_CATEGORY_MORE`, `PERSON_COUNTER_EVENT_SECONDARY_CATEGORY_LESS`. В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `DEBUG=False`, `DEPENDS=["inf-kafka:9092","st-object-visit-zone-counter-postgres:5432"]`, `POSTGRES_HOST=st-object-visit-zone-counter-postgres`, `KAFKA_HOST=inf-kafka:9092`, `KAFKA_GROUP=object-visit-zone-counter`, категории `enter_zone` / `exit_zone` / `more_persons_count` / `less_persons_count`; значения параметров доступа не фиксируются.
Логирование	Приложение, Uvicorn/gRPC-обвязка, Kafka consumers/producers, Aerich-миграции и фоновый сброс счётчиков пишут в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver - `loki`. В логах контура видна проблема подписки Kafka на пустой topic, что соответствует пустому значению `KAFKA_TOPIC_OBJECT_VISIT_ZONE_EVENT` в контейнере.
Мониторинг	Docker healthcheck не задан, `RestartPolicy=always`. По контракту доступен `GET /metrics`, но на контейнере продуктового контура endpoint отвечает `500`, поэтому практические проверки: состояние контейнера, доступность PostgreSQL и ожидаемых таблиц, отсутствие ошибок Kafka consumer, consumer lag группы `object-visit-zone-counter`, успешные read-only gRPC-вызовы истории/агрегатов через `ui-rest-to-gprc`.
Критичность	Высокая для функций входа-выхода, текущей численности и UI-истории объектов посещения: отказ сервиса останавливает обновление счётчиков, CRUD конфигурации, агрегаты и генерацию overflow-событий. Основной event-storage pipeline может продолжить работу для других типов событий, но объектные посещения станут неполными или устареют; потеря PostgreSQL volume означает потерю настроек, расписаний и истории посещений.
Эксплуатационные особенности и известные ограничения	Обрабатываются только события с `zone_zid=ENTRANCE_EXIT_ZONE_ZID` и вторичной категорией `enter_zone` или `exit_zone`. Если несколько `object_visit` привязаны к одной камере и поддерживаемому `zone_zid`, обновляется первый объект из выборки по возрастанию id. `AddObjectVisitList` работает как full-replace и удаляет отсутствующие в запросе записи. По service spec обработчик model-info фактически не использует payload, `PERSON_COUNTER_EVENT_SECONDARY_CATEGORY_LESS` определён, но under-capacity события не публикуются, а `last_reset_timestamp` не обновляется. В конфигурации продуктового контура дополнительно зафиксированы пустой `KAFKA_TOPIC_OBJECT_VISIT_ZONE_EVENT`, ошибки `'' is not a valid topic name`, неисправный `/metrics` и отсутствие Docker healthcheck; в конфигурации продуктового контура запущен образ `1.1.1`, тогда как часть ограничений относится к аудиту `1.2.3`.

`st-object-visit-zone-counter-postgres`¶

Поле	Описание
Название сервиса	`st-object-visit-zone-counter-postgres` (`docker-images/postgres`). В конфигурации продуктового контура задан контейнер `statistics-st-object-visit-zone-counter-postgres-1` в compose-проекте `statistics`, сервис `st-object-visit-zone-counter-postgres`, образ `docker.vizorlabs.ru/vizorlabs/postgres:13.1`.
Назначение	PostgreSQL-хранилище прикладного сервиса `st-object-visit-zone-counter`. Сервис хранит данные счётчика посещений объектов: локальное зеркало камер и зон, наблюдаемые объекты, связи объектов с зонами, расписания сброса, историю событий зон и состояние миграций. Сам контейнер не обрабатывает Kafka-события, не считает входы/выходы и не генерирует нарушения.
Подсистема	`statistics`, контур счётчиков входа-выхода и объектных посещений. Работает как stateful sidecar для `st-object-visit-zone-counter`; downstream UI/API-потоки проходят через приложение и `ui-rest-to-gprc`, а не напрямую в БД.
Основные функции	Запускает PostgreSQL 13.1; инициализирует БД и пользователя через `POSTGRES_DB`, `POSTGRES_USER`, `POSTGRES_PASSWORD`; принимает миграции Aerich от `st-object-visit-zone-counter`; хранит таблицы `cameras`, `camera_zones`, `object_visits`, `object_visits_camera_zones`, `object_visit_reset_schedules`, `zone_events`, `aerich`; обеспечивает SQL-чтение для истории и агрегатов посещений.
Входящие вызовы	PostgreSQL wire protocol на `5432/tcp` из внутренней Docker-сети. Штатный прямой клиент - `st-object-visit-zone-counter`, который на старте ждёт `st-object-visit-zone-counter-postgres:5432`, выполняет миграции и далее читает/пишет прикладную схему через Tortoise ORM/Aerich. Host-порт в конфигурации продуктового контура не опубликован (`5432/tcp` доступен только внутри compose-сети).
Исходящие вызовы	Прикладных исходящих сетевых вызовов нет: контейнер не обращается к HTTP/gRPC API, Kafka, ClickHouse, MinIO/S3 или другим сервисам. Запись состояния выполняется в локальный `PGDATA`; ответы клиентам идут в рамках входящих PostgreSQL-соединений.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`; файловый ввод-вывод PostgreSQL в `PGDATA`; stdout/stderr для технологических логов контейнера. REST, gRPC, Kafka и Prometheus endpoint у sidecar отсутствуют.
Хранилища	Основное состояние в `/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/statistics/pgdata-object-visit-zone-counter` -> `/var/lib/postgresql/data`. База `dnn` содержит таблицы `aerich`, `cameras`, `camera_zones`, `object_visits`, `object_visits_camera_zones`, `object_visit_reset_schedules`, `zone_events`. Отдельного контейнера `*-postgres-backup` для этого сервиса в конфигурации продуктового контура не предусмотрено.
Конфигурация	В конфигурации продуктового контура заданы открытые параметры: `POSTGRES_DB=dnn`, `POSTGRES_USER=dnn`, `PGDATA=/var/lib/postgresql/data`, `PG_MAJOR=13`, `PG_VERSION=13.1-1.pgdg100+1`; также присутствуют env-ключи `POSTGRES_PASSWORD`, `GOSU_VERSION`, `LANG`, `PATH`. Значение `POSTGRES_PASSWORD` не фиксируется. Для конфигурации продуктового контура закреплён image-tag `13.1` с датой pinning `2026-04-13`; Docker restart policy - `always`, shm size - стандартные `64 MiB`.
Логирование	PostgreSQL пишет логи старта, подключений, ошибок и shutdown в stdout/stderr контейнера; в конфигурации продуктового контура Docker log driver - `loki` с ротацией. Бизнес-логи миграций, Kafka-обработки, CRUD и агрегатов нужно смотреть в `st-object-visit-zone-counter`, потому что БД не знает прикладный контекст запросов.
Мониторинг	Docker healthcheck не задан, собственного `/metrics` нет. Практические проверки: контейнер `statistics-st-object-visit-zone-counter-postgres-1` в состоянии `running`, `pg_isready` внутри контейнера отвечает `accepting connections`, `psql SELECT version()` возвращает PostgreSQL `13.1`, а список таблиц public-схемы совпадает с ожидаемой схемой сервиса.
Критичность	Высокая для функций входа-выхода и объектных посещений. Отказ БД блокирует стартовые миграции и runtime-запись `st-object-visit-zone-counter`, ломает CRUD наблюдаемых объектов, расписания сброса, текущие счётчики, историю `zone_events` и агрегаты для UI. Остальные статистические сервисы и общий event-storage pipeline могут продолжить работу, но данные объектных посещений станут недоступны или устареют.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без прикладного API, собственной бизнес-валидации, healthcheck и Prometheus-метрик. Схема полностью принадлежит `st-object-visit-zone-counter` и меняется миграциями Aerich из приложения; ручные изменения БД могут нарушить ORM-контракт. Потеря bind mount `PGDATA` означает потерю настроек объектов посещения, расписаний, локального зеркала камер/зон и истории событий; восстановление зависит от доступных бэкапов и возможности заново получить справочники/события из upstream. БД не публикует host-порт и должна использоваться только внутренними сервисами compose-сети.

`st-virt-cam-video-upload`¶

Поле	Описание
Название сервиса	`st-virt-cam-video-upload` (`statistics/virt-cam-video-upload`). В конфигурации продуктового контура развёрнут как контейнер `statistics-st-virt-cam-video-upload-1` с образом `docker.vizorlabs.ru/statistics/virt-cam-video-upload:dev`; сервис доступен только во внутренней Docker-сети на `3000/tcp`.
Назначение	Хранит подготовленные видеофайлы для виртуальных камер статистического контура, принимает загрузки из UI и интеграций, готовит файл к воспроизведению и привязывает его к виртуальной камере. После готовности файла обновляет `media_uri` камеры в `st-camera-storage`, чтобы видеопоток был доступен как статический файл сервиса.
Подсистема	`statistics`, контур управления камерами и объектами, сценарий загрузки видео для виртуальных камер. Работает вместе с `ui-rest-to-gprc`, `st-camera-storage`, `inf-kafka` и `st-virt-cam-video-upload-postgres`.
Основные функции	CRUD и список видеофайлов через gRPC (`UploadVideo`, `GetVideo`, `GetVideoList`, `DeleteVideo`, `TranscodeVideo`); compatibility-загрузка multipart-файла через `POST /upload-file/`; отдача готового файла через `GET /static/{video_name_on_disk}` с поддержкой `Range` и `206 Partial Content`; фоновая подготовка видео (`moov`/faststart, конвертация в MP4, перекодирование неподдерживаемых кодеков в H.264 через `ffmpeg`/`ffprobe`); локальное зеркало камер из Kafka; привязка файла к виртуальной камере через `SetVideoForCamera` и чтение текущей привязки через `GetCameraVideoId`; отложенная привязка через `camera_video_queue`, если камера ещё не пришла в локальное зеркало.
Входящие вызовы	HTTP/gRPC на `:3000`, включая `UploadVideo`, `GetVideo`, `GetVideoList`, `DeleteVideo`, `TranscodeVideo`, `SetVideoForCamera`, `GetCameraVideoId`, `GetCamera`, служебный `FlushDb`; REST `POST /upload-file/` и `GET /static/{video_name_on_disk}`; `GET /metrics` для Prometheus. Синхронный клиент продуктового контура - `ui-rest-to-gprc`; браузерские скачивания проходят через gateway. Kafka consumers читают `statistic_camera_add`, `statistic_camera_update`, `statistic_camera_del` от `st-camera-storage` через `inf-kafka`.
Исходящие вызовы	PostgreSQL `st-virt-cam-video-upload-postgres:5432` для метаданных видео, зеркала камер и очереди привязок; HTTP/gRPC в `st-camera-storage` (`GetCamera`, `UpdateCamera`) для записи `camera.media_uri = {SERVICE_HOSTNAME}/static/{name_on_disk}`; файловые операции в `VIDEO_DIR_INSIDE`; локальные subprocess-вызовы `ffmpeg`/`ffprobe`. Прямой Kafka producer в версии не предусмотрен: fan-out обновлённой камеры происходит косвенно через `st-camera-storage`.
Протоколы	HTTP/gRPC, HTTP/REST multipart upload, HTTP static download с `Range`, Prometheus text exposition, Kafka consumer protocol, PostgreSQL wire protocol через Tortoise ORM/Aerich, файловый ввод-вывод, stdout/stderr для логов контейнера.
Хранилища	Видео хранятся в `VIDEO_DIR_INSIDE=/videos`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/vc_videos` -> `/videos`. Метаданные и связи хранятся в `st-virt-cam-video-upload-postgres`: таблицы `videofile`, `cameras`, `camera_video_queue`, `aerich`; в конфигурации продуктового контура присутствует 38 готовых записей `videofile` и 207 записей отложенной очереди. У контейнера приложения других persistent mounts не предусмотрено.
Конфигурация	Ключевые переменные: `PORT`, `SETTINGS_FILE`, `DEBUG`, `DEPENDS`, `POSTGRES_`, `VIDEO_DIR_INSIDE`, `VIDEO_DIR_OUTSIDE`, `VIDEO_DIR_WEB`, `VIDEO_URL_PREFIX`, `SERVICE_HOSTNAME`, `CAMERA_STORAGE`, `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_STATISTIC_CAMERA_ADD`, `KAFKA_TOPIC_STATISTIC_CAMERA_UPDATE`, `KAFKA_TOPIC_STATISTIC_CAMERA_DEL`, `TZ`. В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `DEBUG=false`, `DEPENDS=["inf-kafka:9092", "st-virt-cam-video-upload-postgres:5432"]`, `POSTGRES_HOST=st-virt-cam-video-upload-postgres`, `VIDEO_DIR_OUTSIDE=/data/compose-data2-no-swarm/vc_videos`; остальные значения берутся из настроек образа, конфиденциальные `POSTGRES_` значения не фиксируются.
Логирование	Приложение использует Loguru, Uvicorn/gRPC/REST-обвязку и пишет обработку загрузок, удаления, фоновой подготовки, Kafka mirror handlers, `SetCameraVideo`, ошибки `ffmpeg`/`ffprobe` и stack traces в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver - `loki`. В логах контура присутствуют static-download запросы с ответом `206 Partial Content`.
Мониторинг	Docker healthcheck не задан, `RestartPolicy=always`. `GET /metrics` внутри контейнера в конфигурации продуктового контура отвечает HTTP `200` и отдаёт Prometheus-метрики. Практические проверки: контейнер `statistics-st-virt-cam-video-upload-1` в состоянии `Up`, Postgres sidecar доступен и содержит ожидаемые таблицы, static download отдаёт `206` для range-запросов, Kafka consumer lag группы `virt-cam-video-upload` не растёт, размер `camera_video_queue` контролируется как индикатор отставания зеркала камер.
Критичность	Высокая для работы виртуальных камер: отказ сервиса ломает загрузку, подготовку, список, скачивание и привязку видео, а также оставляет у камер пустой или устаревший `media_uri`. Основной `st-camera-storage` и другие типы камер могут продолжить работу, но виртуальные камеры, использующие uploaded media, деградируют; потеря Postgres или `/videos` приводит к рассинхронизации метаданных и файлов.
Эксплуатационные особенности и известные ограничения	`UploadVideo` принимает только `mp4` и `mov`; расширенная загрузка через `/upload-file/` зависит от фоновой очереди и `ffmpeg`/`ffprobe`, поэтому сбой подготовки оставляет запись с `is_ready=false` и без обновления `media_uri`. `SetVideoForCamera` разрешён только для камер типа `VIRTUAL`; если Kafka-зеркало камеры отстаёт, привязка уходит в `camera_video_queue` и камера сохраняет старый `media_uri` до получения события; в конфигурации продуктового контура в конфигурации продуктового контура уже было 207 таких записей. Прямой Kafka producer отсутствует, а обновление downstream-зеркал зависит от успешного `UpdateCamera` в `st-camera-storage`. Docker healthcheck отсутствует; в конфигурации продуктового контура используется непинованный тег `dev`, а локальный compose репозитория монтирует `/videos` как tmpfs, что отличается от реального persistent bind mount.

`st-virt-cam-video-upload-postgres`¶

Поле	Описание
Название сервиса	`st-virt-cam-video-upload-postgres`. В конфигурации продуктового контура развёрнут как контейнер `statistics-st-virt-cam-video-upload-postgres-1` в compose-проекте `statistics`, образ `docker.vizorlabs.ru/docker-images/postgres:13.1`; порт `5432/tcp` доступен только во внутренней Docker-сети.
Назначение	PostgreSQL-хранилище сервиса `st-virt-cam-video-upload`. Сохраняет метаданные загруженных видео, локальное зеркало камер, очередь отложенных привязок камера-видео и состояние миграций Aerich. Сам контейнер не реализует бизнес-функции загрузки, подготовки или привязки видео и не предоставляет прикладной API.
Подсистема	`statistics`, контур управления виртуальными камерами и загрузки видео. Sidecar расположен рядом с `st-virt-cam-video-upload`, который владеет схемой, запускает миграции, читает и изменяет данные, а сами видеофайлы хранит на отдельном filesystem mount.
Основные функции	Инициализация базы по `POSTGRES_*` при первом старте; приём PostgreSQL-подключений от `st-virt-cam-video-upload`; хранение таблиц, индексов, WAL и служебных файлов в `PGDATA`; предоставление состояния для Aerich-миграций и ORM-запросов родительского сервиса. Ключевая доменная нагрузка sidecar - долговременная очередь `camera_video_queue`, благодаря которой привязки к ещё не зеркалированным камерам переживают рестарты приложения.
Входящие вызовы	PostgreSQL-подключения на `5432/tcp` из внутренней Docker-сети. Основной клиент - `st-virt-cam-video-upload`: при старте он ждёт БД, выполняет миграции, затем использует Tortoise ORM для CRUD `videofile`, чтения/обновления зеркала `cameras` и записи/разбора `camera_video_queue`. Host-порт в конфигурации продуктового контура не опубликован.
Исходящие вызовы	Прикладных сетевых вызовов нет. Контейнер не обращается к REST, gRPC, Kafka, MinIO, ClickHouse, `st-camera-storage` или файловому каталогу видео; он отвечает SQL-клиентам и пишет состояние PostgreSQL в подключённый каталог `PGDATA`.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`; локальные файловые операции PostgreSQL в `PGDATA`; `stdout`/`stderr` для технологических логов. HTTP, REST, gRPC, Kafka, Prometheus и S3/MinIO-интерфейсов у sidecar нет.
Хранилища	Основное состояние в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/statistics/st-virt-cam-video-upload` -> `/var/lib/postgresql/data`. В схеме контура присутствуют таблицы `aerich`, `camera_video_queue`, `cameras`, `videofile`; в конфигурации продуктового контура - 38 записей `videofile` и 207 записей `camera_video_queue`. Видеофайлы хранятся вне этой БД, в `/videos` контейнера `st-virt-cam-video-upload`; PostgreSQL хранит только метаданные, состояние подготовки и связи с камерами.
Конфигурация	Env-only конфигурация shared PostgreSQL image: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`, `PATH`. По спецификации defaults для прикладной БД - `POSTGRES_DB=dnn`, `POSTGRES_USER=dnn`, `PGDATA=/var/lib/postgresql/data`; значения параметров доступа не фиксируются. В конфигурации продуктового контура заданы PostgreSQL `13.1`, `RestartPolicy=always`, Docker log driver `loki`, отсутствие Docker healthcheck и внутренний порт `5432/tcp` без публикации на host.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. В этих логах ожидаемы старт БД, готовность принимать подключения и ошибки SQL/миграций; ошибки загрузки файлов, `ffmpeg`/`ffprobe`, Kafka mirror handlers и вызовов `st-camera-storage` нужно смотреть в `st-virt-cam-video-upload`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck нет. Практические проверки: контейнер `statistics-st-virt-cam-video-upload-postgres-1` находится в состоянии `running`, `pg_isready` внутри контейнера возвращает `accepting connections`, SQL-подключение к рабочей БД успешно, а в схеме есть `videofile`, `cameras`, `camera_video_queue` и `aerich`. Размер `camera_video_queue` полезен как индикатор отставания зеркала камер в родительском сервисе.
Критичность	Высокая для сценариев виртуальных камер. Отказ БД блокирует нормальный старт и миграции `st-virt-cam-video-upload`, список и состояние загруженных видео, привязку файлов к виртуальным камерам и восстановление отложенных привязок после рестарта. Основной `st-camera-storage` и другие типы камер могут продолжить работу, но виртуальные камеры с uploaded media деградируют; потеря volume означает потерю метаданных и связей даже при сохранённых видеофайлах.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без собственной бизнес-логики, публичного API, метрик и healthcheck. Схемой и миграциями управляет `st-virt-cam-video-upload`; контейнер не валидирует тип камеры, не готовит видео и не обновляет `media_uri`. База не хранит сами видеофайлы, поэтому возможен рассинхрон между строками `videofile` и содержимым `/videos`. В compose-метках отдельный backup-sidecar для этой БД не предусмотрен, поэтому долговечность зависит от корректного bind mount и внешних процедур резервного копирования.

`st-domain-gateway`¶

Поле	Описание
Название сервиса	`st-domain-gateway` (`statistics/st-domain-gateway`). В конфигурации продуктового контура развёрнут как контейнер `statistics-st-domain-gateway-1` с образом `docker.vizorlabs.ru/docker-images/nginx-1.18:master`; это типовой Nginx-контейнер со смонтированной конфигурацией статистического домена.
Назначение	Тонкий Nginx-шлюз для statistics-side объектных URL: публикует префикс `/api/s3/` на внутреннем HTTP listener и проксирует его в MinIO `ds-minio:9000`. Используется для стабильных ссылок вида `/api/s3/event-storage/...` и `/api/s3/camera-storage/...`; бизнес-API, авторизацию и хранение данных сам не реализует.
Подсистема	`statistics`, контур доступа к объектам и медиафайлам, которые статистические сервисы сохраняют в MinIO. Работает рядом с сервисами, формирующими `/api/s3/...` ссылки, и с нижестоящим хранилищем `ds-minio`; не является внешним UI edge всего решения.
Основные функции	HTTP reverse proxy для `location /api/s3/`; удаление префикса `/api/s3/` при проксировании за счёт `proxy_pass http://ds-minio:9000/`; передача `X-Forwarded-For` и `Host`; отключение `proxy_redirect`; приём крупных запросов до `client_max_body_size 500M`; Nginx access/error логирование. Другие активные `location` в конфиге отсутствуют.
Входящие вызовы	Внутренний HTTP на `:8000` от сервисов или gateway-контейнеров, которые обращаются к `http://st-domain-gateway:8000/api/s3/...`. В конфигурации продуктового контура host-порты не опубликованы (`PortBindings={}`); Docker-метаданные образа показывают `80/tcp`, но фактическая конфигурация Nginx слушает `8000`. Запросы на `/` возвращают `404`; текущий `ui-nginx` в конфигурации продуктового контура также имеет собственный прямой маршрут `/api/s3/ -> ds-minio:9000`, поэтому часть браузерного трафика может обходить `st-domain-gateway`.
Исходящие вызовы	Единственный активный upstream - HTTP к `ds-minio:9000` для всех запросов под `/api/s3/`. Прямых вызовов к PostgreSQL, ClickHouse, Kafka, Redis, gRPC, `st-auth` или другим statistics-сервисам в текущем исходном и live-конфиге нет.
Протоколы	HTTP/1.x reverse proxy; S3-compatible HTTP upstream MinIO; файловое чтение смонтированного `nginx.conf`; stdout/stderr для логов контейнера. gRPC, WebSocket, Kafka, PostgreSQL, ClickHouse и Prometheus exposition сервисом не используются.
Хранилища	Собственного persistent storage нет. Контейнер читает только `/etc/nginx/conf.d/default.conf`, смонтированный из `statistics/configs/nginx.conf`; объектные данные находятся в `ds-minio` и не принадлежат `st-domain-gateway`. БД, Redis, Kafka state, локальные media volume и прикладные каталоги не подключены.
Конфигурация	Источник истины - `box3/box3-statistics-solution`: compose-сервис `st-domain-gateway` с `restart: always`, внешней сетью `${NETWORK_NAME}` и `configs/nginx.conf`. В non-swarm режиме конфиг подключается bind mount `./configs/nginx.conf:/etc/nginx/conf.d/default.conf`, в swarm - Docker config `st_nginx_config`. Собственных env-переменных не задаётся; рабочие параметры маршрута заданы в Nginx (`listen 8000`, `client_max_body_size 500M`, `fastcgi_read_timeout 300`, `proxy_read_timeout 300`).
Логирование	Nginx пишет access/error logs в `/var/log/nginx/access.log` и `/var/log/nginx/error.log`; в контейнере они доступны через `docker logs statistics-st-domain-gateway-1`. В конфигурации продуктового контура Docker log driver - `loki`. Логи содержат HTTP-метод, путь, код ответа и ошибки upstream/файлового поиска; сырые URL объектного доступа и query-параметры не следует публиковать без редактирования.
Мониторинг	Docker healthcheck не задан, `/metrics`, `/health` и `stub_status` не настроены. Проверка в конфигурации продуктового контура: контейнер `Up`, `GET /api/s3/` внутри контейнера возвращает upstream-ответ MinIO `403` для корня без авторизации, `GET /metrics` и `GET /health` возвращают `404`. Практический мониторинг - состояние контейнера, доступность `ds-minio:9000`, HTTP-коды `/api/s3/...` и ошибки Nginx в Loki/docker logs.
Критичность	Средняя. Отказ сервиса ломает только те объектные ссылки и скачивания, которые проходят именно через `st-domain-gateway`; запись событий, загрузка объектов в MinIO и большинство backend-сервисов продолжают работать напрямую. При этом для клиентов, использующих `http://st-domain-gateway:8000/api/s3/...`, недоступность шлюза проявляется как потеря изображений, документов или видеофрагментов из statistics-контуров.
Эксплуатационные особенности и известные ограничения	Активный маршрутный набор минимален: только `/api/s3/ -> ds-minio:9000`. Старые маршруты приложения статистики встречаются в историческом `box-statistics/domain-gateway` или закомментированы, но на текущем контуре BOX5-DIT-MGSN не активны. Нет собственной авторизации, TLS, rate limiting, healthcheck и метрик; контейнер стартует даже при недоступном MinIO, а ошибки проявляются только на запросах. Фактический контракт задаёт смонтированный `nginx.conf`, поэтому тег generic Nginx-образа и `ExposedPorts=80/tcp` не описывают реальный listener и маршруты.

`inference`¶

Назначение: обработка видеопотоков, выполнение NRI-сценариев, хранение модельной и оперативной информации для инференса.

`inf-nri-inference`¶

Поле	Описание
Название сервиса	`inf-nri-inference` (`node-red-integration/node-red-inference`)
Назначение	Основной runtime Node-RED Inference в BOX5-DIT-MGSN: выполняет NRI-сценарии для видеопотоков камер и публикует результаты инференса, прикладные события и heartbeat-телеметрию в Kafka.
Подсистема	`inference`, контур NRI. Работает рядом с `inf-mediaserver`, `inf-kafka`, `svr-scenario-storage`, `svr-models-registry`, `inf-flows-manager`, `node-red-vl`, `yolo_conversion` и `mm_conversion`.
Основные функции	Запускает supervisor `tools/entrypoint/launch.py`, два процесса `tsm_inference.py` на GPU `0` и процесс `models_manager_service.py`; принимает кадры по NNG IPC-очередям `queue_<camera_id>`; собирает и выполняет графы Node-RED из NRI-нод детекции, классификации, трекинга, зон, PRR/3D, визуализации и отправки событий; загружает модели из `/models` через `vlflow`/MLflow/fs; реагирует на Kafka-события жизненного цикла моделей; опционально сохраняет видео/события online saver.
Входящие вызовы	Публичного HTTP/gRPC API и опубликованных host-портов нет. Основной входящий поток — кадры от `inf-mediaserver` через NNG IPC `ipc://${INFERENCE_IPC_DIRECTORY}/queue_<camera_id>` в общем IPC-каталоге и `/dev/shm`. Также сервис потребляет Kafka-топики управления моделями: `models_storage_ready`, `model_version_ready`, `model_version_updated`, `model_version_deleted`.
Исходящие вызовы	Kafka produce в основные топики инференса и телеметрии: `event_update`, `make_severstal_event`, `save_rejected_severstal_event` при настройке rejected-потока, `make_defect_event`, `finish_defect_event`, `camera_nri_state_heartbeat`, `models_summary_heartbeat`, `tsm_process_stats_heartbeat`, `camera_error_log`, `error_log`. HTTP-запросы к `svr-scenario-storage` (`/get-scenarios/simple-info/`, `/get-flow-json-file/`), `svr-models-registry`/`VLFLOW_ENDPOINT`, MLflow/S3/MinIO для артефактов моделей, `ui-rest-to-gprc`/Box API для отдельных внешних справочников и `svr-severstal-integration` для данных ДИТ-МГСН. Для конвертации моделей использует Unix-socket endpoints `YOLO_CONVERSION_URI` и `MMLAB_CONVERSION_URI`.
Протоколы	NNG IPC поверх Unix-сокетов; shared memory через `/dev/shm`; Kafka; HTTP/REST к storage/registry/API сервисам; S3-compatible API для MinIO/MLflow artifacts; Unix sockets для `yolo_conversion` и `mm_conversion`; Docker stdout/stderr и файловые логи subprocess-ов.
Хранилища	Собственной БД нет. В конфигурации продуктового контура смонтированы `/inference_ipc`, `/dev/shm`, `/models`, `/video-storage`, `/events-storage`, `/log`, `/tmp`, `/converts`, `/opt/tests`, `/proc` и файл `.env` приложения. Долговременные сценарии хранятся в `svr-scenario-storage`, модели — в registry/MLflow/MinIO и локальном `/models`, события — в Kafka и downstream-хранилищах статистики.
Конфигурация	В конфигурации продуктового контура контейнер `inference-inf-nri-inference-1` запущен в compose-проекте `inference` из `/home/vizorlabs/CODE/box3/inference`, образ `docker.vizorlabs.ru/vizorlabs/node-red-inference:v1.19.3`, `restart: always`, `ipc: host`, `cap_add: SYS_PTRACE`, сеть `bx_default`, alias `inf-nri-inference`, host-порты не опубликованы. Основные группы env: `KAFKA_HOST` и `KAFKA_TOPIC_`/`INFERENCE_KAFKA_TOPIC_`, `INFERENCE_IPC_DIRECTORY`, `MODELS_PATH`, `MODEL_REGISTRIES_PRIORITY`, `VLFLOW_`, `MLFLOW_`, `AWS_`, `YOLO_CONVERSION_URI`, `MMLAB_CONVERSION_URI`, `USE_GPU`/`USE_AUTO_LIST_GPU`/`LIST_GPU`, `BOX_URL`/`BOX_LOGIN`/`BOX_PASSWORD`, `SVR_SEVERSTAL_INTEGRATION`, `ONLINE_SAVER_`, `SAVE_*`, `LOGGING_LEVEL`, `ENABLE_TSM_FILE_LOGGING`, `TSM_PROCESS_HEARTBEAT_INTERVAL_SEC`. Значения конфиденциальных переменных не фиксируются в документации.
Логирование	Основной поток логов идёт в stdout/stderr контейнера и в конфигурации продуктового контура собирается Docker log driver `loki`. Supervisor пишет heartbeat вида `inference processes: [...] is working`; worker-процессы `tsm_inference.py` и `models_manager_service.py` пишут Loguru-сообщения, включая ошибки графов, загрузку моделей, отправку событий и predict-debug. При включённом файловом логировании отдельные subprocess-логи пишутся в смонтированный `/log`.
Мониторинг	Docker healthcheck и HTTP `/metrics` endpoint не предусмотрены. Практическая проверка: контейнер `running`, `RestartCount=0`, наличие процессов `launch.py`, двух `tsm_inference.py` и `models_manager_service.py`, свежие Docker/Loki-логи, отсутствие ошибок в EventSender/TSM, а также поступление Kafka heartbeat-топиков `camera_nri_state_heartbeat`, `models_summary_heartbeat`, `tsm_process_stats_heartbeat`, которые использует контур мониторинга.
Критичность	Высокая. Отказ сервиса останавливает выполнение NRI-сценариев по камерам BOX5-DIT-MGSN, прекращает выпуск событий и heartbeat-телеметрии; UI, storage и медиасервер могут оставаться доступны, но новые нарушения по NRI-сценариям не формируются.
Эксплуатационные особенности и известные ограничения	У сервиса нет публичного health/API endpoint, Prometheus-метрик и локального гарантированного буфера для событий при недоступности Kafka. Работоспособность зависит от GPU, shared memory/IPC mounts, `/models`, конвертеров моделей, scenario/model storage и корректности NRI-графов. Текущий код в конфигурации продуктового контура отправляет события ДИТ-МГСН в `make_severstal_event` только при наличии блока `Inconsistencies`, иначе использует rejected-поток при его настройке или fallback в `event_update`; сценарии без такого блока нужно проверять отдельно. Поведение runtime может определяться не только образом, но и host checkout `node-red-inference`, если он смонтирован в compose; перед изменениями нужно сверять фактические mounts и запущенный образ.

`inf-mediaserver`¶

Поле	Описание
Название сервиса	`inf-mediaserver` (`inference/inf-mediaserver`). В конфигурации продуктового контура развёрнут как контейнер `inference-inf-mediaserver-1` с образом `docker.vizorlabs.ru/box-inference/mediaserver:3.0.0`; основной HTTP/gRPC-порт `3000/tcp` доступен только во внутренней Docker-сети, debug HTTP работает на `4000/tcp`.
Назначение	Центральный медиасервер контура инференса: принимает назначенные балансировщиком камеры, открывает RTSP/file/специализированные media source, декодирует видеопоток, держит локальные буферы кадров, отдаёт HLS/WebRTC/JPEG/MJPEG-представления и передаёт кадры в `inf-nri-inference` через IPC/shared memory.
Подсистема	`inference`, runtime-видеоконтур BOX5-DIT-MGSN. Работает между `inf-load-balancer`, `inf-kafka`, `inf-monitoring`, `inf-image-storage`, `inf-nri-inference`, `ds-data-temporary-storage`, `inf-coturn` и, для камер `MEDIAMTX`, upstream-контуром `mtx-mediamtx`/`mtx-mediamtx-proxy`.
Основные функции	Регистрация экземпляра в `inf-load-balancer`; обработка команд `AddCamera`/`UpdateCamera`/`DeleteCamera`; запуск и перезапуск декодеров камер; генерация HLS-плейлистов и чанков для camera/inference/motion/multiply-потоков; обработка WebRTC offer; отдача текущего кадра через gRPC `GetImage` и прямые JPEG/MJPEG endpoints; публикация heartbeat, full-frame и preview-сообщений в Kafka; создание NNG `queue_<n>` и `.tsm` каналов для передачи кадров в NRI; watchdog обработки Kafka-команд и camera command runner.
Входящие вызовы	Kafka consumer читает per-instance topic с именем `INSTANCE_ID` с командами `KafkaCommand` от `inf-load-balancer`; HTTP/gRPC на `:3000` принимает `AddCamera`, `UpdateCamera`, `DeleteCamera`, `GetHlsPlaylist`, `GetHlsChank`, `GetHlsPlaylistMultiply`, `GetHlsChankMultiply`, `GetImage`, `ProcessWebRTCOffer`; прямые `GET /api/camera/stream/video/{jpeg,mjpeg}/...` отдают JPEG/MJPEG; debug `GET /api/status` на `:4000` возвращает состояние camera storage, decode, HLS/WebRTC и GPU; `inf-nri-inference` подключается к NNG IPC-сокетам в `/inference_ipc`.
Исходящие вызовы	Каждые 5 секунд отправляет HTTP/gRPC `RegisterMediaserver` в `inf-load-balancer` с hostname, node hostname и ресурсами узла; открывает RTSP/file/Milestone/V4L2/XMeye источники из `Camera.media_uri` и может публиковать RTSP наружу при включённом `RTSP_CLIENT_*`; пишет Kafka topics `camera_update_heartbeat`, `img_update`, `preview_update`; при `USE_DATA_STORAGE=true` отправляет JPEG payload в `ds-data-temporary-storage` и публикует UUID-ссылку; передаёт NNG control messages и `.tsm` frame channels в `inf-nri-inference`; пишет HLS-артефакты и служебные IPC-файлы в локальные mounts.
Протоколы	HTTP/gRPC protobuf, HTTP GET JPEG/MJPEG, HLS (`m3u8`/chunks через gRPC-прокси), WebRTC SDP/RTP, Kafka protobuf, RTSP pull/push, NNG IPC (`ipc://.../queue_<n>`), TSM/shared-memory files в `/dev/shm`, файловый ввод-вывод, stdout/stderr для логов контейнера.
Хранилища	Собственной БД нет. Runtime-состояние хранится в памяти процесса и во временных файлах: `/hls-server-data` для HLS-плейлистов/чанков, `/dev/shm/.tsm` для кадров в NRI, `/inference_ipc/queue_` для NNG-сокетов. В конфигурации продуктового контура заданы mounts `/data/compose-data2-no-swarm/inference_ipc -> /inference_ipc`, `/dev/shm -> /dev/shm`, `/data/compose-data2-no-swarm/inference/logs/mediaserver -> /log`, `/data/compose-data2-no-swarm/vc_videos -> /vc-videos`, `/home/vizorlabs/videos -> /home/vizorlabs/videos:ro`, `/home/vizorlabs/CODE/nodered -> /home/vizorlabs/CODE/nodered`. При включённом `USE_DATA_STORAGE` бинарные JPEG-данные выносятся во внешний `ds-data-temporary-storage`.
Конфигурация	Env-only конфигурация Docker Compose: `VIN_MEDIASERVER_VERSION`, `INSTANCE_ID`, `HTTP_SERVER_PORT`, `DEBUG_HTTP_SERVER_PORT`, `KAFKA_HOST`, `KAFKA_TOPIC_IMG_UPDATE`, `KAFKA_TOPIC_PREVIEW_UPDATE`, `KAFKA_TOPIC_CAMERA_UPDATE_HEARTBEAT`, `LOAD_BALANCER_HOST`, `LOAD_BALANCER_PORT`, `USE_DATA_STORAGE`, `DATA_STORAGE_URL`, `INFERENCE_IPC_DIRECTORY`, `INFERENCE_COUNT`/`LIST_GPU`, `INFERENCE_GROUPS`, `HLS_`, `WEBRTC_`, `DECODE_`, `WATCHDOG_`, `NVIDIA_VISIBLE_DEVICES`, `PEAR_RELAY_HOST`, `LICENSE_CAMS_EXCEEDED_IMG_WATERMARK_PATH`. В конфигурации продуктового контура заданы `VIN_MEDIASERVER_VERSION=3.0.0`, `KAFKA_HOST=inf-kafka:9092`, `LOAD_BALANCER_HOST=inf-load-balancer`, `LOAD_BALANCER_PORT=3000`, `USE_DATA_STORAGE=true`, `INFERENCE_IPC_DIRECTORY=/inference_ipc`, `HLS_CHANK_DURATION=2`, `HLS_PLAYLIST_LENGTH=2`, `HLS_VIDEO_BITRATE=1800`, `HLS_IMG_CACHING_TIME=20`, `DECODE_MAX_FPS=10`, `DECODE_HARDWARE_DECODE_ENABLED=false`, `WATCHDOG_ENABLED=true`, `NVIDIA_VISIBLE_DEVICES=all`; значения параметров доступа не фиксировались.
Логирование	Приложение использует Boost.Log и пишет в `stdout`/`stderr`; в коде 3.0.0 файловый sink закомментирован, хотя compose монтирует `/log`. В конфигурации продуктового контура Docker log driver - `loki`, `RestartPolicy=always`. В логах видны запуск/перезапуск, команды камер, gRPC-методы, Kafka consumption/produce, heartbeat `camera_update_heartbeat`, decode/GStreamer события, системная CPU/RAM-статистика и watchdog warnings/errors.
Мониторинг	Docker healthcheck не задан. Собственного Prometheus endpoint в конфигурации продуктового контура нет: `GET /metrics` на `:3000` возвращает `404`. Практические проверки: контейнер `inference-inf-mediaserver-1` в состоянии `Up`, debug `GET /api/status` на `:4000` отвечает `200`, в `/inference_ipc` есть активные `queue_`, в `/dev/shm` создаются парные `-to-inference-.tsm`/`-from-inference-*.tsm`, в логах идут heartbeat-сообщения, а downstream `inf-monitoring` и `inf-load-balancer` получают `camera_update_heartbeat` и регистрацию медиасервера.
Критичность	Критическая для онлайн-видео и событийного контура: отказ сервиса останавливает запуск назначенных камер, HLS/WebRTC/JPEG-представления, публикацию preview/full-frame в `inf-image-storage`, heartbeat для `inf-monitoring` и доставку кадров в `inf-nri-inference`; новые детекции и связанные события по этим камерам перестают появляться. Остальные storage/control-plane сервисы могут оставаться доступными, но без живого видеопотока их функции деградируют.
Эксплуатационные особенности и известные ограничения	В конфигурации продуктового контура используется major version `3.0.0`; он считается первый 3.0-контур с возможными API-несовместимостями относительно 2.x клиентов. Сервис не имеет собственной БД, healthcheck и Prometheus `/metrics`; диагностика опирается на debug `/api/status`, Docker/Loki-логи, Kafka lag/heartbeat и состояние IPC-файлов. `INSTANCE_ID` должен совпадать с hostname/topic, который знает `inf-load-balancer`, иначе команды камер не будут доставлены. IPC и `/dev/shm` являются node-local, поэтому `inf-mediaserver` и соответствующий NRI worker должны работать на одном узле; переполнение `/dev/shm` или HLS storage приводит к зависшим inference/HLS-потокам. При `USE_DATA_STORAGE=true` доступность кадров в Kafka зависит от `ds-data-temporary-storage`; debug/status и подробные логи могут содержать технические сведения о камерах, поэтому их нельзя публиковать без редактирования.

`inf-load-balancer`¶

Поле	Описание
Название сервиса	`inf-load-balancer`. Прикладной сервис `load-balancer2` из репозитория `box-inference/load-balancer2`; в compose-проекте `inference` в конфигурации продуктового контура развёрнут как контейнер `inference-inf-load-balancer-1` с образом `docker.vizorlabs.ru/box-inference/load-balancer2:1.2.12-unlimited`. Слушает внутренний Docker-порт `3000/tcp`; host-порт не опубликован.
Назначение	Control-plane видеоконтура BOX5-DIT-MGSN: принимает жизненный цикл камер, хранит размещение камер по медиасерверам, выбирает целевой `inf-mediaserver`, отправляет ему команды через Kafka и проксирует клиентские HLS/WebRTC/image-запросы на нужный медиасервер.
Подсистема	`inference`, runtime-видеоконтур. Работает между `inf-kafka`, `inf-mediaserver`, `inf-load-balancer-postgres`, `inf-load-balancer-redis`, `ds-data-temporary-storage`, `inf-monitoring`, `inf-nri-inference`, `inf-domain-gateway` и UI gateway `ui-rest-to-gprc`.
Основные функции	Регистрация медиасерверов через `RegisterMediaserver`; назначение и переназначение камер по весу, balance tags и `mediaserver_groups`; обработка `camera_add`/`camera_update`/`camera_del`/`camera_is_down`; плавный запуск и переподключение камер; публикация per-node `KafkaCommand` в topic, равный hostname медиасервера; проксирование HLS playlist/chunk, WebRTC offer и `GetImage`; учёт TSM heartbeat и deployed-model inventory; хранение настроек балансировки, reconnect и smooth launch; отдача Prometheus `/metrics`; выдача licensing info для unlimited/licensed режима.
Входящие вызовы	HTTP/gRPC на `:3000`: `RegisterMediaserver`, `GetBalancerInfo`, `GetCamerasLicensingInfo`, `GetBalancerSettings`, `SetBalancerSettings`, `UpdateMediaserverNode`, `GetMediaserverNode`, `GetCamera`/`GetBalanceCamera`, `UpdateCameraSettings`, CRUD/назначение balance tags, `GetHlsPlaylist`, `GetHlsChank`, `GetHlsPlaylistMultiply`, `GetHlsChankMultiply`, `ProcessWebRTCOffer`, `GetImage`. REST-прокси под `/api/inference/load-balancer`: HLS camera/inference/motion playlist и chunk endpoints, `POST /webrtc/`. Kafka consumer group `load-balancer` читает `camera_add`, `camera_update`, `camera_del`, `camera_is_down`, `camera_update_heartbeat`, `tsm_process_stats_heartbeat`, `models_deploy_size_local`; в конфигурации продуктового контура lag по контролируемым topics равен `0`. `inf-mediaserver` каждые несколько секунд вызывает `RegisterMediaserver`; Prometheus читает `GET /metrics`.
Исходящие вызовы	Kafka producer отправляет `KafkaCommand` в topic конкретного медиасервера; в конфигурации продуктового контура задан topic `524a20a69089`, совпадающий с `mediaservers.hostname`, а `node_hostname задаётся именем хоста контура. Kafka producer также пишет `camera_planned_launched` для downstream-мониторинга. HTTP/gRPC вызывает выбранный `inf-mediaserver:3000` для HLS/WebRTC/image-операций. Постоянно читает/пишет PostgreSQL `inf-load-balancer-postgres:5432`; на старте дополнительно проверяет доступность `inf-load-balancer-redis:6379`, но в текущей реализации `load-balancer2` service-specific Redis-клиент не предусмотрен.
Протоколы	HTTP/1.1 на `3000/tcp`, gRPC JSON/protobuf, REST для HLS/WebRTC-прокси, Prometheus text exposition на `/metrics`, Kafka protocol через `inf-kafka:9092`, PostgreSQL wire protocol к `inf-load-balancer-postgres:5432`, Redis RESP/TCP только как стартовая зависимость, stdout/stderr для логов. TLS и внешний host-порт в конфигурации продуктового контура не используются.
Хранилища	Основное хранилище - PostgreSQL sidecar `inf-load-balancer-postgres` (`dnn`): таблицы `balancer_infos`, `mediaservers`, `cameras`, `balance_tags`, `cameras_balance_tags`, `mediaservers_balance_tags`, `cameras_reconnection_settings`, `smooth_cameras_launch_settings`, `tsm_process_states`, `tsm_process_states_cameras`, `tsm_model_infos`, `deployed_model_infos`, `aerich`. В конфигурации продуктового контура присутствует: `1` mediaserver, `51` camera rows, `1` balance tag, `2` TSM process states, `40` deployed model rows; применены Aerich migration `0`-`11`. `inf-load-balancer-redis` развёрнут с `/data`, отвечает `PONG`, но keyspace пустой и persistent state сервиса хранится в PostgreSQL. Сам app-контейнер не имеет service-specific mounts.
Конфигурация	Env-only сервис, запускается `/service/start-service.sh`: ждёт `DEPENDS`, выполняет `aerich upgrade`, затем `python /service/main.py server`. В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `DEBUG=false`, `DEPENDS=["inf-kafka:9092", "inf-load-balancer-redis:6379", "inf-load-balancer-postgres:5432"]`, `BALANCE_SETTINGS_SRC=UI`, `CHECK_TIME=60`, `DATA_SENDING_METHOD=kafka`, `IS_UNLIMITED=true`, `KAFKA_HOST=inf-kafka`, `KAFKA_GROUP=load-balancer` (default, consumer group существует), `KAFKA_TOPIC_CAMERA_ADD=camera_add`, `KAFKA_TOPIC_CAMERA_UPDATE=camera_update`, `KAFKA_TOPIC_CAMERA_DEL=camera_del`, `KAFKA_TOPIC_CAMERA_IS_DOWN=camera_is_down`, defaults `KAFKA_TOPIC_CAMERA_UPDATE_HEARTBEAT=camera_update_heartbeat`, `KAFKA_TOPIC_TSM_PROCESS_STATS_HEARTBEAT=tsm_process_stats_heartbeat`, `KAFKA_TOPIC_MODELS_DEPLOY_SIZE_LOCAL=models_deploy_size_local`, `KAFKA_TOPIC_CAMERA_PLANNED_LAUNCHED=camera_planned_launched`, `POSTGRES_DATABASE=dnn`, `POSTGRES_USER=dnn`, `POSTGRES_HOST=inf-load-balancer-postgres`, `PORT=3000`, `DS_DATA_STORAGE_SERVICE=http://ds-data-temporary-storage:3000`. переменная `POSTGRES_PASSWORD` задаётся как параметр доступа и в документации не раскрывается.
Логирование	Приложение и `uvicorn` пишут структурированные `loguru`-сообщения в stdout/stderr; Docker log driver в конфигурации продуктового контура - `loki`. В логах фиксируются startup, Aerich migration, маршруты FastAPI, Kafka consumer/producer события, регистрация медиасерверов, плановые запуски, ребаланс, reconnect и ошибки проксирования. Логи могут содержать идентификаторы и имена камер, поэтому при публикации требуют редактирования.
Мониторинг	`GET /metrics` на `:3000` отвечает `200 text/plain`; отдаются метрики `request_count_total`, `request_traffic_total`, `response_traffic_total`, `request_duration`, `request_error_total`, `cpu_usage`, `memory_usage`, `uptime`. `GET /health` и `GET /api/status` на контейнере продуктового контура возвращают `404`, Docker healthcheck не задан (`Health=none`, `RestartPolicy=always`). Практические проверки: контейнер `Up`, gRPC `GetBalancerInfo`/`GetBalancerSettings`/`GetCamerasLicensingInfo` отвечают `200`, TCP-доступны `inf-kafka:9092`, `inf-load-balancer-postgres:5432`, `inf-load-balancer-redis:6379`, `inf-mediaserver:3000`, `ds-data-temporary-storage:3000`, Kafka group `load-balancer` имеет lag `0` по основным topics.
Критичность	Высокая. Без сервиса новые и обновлённые камеры не назначаются на медиасерверы, команды `AddCamera`/`UpdateCamera`/`DeleteCamera`/restart не доставляются, UI/API теряют штатный HLS/WebRTC/image-прокси, не работают балансировка и reconnect. Уже запущенный `inf-mediaserver` может продолжать декодировать существующие потоки, но управление, восстановление и клиентский доступ через балансировщик деградируют.
Эксплуатационные особенности и известные ограничения	В конфигурации продуктового контура используется `1.2.12-unlimited`: режим `IS_UNLIMITED=true` обходит стандартный Guardant license path и не отражает поведение licensed-сборки. `/health` отсутствует, Docker healthcheck не задан, host-порт не опубликован; доступ рассчитан на внутреннюю Docker-сеть `bx_default` и upstream gateways. Критичный контракт доставки команд - topic Kafka должен совпадать с `mediaserver.hostname`/`INSTANCE_ID`; рассинхронизация оставит камеры неназначенными. При старте сервис сбрасывает active/heartbeat state медиасерверов, очищает TSM heartbeat state, снимает `mediaserver_id` у камер и заново планирует запуск, поэтому рестарт вызывает управляемый relaunch. Redis sidecar включён в `DEPENDS`, но актуальная persistence-модель PostgreSQL; потеря PostgreSQL или неуспешный `aerich upgrade` блокирует старт.

`inf-load-balancer-postgres`¶

Поле	Описание
Название сервиса	`inf-load-balancer-postgres` (`docker-images/postgres`). В конфигурации продуктового контура задан контейнер `inference-inf-load-balancer-postgres-1` в compose-проекте `inference`, сервис `inf-load-balancer-postgres`, образ `docker.vizorlabs.ru/docker-images/postgres:13.1`; порт `5432/tcp` доступен только внутри Docker-сети, host-порт не опубликован.
Назначение	PostgreSQL 13 sidecar сервиса `inf-load-balancer`: реляционное хранилище control-plane состояния балансировщика камер и медиасерверов. Сам контейнер является СУБД, не находится в медиапути, не реализует прикладные HTTP/gRPC/Kafka-функции и не является отдельной бизнес-функцией BOX5-DIT-MGSN.
Подсистема	`inference`, контур маршрутизации камер к медиасерверам и управления видеопотоками. Работает в паре с `inf-load-balancer`; схему, миграции и смысл данных определяет приложение `box-inference/load-balancer2`, а не PostgreSQL-образ.
Основные функции	Инициализация PostgreSQL при первом старте; создание bootstrap-БД и пользователя через `POSTGRES_DB`, `POSTGRES_USER`, `POSTGRES_PASSWORD`; приём SQL-запросов и Aerich-миграций от `inf-load-balancer`; хранение сведений о зарегистрированных медиасерверах, размещении камер, тегах балансировки, настройках переподключения и плавного запуска камер, TSM-процессах, deployed/model inventory и состоянии миграций.
Входящие вызовы	PostgreSQL wire protocol на `5432/tcp` из внутренней сети `bx_default`. Штатный клиент - `inf-load-balancer`: в конфигурации продуктового контура у него заданы `POSTGRES_HOST=inf-load-balancer-postgres`, `POSTGRES_DATABASE=dnn`, `POSTGRES_USER=dnn` и `DEPENDS=["inf-kafka:9092", "inf-load-balancer-redis:6379", "inf-load-balancer-postgres:5432"]`; значение `POSTGRES_PASSWORD` не фиксируется. Операционная проверка выполняется через `pg_isready`/`psql` внутри контейнера.
Исходящие вызовы	Прикладных исходящих сетевых вызовов нет. Контейнер не обращается к HTTP/gRPC API, Kafka, Redis, ClickHouse, MinIO/S3 или медиасервисам; он отвечает PostgreSQL-клиентам и пишет данные, WAL и служебные файлы в `PGDATA`.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`; файловый ввод-вывод PostgreSQL в `PGDATA`; stdout/stderr для технологических логов контейнера. REST, gRPC, Kafka, Redis, Prometheus endpoint и публичный API у sidecar отсутствуют.
Хранилища	Основное состояние хранится в PostgreSQL `13.1`, `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/inference/inf-load-balancer` -> `/var/lib/postgresql/data`. База `dnn` содержит таблицы `aerich`, `balancer_infos`, `mediaservers`, `cameras`, `balance_tags`, `cameras_balance_tags`, `mediaservers_balance_tags`, `cameras_reconnection_settings`, `smooth_cameras_launch_settings`, `tsm_process_states`, `tsm_process_states_cameras`, `tsm_model_infos`, `deployed_model_infos`.
Конфигурация	Env-only конфигурация shared PostgreSQL image. В конфигурации продуктового контура заданы `POSTGRES_DB=dnn`, `POSTGRES_USER=dnn`, `PGDATA=/var/lib/postgresql/data`, `PG_MAJOR=13`, `PG_VERSION=13.1-1.pgdg100+1`, `GOSU_VERSION=1.12`, `LANG=en_US.utf8`, `RestartPolicy=always`; ключ `POSTGRES_PASSWORD` присутствует, но значение не фиксируется. Для конфигурации продуктового контура закреплён image-tag `13.1` с pinning `2026-04-13`.
Логирование	PostgreSQL пишет технологические логи старта, подключений, ошибок, checkpoint/WAL и shutdown в stdout/stderr контейнера; в конфигурации продуктового контура Docker log driver - `loki` с ротацией. Прикладные логи миграций Aerich, rebalance, назначения камер и ошибок работы с БД нужно смотреть в `inf-load-balancer`, потому что sidecar не знает бизнес-контекст SQL-запросов.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck нет (`Health=none`). Практические проверки: контейнер `inference-inf-load-balancer-postgres-1` в состоянии `Up`, `pg_isready -U dnn -d dnn` внутри контейнера возвращает `accepting connections`, `psql` показывает ожидаемую public-схему, `inf-load-balancer` стартует после `inf-load-balancer-postgres:5432` и успешно выполняет `aerich upgrade`.
Критичность	Высокая для control-plane видеоконтура. Отказ БД блокирует стартовые миграции и нормальную работу `inf-load-balancer`, сохранение регистрации медиасерверов, размещения камер, тегов балансировки, настроек переподключения и TSM/model state; HLS/WebRTC/image proxy и новые команды камер через балансировщик становятся ненадёжны или недоступны. Сам PostgreSQL-sidecar не обрабатывает видеокадры и не публикует события, но потеря его состояния нарушает восстановление и управление маршрутизацией камер.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без собственной бизнес-логики, публичного API, Prometheus-метрик и healthcheck. Схема полностью принадлежит версии `inf-load-balancer` и меняется его Aerich-миграциями; ручные изменения БД могут нарушить ORM-контракт. Без доступного bind mount `PGDATA` теряются placement/control-plane state и migration state, восстановление зависит от бэкапов или повторного наполнения из upstream-событий и регистраций медиасерверов. `POSTGRES_DB`, `POSTGRES_USER` и `POSTGRES_PASSWORD` должны совпадать с настройками `inf-load-balancer`; БД не публикует host-порт и должна использоваться только внутренними сервисами compose-сети.

`inf-load-balancer-redis`¶

Поле	Описание
Название сервиса	`inf-load-balancer-redis`. Вспомогательный Redis 6 sidecar сервиса `inf-load-balancer`; в compose-проекте `inference` в конфигурации продуктового контура развёрнут как контейнер `inference-inf-load-balancer-redis-1` с образом `docker.vizorlabs.ru/docker-images/redis-6:master`. Слушает только внутренний Docker-порт `6379/tcp`, host-порт не опубликован.
Назначение	Оперативный Redis-бэкенд для `inf-load-balancer`: кэш, очередь и хранилище краткоживущего состояния балансировщика нагрузки. Самостоятельной бизнес-функции не выполняет; постоянное состояние камер, медиасерверов, тегов балансировки и настроек хранится в `inf-load-balancer-postgres`.
Подсистема	`inference`, управляющий контур маршрутизации камер к `inf-mediaserver`. Работает как технический sidecar рядом с `inf-load-balancer`, который также связан с `inf-kafka`, `inf-load-balancer-postgres`, `inf-mediaserver` и проксируемыми вызовами к выбранному медиасерверу.
Основные функции	Принимает Redis-команды от версии `inf-load-balancer`, которой требуется оперативное Redis-состояние; предоставляет место для краткоживущих ключей кэша, очередей и блокировок балансировщика; выступает проверкой зависимости на старте `inf-load-balancer` через `DEPENDS=["inf-kafka:9092", "inf-load-balancer-redis:6379", "inf-load-balancer-postgres:5432"]`; сохраняет Redis RDB-файл в `/data` между рестартами контейнера. Схема ключей Redis является внутренним контрактом конкретной версии `load-balancer2` и не публикуется как внешний API.
Входящие вызовы	Redis RESP/TCP на `6379` из внутренней Docker-сети. Штатный потребитель - `inf-load-balancer`, который ждёт доступности `inf-load-balancer-redis:6379` при запуске; операционные проверки выполняются через `redis-cli PING` внутри контейнера.
Исходящие вызовы	Сервис-специфичных исходящих HTTP, gRPC, Kafka, SQL или Redis-вызовов нет. Контейнер только отвечает клиентам Redis по входящему TCP-соединению и пишет локальное состояние Redis в `/data`.
Протоколы	Redis RESP поверх TCP `6379`; stdout/stderr для логов контейнера. HTTP/gRPC, Kafka, PostgreSQL, Prometheus endpoint, TLS, Redis ACL/password auth, Pub/Sub и Redis Streams как прикладной контракт в текущей конфигурации не предусмотрены.
Хранилища	База Redis по умолчанию `0` и файловое хранилище `/data`. В конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/inference/load-balancer-redis-data` -> `/data`; в конфигурации продуктового контура `DBSIZE=0` и `INFO keyspace` не показывал активных баз. AOF выключен (`appendonly no`), действует стандартная RDB-политика `save 3600 1 300 100 60 10000`.
Конфигурация	Стандартный Redis-контейнер из compose: `image=docker.vizorlabs.ru/docker-images/redis-6:master`, `restart=always`, том `${COMPOSE_DATA}/inference/load-balancer-redis-data:/data`, label `vizorlabs_container_name=inf-load-balancer-redis`. Сервисные переопределения env, пользовательский `redis.conf` и переопределение команды в конфигурации продуктового контура не предусмотрены; в env Redis-контейнера присутствуют только переменные базового образа (`GOSU_VERSION`, `PATH`, `REDIS_DOWNLOAD_SHA`, `REDIS_DOWNLOAD_URL`, `REDIS_VERSION`). У `inf-load-balancer` в конфигурации продуктового контура заданы имена env для Kafka/Postgres/балансировки и `DEPENDS`; `REDIS_*` переменные не заданы.
Логирование	Штатные логи Redis пишутся в stdout/stderr и собираются драйвером логирования Docker `loki`. Ошибки подключения к Redis, если они возникают на стороне приложения, следует искать в логах `inf-load-balancer`; сам sidecar не пишет прикладных событий о камерах или медиасерверах.
Мониторинг	Собственного HTTP endpoint, Prometheus-метрик и Docker healthcheck в конфигурации продуктового контура не задано (`Health=none`, `RestartPolicy=always`). Базовые проверки: контейнер `Up`, `redis-cli PING` возвращает `PONG`, `INFO keyspace`/`DBSIZE` показывают ожидаемое состояние DB, а `inf-load-balancer` стартует после доступности `inf-load-balancer-redis:6379`.
Критичность	Высокая для старта и зависящей от Redis оперативной логики `inf-load-balancer`: если sidecar недоступен, `DEPENDS` блокирует запуск балансировщика, а кэш, очередь и оперативное состояние Redis становятся недоступными. Потеря Redis не должна считаться потерей постоянного реестра камер и медиасерверов, потому что источник постоянных данных находится в `inf-load-balancer-postgres`, но деградация Redis может нарушить текущие операции балансировки и восстановления.
Эксплуатационные особенности и известные ограничения	Это типовой Redis sidecar без собственной бизнес-логики, публичного API, healthcheck и выделенных метрик. Тег образа `master` не является immutable-релизом. Redis работает без TLS/auth/ACL и без опубликованного host-порта, поэтому безопасность опирается на изоляцию Docker-сети. AOF выключен; при потере bind mount или пересоздании данных теряется только локальное оперативное Redis-состояние. Redis-sidecar не является источником бизнес-данных; схема ключей, очередей и блокировок относится к внутренней реализации `inf-load-balancer`.

`inf-monitoring`¶

Поле	Описание
Название сервиса	`inf-monitoring` (`box-inference/monitoring2`). В конфигурации продуктового контура развёрнут как контейнер `inference-inf-monitoring-1` с образом `docker.vizorlabs.ru/box-inference/monitoring2:1.0.19-dev`; основной порт `3000/tcp` доступен только во внутренней Docker-сети.
Назначение	Сервис оперативного мониторинга состояния камер и инференса: принимает topology events и heartbeat-телеметрию из Kafka, держит актуальное состояние камер в памяти, сохраняет справочники и диагностические логи в PostgreSQL, отдаёт состояние через gRPC/REST и публикует Prometheus-метрики. При включённом ClickHouse пишет исторические снимки состояния камер и NRI-state heartbeat.
Подсистема	`inference`, контур мониторинга и диагностики BOX5-DIT-MGSN. Работает между `inf-mediaserver`, `inf-nri-inference`, `inf-load-balancer`, `inf-domain-gateway`, `inf-kafka`, `inf-monitoring-postgres`, `st-event-storage-clickhouse` и UI/API-клиентами, которые читают состояние камер.
Основные функции	Ведёт локальные heartbeat-карты `cameras_heartbeats`, `inference_heartbeats` и `nri_state_heartbeats`; синхронизирует список камер из `camera_add`/`camera_update`/`camera_del`; обновляет состояние по `camera_update_heartbeat`, `inference_update_heartbeat` и `camera_nri_state_heartbeat`; проверяет просроченные heartbeat и публикует `camera_is_down`; хранит camera failure/error logs и generic error logs; принимает и хранит camera defects; отдаёт `GetCameraState`, `GetCamerasState`, `GetCamerasStateL`, NRI-state и error-log методы; формирует `/metrics`; при `IS_USE_CLICKHOUSE=true` создаёт и пополняет таблицы `camera_states` и `camera_nri_state_heartbeats`.
Входящие вызовы	Kafka consumer group `monitoring` читает `camera_add`, `camera_update`, `camera_del`, `camera_update_heartbeat`, `inference_update_heartbeat`, `camera_nri_state_heartbeat`, `camera_planned_launched`, `set_camera_defect`, `unset_camera_defect`, `add_camera_failure_log`, `camera_error_log`, `error_log`, `websocket_heartbeat`. HTTP/gRPC на `:3000` предоставляет методы мониторинга камер, heartbeat/defect/error-log handlers и чтение состояния; REST endpoints `POST /cameras/nri/` и `POST /cameras/nri/{camera_id}/` работают с NRI-state. `GET /metrics` на том же порту отдаёт Prometheus text format. `inf-domain-gateway` проксирует `Gateway.GetCamerasState` в `inf-monitoring:3000`. Host-порты в конфигурации продуктового контура не опубликованы.
Исходящие вызовы	Kafka produce в `camera_is_down`, когда камера долго не присылает heartbeat; при активном `websocket_heartbeat` defect set/unset публикует `websocket_service_state_changed`. PostgreSQL-записи в `inf-monitoring-postgres` выполняются через Tortoise ORM. При `IS_USE_CLICKHOUSE=true` сервис подключается по ClickHouse native TCP к `st-event-storage-clickhouse:9000`, создаёт/мигрирует таблицы истории и пишет периодические строки состояния камер и NRI heartbeat. Внешних HTTP-вызовов к report/alert-device сервисам в текущей реализации не предусмотрено.
Протоколы	Kafka с protobuf-сообщениями для стандартных gRPC handlers и JSON/Pydantic-сообщениями для NRI/error/failure logs; HTTP/gRPC protobuf; HTTP REST; HTTP `/metrics` Prometheus text; PostgreSQL wire protocol; ClickHouse native TCP; Docker stdout/stderr. Приложение `monitoring2` на версии не использует Redis-протокол.
Хранилища	PostgreSQL sidecar `inf-monitoring-postgres` хранит таблицы `cameras`, `camera_defects`, `camera_glitches`, `camera_failure_logs`, `camera_error_logs`, `error_logs`, `aerich`; в конфигурации продуктового контура применена миграция `4_20260407124529_camera_node_name.sql`, а heartbeat-таблицы PostgreSQL удалены предыдущей миграцией. Оперативные heartbeat и NRI-state хранятся в памяти процесса и восстанавливаются по новым Kafka-сообщениям. При включённом ClickHouse используются `camera_states` и `camera_nri_state_heartbeats` в общем `st-event-storage-clickhouse`; в конфигурации продуктового контура обе таблицы есть и заполнены. `inf-monitoring-redis` поднят как sidecar (`db0:keys=55`), но в env и коде `monitoring2:1.0.19-dev` нет `REDIS_*` контракта, поэтому для текущего приложения это не предусмотренное прикладное хранилище.
Конфигурация	Env-only сервис в compose-проекте `inference` из `/home/vizorlabs/CODE/box3/inference/docker-compose.yml`, сеть `bx_default`, alias `inf-monitoring`, `restart: always`, Docker log driver `loki`, Docker healthcheck не задан. В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `DEPENDS=["inf-kafka:9092", "inf-monitoring-postgres:5432"]`, `KAFKA_HOST=inf-kafka:9092`, `POSTGRES_HOST=inf-monitoring-postgres`, `POSTGRES_DATABASE=dnn`, `POSTGRES_USER=dnn`, `CAMERA_LIFE_TIME=60`, `CAMERA_FAILURES_DURATION_SECONDS=86400`, `DELAY_FOR_SET_FAILURES_COUNT=120`, `IS_USE_CLICKHOUSE=true`, `CLICKHOUSE_HOST=st-event-storage-clickhouse`, `CH_CAMERAS_STATE_TASK_INTERVAL_SEC=60`, `IS_INFERENCE_HEARTBEATS_ENABLED=false`, `IS_CAMERA_DEFECTS_CLEANER_ENABLED=false`, `LIB_VZRPC_VERSION=vzrpc-1-0-19`, `PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=upb`. Kafka topic overrides в конфигурации продуктового контура явно заданы для topology/camera heartbeat topics; остальные используются по defaults кода (`camera_nri_state_heartbeat`, `camera_error_log`, `error_log`, `set_camera_defect`, `unset_camera_defect`, `websocket_*` и др.). Значения `POSTGRES_PASSWORD` и прочие параметры доступа не фиксируются в документации.
Логирование	Приложение использует Loguru и пишет в stdout/stderr; в конфигурации продуктового контура логи собираются Docker log driver `loki`. В логах фиксируются запуск Kafka consumers, `CheckCameraAlive`, `UpdateCameraHeartbeat`, `AddCameraNriStateHeartbeat`, ClickHouse tasks, cleaners и время обработки gRPC/Kafka handlers. Прикладные диагностические события из Kafka `camera_error_log` и `error_log` дополнительно сохраняются в PostgreSQL-таблицы `camera_error_logs` и `error_logs`.
Мониторинг	`GET /metrics` внутри контейнера возвращает `200 OK` и метрики `request_count_total`, `request_error_total`, `request_duration`, `cpu_usage`, `memory_usage`, `uptime`, `check_camera_state`, `check_inference_state`. Практические проверки: контейнер `inference-inf-monitoring-1` в состоянии `Up`, Kafka consumer group `monitoring` имеет lag `0` по большинству topology/error/NRI topics и читает `camera_update_heartbeat`, `camera_nri_state_heartbeat`, `camera_error_log`, `error_log`; PostgreSQL отвечает и содержит ожидаемые таблицы; Redis sidecar отвечает `PONG`, но не является контрактом приложения; ClickHouse содержит `camera_states` и `camera_nri_state_heartbeats`.
Критичность	Высокая. Отказ сервиса не останавливает сам видеопоток или NRI-инференс, но UI и API получают устаревшее состояние камер, перестают обновляться NRI-state/error-log представления, не публикуется `camera_is_down` для перезапуска зависших камер, не сохраняется история в ClickHouse и не проходит defect/WebSocket fan-out. Для эксплуатации это быстро деградирует диагностику и реакцию на отказы камер.
Эксплуатационные особенности и известные ограничения	Docker healthcheck и host-порт отсутствуют; liveness нужно проверять через `/metrics`, Kafka lag, PostgreSQL/ClickHouse и логи. Актуальные heartbeat-состояния живут в памяти, поэтому после рестарта сервис показывает неполную картину до прихода новых Kafka-сообщений; старые live-топики с `is_seek_to_end=True` не переигрываются полностью. В конфигурации продуктового контура `IS_INFERENCE_HEARTBEATS_ENABLED=false`, поэтому `inference_update_heartbeat` читается, но не участвует в решении о перезапуске камер. Redis sidecar присутствует в compose, но текущий `monitoring2` его не использует. Defect cleaner выключен (`IS_CAMERA_DEFECTS_CLEANER_ENABLED=false`), а функции отчётов, alert-device orchestration и бизнес-уведомлений находятся в сервисах статистики, а не в `inf-monitoring`; здесь есть только camera defect state и optional `websocket_service_state_changed` fan-out при свежем `websocket_heartbeat`.

`inf-monitoring-postgres`¶

Поле	Описание
Название сервиса	`inf-monitoring-postgres`. В конфигурации продуктового контура задан контейнер `inference-inf-monitoring-postgres-1` с образом `docker.vizorlabs.ru/vizorlabs/postgres:13.1`; порт `5432/tcp` доступен только во внутренней Docker-сети `bx_default`.
Назначение	PostgreSQL-хранилище сервиса `inf-monitoring`. Сохраняет реестр камер и долговременные данные мониторинга: дефекты, сбои/глитчи, журналы отказов камер, журналы ошибок камер, общие error logs и состояние Aerich-миграций. Это служба СУБД, а не отдельная бизнес-функция и не прикладной API.
Подсистема	`inference`, контур мониторинга живости камер и инференса. Sidecar расположен рядом с `inf-monitoring`, который владеет схемой, запускает миграции и отдаёт пользовательские методы через HTTP/gRPC; прямые UI/API-вызовы в PostgreSQL не идут.
Основные функции	Инициализация базы по `POSTGRES_*` при первом старте; приём PostgreSQL-подключений от `inf-monitoring`; хранение таблиц, индексов, WAL и служебных файлов в `PGDATA`; предоставление состояния для Aerich-миграций и ORM-запросов родительского сервиса. Живые heartbeat/NRI-состояния не являются бизнес-данными этого sidecar: в текущей линии `inf-monitoring` они держатся в памяти сервиса, а исторические срезы при `IS_USE_CLICKHOUSE=true` пишутся в ClickHouse.
Входящие вызовы	PostgreSQL-подключения на `5432/tcp` из внутренней сети. Основной клиент - `inf-monitoring`: при старте он ждёт `inf-monitoring-postgres:5432` через `DEPENDS`, выполняет Aerich-миграции и использует БД для камер, defects/glitches и логов. Host-порт в конфигурации продуктового контура не опубликован; диагностические SQL-подключения возможны только из контейнерной сети или через сам контейнер в конфигурации продуктового контура.
Исходящие вызовы	Прикладных сетевых вызовов нет. Контейнер не обращается к REST, gRPC, Kafka, Redis, ClickHouse, MinIO или другим сервисам; он только отвечает SQL-клиентам и пишет состояние PostgreSQL в подключённый каталог данных. Kafka-consumers, ClickHouse-запись и gRPC/API-контракт принадлежат `inf-monitoring`, а не sidecar.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`; локальные файловые операции PostgreSQL в `PGDATA`; `stdout`/`stderr` для технологических логов. HTTP, REST, gRPC, Kafka, Redis, Prometheus endpoint, TLS и публичный API у контейнера отсутствуют.
Хранилища	Основное состояние в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/inference/inf-monitoring-postgres` -> `/var/lib/postgresql/data`. В схеме `public` присутствуют таблицы `aerich`, `cameras`, `camera_defects`, `camera_glitches`, `camera_failure_logs`, `camera_error_logs`, `error_logs`; применённые миграции включают удаление legacy heartbeat-таблиц и добавление `cameras.node_name`.
Конфигурация	Env-only конфигурация shared PostgreSQL image: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`, `PATH`. В конфигурации продуктового контура заданы PostgreSQL `13.1`, `RestartPolicy=always`, Docker log driver `loki`, отсутствие Docker healthcheck и внутренний порт `5432/tcp` без публикации на host. У `inf-monitoring` заданы `POSTGRES_HOST=inf-monitoring-postgres`, `POSTGRES_DATABASE=dnn`, `DEPENDS=["inf-kafka:9092", "inf-monitoring-postgres:5432"]`, `IS_USE_CLICKHOUSE=true`; значения параметров доступа не фиксируются.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. Отдельного прикладного логирования у sidecar нет; ошибки миграций, ORM-запросов, Kafka handlers, ClickHouse-задач и gRPC/API нужно смотреть также в логах `inf-monitoring`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck нет. Практические проверки: контейнер `inference-inf-monitoring-postgres-1` находится в состоянии `running`, `pg_isready` внутри контейнера возвращает `accepting connections`, SQL-подключение к рабочей БД успешно, а в схеме есть ожидаемые таблицы мониторинга и актуальная запись Aerich-миграций.
Критичность	Высокая для `inf-monitoring`: отказ БД блокирует нормальный старт сервиса, миграции, работу API по камерам/дефектам/глитчам/логам и сохранение долговременной истории ошибок. Основной видеопоток, Kafka и инференс не останавливаются напрямую, но пользовательская диагностика живости камер и восстановление состояния мониторинга деградируют; потеря volume означает потерю локального реестра мониторинга и журналов, если они не восстановлены из бэкапа или upstream-событий.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без собственной бизнес-логики, публичного API, метрик, healthcheck и отдельного backup-sidecar в текущей конфигурации. Схемой полностью управляет `inf-monitoring`; ручные изменения БД могут нарушить ORM/Aerich-контракт. БД не хранит live heartbeat/NRI-state как оперативное состояние и не заменяет ClickHouse-историю при включённом `IS_USE_CLICKHOUSE`. Конфиденциальные значения `POSTGRES_*` должны быть синхронизированы между приложением и sidecar; host-порт намеренно не опубликован, поэтому доступ рассчитан только на внутреннюю Docker-сеть.

`inf-monitoring-redis`¶

Поле	Описание
Название сервиса	`inf-monitoring-redis`. Redis 6 sidecar сервиса `inf-monitoring`; в compose-проекте `inference` в конфигурации продуктового контура развёрнут как контейнер `inference-inf-monitoring-redis-1` с образом `docker.vizorlabs.ru/docker-images/redis-6:master`. Слушает только внутренний Docker-порт `6379/tcp`, host-порт не опубликован.
Назначение	Оперативный Redis-бэкенд для `inf-monitoring`: кэш, очередь/координационное хранилище и хранилище состояния мониторинга камер на Redis-backed линии сервиса. Самостоятельной бизнес-функции не выполняет и не принимает пользовательские HTTP/gRPC/Kafka-запросы.
Подсистема	`inference`, контур мониторинга работоспособности камер и инференса. Работает как служебный sidecar рядом с `inf-monitoring`, который получает heartbeat-события из `inf-kafka`, отдаёт состояние камер по gRPC и, в актуальной конфигурации BOX5-DIT-MGSN, также использует `inf-monitoring-postgres` и ClickHouse.
Основные функции	Принимает Redis-команды от `inf-monitoring`; хранит оперативные записи состояния камер в Redis DB `0` (в конфигурации продуктового контура заданы ключи вида `rom-camera-id-*`); служит внутренним кэшем и координатором очередей/временного состояния для мониторинга; сохраняет Redis-данные между рестартами контейнера через `/data`; не выполняет преобразование данных и не содержит собственной прикладной логики.
Входящие вызовы	Redis RESP/TCP на `6379` из внутренней compose-сети. Контрактный клиент - `inf-monitoring`; в compose текущего контура также сохранена историческая Redis-зависимость `inf-monitoring-redis:6379` в закомментированном `DEPENDS`. Операционные проверки выполняются через `redis-cli PING` внутри контейнера; внешний host-порт отсутствует.
Исходящие вызовы	Сервис-специфичных исходящих HTTP, gRPC, Kafka, SQL или Redis-вызовов нет. Контейнер только отвечает клиентам Redis по входящему TCP-соединению и пишет локальное состояние Redis в `/data`.
Протоколы	Redis RESP поверх TCP `6379`; stdout/stderr для логов контейнера. HTTP/gRPC, Kafka, PostgreSQL, Prometheus endpoint, TLS, Redis ACL/password auth, Pub/Sub и Redis Streams как внешний контракт в текущей конфигурации не предусмотрены.
Хранилища	Redis DB `0` используется как оперативное хранилище состояния `inf-monitoring`; в конфигурации продуктового контура присутствует `db0:keys=55,expires=0`, ключи имеют префикс `rom-camera-id-*`. Данные Redis размещены в `/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/inference/monitoring-redis-data` -> `/data`. AOF выключен (`appendonly no`), действует стандартный RDB `save 3600 1 300 100 60 10000`.
Конфигурация	У Redis-контейнера не предусмотрены service-specific env overrides, custom `redis.conf` или command override; присутствуют только переменные базового образа (`GOSU_VERSION`, `REDIS_VERSION`, `REDIS_DOWNLOAD_URL`, `REDIS_DOWNLOAD_SHA`, `PATH`). Compose задаёт `restart: always`, образ `redis-6:master` и volume `/data`. В текущем контуре BOX5-DIT-MGSN активный `inf-monitoring` запущен в Postgres-backed конфигурации (`DEPENDS` указывает на `inf-monitoring-postgres:5432`), поэтому перед эксплуатационными выводами нужно сверять конкретную ветку конфигурации.
Логирование	Штатные логи Redis пишутся в stdout/stderr и собираются Docker log driver `loki`. Прикладные ошибки чтения/записи состояния, очередей и heartbeat-обработки фиксируются в логах `inf-monitoring`, а не в Redis-sidecar.
Мониторинг	Собственного HTTP endpoint, Prometheus-метрик и Docker healthcheck в конфигурации продуктового контура не задано (`Health=none`, `RestartPolicy=always`). Базовые проверки: контейнер `Up`, `redis-cli PING` возвращает `PONG`, `INFO keyspace` показывает ожидаемое наличие DB `0`, а `inf-monitoring` на Redis-backed конфигурации может подключиться к `inf-monitoring-redis:6379`.
Критичность	Высокая для Redis-backed конфигурации `inf-monitoring`: отказ Redis нарушает хранение оперативного состояния камер, внутреннюю координацию и восстановление state после рестартов, из-за чего ответы мониторинга и фиксация деградаций камер становятся неполными или недоступными. На текущей Postgres-backed конфигурации BOX5-DIT-MGSN прямой эффект ниже, но контейнер остаётся частью поставки и persisted state может использоваться при переключении линии сервиса.
Эксплуатационные особенности и известные ограничения	Это generic Redis sidecar без собственной бизнес-логики, публичного API, healthcheck и выделенных метрик. Тег образа `master` не является immutable-релизом. Redis работает без TLS/auth/ACL и без опубликованного host-порта, поэтому безопасность опирается на изоляцию Docker-сети. AOF выключен; при потере bind mount или пересоздании данных теряется локальное состояние мониторинга, пока оно не будет восстановлено из Kafka/gRPC/БД-событий. В конфигурации продуктового контура рядом развёрнут `inf-monitoring-postgres`, а Redis-зависимость в `inf-monitoring` не активна в compose, поэтому нельзя автоматически считать Redis единственным источником состояния для всех контуров.

`inf-image-storage`¶

Поле	Описание
Название сервиса	`inf-image-storage` (`box-inference/image-storage`). В конфигурации продуктового контура развёрнут как контейнер `inference-inf-image-storage-1` с образом `docker.vizorlabs.ru/box-inference/image-storage:1.3.1`; внутри образа указан исходный commit `6a42af3d2587bac04e47c9c8b35313a502fcaae2` (`BOXD-2588 python base pb6`). HTTP-порт `3000/tcp` доступен только во внутренней Docker-сети `bx_default` по alias `inf-image-storage`, host-порт не опубликован.
Назначение	Кэш последних изображений камер в контуре инференса: принимает полноразмерные кадры и preview-кадры из Kafka/gRPC, сохраняет актуальное значение в Redis и отдаёт его синхронным клиентам для UI, настройки зон, диагностических и вспомогательных сценариев. Сервис хранит только последнее состояние на камеру, не является архивом видео или долговременным хранилищем медиа.
Подсистема	`inference`, кэш latest-frame/preview между `inf-mediaserver`, `inf-kafka`, `inf-image-storage-redis`, `ds-data-temporary-storage` и клиентами чтения (`inf-domain-gateway`, `ui-rest-to-gprc`).
Основные функции	Подписывается Kafka consumer group `image-storage` на `img_update` и `preview_update`; обрабатывает protobuf `box.inference.datatype.image_storage.Image`; при наличии `img_ds` dereference-ит содержимое через `DataTemporaryStorage.GetData`, иначе использует `img_base64`; сохраняет full-frame и preview в Redis-backed ROM-модели с TTL `IMAGE_EXPIRE_SEC`; отдаёт пакетные методы `GetImages`/`GetPreviews`; отдаёт бинарные методы `GetBinaryImage`/`GetBinaryPreview` как `MediaFile`; публикует Prometheus-метрики метода, трафика и длительности запросов.
Входящие вызовы	Kafka из `inf-kafka:9092`: `img_update` и `preview_update`, группа `image-storage`; в конфигурации продуктового контура оба topic partition имеют lag `0`. HTTP/gRPC на `:3000`, путь `/grpc/box.inference.image_storage.ImageStorage/<Method>`: `UpdateImage`, `UpdatePreview`, `GetImages`, `GetPreviews`, `GetBinaryImage`, `GetBinaryPreview`. `GET /metrics` на том же listener отдаёт Prometheus text. `inf-domain-gateway` проксирует `Gateway.GetImages`/`Gateway.GetPreviews` в `inf-image-storage`.
Исходящие вызовы	Redis RESP/TCP к `inf-image-storage-redis:6379` для `save`, `get` и `select` ROM-записей. HTTP/gRPC к `ds-data-temporary-storage:3000` методом `DataTemporaryStorage.GetData` используется только когда входное Kafka/gRPC-сообщение содержит `img_ds` вместо `img_base64`; в коде клиента задан timeout `10s`. Kafka production, PostgreSQL, ClickHouse, MinIO/S3 и внешние REST-вызовы в текущей реализации не предусмотрены.
Протоколы	Kafka consumer protocol с protobuf-сообщениями `image_storage.Image`; HTTP/gRPC protobuf для API чтения/записи; HTTP `GET /metrics` в Prometheus text exposition format; Redis RESP/TCP; HTTP/gRPC к `DataTemporaryStorage`; Docker stdout/stderr. Методы `GetImages`/`GetPreviews` возвращают protobuf `Images` с `img_base64`, `width`, `height`; `GetBinaryImage`/`GetBinaryPreview` возвращают `base.MediaFile` с декодированным бинарным содержимым и `content_type='image/jpg'`.
Хранилища	Основное прикладное состояние находится в `inf-image-storage-redis`: ключи `rom-image-id-<camera_id>` для полноразмерного кадра и `rom-preview-id-<camera_id>` для preview, значения включают `id`, `size.height`, `size.width`, `img_base64`. TTL каждой записи задаёт приложение через `IMAGE_EXPIRE_SEC` (default `300s`); в конфигурации продуктового контура заданы `db0:keys=6,expires=6`, ключи `rom-image-id-` и `rom-preview-id-`. У самого `inf-image-storage` нет bind-mounted бизнес-данных; Redis-контейнер имеет Docker-managed volume `/data`, но кэш остаётся временным и истекающим.
Конфигурация	Env-only сервис в compose-проекте `inference` из `/home/vizorlabs/CODE/box3/inference/docker-compose.yml`, `restart: always`, Docker log driver `loki`, Docker healthcheck не задан. В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `DEPENDS=["inf-kafka:9092", "inf-image-storage-redis:6379"]`, `KAFKA_HOST=inf-kafka:9092`, `KAFKA_TOPIC_IMG_UPDATE=img_update`, `KAFKA_TOPIC_PREVIEW_UPDATE=preview_update`, `REDIS_HOST=inf-image-storage-redis`, `LIB_VZRPC_VERSION=vzrpc==2.0.0`, `PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=upb`. В deployed-коде defaults: `PORT=3000`, `IMAGE_EXPIRE_SEC=300`, `DS_DATA_STORAGE_SERVICE=http://ds-data-temporary-storage:3000`, `DEBUG=false`; явные конфиденциальные переменные у сервиса отсутствуют.
Логирование	Приложение использует Loguru и uvicorn access logs, пишет в stdout/stderr, в конфигурации продуктового контура логи собираются Docker log driver `loki`. В логах видны `update img camera=<id>`, `update preview camera=<id>`, время обработки gRPC/Kafka handler-ов, HTTP access records для `/metrics` и gRPC-методов, а также ошибки `gRPCServerException` при сбоях update/read. Содержимое изображений и параметры доступа штатно не логируются, но camera id считается эксплуатационным идентификатором и требует аккуратности при публикации фрагментов логов.
Мониторинг	`GET /metrics` внутри контейнера возвращает `200 OK` и метрики `request_count_total`, `request_traffic_total`, `response_traffic_total`, `request_duration` по методам `UpdateImage`, `UpdatePreview`, `GetImages`, `GetBinaryImage`, `GetPreviews`, `GetBinaryPreview`. `elk-log` Prometheus scrape config содержит job `image-storage` с target `inf-image-storage:3000`; запрос `up{job="image-storage"}` в конфигурации продуктового контура вернул `1`. Практические проверки: контейнер `Up`, Kafka group `image-storage` lag `0` по `img_update` и `preview_update`, Redis `PING` возвращает `PONG`, gRPC-чтение `GetImages`/`GetPreviews` и бинарные методы успешно вернули кадр/preview для контрольной камеры без вывода содержимого изображения.
Критичность	Высокая для пользовательских представлений последних кадров и downstream-функций, которым нужен актуальный still image: UI-превью и снимки камер, настройка зон, empty-zone проверки счётчиков и диагностические сценарии. Отказ сервиса не останавливает напрямую mediaserver, NRI-инференс и Kafka-публикацию событий, но клиенты чтения получают ошибки или пустые результаты, а Redis-кэш быстро устаревает по TTL.
Эксплуатационные особенности и известные ограничения	Кэш хранит только последний full-frame и preview на камеру; истории, поиска по времени, архива видео и долговременной гарантии сохранности нет. Docker healthcheck и host-порт отсутствуют, поэтому liveness нужно проверять через `/metrics`, Kafka lag, Redis и логи. При недоступности Redis сервис не может сохранять и отдавать кадры; при недоступности `ds-data-temporary-storage` ломаются только сообщения с `img_ds`, тогда как сообщения с `img_base64` продолжают работать. Missing/expired ключи дают пустые списки в пакетных методах или gRPC-ошибку в binary-методах. Binary-ответы всегда маркируются `image/jpg`, исходный MIME из base64-префикса не сохраняется.

`inf-image-storage-redis`¶

Поле	Описание
Название сервиса	`inf-image-storage-redis`. Redis 6 sidecar сервиса `inf-image-storage`; в конфигурации продуктового контура развёрнут как контейнер `inference-inf-image-storage-redis-1` с образом `docker.vizorlabs.ru/docker-images/redis-6:master`. Слушает только внутренний Docker-порт `6379/tcp`, host-порт не опубликован.
Назначение	Оперативный кэш и Redis-хранилище последних изображений для `inf-image-storage`: хранит последний полноразмерный кадр и последнее preview по камерам, чтобы `inf-image-storage` мог отдавать `GetImages`, `GetPreviews`, `GetBinaryImage` и `GetBinaryPreview` без хранения бинарных данных в памяти процесса. Самостоятельной бизнес-функции, пользовательского API и обработки видеопотока не выполняет.
Подсистема	`inference`, контур хранения текущих кадров. Работает как технический sidecar рядом с `inf-image-storage`, который получает `img_update` и `preview_update` из Kafka, при необходимости разыменовывает `img_ds` через `ds-data-temporary-storage` и сохраняет результат в Redis.
Основные функции	Принимает Redis-команды от `inf-image-storage`; хранит Redis ROM-записи по ключам `rom-image-id-<camera_id>` и `rom-preview-id-<camera_id>`; держит в значении идентификатор камеры, размер изображения и `img_base64`; применяет TTL, который задаёт `inf-image-storage` при записи (`IMAGE_EXPIRE_SEC`, по умолчанию 300 секунд); отдаёт записи для пакетных и бинарных методов чтения изображений.
Входящие вызовы	Redis RESP/TCP на `6379` из внутренней Docker-сети. Контрактный клиент - `inf-image-storage`, в compose он запускается с `REDIS_HOST=inf-image-storage-redis` и ждёт зависимость `inf-image-storage-redis:6379` через `DEPENDS`. Операционные проверки выполняются через `redis-cli PING`, `DBSIZE`, `INFO keyspace` внутри контейнера.
Исходящие вызовы	Сервис-специфичных исходящих HTTP, gRPC, Kafka, SQL, S3/MinIO или Redis-вызовов нет. Контейнер только отвечает клиентам Redis по входящему TCP-соединению и пишет локальное состояние Redis в `/data`.
Протоколы	Redis RESP поверх TCP `6379`; файловый ввод-вывод Redis в `/data`; stdout/stderr для технологических логов контейнера. HTTP/gRPC, Kafka, PostgreSQL, Prometheus endpoint, TLS, Redis ACL/password auth, Pub/Sub и Redis Streams как внешний контракт в текущей конфигурации не предусмотрены.
Хранилища	Redis DB `0` используется как оперативное хранилище последних кадров и preview. В конфигурации продуктового контура заданы ключи только двух шаблонов: `rom-image-id-<id>` и `rom-preview-id-<id>`; `INFO keyspace` показывал `db0:keys=6,expires=6`. Каталог `/data` существует как anonymous Docker volume, но в compose для этого сервиса нет именованного bind mount; AOF выключен (`appendonly no`), действует стандартная RDB-политика `save 3600 1 300 100 60 10000`.
Конфигурация	Compose задаёт образ `docker.vizorlabs.ru/docker-images/redis-6:master`, `restart: always`, label `vizorlabs_container_name=inf-image-storage-redis` и подключение к сети `bx_default`. Пользовательский `redis.conf`, command override, healthcheck и service-specific env overrides не предусмотрены; в env контейнера присутствуют только переменные базового Redis-образа (`PATH`, `GOSU_VERSION`, `REDIS_VERSION`, `REDIS_DOWNLOAD_URL`, `REDIS_DOWNLOAD_SHA`). Тег `master` закреплён в deployment-конфигурации для платформы контуров.
Логирование	Штатные логи Redis пишутся в stdout/stderr и в конфигурации продуктового контура собираются Docker log driver `loki`. Прикладные ошибки обновления, чтения, TTL и разыменования `img_ds` нужно искать в логах `inf-image-storage`, потому что Redis-sidecar не знает бизнес-контекст камеры и gRPC-метода.
Мониторинг	Собственного HTTP endpoint, Prometheus-метрик и Docker healthcheck в конфигурации продуктового контура не задано (`Health=none`, `RestartPolicy=always`). Базовые проверки: контейнер `Up`, `redis-cli PING` возвращает `PONG`, `INFO keyspace` показывает ожидаемые ключи с TTL, а `inf-image-storage` стартует после доступности `inf-image-storage-redis:6379`.
Критичность	Высокая для функции выдачи актуальных кадров. При отказе Redis `inf-image-storage` не может надёжно сохранять и отдавать свежие `GetImages`/`GetPreviews`/binary-read результаты, из-за чего деградируют UI-просмотр текущих кадров и сервисы, которым нужны последние изображения. Сам медиасервер, Kafka, NRI-инференс и постоянные бизнес-хранилища напрямую не останавливаются.
Эксплуатационные особенности и известные ограничения	Это типовой Redis sidecar без собственной бизнес-логики, публичного API, healthcheck и выделенных метрик. Тег образа `master` не является immutable-релизом. Redis работает без TLS/auth/ACL и без опубликованного host-порта, поэтому безопасность опирается на изоляцию Docker-сети. Данные имеют TTL и не являются долговременным архивом изображений; отсутствие именованного bind mount в compose и anonymous volume в конфигурации продуктового контура не следует трактовать как гарантированное persistent-хранилище. Потеря Redis означает потерю локального кэша последних кадров до прихода новых `img_update`/`preview_update` от медиаконтура.

`inf-report-video-extractor`¶

Поле	Описание
Название сервиса	`inf-report-video-extractor`. В конфигурации продуктового контура задан контейнер `inference-inf-report-video-extractor-1` с образом `docker.vizorlabs.ru/box-inference/report-video-extractor:1.3.1-nvidia-dev`; compose service расположен в проекте `inference`, портов на host и внутренних HTTP-портов не публикует.
Назначение	Файловый sidecar для online-saver артефактов инференса. Сервис следит за JSON/MP4 dump-парами, вырезает короткие MP4-фрагменты для объектов `report` и `related_report`, прикладывает их к уже созданным событиям через event-storage pipeline, архивирует `.pickle` dumps в `.7z` и чистит saver/output каталоги по лимитам размера. Это не видеоархив и не пользовательский API.
Подсистема	`inference`, связка между NRI saver-каталогами и контуром статистики/событий. В текущем контуре BOX5-DIT-MGSN сервис читает shared saver volume из `/data/sandbox-compose-data/inference/*`, а результат доставки видео проходит через `ds-data-temporary-storage`, `inf-kafka` и `st-event-storage`.
Основные функции	Рекурсивный inotify-watch каталога `ONLINE_SAVER_PATH`; ожидание полной записи JSON и `.pickle`; разбор `json_data["data"][*]["objects"]`; фильтрация и проверка существования `report`-событий; построение crop-окна по кадрам, при необходимости с соседним сегментом; запуск FFmpeg для MP4-клипов с bbox/zone overlays; отправка основного и related-camera видео как `VideoEvent`; удаление временного MP4 после успешной обработки, если не включён debug-режим; периодическая очистка `/video-storage`, `/events-storage` и `/video-events-cropped`.
Входящие вызовы	Сетевых входящих вызовов нет: сервис не поднимает HTTP, gRPC, Kafka consumer, `/metrics` или health endpoint. Входной контракт - события файловой системы под `/video-storage`: новые `.json` запускают нарезку видео, новые `.pickle` архивируются в `.7z`; `/events-storage` используется для cleanup-цикла. В конфигурации продуктового контура заданы `ports={}`, `Health=none` и единственный прикладной процесс `python3 ./main.py`.
Исходящие вызовы	На активной платформы-линии (`IS_NEW_BOX3=true`, `IS_NEW_BOX=true`) сервис вызывает `st-event-storage.IsEventExists` по gRPC `http://st-event-storage:3000`, кладёт MP4 bytes в `ds-data-temporary-storage.SetData` по умолчанию `http://ds-data-temporary-storage:3000`, затем публикует protobuf `VideoEvent` в `inf-kafka:9092` в топики `kafka_topic_statistic_cmd_send_video_event` и `kafka_topic_statistic_cmd_send_addition_video_event`. Прямой записи в `ds-minio` или долговременный видеоархив в коде 1.3.1 не предусмотрено: `st-event-storage` позже забирает `data_storage_uuid` и переносит media в bucket `event-storage`. Неактивные legacy-ветки в состав продуктового контура реестра не включаются.
Протоколы	Linux filesystem/inotify; локальный запуск `ffmpeg`; HTTP/gRPC к `st-event-storage` и `ds-data-temporary-storage`; Kafka producer с protobuf-сообщениями `VideoEvent`; stdout/stderr и файловые логи. PostgreSQL, Redis, MinIO/S3, REST API, Prometheus endpoint и входящий HTTP-протокол непосредственно у сервиса отсутствуют.
Хранилища	Собственной БД нет. В конфигурации продуктового контура заданы bind mounts: `/data/sandbox-compose-data/inference/video-storage` -> `/video-storage`, `/data/sandbox-compose-data/inference/events-storage` -> `/events-storage`, `/data/sandbox-compose-data/inference/video-events-cropped` -> `/video-events-cropped`, `/data/compose-data2-no-swarm/inference/logs/report-video-extractor` -> `/logs`. Временные MP4 создаются в `/video-events-cropped` и обычно удаляются после отправки; `.pickle` dumps архивируются рядом с исходниками. Долговременное media-хранилище находится не здесь: временные bytes живут в Redis-бэкенде `ds-data-temporary-storage` с TTL, а финальная запись в MinIO bucket `event-storage` выполняется `st-event-storage`.
Конфигурация	Env-driven сервис, entrypoint `/report-video-extractor/start-service.sh`, рабочий каталог `/report-video-extractor`. В конфигурации продуктового контура заданы `DEBUG=false`, `LOGGING_LEVEL=DEBUG`, `ONLINE_SAVER_PATH=/video-storage`, `ONLINE_SAVER_EVENTS_PATH=/events-storage/`, `OUTPUT_VIDEOS_EVENTS_PATH=/video-events-cropped`, лимиты `ONLINE_SAVER_EVENTS_LIMIT_GB=10.0` и `OUTPUT_VIDEOS_EVENTS_LIMIT_GB=10.0`, `OUTPUT_VIDEOS_LENGTH_FRAMES=180`, `OUTPUT_VIDEOS_FPS=3.0`, `VIDEO_LENGTH_LIMIT_SEC=300`, `IS_NEW_BOX=true`, `IS_NEW_BOX3=true`, `IS_EVRAZ_AGLO=false`, `USE_REST_API=false`, `FFMPEG_ENCODE_CODEC=h264_nvenc`, `CUDA_VERSION=12.0.1`, `NVIDIA_VISIBLE_DEVICES=all`, `NVIDIA_DRIVER_CAPABILITIES=all`. `KAFKA_HOST`, `DATA_STORAGE_HOST`, `TOPIC_SEND_VIDEO_EVENT`, `TOPIC_ADDITIONAL_VIDEO_EVENT` и `REST_VIDEO_SAVE_URL` в compose не переопределены и берутся из дефолтов кода.
Логирование	Loguru пишет отдельный файл `/logs/<timestamp>_pid<PID>.txt` и дублирует сообщения в stdout; Docker log driver в конфигурации продуктового контура - `loki`. В логах фиксируются startup-config, наблюдаемый каталог, чтение JSON/pickle, результат нарезки, отправка в Kafka/DataTemporaryStorage и ошибки FFmpeg/gRPC/Kafka. При диагностике важно смотреть и логи `st-event-storage`: именно там видны получение `VideoEvent`, чтение временного media и перенос в MinIO.
Мониторинг	Собственных метрик, `/metrics`, liveness/readiness endpoint и Docker healthcheck нет. Рабочие проверки: контейнер `running`, процесс `python3 ./main.py` жив, в `/logs` появляются новые файлы, FFmpeg доступен (`/usr/local/bin/ffmpeg`, в конфигурации продуктового контура задан запуск с `h264_nvenc`), в `/video-events-cropped` создаются временные MP4, `ds-data-temporary-storage` и `st-event-storage` доступны, а в событиях появляются video attachments. Метрики нужно брать с соседних сервисов (`ds-data-temporary-storage`, `st-event-storage`, Kafka/consumer lag), а не с самого extractor.
Критичность	Высокая для доказательных видеофрагментов, отчётов и разбора инцидентов: отказ сервиса оставляет события без delayed MP4/related-camera видео и может привести к переполнению saver-каталогов из-за остановки cleanup-цикла. Основной инференс, публикация raw events и сохранение события в `st-event-storage` напрямую не блокируются, поэтому деградация проявляется как потеря/задержка видео-вложений, а не как остановка детекта.
Эксплуатационные особенности и известные ограничения	Нет входящего API, `/metrics`, healthcheck и явного `depends_on`, поэтому недоступность Kafka/DataTemporaryStorage/EventStorage проявляется только во время обработки файла. Сервис критичен к совпадению shared mounts с writer-ом инференса и к лимитам inotify на host; известная ошибка - `OSError: [Errno 24] inotify instance limit reached`. `ds-data-temporary-storage` хранит bytes временно (`DATA_LIFE_TIME=900` в конфигурации продуктового контура), поэтому задержки между upload и чтением `st-event-storage` могут привести к потере media. Прямого контракта с MinIO или видеоархивом у сервиса нет.

`inf-pushgateway`¶

Поле	Описание
Название сервиса	`inf-pushgateway`. Инфраструктурный сервис агрегации pushed Prometheus-метрик; в конфигурации продуктового контура развёрнут в compose-проекте `inference` как контейнер `inference-inf-pushgateway-1` с образом `docker.vizorlabs.ru/docker-images/prometheus-pushgateway:master`. Слушает HTTP `80/tcp` только во внутренней Docker-сети `bx_default`, host-порт не опубликован.
Назначение	Принимать Prometheus text payloads от сервисов, которым удобнее отправлять метрики push-моделью, агрегировать их в памяти и отдавать объединённый поток для scrape со стороны Prometheus. Это компонент мониторинга и наблюдаемости, а не часть пользовательского API, видеопотока или контура управления камерами.
Подсистема	`inference`, контур метрик для `elk-log`/observability. Сервис размещён рядом с inference-сервисами, а фактический потребитель находится в домене observability: `log-prometheus` скрапит `inf-pushgateway:80/metrics`, после чего данные доступны в Prometheus.
Основные функции	Принимает HTTP-запросы с Prometheus text exposition под префиксом `/metrics/`; объединяет совпадающие семейства метрик в in-memory aggregate; отдаёт текущий агрегат через `GET /metrics`; предоставляет служебные endpoints `GET /-/healthy` и `GET /-/ready`. В текущей реализации это VizorLabs wrapper вокруг `weaveworks/prom-aggregation-gateway`, а не официальный Prometheus Pushgateway с полноценной моделью job/group lifecycle.
Входящие вызовы	HTTP `80/tcp` из внутренней Docker-сети. Чтение: `log-prometheus` выполняет `GET http://inf-pushgateway:80/metrics`. Запись: совместимые producers могут отправлять Prometheus text payloads на `/metrics/` и вложенные пути этого префикса, но в актуальных compose/config файлах контура активных сервисов с `ADDRESS_TO_PUSH` или явной привязкой к `inf-pushgateway` не предусмотрено. Операционные проверки: `GET /metrics`, `GET /-/healthy`, `GET /-/ready`.
Исходящие вызовы	Прикладных исходящих вызовов нет: сервис не ходит в HTTP API, Kafka, Redis, PostgreSQL, ClickHouse, gRPC, S3/MinIO и не пушит метрики дальше. Он только отвечает на входящие HTTP-запросы и хранит агрегат в памяти процесса; Prometheus сам забирает метрики через scrape.
Протоколы	HTTP поверх TCP `80`; Prometheus text exposition format на `/metrics` и `/metrics/`; stdout/stderr для логов контейнера. TLS, authentication/authorization, Kafka, SQL, Redis, gRPC, WebSocket и опубликованный host-порт в конфигурации продуктового контура отсутствуют.
Хранилища	Persistent storage отсутствует. В конфигурации продуктового контура у контейнера нет bind mount'ов или named volumes; агрегированные метрики живут только в памяти `/prom-aggregation-gateway` и полностью очищаются при рестарте или пересоздании контейнера. На момент проверки `GET /metrics` возвращал `200 OK` с пустым телом, что соответствует отсутствию активных отправленных samples.
Конфигурация	Compose задаёт только `restart: always`, образ `docker.vizorlabs.ru/docker-images/prometheus-pushgateway:master` и label `vizorlabs_container_name=inf-pushgateway`; `depends_on`, host-порты, volumes, env overrides и command override отсутствуют. В конфигурации продуктового контура entrypoint/процесс - `/prom-aggregation-gateway`; используются значения по умолчанию образа для listen `:80`, push path `/metrics/` и CORS. Для конфигурации продуктового контура закреплён тег образа `master` с pinning `2026-04-13`.
Логирование	Сервис пишет технологические сообщения в stdout/stderr контейнера; Docker log driver в конфигурации продуктового контура - `loki`. На момент проверки последние строки `docker logs` пустые, что нормально для спокойного gateway без активных push-запросов. История агрегированных метрик в логах не хранится; для результата scrape нужно смотреть `log-prometheus`.
Мониторинг	Сам сервис отдаёт `GET /-/healthy` и `GET /-/ready`, оба endpoint в конфигурации продуктового контура вернули `200 OK` с `{"alive": true}`. `GET /metrics` вернул `200 OK`; Docker healthcheck не задан (`Health=none`). Основная внешняя проверка - состояние target `inf-pushgateway:80` в `log-prometheus` и значение `up{instance="inf-pushgateway:80"}`; при недоступности gateway Prometheus помечает target как `down`.
Критичность	Средняя для наблюдаемости и низкая для основного видеоконтура. Отказ `inf-pushgateway` не останавливает камеры, медиасервер, инференс или API BOX5-DIT-MGSN, но приводит к потере текущих pushed/aggregated метрик, target `inf-pushgateway:80` становится `down`, а панели и алерты, завязанные на эти метрики, показывают пробелы или устаревшие данные.
Эксплуатационные особенности и известные ограничения	Агрегат хранится только in-memory, поэтому рестарт очищает все накопленные samples; persistence и replay отсутствуют. Это не полная замена официального Prometheus Pushgateway: путь после `/metrics/` не образует отдельные job/group buckets, delete/reset semantics не предусмотрены, gauges суммируются, summaries не агрегируются корректно. В текущем compose контура активный отправитель не предусмотрен, поэтому `/metrics` может быть пустым при исправном сервисе. Нет TLS/auth, host-порта, Docker healthcheck и immutable release tag: используется `master`, а безопасность опирается на изоляцию внутренней Docker-сети.

`inf-domain-gateway`¶

Поле	Описание
Название сервиса	`inf-domain-gateway` (`inference/inf-domain-gateway`). В конфигурации продуктового контура развёрнут как контейнер `inference-inf-domain-gateway-1` с образом `docker.vizorlabs.ru/docker-images/nginx-1.18:master`; это тонкий Nginx/gRPC-шлюз inference-домена, а не внешний `ui-nginx` и не статистический `st-domain-gateway`.
Назначение	Предоставляет единый внутренний gRPC endpoint `box.inference.gateway.Gateway` для функций видеоконтура: получения HLS/WebRTC, кадров/превью, информации балансировщика и состояния камер. Сервис не содержит прикладной логики хранения или инференса, а только переписывает gateway-методы в методы целевых inference-сервисов.
Подсистема	`inference`, runtime-видеоконтур BOX5-DIT-MGSN. Работает между клиентами inference API (`ui-rest-to-gprc` и другие внутренние HTTP/gRPC-клиенты) и сервисами `inf-load-balancer`, `inf-image-storage`, `inf-monitoring`.
Основные функции	Слушает Nginx `server` на `:8000`, принимает пути `/grpc/box.inference.gateway.Gateway/<Method>` и выполняет rewrite/proxy. В `inf-load-balancer:3000` направляются `GetHlsPlaylist`, `GetHlsChank`, `GetBalancerInfo`, `GetHlsPlaylistMultiply`, `GetHlsChankMultiply`, `ProcessWebRTCOffer`; в `inf-image-storage:3000` - `GetPreviews`, `GetImages`; в `inf-monitoring:3000` - `GetCamerasState`. Для проксируемых запросов передаются `Host` и `X-Forwarded-For`; в конфиге заданы `client_max_body_size 500M`, `fastcgi_read_timeout 300`, `proxy_read_timeout 300`.
Входящие вызовы	Внутренний HTTP/gRPC на `:8000` из общей Docker-сети compose-проекта `inference`. В конфигурации продуктового контура host-порты не опубликованы (`PortBindings={}`), а `docker ps` показывает только image-level `80/tcp`; фактический Nginx-конфиг слушает `8000`. Проверочные POST-запросы через gateway к `GetBalancerInfo`, `GetPreviews` и `GetCamerasState` вернули HTTP `200`; запросы на `/`, `/metrics` и `/-/healthy` вернули `404`.
Исходящие вызовы	Только HTTP proxy к `inf-load-balancer:3000`, `inf-image-storage:3000` и `inf-monitoring:3000`. Kafka, PostgreSQL, Redis, ClickHouse, MinIO/S3, gRPC, shared memory, локальные helper-процессы и внешние internet-вызовы не используются самим gateway.
Протоколы	Входящие и исходящие: HTTP/gRPC поверх TCP внутри Docker-сети. Логи пишутся в stdout/stderr через стандартные Nginx access/error logs. TLS, WebSocket, Kafka, SQL, Redis, S3 и собственный Prometheus exporter у сервиса не предусмотрены.
Хранилища	Persistent storage отсутствует. Контейнер не подключает БД, Redis, Kafka state, объектные бакеты или прикладные data volume; единственный bind mount - `/home/vizorlabs/CODE/box3/inference/configs/nginx.conf` в `/etc/nginx/conf.d/default.conf`.
Конфигурация	Источник истины - `box-inference/inference-domain-solution` и compose inference-домена. В non-swarm режиме конфиг подключается bind mount `./configs/nginx.conf:/etc/nginx/conf.d/default.conf`; в swarm-режиме предусмотрен Docker config `inf_nginx_config`. Compose задаёт `restart: always`, label `vizorlabs_container_name=inf-domain-gateway`, внешний образ `nginx-1.18:master`; собственных runtime env-переменных и `depends_on` у сервиса нет. Для конфигурации продуктового контура закреплён тег `master` с pinning `2026-04-13`.
Логирование	Nginx пишет `/var/log/nginx/access.log` и `/var/log/nginx/error.log`; в контейнере они доступны через `docker logs inference-inf-domain-gateway-1`. В конфигурации продуктового контура Docker log driver - `loki`; последние логи содержали только startup-сообщения Nginx о применении смонтированного `default.conf`. Access log фиксирует HTTP-метод, путь, код ответа, referer, user agent и `X-Forwarded-For`; сырые URL/query-параметры не следует публиковать без редактирования.
Мониторинг	Docker healthcheck не задан (`Health=none`), собственных `/metrics`, `/-/healthy` или `/-/ready` endpoint нет. Практические проверки: состояние контейнера, `nginx -T`/`nginx -t`, доступность listener `:8000`, выборочные gRPC POST-запросы через gateway и метрики целевых upstream-сервисов (`inf-load-balancer`, `inf-image-storage`, `inf-monitoring`) на их собственных `/metrics`.
Критичность	Высокая для интерактивного видеоконтура и пользовательского UI: отказ ломает единый доступ к HLS/WebRTC, превью/кадрам, информации балансировщика и состоянию камер через inference gateway. При этом ingestion камер, Kafka-пайплайн, инференс и внутренние хранилища могут продолжать работать напрямую; эффект проявляется как недоступность чтения/управления через gateway.
Эксплуатационные особенности и известные ограничения	Нет собственного healthcheck, метрик, TLS/auth, host-порта и persistent state; надёжность зависит от DNS Docker-сети и доступности трёх upstream-сервисов. Сервис стартует без `depends_on`, поэтому Nginx может подняться раньше upstream'ов, а методы будут отвечать ошибками до восстановления целей. Набор маршрутов whitelist-based: неподдержанные пути получают `404`; имя `GetHlsChank` является существующим контрактом с исторической опечаткой. Используется mutable tag `master`, а поведение определяется смонтированным `nginx.conf`, поэтому при аудите нужно проверять именно активный конфиг в конфигурации продуктового контура.

`inf-coturn`¶

Поле	Описание
Название сервиса	`inf-coturn`. Upstream Coturn TURN/STUN relay для WebRTC; в конфигурации продуктового контура развёрнут в compose-проекте `inference` как контейнер `inference-inf-coturn-1` с образом `coturn/coturn:4.6.1-r0`. Работает в `network_mode: host`, поэтому `3478/tcp`, `3478/udp` и Prometheus HTTP `9641/tcp` открываются на интерфейсах host, без Docker port publishing.
Назначение	Обеспечивает STUN и TURN relay для WebRTC-подключений, когда браузер или другой WebRTC-клиент не может напрямую установить media path с видеоконтуром BOX5-DIT-MGSN. Основной потребитель - WebRTC-функции `inf-mediaserver`/`inf-load-balancer`: медиасервер обрабатывает SDP offer и media stream, а `inf-coturn` даёт клиентам ICE/STUN/TURN опорную точку и relay-кандидаты.
Подсистема	`inference`, runtime-видеоконтур WebRTC. Сервис стоит рядом с `inf-mediaserver`, `inf-load-balancer`, `inf-domain-gateway` и UI/API-клиентами, но не участвует в gRPC/Kafka/control-plane потоках; его контракт - сетевой relay для WebRTC media plane.
Основные функции	Приём STUN binding-запросов; выдача TURN allocations по долгосрочным учётным данным Coturn; relay UDP/TCP traffic между WebRTC peer'ами; публикация Prometheus-метрик Coturn; запись диагностических session-логов в stdout. Relay-порты не переопределены, поэтому используется стандартный диапазон Coturn `49152-65535/udp`.
Входящие вызовы	STUN/TURN на `3478/udp` и `3478/tcp` от WebRTC-клиентов и media peer'ов; в конфигурации продуктового контура заданы UDP listener, TCP listener и локальная STUN-проверка. HTTP `GET /` и `GET /metrics` на `9641/tcp` используются для readiness/Prometheus-проверок; `GET /health` не является рабочим health endpoint. В compose `inf-mediaserver` получает `PEAR_RELAY_HOST=${COTURN_HOST_IP}`, поэтому debug-страницы и WebRTC-конфигурация клиента указывают на этот TURN/STUN host.
Исходящие вызовы	Прикладных исходящих вызовов в сервисы BOX5-DIT-MGSN нет: сервис не ходит в HTTP/gRPC API, Kafka, Redis, PostgreSQL, ClickHouse, MinIO/S3 и не пушит метрики. Единственный исходящий сетевой трафик - пересылка TURN relay packets к адресам peer'ов, выбранным в рамках ICE/WebRTC-сессии.
Протоколы	STUN/TURN over UDP `3478`, TURN/STUN over TCP `3478`, relay media traffic преимущественно UDP `49152-65535`, HTTP `9641` для `/` и `/metrics`, Prometheus text exposition, stdout/stderr для логов. TURN over TLS/DTLS на `5349`, HTTPS, WebSocket, Kafka, SQL, Redis, gRPC в конфигурации продуктового контура не используются.
Хранилища	Бизнес-хранилищ и Box-managed volumes нет. Образ Coturn создаёт anonymous Docker volume `/var/lib/coturn`; в конфигурации продуктового контура он смонтирован в контейнер и содержит служебный `turndb`, но compose не задаёт bind mount и не использует это как контрактное состояние BOX5-DIT-MGSN. Конфигурационных файлов `/etc/turnserver.conf` и `/etc/coturn/turnserver.conf` в контейнере не предусмотрено.
Конфигурация	Compose задаёт `restart: always`, образ `coturn/coturn:4.6.1-r0`, `network_mode: host` и команду `turnserver --prometheus --log-file=stdout --external-ip=${COTURN_HOST_IP} --relay-ip=${COTURN_HOST_IP} -u <учётная-пара> -r <realm> -v`. Ключевая runtime-переменная - `COTURN_HOST_IP`: она должна быть внешним адресом host, достижимым из сетей WebRTC-клиентов. `depends_on`, `--min-port`, `--max-port`, отдельный config file и TLS-сертификаты не заданы.
Логирование	Coturn пишет verbose session logs в stdout/stderr, Docker log driver в конфигурации продуктового контура - `loki`. Логи содержат технические сведения о STUN/TURN-сессиях, realm, локальных и удалённых адресах, объёмах трафика и причинах закрытия allocation; перед публикацией их нужно редактировать. Отдельного файла логов или audit-хранилища у сервиса нет, так как задан `--log-file=stdout`.
Мониторинг	В конфигурации продуктового контура `GET http://127.0.0.1:9641/` возвращает `200 OK` с `OK`, а `GET /metrics` возвращает `200` с метриками Coturn и process-метриками; Docker healthcheck отсутствует (`Health=none`). Практические проверки: контейнер `Up`, TCP `3478` открыт, STUN UDP отвечает, `ss` показывает listeners на `3478/tcp`, `3478/udp` и `9641/tcp`. Явный scrape target для `inf-coturn:9641` в Prometheus-конфигурациях контура не предусмотрен.
Критичность	Средняя для решения в целом и высокая для WebRTC-доступа. Отказ `inf-coturn` не останавливает камеры, HLS, gRPC API, Kafka, инференс и генерацию событий, но WebRTC-клиенты за NAT/firewall могут перестать устанавливать соединение или перейти на менее надёжные direct candidates.
Эксплуатационные особенности и известные ограничения	Сервис критичен к корректности `COTURN_HOST_IP`: устаревший или внутренний адрес делает ICE relay-кандидаты недоступными извне. Из-за `network_mode: host` портовый конфликт на `3478` или `9641` блокирует старт контейнера, а firewall/security group должны пропускать `3478/tcp`, `3478/udp` и relay-диапазон `49152-65535/udp`. Учётные данные TURN заданы в compose command line и не должны попадать в документацию или логи задач. Не настроены TLS/TURNS `5349`, Docker healthcheck, `/health`, явные `min-port/max-port`, persistent config file и штатный scrape target Prometheus в конфигурации продуктового контура.

`inf-guardant-control-center`¶

Поле	Описание
Название сервиса	`inf-guardant-control-center`. Вспомогательный сервис лицензирования Guardant; в конфигурации продуктового контура задан контейнер `inference-inf-guardant-control-center-1` с образом `docker.vizorlabs.ru/box-inference/guardant_control_center:1.1.0`. Сервис compose находится в проекте `inference`, запускается с `network_mode: host`, поэтому Docker `ports` не задан, а процессы слушают host TCP `3189` и `19191`.
Назначение	Поддержка лицензированного пути платформы через Guardant: ожидание доступности Guardant Control Center (GCC), online/offline активация через библиотеку `vzguard` и поднятие HTTP API на `19191`, которое используется как endpoint оффлайн-активации и признак готовности лицензирования для зависимых сервисов. Это не пользовательский API и не сервис бизнес-данных.
Подсистема	`inference`, контур лицензирования. В штатном лицензированном пути `inf-load-balancer` должен учитывать готовность Guardant через `host.docker.internal:19191` и читать лимиты из Guardant runtime; в текущей конфигурации продуктового контура балансировщик запущен как `load-balancer2:1.2.12-unlimited` с `IS_UNLIMITED=true`, поэтому проверка лимита камер обойдена, хотя Guardant sidecar остаётся развёрнутым.
Основные функции	Запуск `/guardant/start-service.sh`; при наличии `DO_START_GCC` старт встроенного `/opt/guardant/grdcontrol/grdcontrold`; ожидание TCP-доступности `GCC_HOST:3189`; нормализация `ACTIVATION_TYPE` (`online`, `offline`, `any`); online-активация при заданном серийном номере в licensed online/any-режиме; генерация offline request через `GET /get_request`; установка offline activation response через `POST /set_response`; запуск Waitress/Flask сервера на `0.0.0.0:19191` только после готовности GCC и завершения начальной активационной фазы.
Входящие вызовы	HTTP `19191/tcp` в host-сети: `GET /get_request` возвращает JSON с activation request, `POST /set_response` принимает JSON с activation response. TCP `3189` обслуживает установленный на хосте GCC runtime, который в конфигурации продуктового контура запущен как `/opt/guardant/grdcontrol/grdcontrold --daemon`; сам контейнер его только ожидает, потому что `DO_START_GCC` не задан. `/`, `/health` и `/metrics` на `19191` вернули `404`, отдельного health/metrics endpoint нет.
Исходящие вызовы	Локальные обращения к Guardant runtime на `GCC_HOST:3189` через `nc` и `vzguard`; при `ACTIVATION_TYPE=online` или online-фазе `any` возможен исходящий доступ к внешней Guardant Station / backend активации. Kafka, PostgreSQL, Redis, MinIO/S3, gRPC и бизнес-API BOX5-DIT-MGSN сервис напрямую не вызывает.
Протоколы	HTTP поверх TCP `19191` для offline activation/readiness; Guardant GCC HTTP/TCP `3189`; host network namespace; доступ к host `/dev/mem` и `/dev/shm`; stdout/stderr для логов. TLS, аутентификация на локальном API, Prometheus exposition, Kafka, SQL, Redis и gRPC у сервиса не используются.
Хранилища	Собственной БД и файлового persistent volume у контейнера нет. В конфигурации продуктового контура заданы bind mount `/dev/shm:/dev/shm` и device `/dev/mem:/dev/mem`; состояние активации и Guardant runtime живут вне контейнера в установленном на хосте GCC, чтобы пересоздание контейнера не требовало повторной offline-активации. Чувствительная информация и серийные номера лицензий не документируются и не должны попадать в вывод команд.
Конфигурация	Основные параметры: `GUARDANT_CONTROL_VERSION`, `ACTIVATION_TYPE`, `LICENSE_KEY_SERIAL`, `DO_START_GCC`, `GCC_HOST`, `PYTHONUNBUFFERED`. В конфигурации продуктового контура фактически задано `ACTIVATION_TYPE=offline`, `PYTHONUNBUFFERED=1`, серийный номер передан через env и намеренно не раскрывается; `DO_START_GCC` отсутствует, `GCC_HOST` берётся по умолчанию как `localhost`. Compose задаёт `privileged: true`, `init: true`, `network_mode: host`, volume `/dev/shm:/dev/shm` и device `/dev/mem:/dev/mem`; `restart` и `depends_on` у самого сервиса в compose не заданы.
Логирование	`start-service.sh` и `activator-py` пишут в stdout/stderr; Docker log driver в конфигурации продуктового контура - `loki`. В логах видны ожидание GCC, выбранный `GCC_HOST`, старт activator, результат online-активации и обработка `/get_request`/`/set_response`.
Мониторинг	Docker healthcheck отсутствует (`Health=none`), `/health` и `/metrics` не реализованы. Практические проверки: контейнер `running`, процессы `/guardant/start-service.sh` и `python3 /activator-py/main.pyc` живы, host слушает `0.0.0.0:3189` и `0.0.0.0:19191`, TCP connect к `127.0.0.1:3189` и `127.0.0.1:19191` успешен. Для штатной проверки не следует дергать `GET /get_request`, потому что он генерирует activation request; достаточно TCP/readiness-проверки порта `19191` или зависимости `host.docker.internal:19191` в licensed services.
Критичность	Высокая для licensed-развёртываний: отказ GCC или activator блокирует готовность лицензирования, offline/online активацию и может остановить запуск/работу сервисов, которые ждут `host.docker.internal:19191` или читают реальные лимиты Guardant. На текущем конфигурации продуктового контура влияние на видеоконтур ниже, потому что `inf-load-balancer` работает в `-unlimited` режиме и не ждёт Guardant в `DEPENDS`; это не отражает production licensed-путь.
Эксплуатационные особенности и известные ограничения	Сервис зависит от установленного на хосте GCC и низкоуровневого доступа к хосту (`privileged`, `/dev/mem`, `/dev/shm`), поэтому перенос контейнера без подготовки хоста невалиден. Если `DO_START_GCC` не задан и host GCC остановлен, wrapper бесконечно ждёт `3189` и не поднимает `19191`. Из-за `network_mode: host` порты `3189` и `19191` слушают на `0.0.0.0`, а не изолированы Docker port publishing; отдельной auth/TLS-защиты на activation API нет. Docker healthcheck и restart policy в конфигурации продуктового контура отсутствуют. Текущая конфигурация продуктового контура использует `load-balancer2:1.2.12-unlimited`, поэтому по нему нельзя оценивать реальное принудительное соблюдение лимита камер в licensed-сборке.

`mm-conversion`¶

Поле	Описание
Название сервиса	`mm-conversion`. В compose-файле сервиса используется имя `mm_conversion`; в конфигурации продуктового контура развёрнут контейнер `inference-mm_conversion-1` с образом `docker.vizorlabs.ru/vizorlabs/mm-conversion-image:v2.0.0`.
Назначение	Внутренний сервис конвертации MMLAB/MMDeploy-моделей для контура инференса. По запросу `vlmodels`/NRI запускает packaged export-команды для MM-моделей и материализует ONNX/TensorRT-артефакты в общий каталог моделей, чтобы `inf-nri-inference` мог загрузить уже сконвертированные веса.
Подсистема	`inference`, runtime-контур подготовки моделей BOX5-DIT-MGSN. Работает рядом с `inf-nri-inference` и `yolo_conversion`; разделяет с ними `/tmp` для Unix-сокетов и `/models` для артефактов. Registry/MLflow/VLFLOW-доступ выполняет вызывающий `inf-nri-inference`, а не сам conversion-сервис.
Основные функции	Принимает команду конвертации через FastAPI, создаёт `process_id`, запускает команду в отдельном `multiprocessing.Process` через `subprocess.run(..., shell=True, check=True)`, хранит статус процесса в памяти и отдаёт его по polling API. В образе `v2.0.0` присутствуют entrypoint-скрипты `python3 /opt/converter/mmpose/export.py` и `python3 /opt/converter/mmpretrain/export.py`; они используют MMDeploy-профили из `/opt/mmlab/mmdeploy/configs`, читают исходные `weights.pth`/`config.py` из `/models/.../model/artifacts` и пишут ONNX/TensorRT-результат обратно в тот же shared model tree.
Входящие вызовы	Основной вызывающий сервис на BOX5-DIT-MGSN - `inf-nri-inference`: compose задаёт `depends_on: mm_conversion`, общий mount `/tmp` и env `MMLAB_CONVERSION_URI=/tmp/mm_conversion_sock`. Текущий контейнер слушает только HTTP-over-Unix-socket `uvicorn main:app --uds /tmp/mm_conversion_sock`: `POST /start-process/` с JSON `{"command": "<shell command>"}`, `GET /status/{process_id}` и `GET /status_server`. Host-порты не опубликованы, TCP `127.0.0.1:8000` внутри контейнера закрыт; gRPC API отсутствует (`/grpc/...` возвращает `404`).
Исходящие вызовы	Сетевых исходящих интеграций нет: сервис не обращается к Kafka, PostgreSQL, Redis, MinIO/S3, MLflow/VLFLOW, HTTP/gRPC upstream и не публикует события. Единственный runtime side effect - локальный запуск shell-команды конвертации, чтение/запись файлов в `/models` и временные рабочие каталоги `/tmp/mmpose` и `/tmp/mmpretrain`.
Протоколы	HTTP/1.1 + JSON поверх Unix domain socket `/tmp/mm_conversion_sock`; локальная файловая система; shell subprocess; Docker stdout/stderr. В конфигурации продуктового контура нет TCP HTTP listener, gRPC, Kafka, SQL, Redis, WebSocket, Prometheus exposition и внешнего API.
Хранилища	Собственной БД и persistent state нет. В конфигурации продуктового контура заданы bind mounts: `/data/mlflow-models` -> `/models` и `/tmp` -> `/tmp`. Выходные артефакты сохраняются в `/models/<model>/<version>/model/artifacts`; `process_status` хранится только в памяти процесса и теряется при рестарте контейнера. Каталог `/converts` в текущей схеме смонтирован в `inf-nri-inference`, но не в `mm_conversion`.
Конфигурация	Compose-проект `inference` из `/home/vizorlabs/CODE/box3/inference/docker-compose.yml`; service label `com.docker.compose.service=mm_conversion`, сеть `bx_default`, alias `mm_conversion`. Ключевые параметры: `MM_CONVERTER_IMAGE`, `MODELS_PATH`, `BOX_MMLAB_CONVERSION_URI`, env `MODELS_PATH=/models`, command `uvicorn main:app --uds $BOX_MMLAB_CONVERSION_URI`. Контейнер запущен с NVIDIA runtime, `CUDA_VERSION=12.6.1`, `NVIDIA_VISIBLE_DEVICES=all`, `NVIDIA_DRIVER_CAPABILITIES=compute,utility`; внутри доступны `torch.cuda.is_available() = True` и одна видимая GPU. Docker `restart` policy и healthcheck не заданы.
Логирование	Uvicorn пишет startup/request logs в stdout/stderr; FastAPI-обработчики через Loguru фиксируют команду конвертации и проверки статуса, export-скрипты прокидывают stdout дочерних процессов в Loguru. В конфигурации продуктового контура Docker log driver - `loki` с ротационными параметрами; отдельного файлового log mount у сервиса нет.
Мониторинг	Собственных `/metrics`, Prometheus exporter и Docker healthcheck нет. Минимальная прикладная проверка - `GET /status_server` через Unix-сокет, в конфигурации продуктового контура вернула `{"process_id":null,"status":"200","error":false}`; `/metrics` возвращает `404`. Операционные проверки: контейнер `running`, наличие socket-файла `/tmp/mm_conversion_sock`, доступность GPU/TensorRT-стека, отсутствие зависших converter-процессов, появление ожидаемого файла в `/models/.../artifacts` и успешный polling `GET /status/{process_id}` со стороны `inf-nri-inference`.
Критичность	Высокая для первого запуска или обновления MMLAB-моделей, когда сконвертированный артефакт отсутствует в `/models`: NRI не сможет самовосстановить TensorRT/ONNX-веса и запуск соответствующего model node завершится ошибкой. Для уже подготовленных моделей отказ сервиса не останавливает камеры, медиасервер, Kafka и уже запущенные сценарии, пока нужные converted artifacts остаются на shared volume.
Эксплуатационные особенности и известные ограничения	API исполняет shell-команду от доверенного внутреннего клиента, поэтому сервис нельзя публиковать наружу и нельзя отдавать недоверенным пользователям. Статусы процессов не персистентны: после рестарта старые `process_id` становятся `unknown`, а Docker healthcheck не выявляет зависание export-команды. Транспорт должен совпадать с настройками клиента: на текущем BOX5-DIT-MGSN используется socket mode, тогда как HTTP `:8000` в старых/Box3-сценариях требует другой команды запуска. Сервис критичен к совпадению shared mounts `/tmp` и `/models` между `inf-nri-inference` и `mm_conversion`; `/converts` в сам conversion-контейнер не смонтирован. В образе `v2.0.0` фактически присутствуют только `mmpose` и `mmpretrain` export entrypoints, поэтому другие MM-семейства требуют отдельной поддержки в образе и command builder.

`yolo-conversion`¶

В compose-файле сервиса используется имя yolo_conversion.

Поле	Описание
Название сервиса	`yolo-conversion`, compose-сервис `yolo_conversion`. В конфигурации продуктового контура развёрнут в проекте `inference` как контейнер `inference-yolo_conversion-1` с образом `docker.vizorlabs.ru/vizorlabs/yolo-conversion-image:v2.0.0`; host-порты не опубликованы, сервис слушает только Unix socket `/tmp/yolo_conversion_sock`.
Назначение	Внутренний conversion-sidecar для подготовки артефактов non-MMLAB моделей в контуре NRI: YOLOv5, YOLOv7, YOLOv8, DEIM и `abob_classifier`. По командам, построенным `vlmodels`/`vlmrs`, запускает экспорт в ONNX, TensorRT или TorchScript и кладёт результат в общий каталог моделей.
Подсистема	`inference`, контур BOX5-DIT-MGSN NRI и материализации моделей. Работает рядом с `inf-nri-inference`, `mm_conversion`, `inf-mediaserver`, `svr-models-registry` и модельным хранилищем `/models`; sandbox-окружение имеет отдельный аналог `nr-sbx-yolo-conversion`.
Основные функции	Предоставляет FastAPI API `POST /start-process/`, `GET /status/{process_id}` и `GET /status_server`; принимает JSON с shell-командой конвертации; запускает команду в отдельном `multiprocessing.Process` через `subprocess.run(..., shell=True, check=True)`; хранит статус процесса в памяти; выполняет packaged entrypoints под `/opt/converter`, включая `yolov5/export.py`, `yolov7/export.py`, `yolov8/export.py`, `deim/export.py` и `abob_classifier/export.py`; пишет сконвертированные артефакты в `/models/.../model/artifacts`.
Входящие вызовы	Основной вызывающий сервис - `inf-nri-inference`: в конфигурации продуктового контура у него заданы `YOLO_CONVERSION_URI=/tmp/yolo_conversion_sock` и общий bind mount `/tmp`, поэтому клиент `mscmodels_converter` обращается к тем же HTTP routes через Unix socket. Проверка в конфигурации продуктового контура показала, что `inf-nri-inference` видит socket и `GET /status_server` возвращает `{"process_id": null, "status": "200", "error": false}`. Внешний HTTP-порт и gRPC API отсутствуют.
Исходящие вызовы	Прикладных сетевых исходящих вызовов у API-слоя нет: сервис не ходит в Kafka, Redis, PostgreSQL, gRPC, MinIO, MLflow или Box API. Его исходящее взаимодействие - локальные subprocess-ы конвертации, чтение исходных весов и запись ONNX/TensorRT/TorchScript файлов в `/models`, а также временные файлы в `/tmp`; доступ к registry и выбор профиля выполняет вызывающий `inf-nri-inference`/`vlmodels`.
Протоколы	HTTP/JSON поверх Unix domain socket в текущем BOX5-DIT-MGSN compose; FastAPI OpenAPI routes доступны через тот же socket. В образе поддержан альтернативный TCP-режим `uvicorn --host 0.0.0.0 --port 8000`, но в конфигурации продуктового контура фактическая команда - `uvicorn main:app --uds /tmp/yolo_conversion_sock`, `Ports={}` и `127.0.0.1:8000` не слушается. gRPC, Kafka, WebSocket, TLS и published host-port не используются.
Хранилища	Собственной БД и persistent state нет. В конфигурации продуктового контура смонтированы `/data/mlflow-models -> /models` и `/tmp -> /tmp`; `/models` содержит исходные и сконвертированные model artifacts, `/tmp` нужен для Unix socket и временных файлов конвертеров. `/converts` в сам `yolo_conversion` не смонтирован; этот каталог есть у `inf-nri-inference` как локальный каталог NRI-конвертаций. Статусы `process_id` живут только в памяти процесса и теряются при рестарте контейнера.
Конфигурация	Compose задаёт `image: ${YOLO_CONVERTER_IMAGE}`, `MODELS_PATH=/models`, bind mounts `/models` и `/tmp`, команду `uvicorn main:app --uds $BOX_YOLO_CONVERSION_URI`; в конфигурации продуктового контура `BOX_YOLO_CONVERSION_URI` раскрыт в `/tmp/yolo_conversion_sock`. Контейнер подключён к сети `bx_default` с alias `yolo_conversion`, работает через NVIDIA runtime, `NVIDIA_VISIBLE_DEVICES=all`, `NVIDIA_DRIVER_CAPABILITIES=compute,utility`, `CUDA_VERSION=12.6.1`; видит GPU `NVIDIA RTX A2000`. `restart` и Docker healthcheck для самого `yolo_conversion` не заданы, `depends_on` задан со стороны `inf-nri-inference`.
Логирование	Логи идут в stdout/stderr контейнера и собираются Docker log driver `loki`. В логах видны startup uvicorn, access-строки к `/status_server`, `/metrics`, `/health`, `/docs` и вывод запускаемых conversion subprocess-ов; отдельного файлового лог-хранилища или ротации внутри сервиса не настроено.
Мониторинг	Docker healthcheck отсутствует (`Health=none`). Рабочая ручная проверка - наличие socket `/tmp/yolo_conversion_sock` и `GET /status_server` через `curl --unix-socket`; в конфигурации продуктового контура endpoint вернул HTTP 200. `/metrics` и `/health` возвращают 404, `/docs` возвращает 200; Prometheus scrape и service-level metrics для этого контейнера не настроены. Косвенный мониторинг - ошибки материализации моделей в логах `inf-nri-inference` и `yolo_conversion`.
Критичность	Высокая для ввода новых моделей, первого запуска профиля и forced reconversion: при недоступности сервиса `inf-nri-inference` не сможет собрать недостающие ONNX/TensorRT артефакты. Для уже работающих сценариев критичность средняя: если все нужные артефакты уже лежат в `/models`, текущий инференс может продолжать работу без нового обращения к конвертеру.
Эксплуатационные особенности и известные ограничения	API доверенный и выполняет произвольную shell-команду от внутреннего клиента, поэтому socket нельзя публиковать наружу. Нет auth/TLS, gRPC-контракта, TCP-порта, `/metrics`, `/health`, Docker healthcheck, очереди заданий, persistence статусов и отдельного restart policy. Рестарт контейнера делает старые `process_id` неизвестными. Успех конвертации зависит от совпадения shared mount `/models` у caller-а и converter-а, доступности CUDA/TensorRT и GPU runtime; CPU-only режим для штатного ONNX/TRT пути не является штатным режимом контура. Так как `/converts` не смонтирован в `yolo_conversion`, команды должны ссылаться только на пути, доступные внутри converter-контейнера, прежде всего `/models` и packaged scripts под `/opt/converter`.

`extended-inference`¶

Назначение: дополнительные сервисы управления BOX5-DIT-MGSN-инференсом.

`inf-flows-manager`¶

Поле	Описание
Название сервиса	`inf-flows-manager` (`node-red-integration/flows-manager`). В конфигурации продуктового контура развёрнут в compose-проекте `extended-inference` как контейнер `extended-inference-inf-flows-manager-1` с образом `docker.vizorlabs.ru/box-inference/flows-manager:1.0.9-dev`. Слушает FastAPI/uvicorn на внутреннем `3000/tcp`; host-порт не опубликован.
Назначение	Сервис контура управления BOX5-DIT-MGSN/NRI для управления версиями моделей в сохранённых Node-RED `flows.json`: отдаёт каталог доступных и уже скачанных версий моделей, ставит в очередь массовую замену версии модели в выбранных flow, извлекает параметры блоков из загруженного flow-файла. Сервис не исполняет инференс и не является исполняющим движком сценариев.
Подсистема	`extended-inference`, контур управления NRI-сценариями. Находится между `ui-rest-to-gprc`, `svr-scenario-storage`, `svr-models-registry`/VLFlow, локальным кэшем `/models` и топиком Kafka `websocket_service_state_changed`. `inf-vl-resource-manager` развёрнут рядом, но прямой вызов `flows-manager -> inf-vl-resource-manager` в текущей реализации не предусмотрен.
Основные функции	На старте запускает фоновую корутину `flow_manager.update_process`; через `models_service` из встроенного NRI-пакета читает все версии моделей и версии, уже лежащие в `MODELS_PATH`; принимает `PUT /api/v1/models/{model_name}/flows/`, сериализует обновления по `model_name`, скачивает каждый указанный `flows.json` из `svr-scenario-storage`, переписывает ссылки на `new_model_version` через NRI helper `model_update_flow_tab` и загружает обновлённый файл обратно; отдаёт список текущих процессов обновления; извлекает параметры блоков из multipart `flow` через `nri.node_red.tools.extract_flows_parameters`; публикует Kafka-события начала, ошибки и завершения обновления для WebSocket-уведомлений UI.
Входящие вызовы	HTTP REST на `:3000`: `GET /api/v1/models/versions/all/`, `GET /api/v1/models/versions/downloaded/`, `GET /api/v1/models/{model_name}/flow-ids/`, `PUT /api/v1/models/{model_name}/flows/`, `GET /api/v1/models/update-processes/`, `GET /api/v1/models/flows/{flow_id}/model-versions/`, `POST /api/v1/models/flows/parameters/extract/`; интерфейс OpenAPI доступен на `/api/docs/`, schema JSON — на `/api/swagger.json`. Основные вызывающие: `ui-rest-to-gprc`, который проксирует внешние для браузера пути `/api/inference/flows-manager/*`; `svr-scenario-storage`, который вызывает endpoint извлечения параметров при сохранении, миграции или patch flow; `nr-sbx-backend`, который ходит через публичный Box API для извлечения параметров сценария; внутренние скрипты выката и пользователи с эксплуатационным доступом.
Исходящие вызовы	HTTP к `svr-scenario-storage:3000`: `GET /download-flow-json-file/?scenario_version_uuid=...` для чтения flow, `POST /flows/update-models-info/?flow_id=...` с multipart `flows_info` для записи обновлённого flow; в коде также есть helper `POST /get-scenarios/simple-info/`. Через встроенный NRI model stack читает каталог и артефакты моделей из `svr-models-registry`/VLFlow (`VLFLOW_ENDPOINT=http://svr-models-registry:3000` в конфигурации продуктового контура), локального `/models` и, при соответствующем приоритете реестров, MLflow/S3/MinIO. В Kafka `inf-kafka:9092` публикует `websocket_service_state_changed` с `service=flows-manager`, `object_type=ModelFlows` и action `CREATE`/`OTHER`/`DELETE`. Прямого REST-вызова в `inf-nri-inference`, runtime `node-red-vl` или `inf-vl-resource-manager` не предусмотрено.
Протоколы	HTTP/REST JSON и multipart upload; OpenAPI/Swagger; протокол Kafka producer; HTTP к scenario/model storage; S3/MinIO/MLflow-клиенты через NRI model helpers при загрузке артефактов; файловый доступ к `/models` и служебным каталогам NRI; stdout/stderr Docker logs. gRPC, сервер WebSocket, TLS/auth на самом сервисе, Prometheus text endpoint и опубликованный host-порт в конфигурации продуктового контура отсутствуют.
Хранилища	Собственной БД нет. Очередь обновлений и `process_data_by_model_name` живут в памяти процесса и теряются при рестарте. Постоянный источник истины для production flow — `svr-scenario-storage` (PostgreSQL/MinIO), а не локальные файлы контейнера. В конфигурации продуктового контура заданы монтирования: `/data/mlflow-models -> /models`, `/data/compose-data2-no-swarm -> /compose_data`, `/data/compose-data2-no-swarm/inference/logs/nri_inference -> /log`, `/data/compose-data2-no-swarm/inference_ipc -> /inference_ipc`, `/dev/shm -> /dev/shm`, `/tmp -> /tmp`, `/data/sandbox-compose-data/inference/video-storage -> /video-storage`, `/data/sandbox-compose-data/inference/events-storage -> /events-storage`, `/etc/hostname -> /etc/hostname:ro`. Каталоги `/node-red-vl-data` и `/node-red-vl-configs` существуют в образе, но в конфигурации продуктового контура не являются bind-монтированиями и не являются долговременным хранилищем production flow.
Конфигурация	Базовые настройки приложения: `PORT=3000`, `SCENARIO_STORAGE=http://svr-scenario-storage:3000`, `KAFKA_HOST=inf-kafka:9092`, `KAFKA_GROUP=flows-manager`, `KAFKA_TOPIC_WEBSOCKET_SERVICE_STATE_CHANGED=websocket_service_state_changed`, `WEBSOCKET_SERVICE_NAME=flows-manager`; в конфигурации продуктового контура часть из них берётся из default-кода, потому что не задана в env. Compose задаёт `DEBUG=false`, `MODELS_PATH=/models`, `MODEL_REGISTRIES_PRIORITY=["filesystem", "vlflow"]`, `VLFLOW_ENDPOINT=http://svr-models-registry:3000`, `REACT_APP_NODE_RED_BACKEND_URL=/sandbox/node-red/` и большой набор унаследованных NRI/env-переменных для топиков Kafka, конвертеров YOLO/MMLab, VLFlow/MinIO/MLflow, переводов и вспомогательных Box-потоков. Значения параметров доступа (`GITLAB_TOKEN`, учётные данные MinIO/MLflow/Box) не должны попадать в документацию или логи проверок. `DEBUG=true` переводит entrypoint в бесконечный sleep; `DEPENDS` поддерживается entrypoint, но в конфигурации продуктового контура не задан.
Логирование	Приложение использует Loguru и uvicorn access/error logs в stdout/stderr; Docker log driver в конфигурации продуктового контура — `loki`. Ошибки FastAPI middleware пишутся stack trace в контейнерный лог, Kafka producer helper пишет технологические сообщения при отправке событий прогресса. Отдельное монтирование `/log` унаследовано от NRI и нужно helper-путям/отладке, но основной FastAPI-журнал читается через Docker/Loki.
Мониторинг	Docker healthcheck отсутствует (`Health=none`). `GET /api/docs/`, `GET /api/swagger.json`, `GET /api/v1/models/update-processes/`, `GET /api/v1/models/versions/downloaded/` и `GET /api/v1/models/versions/all/` в конфигурации продуктового контура вернули `200 OK`; в конфигурации продуктового контура `update-processes` был пустым, `versions/downloaded` вернул 75 записей, `versions/all` — 42 модели. `GET /metrics` вернул `404`, Prometheus endpoint в OpenAPI отсутствует. Практический мониторинг: состояние контейнера, проверочные API-запросы, ошибки в Loki, успешность HTTP-вызовов `svr-scenario-storage`, доступность `/models` и `svr-models-registry`, а также появление сообщений прогресса в Kafka/WebSocket.
Критичность	Высокая для сопровождения и выката NRI-сценариев, средняя для уже запущенного видеоконтура. Отказ сервиса не останавливает `inf-nri-inference` и текущие камеры напрямую, но блокирует обновление версий моделей в сохранённых flow, чтение сводки версий моделей по flow, извлечение параметров сценария при операциях `svr-scenario-storage`/sandbox и UI-операции через `/api/inference/flows-manager/*`.
Эксплуатационные особенности и известные ограничения	`GET /api/v1/models/{model_name}/flow-ids/` присутствует в OpenAPI и gateway, но текущая реализация вызывает `raise NotImplemented()` и в конфигурации продуктового контура возвращает `500`. Очередь обновлений хранится только в памяти: при рестарте теряются текущие процессы, повторной доставки нет; параллельность ограничена дедупликацией по `model_name`. HTTP-клиент `svr-scenario-storage` использует `timeout=None`, поэтому зависший storage/model registry может надолго подвесить процесс обновления. Нет собственного healthcheck, `/metrics`, постоянного журнала аудита, host-порта, TLS/auth на внутреннем API и прямого callback в исполняющий NRI runtime; применение изменения зависит от downstream-процесса чтения `svr-scenario-storage` и событий model registry. Для расследований используется фактическая runtime-конфигурация: running image, compose и код контейнера.

`inf-vl-resource-manager`¶

Поле	Описание
Название сервиса	`inf-vl-resource-manager` (`box-inference/vl-resource-manager`). В конфигурации продуктового контура развёрнут в compose-проекте `extended-inference` как контейнер `extended-inference-inf-vl-resource-manager-1` с образом `docker.vizorlabs.ru/box-inference/vl-resource-manager:dev`. Слушает FastAPI/uvicorn на внутреннем `3000/tcp`; host-порт не опубликован.
Назначение	Внутренний BOX5-DIT-MGSN-сервис управления ресурсами GPU для control-plane операций перед выкатыванием или включением моделей: проверяет доступную память GPU, создаёт краткоживущие резервирования, подтверждает или отменяет их и публикует heartbeat со снимком GPU-памяти. Сервис не исполняет NRI-сценарии, не загружает модели и не заменяет `svr-models-registry`/VLFlow.
Подсистема	`extended-inference`, вспомогательный контур resource management рядом с `inf-flows-manager`, `inf-nri-inference`, `inf-kafka` и Redis-sidecar `inf-vl-resource-manager-redis`. Фактическая связь сервиса — external rollout/control-plane client -> `inf-vl-resource-manager` -> Redis/Kafka/nvidia-smi. Прямой вызов из `inf-flows-manager`, `inf-nri-inference` или `ui-rest-to-gprc` в текущей реализации и env контура не предусмотрен.
Основные функции	Отдаёт REST-контракт `GET /api/v1/gpus/`, `GET /api/v1/gpus/{gpu_id}/`, `POST /api/v1/check-free-memory/`, `GET`/`POST`/`DELETE /api/v1/reservations/{reservation_uuid}/`; при первом запросе GPU читает `nvidia-smi --query-gpu=index,memory.total,memory.used,memory.free --format=csv` и сохраняет `GpuInfo` в Redis; создаёт `ReservationInfo` со статусом `RESERVED`, `expire_timestamp` и опциональным `model_info {name, version}`; подтверждает резервирование статусом `CONFIRMED` или отменяет статусом `CANCELED`; сериализует операции по GPU через Redis lock `gpu-<gpu_id>`; фоновая задача каждые 5 секунд удаляет истёкшие резервирования; отдельная фоновая задача публикует heartbeat с `hostname`, `node_hostname`, `timestamp`, `gpu_infos[]`.
Входящие вызовы	HTTP REST внутри сети `bx_default`: OpenAPI доступен на `GET /api/docs/` и `GET /api/swagger.json`; рабочие прикладные endpoints — `GET /api/v1/gpus/`, `GET /api/v1/gpus/{gpu_id}/`, `POST /api/v1/check-free-memory/` с JSON `{gpu_id, required_memory_mb, model_info?}`, `GET /api/v1/reservations/{reservation_uuid}/`, `POST /api/v1/reservations/{reservation_uuid}/` для подтверждения и `DELETE /api/v1/reservations/{reservation_uuid}/` для отмены. Предполагаемые вызывающие — внешние скрипты выката, пользователи с эксплуатационным доступом и control-plane клиенты, которым нужен admission check перед rollout модели. В конфигурации продуктового контура `GET /api/v1/gpus/0/` вернул `200 OK` и GPU record; прямых вызовов из `flows-manager`/NRI не предусмотрено.
Исходящие вызовы	Redis protocol к `inf-vl-resource-manager-redis:6379` для `GpuInfo` и `ReservationInfo`; Kafka produce в `inf-kafka:9092`, топик `vl_resource_manager_heartbeat`; локальный вызов `nvidia-smi` внутри контейнера с NVIDIA runtime. Исходящих HTTP/gRPC вызовов в `svr-scenario-storage`, `svr-models-registry`/VLFlow, MLflow, MinIO/S3, PostgreSQL или Box API в текущей реализации нет; Kafka consumer также отсутствует.
Протоколы	HTTP/REST JSON через FastAPI; OpenAPI/Swagger; Redis protocol; Kafka producer; локальный subprocess `nvidia-smi`; stdout/stderr Docker logs. TLS, auth, published host-port, WebSocket, gRPC, Prometheus text endpoint и файловый API в конфигурации продуктового контура отсутствуют.
Хранилища	Собственной БД и bind-mount-ов у контейнера `inf-vl-resource-manager` нет. Состояние хранится в Redis-sidecar `inf-vl-resource-manager-redis`: ключи `gpu-<id>` и записи резервирований `ReservationInfo`; в конфигурации продуктового контура Redis смонтирован в `/data` из `/data/compose-data2-no-swarm/inference/vl-resource-manager-redis-data`. Список `GET /api/v1/gpus/` показывает только уже закэшированные GPU; `GET /api/v1/gpus/{gpu_id}/` может инициализировать запись из текущего `nvidia-smi`.
Конфигурация	Compose задаёт `DEBUG=false`, `DEPENDS=["inf-vl-resource-manager-redis:6379","inf-kafka:9092"]`, `REDIS_HOST=inf-vl-resource-manager-redis`, `REDIS_PORT=6379`, `REDIS_DB=0`, `KAFKA_HOST=inf-kafka:9092`, `KAFKA_GROUP=vl-resource-manager`, `RESERVE_TTL_SECS=30`, `HEARTBEAT_INTERVAL_SEC=15`, `NODE_HOST_NAME=$(cat /etc/hostname)` и `SETTINGS_FILE=config.settings.production`; `KAFKA_TOPIC_VL_RESOURCE_MANAGER_HEARTBEAT` в конфигурации продуктового контура не задан и берётся из default-кода как `vl_resource_manager_heartbeat`. Контейнер работает в сети `bx_default`, `restart=always`, `Runtime=nvidia`, `NVIDIA_VISIBLE_DEVICES=all`, `NVIDIA_DRIVER_CAPABILITIES=compute,utility`; параметры доступа для VLFlow, model storage, scenario storage, MinIO или MLflow у сервиса отсутствуют.
Логирование	Приложение пишет Loguru и uvicorn access/error logs в stdout/stderr; Docker log driver в конфигурации продуктового контура — `loki`. В контейнерных логах видны startup, сообщения `CheckReservationsTask started`, `HeartbeatTask started` и регулярные записи отправки `Kafka send "vl_resource_manager_heartbeat": ...`. Отдельного файлового журнала или монтирования `/log` у сервиса нет.
Мониторинг	Docker healthcheck отсутствует (`Health=none`). Проверка в конфигурации продуктового контура: `/api/docs/`, `/api/swagger.json`, `/api/v1/gpus/` и `/api/v1/gpus/0/` вернули `200 OK`; `/metrics`, `/health` и `/status_server` вернули `404`. Практический контроль — состояние контейнеров `inf-vl-resource-manager` и `inf-vl-resource-manager-redis`, REST smoke-проверка GPU/reservation endpoints, Redis `DBSIZE`/наличие ключей `gpu-*`, логи Loki/Docker и наличие heartbeat-сообщений в Kafka.
Критичность	Средняя для уже запущенного видеоконтура и высокая для процессов выката, которые используют предварительное резервирование GPU-памяти. Отказ сервиса не останавливает `inf-nri-inference` и текущие сценарии напрямую, но отключает admission check, подтверждение/отмену резервирований и heartbeat `vl_resource_manager_heartbeat`; отказ Redis делает API состояния и резервирования неработоспособными.
Эксплуатационные особенности и известные ограничения	API доверенный, внутренний и без auth/TLS, поэтому его нельзя публиковать наружу. Нет `/metrics`, `/health`, Docker healthcheck, host-порта, Kafka consumer, прямой связи с VLFlow/model storage/scenario storage и постоянного аудита операций. GPU inventory не синхронизируется отдельным циклом: список GPU зависит от Redis-кэша и запросов `GET /api/v1/gpus/{gpu_id}/`. `NODE_HOST_NAME` в compose передаётся строкой `$(cat /etc/hostname)`, а не раскрытым hostname. В текущей реализации `confirm` и `cancel` оба уменьшают cached `free_gpu_mb`, поэтому при диагностике нужно сверять Redis-кэш с актуальным `nvidia-smi`. Для расследований используется фактический код запущенного контейнера вместе с running image и compose-конфигурацией.

`inf-vl-resource-manager-redis`¶

Поле	Описание
Название сервиса	`inf-vl-resource-manager-redis`. Redis 6 sidecar сервиса `inf-vl-resource-manager`; в конфигурации продуктового контура развёрнут в compose-проекте `extended-inference` как контейнер `extended-inference-inf-vl-resource-manager-redis-1` с образом `docker.vizorlabs.ru/docker-images/redis-6:master`. Слушает только внутренний Docker-порт `6379/tcp`, host-порт не опубликован.
Назначение	Оперативное Redis-хранилище, кэш и координационное хранилище состояния `inf-vl-resource-manager`: хранит сведения о GPU и резервированиях памяти, которые использует REST API resource-manager. Самостоятельной бизнес-функции, пользовательского API и отдельной логики принятия решений у контейнера Redis нет.
Подсистема	`extended-inference`, внутренний control-plane BOX5-DIT-MGSN/NRI для управления GPU-ресурсами. Работает в паре с `inf-vl-resource-manager`, который также связан с `inf-kafka` и публикует heartbeat `vl_resource_manager_heartbeat`; прямые UI, NRI runtime или `inf-flows-manager` вызовы в Redis не идут.
Основные функции	Принимает Redis-команды от `inf-vl-resource-manager`; хранит ROM-объекты `GpuInfo` и `ReservationInfo` в Redis DB `0`; поддерживает распределённые блокировки по `gpu_id` для сериализации операций резервирования; сохраняет кэшированную свободную память GPU, список активных резервирований, статусы `RESERVED`/`CONFIRMED`/`CANCELED`, `expire_timestamp` и сведения о модели; пишет RDB-снимки в `/data` для восстановления состояния после рестарта контейнера.
Входящие вызовы	Redis RESP/TCP на `6379` из внутренней Docker-сети `bx_default`. Штатный клиент - `inf-vl-resource-manager` с `REDIS_HOST=inf-vl-resource-manager-redis`, `REDIS_PORT=6379`, `REDIS_DB=0`; в `DEPENDS` приложения указано ожидание `inf-vl-resource-manager-redis:6379`. Операционная проверка выполняется через `redis-cli PING` внутри контейнера, в конфигурации продуктового контура получен `PONG`.
Исходящие вызовы	Сервис-специфичных исходящих HTTP, gRPC, Kafka, SQL, S3/MinIO или Redis-вызовов нет. Контейнер только отвечает Redis-клиентам по входящему TCP-соединению и пишет локальное состояние Redis в `/data`; Kafka heartbeat и обращения к `nvidia-smi` выполняет родительский `inf-vl-resource-manager`, а не Redis-sidecar.
Протоколы	Redis RESP поверх TCP `6379`; локальный файловый ввод-вывод Redis в `/data`; stdout/stderr для технологических логов контейнера. HTTP/REST, gRPC, Kafka producer/consumer, PostgreSQL, Prometheus endpoint, TLS, Redis ACL/password auth и опубликованный host-порт в конфигурации продуктового контура отсутствуют.
Хранилища	Основное состояние - Redis DB `0`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/inference/vl-resource-manager-redis-data` -> `/data`. Redis работает с `appendonly no` и стандартной RDB-политикой `save 3600 1 300 100 60 10000`; в конфигурации продуктового контура `DBSIZE=0` и `INFO keyspace` не показывал активных баз. Источник бизнес-смысла данных - код `inf-vl-resource-manager`, а не схема самого Redis-контейнера.
Конфигурация	Стандартный Redis-контейнер из `/home/vizorlabs/CODE/box3/extended-inference/docker-compose.yml`: `image=docker.vizorlabs.ru/docker-images/redis-6:master`, команда `redis-server`, `restart=always`, label `vizorlabs_container_name=vl-resource-manager-redis`, том `${COMPOSE_DATA}/inference/vl-resource-manager-redis-data:/data`, сеть `bx_default` с alias `inf-vl-resource-manager-redis`. Сервисные env-переопределения, custom `redis.conf`, TLS/auth и healthcheck у Redis-sidecar не заданы; образ `docker-images/redis-6` построен поверх `redis:6.0.9`.
Логирование	Штатные логи Redis пишутся в stdout/stderr контейнера и в конфигурации продуктового контура собираются Docker log driver `loki` с ротацией. Redis-sidecar не пишет прикладные события о GPU и резервированиях; ошибки бизнес-операций, истечение резервирований и heartbeat нужно смотреть в логах `inf-vl-resource-manager`.
Мониторинг	Docker healthcheck отсутствует (`Health=none`), HTTP `/metrics` и `/health` у sidecar отсутствуют. Практические проверки: контейнер `Up`, `redis-cli PING` возвращает `PONG`, `DBSIZE`/`INFO keyspace` показывают ожидаемое состояние, bind mount `/data` доступен, а `inf-vl-resource-manager` стартует после доступности `inf-vl-resource-manager-redis:6379` и продолжает публиковать heartbeat в Kafka.
Критичность	Высокая для работы `inf-vl-resource-manager`: недоступность Redis блокирует старт через `DEPENDS`, ломает чтение кэша GPU, создание/подтверждение/отмену резервирований и фоновые операции очистки. Для уже выполняющихся NRI-сценариев критичность ниже, потому что прямой вызов `inf-nri-inference` или `inf-flows-manager` в Redis/resource-manager в текущей конфигурации не предусмотрен.
Эксплуатационные особенности и известные ограничения	Это типовой Redis-sidecar без собственной бизнес-логики, публичного API, healthcheck, выделенных метрик, TLS/auth/ACL, репликации и Sentinel. Тег образа `master` не immutable-релиз. AOF выключен; потеря bind mount `/data` означает потерю кэшированного GPU-состояния и резервирований, после чего `inf-vl-resource-manager` должен заново инициализировать данные из `nvidia-smi` и новых запросов. Корректность статусов и TTL резервирований обеспечивает приложение; Redis не валидирует схему `GpuInfo`/`ReservationInfo` и не является источником самостоятельных бизнес-данных.

`severstal`¶

Назначение: домен интеграций и предметных сервисов проекта «BOX5-DIT-MGSN».

`svr-asutp`¶

Поле	Описание
Название сервиса	`svr-asutp` (`severstal/severstal-asutp`). В конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-asutp-1` с образом `docker.vizorlabs.ru/severstal/severstal-asutp:1.1.2-dev`. Слушает внутренний HTTP/gRPC API на `3000/tcp`; host-порт не опубликован.
Назначение	Интеграционный сервис АСУ ТП BOX5-DIT-MGSN: хранит технологические агрегаты (`units`) и правила привязки к сигналам Kafka, принимает метаданные и значения из выделенного ASUTP-брокера, вычисляет текущее булево состояние агрегатов, сохраняет результат в Redis и публикует изменения в основную Kafka-шину BOX5-DIT-MGSN.
Подсистема	`severstal`, контур ASUTP-интеграции. Находится между `ui-rest-to-gprc`/пользовательскими custom-domain API, собственными sidecar-сервисами `svr-asutp-postgres`, `svr-asutp-redis`, `svr-asutp-kafka`, `svr-asutp-schema-registry` и общей событийной шиной `inf-kafka`.
Основные функции	CRUD типов агрегатов и агрегатов; управление привязками агрегатов к ASUTP-топикам и полям; чтение списка топиков и полей, обнаруженных в Kafka/Schema Registry; чтение текущих значений и результатов агрегатов; ручная установка и снятие принудительного результата; управление Kafka-подключениями, включая default connection из env; синхронизация Avro-схем и материализация `topic_config`/`topic_fields`; обработка `_meta` и `_data` сообщений; периодический пересчёт результатов агрегатов; backup/helper методы для списков агрегатов и типов.
Входящие вызовы	HTTP/gRPC на `/grpc/box.custom.severstal.severstal_asutp.SeverstalAsutp/<Method>`: `Ping`, методы `Add/Edit/Delete/GetUnit`, `GetTopicNameInKafkaList`, `GetTopicDataFields`, `GetTopicValue`, `SetTopicValue`, `GetUnitResult`, `SetForceUnitResultByUuid`, `DeleteForceUnitResultByUuid`, `GetFuncInfoList`, backup-методы и методы `KafkaConnection`. Основной клиент - `ui-rest-to-gprc`, где включён `CUSTOM_DOMAINS=["severstal"]`; ASUTP-маршруты наружу переэкспонируются через custom-domain API BOX5-DIT-MGSN. Дополнительно сервис потребляет данные из `svr-asutp-kafka`: пары топиков `<topic>_meta` и `<topic>_data`, валидные относительно Schema Registry. В конфигурации продуктового контура контрольные запросы вернули `POST .../Ping -> 200 {}`, `GetTopicNameInKafkaList -> 200` и `GetKafkaConnections -> 200`.
Исходящие вызовы	PostgreSQL `svr-asutp-postgres:5432` для `units`, `unit_types`, `topics`, `topic_config`, `topic_fields`, `kafka_connections` и миграций `aerich`; Redis `svr-asutp-redis:6379` для текущих результатов и кэша Schema Registry; HTTP к `svr-asutp-schema-registry:8081` (`/subjects`, `/subjects/{subject}/versions/latest`, в debug-сценариях регистрация схем); Kafka consumer к `svr-asutp-kafka:9092`; Kafka producer в `inf-kafka:9092` для `asutp_unit_created`, `asutp_unit_updated`, `asutp_unit_deleted`, `asutp_unit_change_results`.
Протоколы	HTTP/gRPC JSON/protobuf через ASGI, FastAPI REST-проба, OpenAPI JSON, Kafka, Confluent Schema Registry HTTP API, PostgreSQL wire protocol, Redis RESP, Prometheus text endpoint. На текущем контуре `GET /severstal_asutp/` вернул `200 {"success":true}`, `/api/docs/` и `/openapi.json` доступны, но `/metrics` возвращает `500`.
Хранилища	Основное состояние хранится в `svr-asutp-postgres`; в конфигурации продуктового контура заданы таблицы `units`, `unit_types`, `topics`, `topic_config`, `topic_fields`, `kafka_connections`, `aerich` (`units=25`, `unit_types=15`, `topic_config=10`, `topic_fields=99`, `kafka_connections=14` в конфигурации продуктового контура). Redis хранит ключи вида `asutp_signal_unit_<uuid>` и `schema_registry_get_schema_str-<subject>`. Контейнер приложения имеет bind mount `/service/keys` из `severstal/keys` для keytab/avsc debug-материалов; собственного файлового хранилища бизнес-данных нет.
Конфигурация	В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `DEBUG=False`, `DEPENDS=["svr-asutp-postgres:5432", "inf-kafka:9092", "svr-asutp-kafka:9092", "svr-asutp-redis:6379", "svr-asutp-schema-registry:8081"]`, `SCHEMA_REGISTRY_URL=http://svr-asutp-schema-registry:8081`, `POSTGRES_HOST=svr-asutp-postgres`, `KAFKA_SIGNAL_HOST=svr-asutp-kafka`, `KAFKA_SIGNAL_GROUP=asutp`, `KAFKA_HOST=inf-kafka`, `REDIS_HOST=svr-asutp-redis`, `KAFKA_SIGNAL_COLLECTOR_ENABLE=True`, `RUN_REDIS_TASK=True`, `REDIS_TASK_PERIOD=5`, `DEBUG_DISABLE_SCHEMA_REGISTRY=False`, `DEBUG_MOCK_KAFKA_SIGNAL_TOPIC_DATA=True`, `DEBUG_REGISTER_SCHEMAS=False`. Параметры доступа (`POSTGRES_PASSWORD`, `FERNET_KEY`, учётные данные SASL/OAuth/Kerberos и keytab) в документации не раскрываются.
Логирование	Приложение пишет Loguru-логи и uvicorn access/error logs в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver - `loki`. В логах фиксируются старт consumer-а, получение audit-записи, сериализованный audit payload и результат технической обработки сообщения. Отдельного файлового журнала и отдельного audit topic у самого сервиса нет; его логи могут содержать пользовательские идентификаторы, названия сервисов, камер/сценариев и текст audit-событий, поэтому при публикации диагностических фрагментов требуется редактирование чувствительных данных.
Мониторинг	Docker healthcheck у `severstal-svr-asutp-1` отсутствует (`Health=none`, `RestartCount=0`). Практические проверки: состояние контейнеров `svr-asutp*`, gRPC `Ping`, REST `GET /severstal_asutp/`, доступность `/api/docs/` и `/openapi.json`, наличие валидных subjects в `svr-asutp-schema-registry`, рост/актуальность `topic_config` и `topic_fields`, наличие Redis-ключей результатов, ошибки в Loki. Sidecar `svr-asutp-schema-registry` и `svr-asutp-redis` имеют Docker health status `healthy`; у приложения `/metrics` в конфигурации продуктового контура неисправен и не должен быть единственной health-проверкой.
Критичность	Высокая для ASUTP-интеграции и сценариев, завязанных на технологическое состояние агрегатов. Отказ сервиса не останавливает весь видеоконтур BOX5-DIT-MGSN напрямую, но блокирует управление ASUTP-юнитами, актуализацию их результатов, force-overrides и публикацию событий `asutp_unit_*` downstream-компонентам.
Эксплуатационные особенности и известные ограничения	Сервис зависит от согласованности отдельного ASUTP Kafka/Schema Registry контура: топик попадает в обработку только при наличии пары `<topic>_meta`/`<topic>_data` и обязательных Avro-полей `identifier`, `tagName`, `dataKey`, `dataValue`, `dataTs`. В конфигурации продуктового контура включён `DEBUG_MOCK_KAFKA_SIGNAL_TOPIC_DATA=True`, из-за чего в `svr-asutp-kafka` и Schema Registry присутствуют debug-топики `TOPIC_1..TOPIC_10`; это нужно учитывать при диагностике реального ASUTP-трафика. Env `KAFKA_GROUP=severstal-asutp` есть в compose, но код использует `KAFKA_SIGNAL_GROUP`/значение из `kafka_connections`. Ротация `FERNET_KEY` без переупаковки записей ломает чтение сохранённых учётных данных Kafka. `/metrics` в конфигурации продуктового контура возвращает `500`; у приложения нет Docker healthcheck и внешне опубликованного порта.

`svr-asutp-kafka`¶

Поле	Описание
Название сервиса	`svr-asutp-kafka`. В конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-asutp-kafka-1` с образом `docker.vizorlabs.ru/docker-images/kafka:3.4`.
Назначение	Выделенный Kafka-брокер и краткоживущее хранилище событий ASUTP-среза. Обслуживает входные сигнальные топики для `svr-asutp` и Kafka-backed storage для `svr-asutp-schema-registry`; не является прикладным сервисом, REST/gRPC API или основным брокером событий BOX5-DIT-MGSN.
Подсистема	`severstal`, контур ASUTP. Изолирован от основного `inf-kafka` и sandbox-брокера `nr-sbx-kafka`; `svr-asutp` читает сигналы из `svr-asutp-kafka`, а итоговые уведомления о юнитах публикует уже в основной `inf-kafka`.
Основные функции	Single-node Kafka 3.4 в KRaft-режиме: совмещает роли broker/controller, принимает produce/fetch/metadata-запросы клиентов, хранит логи топиков, offsets и metadata, обслуживает Schema Registry topic `_schemas`, поддерживает ASUTP пары топиков `<topic>_meta` / `<topic>_data`. Payload-схемами и бизнес-обработкой владеют `svr-asutp` и `svr-asutp-schema-registry`, а не сам брокер.
Входящие вызовы	Kafka client traffic на `PLAINTEXT://svr-asutp-kafka:9092`. Клиенты по конфигурации: `svr-asutp` как основной consumer и collector consumer, debug/mock producer `svr-asutp` при включённом `DEBUG_MOCK_KAFKA_SIGNAL_TOPIC_DATA`, `svr-asutp-schema-registry` как Kafka store через `SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS=svr-asutp-kafka:9092`. KRaft controller listener настроен как `CONTROLLER://svr-asutp-kafka:9093`. В конфигурации продуктового контура видны топики `_schemas`, `__consumer_offsets`, `TOPIC_1_meta/data` ... `TOPIC_10_meta/data`; consumer groups — `asutp` и группы вида `asutp_<uuid>`.
Исходящие вызовы	Прикладных исходящих REST, gRPC, SQL, Redis или HTTP-вызовов нет. Брокер отвечает Kafka-клиентам по существующим TCP-соединениям, обменивается внутренним KRaft controller traffic и пишет данные Kafka в локальный каталог `/bitnami/kafka`.
Протоколы	Apache Kafka protocol поверх TCP `9092`, KRaft controller traffic поверх TCP `9093`, PLAINTEXT listeners внутри Docker-сети, локальный файловый I/O `/bitnami/kafka`, stdout/stderr для логов контейнера. Host-порты в конфигурации продуктового контура не опубликованы.
Хранилища	Kafka state directory `/bitnami/kafka`: topic logs, consumer offsets, cluster metadata и topic `_schemas` Schema Registry. На compose-контуре mounts у контейнера отсутствуют, поэтому данные находятся в writable layer контейнера и не являются долговечным bind-mounted хранилищем.
Конфигурация	Env-only конфигурация Bitnami Kafka: `KAFKA_ENABLE_KRAFT=yes`, `KAFKA_CFG_NODE_ID=1`, `KAFKA_CFG_PROCESS_ROLES=broker,controller`, `KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093`, `KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://svr-asutp-kafka:9092`, `KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@svr-asutp-kafka:9093`, `KAFKA_CFG_LOG_RETENTION_HOURS=2`, лимиты `KAFKA_CFG_MESSAGE_MAX_BYTES`, `KAFKA_CFG_MAX_PARTITION_FETCH_BYTES`, `KAFKA_CFG_MAX_REQUEST_SIZE` по `15728640`, `ALLOW_PLAINTEXT_LISTENER=yes`. Конфигурационный файл Kafka в compose не монтируется.
Логирование	Штатные логи Kafka/Bitnami startup scripts пишутся в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver — `loki`, restart policy — `always`. Отдельного прикладного журнала, audit-log или файлового лог-хранилища у брокера нет.
Мониторинг	Docker healthcheck у контейнера не задан (`Health=none`), собственного HTTP `/metrics` или `/health` нет. Практические проверки: состояние контейнера, `docker logs`, Kafka admin-команды `kafka-topics.sh --list` и `kafka-consumer-groups.sh --list/--describe`, доступность advertised listener, а также healthcheck `svr-asutp-schema-registry` через `GET /subjects`, который косвенно проверяет Kafka store.
Критичность	Высокая для ASUTP-контура. Отказ останавливает чтение ASUTP-сигналов, хранение offsets и работу Schema Registry store, из-за чего `svr-asutp` перестаёт получать новые `_meta`/`_data` события и корректно пересчитывать состояния юнитов. Основной событийный брокер `inf-kafka` и остальные домены BOX5-DIT-MGSN напрямую не заменяются этим сервисом, но downstream-уведомления ASUTP перестают появляться из-за остановки входного потока.
Эксплуатационные особенности и известные ограничения	Single-node Kafka без ZooKeeper и без кластера реплик; PLAINTEXT-only внутри Docker-сети; host-порт не опубликован; нет Docker healthcheck, Prometheus-метрик и публичного API; retention в конфигурации продуктового контура ограничен `2` часами; отсутствие bind mount на `/bitnami/kafka` означает потерю топиков, offsets и `_schemas` при пересоздании контейнера. Debug/mock topics `TOPIC_1..TOPIC_10` появляются при включённом `DEBUG_MOCK_KAFKA_SIGNAL_TOPIC_DATA` в `svr-asutp` и могут мешать диагностике реального ASUTP-трафика.

`svr-asutp-postgres`¶

Поле	Описание
Название сервиса	`svr-asutp-postgres`. В конфигурации продуктового контура задан контейнер `severstal-svr-asutp-postgres-1` в compose-проекте `severstal`, сервис `svr-asutp-postgres`, образ `docker.vizorlabs.ru/vizorlabs/postgres:13.1`; состояние `running`, порт `5432/tcp` доступен только во внутренней Docker-сети.
Назначение	Выделенная PostgreSQL-служба для `svr-asutp`: хранит единицы АСУ ТП, типы единиц, привязки к топикам, обнаруженные поля сигналов, конфигурации Kafka-подключений и состояние миграций Aerich. Это хранилище `svr-asutp`, а не отдельная бизнес-функция, API или интеграционный процесс.
Подсистема	Домен `severstal`, ASUTP-контур BOX5-DIT-MGSN. Работает как stateful sidecar рядом с `svr-asutp`, `svr-asutp-kafka`, `svr-asutp-redis` и `svr-asutp-schema-registry`; схемой и семантикой данных владеет приложение `svr-asutp`, а пользовательские и интеграционные вызовы проходят через него.
Основные функции	Инициализирует базу и роль PostgreSQL при первом старте; принимает SQL-подключения от `svr-asutp`; хранит таблицы, индексы, WAL и служебные файлы PostgreSQL в `PGDATA`; предоставляет состояние для Aerich-миграций и ORM-запросов родительского сервиса. Расчёт состояний агрегатов, Kafka-consume/produce, Schema Registry lookup, Redis-кэш и gRPC API находятся в `svr-asutp`, а не в этом контейнере.
Входящие вызовы	PostgreSQL wire protocol на `5432/tcp` из внутренней Docker-сети `bx_default`. Основной клиент — `svr-asutp`: на старте он выполняет `aerich upgrade`, затем использует БД для CRUD единиц, типов, topic metadata и runtime Kafka connection records. Host-порт в конфигурации продуктового контура не опубликован; диагностические SQL-запросы выполняются через контейнер или из внутренней сети.
Исходящие вызовы	Прикладных исходящих сетевых вызовов нет. Контейнер не обращается к HTTP/gRPC API, Kafka, Redis, Schema Registry, ClickHouse, MinIO/S3 или другим сервисам; он отвечает SQL-клиентам и пишет состояние PostgreSQL в подключённый каталог данных.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`; локальный файловый ввод-вывод PostgreSQL в `PGDATA`; `stdout`/`stderr` для технологических логов. HTTP, REST, gRPC, Kafka, Redis, Prometheus endpoint, TLS-терминация и публичный API у sidecar отсутствуют.
Хранилища	Основное состояние — PostgreSQL `13.1` в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/severstal/pgdata-asutp` -> `/var/lib/postgresql/data`. Рабочая БД и пользователь в конфигурации продуктового контура — `dnn`; в схеме `public` присутствуют таблицы `aerich`, `kafka_connections`, `topic_config`, `topic_fields`, `topics`, `unit_types`, `units`.
Конфигурация	Env-only конфигурация shared PostgreSQL image: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, а также базовые переменные образа `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`, `PATH`. Для конфигурации продуктового контура закреплён image-tag `13.1`; живой контейнер использует `RestartPolicy=always`, Docker log driver `loki`, сеть `bx_default` с alias `svr-asutp-postgres`, Docker healthcheck не задан. У `svr-asutp` должны быть согласованы `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST=svr-asutp-postgres` и `POSTGRES_PORT=5432`; значения параметров доступа в документацию не выносятся.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. Отдельного прикладного журнала у sidecar нет; ошибки миграций Aerich, ORM-запросов, Kafka-подключений, обработки сигналов и gRPC API нужно смотреть в логах `svr-asutp`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck в конфигурации продуктового контура нет (`Health=none`). Практические проверки: контейнер `severstal-svr-asutp-postgres-1` находится в состоянии `running`, `pg_isready -U dnn -d dnn` внутри контейнера возвращает `accepting connections`, SQL-подключение к БД успешно, список таблиц `public` совпадает с ожидаемой ASUTP-схемой. Готовность БД не доказывает готовность `svr-asutp`: отдельно нужно проверять приложение, миграции и Kafka/Schema Registry/Redis-зависимости.
Критичность	Высокая для ASUTP-функций BOX5-DIT-MGSN. Отказ или потеря БД блокирует нормальный старт `svr-asutp`, миграции, CRUD единиц и типов, хранение topic metadata и runtime Kafka-подключений; вычисление и публикация новых состояний агрегатов становится неполной или невозможной. Остальные домены BOX5-DIT-MGSN и основной `inf-kafka` не останавливаются напрямую, но ASUTP-срез UI/API и интеграции деградирует.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без собственной бизнес-валидации, публичного API, метрик, healthcheck и отдельного backup-sidecar в текущей конфигурации/в конфигурации продуктового контура. Схемой полностью управляет `svr-asutp`; ручные изменения таблиц могут нарушить ORM/Aerich-контракт и правила агрегирования. Потеря bind mount `pgdata-asutp` означает потерю конфигурации ASUTP-единиц, topic metadata и сохранённых Kafka-подключений, если они не восстановлены из бэкапа. Базовый код `svr-asutp` имеет defaults `asutp`, тогда как продуктовый контур BOX5-DIT-MGSN использует `dnn`, поэтому при переносе между контурами нужно сверять согласованность `POSTGRES_*` у приложения и sidecar.

`svr-asutp-redis`¶

Поле	Описание
Название сервиса	`svr-asutp-redis`. Redis 6 sidecar сервиса `svr-asutp`; в конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-asutp-redis-1` с образом `docker.vizorlabs.ru/docker-images/redis-6:master`. Слушает только внутренний Docker-порт `6379/tcp`; host-порт не опубликован.
Назначение	Оперативный Redis-бэкенд для `svr-asutp`: кэш, очередь/опора для фонового пересчёта и хранилище краткоживущего состояния ASUTP-агрегатов. Хранит текущий или принудительно заданный результат агрегата и кэш последних схем Schema Registry; самостоятельной бизнес-функции, пользовательского API и обработки сигналов АСУТП у контейнера нет.
Подсистема	`severstal`, контур интеграции АСУТП BOX5-DIT-MGSN. Работает только в связке с `svr-asutp`, который также использует `svr-asutp-postgres`, `svr-asutp-kafka`, `svr-asutp-schema-registry` и публикует события результата в основной `inf-kafka`.
Основные функции	Принимает Redis-команды от `svr-asutp`; хранит ключи `asutp_signal_unit_<unit_uuid>` с текущим/forced результатом агрегата как строковый float (`1.0`/`0.0`), где отсутствие ключа означает логическое `None`; хранит кэш `schema_registry_get_schema_str-<subject>` для результата helper-а `get_schema_str(subject)`; применяет TTL, заданный кодом `svr-asutp`; сохраняет Redis RDB в `/data` между рестартами контейнера. Сам Redis не вычисляет агрегаты, не читает Kafka и не выполняет периодические задачи.
Входящие вызовы	Redis RESP/TCP на `6379` из внутренней Docker-сети. Штатный клиент - `svr-asutp` с `REDIS_HOST=svr-asutp-redis`; в конфигурации продуктового контура также включены `RUN_REDIS_TASK=True` и `REDIS_TASK_PERIOD=5`, но сама периодика выполняется в приложении. Операционные проверки выполняются через `redis-cli PING` и `INFO keyspace` внутри контейнера.
Исходящие вызовы	Сервис-специфичных исходящих HTTP, gRPC, Kafka, SQL или Redis-вызовов нет. Контейнер только отвечает клиентам Redis по входящему TCP-соединению и пишет локальные файлы Redis в `/data`.
Протоколы	Redis RESP поверх TCP `6379`; файловый ввод-вывод Redis RDB в `/data`; Docker healthcheck `redis-cli ping`; stdout/stderr процесса Redis. HTTP/gRPC, Kafka, PostgreSQL, Prometheus endpoint, TLS, Redis ACL/password auth, Sentinel, Cluster, Pub/Sub и Redis Streams как прикладной контракт в текущей конфигурации не предусмотрены.
Хранилища	Redis DB `0`. В конфигурации продуктового контура заданы `db0:keys=35,expires=35`: `15` ключей `asutp_signal_unit_` и `20` ключей `schema_registry_get_schema_str-`; все ключи имеют TTL. `/data` смонтирован как anonymous Docker volume базового Redis-образа, audited bind mount для этого sidecar не предусмотрен. AOF выключен (`appendonly no`), действует стандартная RDB-политика `save 3600 1 300 100 60 10000`; данные нужно считать кэшем, а не долговременным источником истины.
Конфигурация	Стандартный Redis-контейнер без service-specific env overrides, custom `redis.conf` и command override (`redis-server`). Compose в конфигурации продуктового контура задаёт `image=docker.vizorlabs.ru/docker-images/redis-6:master`, `restart=always`, healthcheck `redis-cli ping` с интервалом `1s`, timeout `3s`, `30` retries, Docker log driver `none`; для конфигурации продуктового контура закреплён image-tag `master` с pinning `2026-04-13`. Клиентские настройки находятся в `svr-asutp`: `REDIS_HOST`, `REDIS_PORT`, `REDIS_KAFKA_SIGNAL_PREFIX`, `DATA_LIFE_TIME_SEC`, `REDIS_CACHE_SCHEMA_REGISTRY_PREFIX`, `DATA_LIFE_TIME_SCHEMA_REGISTRY_SEC`, `RUN_REDIS_TASK`, `REDIS_TASK_PERIOD`.
Логирование	У Redis нет прикладного логирования ASUTP. Штатный процесс Redis пишет технологические сообщения в stdout/stderr, но в конфигурации продуктового контура Docker logging driver для контейнера установлен в `none`, поэтому `docker logs` не является надёжным источником диагностики. Ошибки чтения/записи Redis, пересчёта результатов агрегатов, Schema Registry cache miss и отправки событий нужно смотреть в логах `svr-asutp`.
Мониторинг	Собственного HTTP `/metrics` и Redis exporter у sidecar нет. В конфигурации продуктового контура контейнер находится в состоянии `Up`/`healthy`, healthcheck выполняет `redis-cli ping`, ручной `PING` возвращает `PONG`, `INFO keyspace` показывает ожидаемые ключи DB `0`. Практический мониторинг: состояние контейнера и healthcheck, доступность `svr-asutp-redis:6379` для `svr-asutp`, динамика TTL-ключей, а также ошибки Redis-клиента в логах parent-сервиса.
Критичность	Высокая для ASUTP-контура `svr-asutp`: при отказе Redis чтение результатов агрегатов возвращает `None`, forced writes и periodic recompute не могут сохранить актуальное состояние, кэш Schema Registry теряется, а публикация `asutp_unit_change_results` в `inf-kafka` перестаёт отражать надёжное текущее состояние. На основной видеопоток BOX5-DIT-MGSN Redis-sidecar напрямую не влияет; постоянные настройки агрегатов и Kafka-подключений остаются в `svr-asutp-postgres`.
Эксплуатационные особенности и известные ограничения	Это generic Redis sidecar без собственной бизнес-логики, публичного API, авторизации/TLS/ACL, host-порта, выделенных метрик и durable queue-контракта. Тег образа `master` не является immutable-релизом. AOF выключен, `/data` в конфигурации продуктового контура не привязан к audited host path, поэтому потеря volume или истечение TTL очищает локальное состояние до следующего `_data` сообщения, forced write, ленивого обращения к Schema Registry или периодического пересчёта `svr-asutp`. Ключи `asutp_signal_topic_value_<topic>-<field>` есть в helper-коде `svr-asutp`, но текущий путь обработки `_data` их не пишет. В конфигурации продуктового контура включён debug/mock поток `svr-asutp`, поэтому часть schema-cache ключей может относиться к debug-топикам `TOPIC_*`.

`svr-asutp-schema-registry`¶

Поле	Описание
Название сервиса	`svr-asutp-schema-registry`. В конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-asutp-schema-registry-1` с образом `confluentinc/cp-schema-registry:7.8.1`; слушает только внутренний Docker-порт `8081/tcp`, host-порт не опубликован.
Назначение	Выделенный Confluent Schema Registry для ASUTP-среза `svr-asutp`. Хранит версии Avro-схем Kafka-топиков, по которым `svr-asutp` обнаруживает валидные пары `<topic>_meta` / `<topic>_data` и декодирует входные ASUTP-сообщения. Это инфраструктурный реестр схем, а не прикладная бизнес-функция, REST/gRPC API BOX5-DIT-MGSN или обработчик сигналов.
Подсистема	`severstal`, ASUTP-контур BOX5-DIT-MGSN. Работает как sidecar рядом с `svr-asutp-kafka`; клиентом является `svr-asutp` через `SCHEMA_REGISTRY_URL=http://svr-asutp-schema-registry:8081`. Хранилище registry metadata находится в выделенном брокере `svr-asutp-kafka`, а не в основном `inf-kafka`.
Основные функции	Обслуживает Confluent Schema Registry REST API; ведёт список subjects, версий, schema id и конфигурации совместимости; сохраняет registry metadata в Kafka-backed store; отдаёт latest-схемы для subjects; принимает регистрацию схем в debug/операционных сценариях. Для ASUTP значимы subjects с суффиксами `_meta` и `_data`: `svr-asutp` принимает только пары, где `_meta` содержит `identifier`, `tagName`, `dataKey`, а `_data` содержит `dataKey`, `dataValue`, `dataTs`. Сам registry не читает ASUTP Kafka-сообщения и не вычисляет агрегаты.
Входящие вызовы	HTTP на `svr-asutp-schema-registry:8081` из внутренней Docker-сети. Операции: `GET /subjects`, `GET /subjects/{subject}/versions/latest`, в debug-сценариях `POST /subjects/{subject}/versions`. `svr-asutp` периодически читает `/subjects` для синхронизации топиков и latest-схемы для декодирования; Docker healthcheck контейнера выполняет `curl -f http://localhost:8081/subjects`. В конфигурации продуктового контура `GET /subjects` вернул `20` subjects, включая debug-топики `TOPIC_1..TOPIC_10` с парами `_meta`/`_data`.
Исходящие вызовы	Kafka store к `svr-asutp-kafka:9092` через `SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS`. Registry пишет и читает служебный compacted topic `_schemas`; в конфигурации продуктового контура topic `_schemas` имеет `PartitionCount=1`, `ReplicationFactor=1`, `cleanup.policy=compact`. Исходящих вызовов к PostgreSQL, Redis, `svr-asutp`, `inf-kafka`, gRPC API или внешним системам у контейнера нет.
Протоколы	Confluent Schema Registry REST over HTTP (`8081`), Kafka protocol к `svr-asutp-kafka:9092`, Avro schema JSON как payload REST API, Docker healthcheck через HTTP `/subjects`. Сервис не предоставляет gRPC, Prometheus `/metrics` или пользовательский UI.
Хранилища	Основное состояние хранится не в файловой системе контейнера, а в Kafka topic `_schemas` на `svr-asutp-kafka`. У контейнера есть служебный anonymous volume базового Confluent-образа; bind mount с прикладными данными не предусмотрен. Долговечность schemas фактически зависит от состояния `svr-asutp-kafka`; в конфигурации продуктового контура этот брокер работает single-node без bind mount на `/bitnami/kafka`, поэтому потеря контейнерного слоя Kafka означает потерю `_schemas`.
Конфигурация	Env-only конфигурация Confluent image: `SCHEMA_REGISTRY_HOST_NAME=svr-asutp-schema-registry`, `SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS=svr-asutp-kafka:9092`, `SCHEMA_REGISTRY_LISTENERS=http://0.0.0.0:8081`. Для конфигурации продуктового контура закреплён tag `7.8.1` с pinning `2026-04-13`. В конфигурации продуктового контура также присутствует опечатанная переменная `DEPENPS=["svr-asutp-kafka:9092"]`; Confluent Schema Registry её не использует.
Логирование	Confluent Schema Registry пишет технологические Java/REST/KafkaStore-логи в `stdout`/`stderr`; Docker log driver в конфигурации продуктового контура - `loki`. В логах ожидаемы старт KafkaStore, REST-запросы, ошибки подключения к `svr-asutp-kafka`, ошибки сериализации/совместимости схем и healthcheck failures. Отдельного прикладного ASUTP-журнала у sidecar нет; ошибки бизнес-синхронизации нужно смотреть в `svr-asutp`.
Мониторинг	В конфигурации продуктового контура контейнер находится в состоянии `running`, Docker health status `healthy`, `RestartCount=0`; healthcheck: `curl -f http://localhost:8081/subjects` с interval `30s`, timeout `10s`, retries `3`. Практические проверки: состояние контейнера, `GET /subjects`, выборочное `GET /subjects/<subject>/versions/latest`, наличие topic `_schemas` в `svr-asutp-kafka`, ошибки Schema Registry/KafkaStore в Loki и актуальность `topic_config`/`topic_fields` в `svr-asutp-postgres`.
Критичность	Высокая для ASUTP-контура. При отказе registry `svr-asutp` теряет надёжное обнаружение topic pairs и доступ к latest Avro-схемам, из-за чего новые ASUTP-топики не материализуются, декодирование сообщений и пересчёт агрегатов деградируют или останавливаются. Основной видеопоток BOX5-DIT-MGSN и общий `inf-kafka` напрямую не зависят от этого sidecar, но функции ASUTP в UI/API становятся неполными.
Эксплуатационные особенности и известные ограничения	Single-instance Schema Registry без внешне опубликованного порта, TLS/auth и отдельного exporter-а; Kafka store одноузловой (`_schemas` RF=1) и в конфигурации продуктового контура зависит от недолговечного хранилища `svr-asutp-kafka`. Registry не валидирует бизнес-смысл ASUTP-полей: фильтрацию пар `_meta`/`_data` и обязательных Avro-полей выполняет `svr-asutp`. В конфигурации продуктового контура присутствуют debug/mock subjects `TOPIC_1..TOPIC_10`, поэтому список `/subjects` не равен списку продуктивных ASUTP-топиков. Опечатка `DEPENPS` в compose не задаёт зависимость запуска; при ручных операциях соблюдать порядок Kafka → Schema Registry → `svr-asutp`.

`svr-severstal-integration`¶

Поле	Описание
Название сервиса	`svr-severstal-integration` (`severstal/severstal-integration`). В конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-severstal-integration-1` с образом `docker.vizorlabs.ru/severstal/severstal-integration:1.3.23-dev`; внутренний HTTP/gRPC порт `3000/tcp`, host-порт не опубликован.
Назначение	Основной адаптер клиентских интеграций BOX5-DIT-MGSN: синхронизирует справочники ПК-КОТ, ведёт статусы отправки событий в ПК-КОТ, управляет подключениями и архивами ЦСВН, валидирует прикладные атрибуты событий и создаёт или дополняет события в `st-event-storage`.
Подсистема	Домен `severstal` / `integration`, стык пользовательского custom-domain API через `ui-rest-to-gprc`, инференса через `inf-kafka`, хранилищ `st-camera-storage` и `st-event-storage`, внешних источников ПК-КОТ/ЦСВН и сервиса `svr-severstal-org-sync`. Состояние приложения хранится в sidecar `svr-severstal-integration-postgres`.
Основные функции	Чтение справочников ПК-КОТ из `svr-postgres-pk-kot` и зеркалирование в локальную БД; экспорт рабочих зон в `st-camera-storage`; отправка полного ПК-КОТ набора в `st-event-storage`; обработка сценарных сообщений `make_severstal_event` и `save_rejected_severstal_event`; хранение отклонённых событий и причин отказа; ручное заполнение customer-specific данных события через `SetSeverstalEventData`; создание событий из архивного видео ЦСВН; очередь и retry отправки подтверждённых событий в ПК-КОТ; CRUD подключений ЦСВН, синхронизация камер через `svr-severstal-org-sync`, хранение sync-log и метаданных архивных видео; обработка defect-event потока; публикация websocket-уведомлений и PK-КОТ status/data updates в Kafka; ведение ClickHouse side-path для `work_zones`, `csvn_cameras` и `event_severstal_data`.
Входящие вызовы	HTTP/gRPC `POST /grpc/box.custom.severstal.severstal_integration.SeverstalIntegration/<Method>`: справочники `GetList`/`Get`, `GetProductionList`, статусы `GetEventStatusPKKot`, `GetEventListStatusPKKot`, `UpdateEventStatusPKKot`, `ExtendPKKotVideo`, CSVN-методы `Add/Get/Update/DeleteCSVNConnection`, `GetCSVNCamera`, `SyncCSNVCameras`, `ProcessMapCSVNCamera`, `GetCSVNSyncLog`, archive-video методы, `MakeSeverstalEventFromArchive`, `SetSeverstalEventData`, `GetRejectedSeverstalEvents`, `GetRejectedSeverstalEvent`, `GetRejectSeverstalEventReasonList`. REST: `GET /static/pk_kot_data.json`, `GET /static/videos/{camera_name}/{video_name_on_disk}` с range-запросами, `GET /kot-videos/{video_uuid}/`; внутри контейнера доступны `/api/docs/` и `/openapi.json`. Kafka consumer group `severstal-integration` читает `statistic_camera_add`, `statistic_camera_update`, `statistic_camera_del`, `camera_is_down`, `make_severstal_event`, `save_rejected_severstal_event`, `make_defect_event`, `finish_defect_event`, `current_scenarios`, `current_lite_scenarios`, `websocket_heartbeat`. Read-only запросы в конфигурации продуктового контура вернули: внешний `GET /api/severstal/severstal-integration/static/pk_kot_data.json -> 200`, внутренние `/api/docs/` и `/openapi.json -> 200`, gRPC `GetProductionList -> 200`, а также paginated `GetEventKindSectionList`, `GetRiskDangerList`, `GetRiskWorkAreaList`, `GetCSVNConnectionList`, `GetRejectedSeverstalEvents`, `GetRejectSeverstalEventReasonList -> 200` при `page=1`, `pageSize=3`.
Исходящие вызовы	PostgreSQL к `svr-severstal-integration-postgres:5432` для локального состояния и к `svr-postgres-pk-kot:5432` для справочников ПК-КОТ. HTTP/gRPC к `st-camera-storage` для camera tags и custom-domain camera-scenario helpers; к `st-event-storage` для `SyncSeverstalPKKotData`, `AddSeverstalEvent`, `SetSeverstalEventData`, `AddEvent`, `SetEventConfirmation`, `GetModelsInfoList`; к `svr-severstal-org-sync` для `SyncCameras`; к `ds-data-temporary-storage` для `SetData`/`GetData` изображений и видео; к `st-auth` для актуализации ролей; к `st-virt-cam-video-upload` для привязки видео виртуальных камер. HTTP отправка в ПК-КОТ через `PK_KOT_PUSH_URL`, опционально с Basic auth/TLS. Интеграции ЦСВН: Cisco VSM SOAP WSDL, Milestone SOAP WSDL, Macroscop HTTP `/configex`, `/command`, `/video`, а также виртуальный connector. Kafka produce в `inf-kafka`: `kafka_topic_statistic_cmd_send_video_event`, `set_event_finish`, `set_camera_defect`, `unset_camera_defect`, `pk_kot_data_updated`, `pk_kot_event_status_updated`, `websocket_service_state_changed`. ClickHouse `st-event-storage-clickhouse:9000`: чтение `object_tree_departments`, запись `work_zones`, `csvn_cameras`, `event_severstal_data` и служебных schema-version записей.
Протоколы	HTTP/gRPC JSON/protobuf через ASGI, HTTP/REST для статических JSON/видео и Swagger/OpenAPI, Kafka, PostgreSQL wire protocol, ClickHouse native protocol, HTTP Basic/TLS для внешнего ПК-КОТ при включении, SOAP/WSDL для Cisco VSM и Milestone, HTTP для Macroscop, локальный файловый ввод-вывод для `/videos` и camera-configs, stdout/stderr через Docker log driver `loki`. Внутренний API в конфигурации продуктового контура без TLS и без собственной авторизации; публикация наружу идёт через nginx/gateway только для нужных путей.
Хранилища	Основное состояние в `svr-severstal-integration-postgres`: `aerich`, `event_kind_sections`, `event_kinds`, `risk_dangers`, `technical_barriers`, `behavioral_barriers`, `basic_rules`, связующие таблицы барьеров/правил, `productions`, `pk_kot_camera_tags`, `cameras`, `cameras_pk_kot_camera_tags`, `csvn_connection_infos`, `csvn_connection_sessions`, `csvn_sync_logs`, `csvn_sync_log_api_responses`, `csvn_cameras`, `csvn_camera_archive_videos`, `pk_kot_pushed_events`, `pk_kot_event_videos`, `reject_severstal_event_reason`, `rejected_events`, `rejected_events_reject_severstal_event_reason`, `defect_events`, `scenarios`, `bboxes`. Объёмы таблиц являются эксплуатационными данными конкретного контура и в документе не фиксируются. Источник ПК-КОТ - `svr-postgres-pk-kot` с таблицами `ViolationKinds`, `ViolationKindSections`, `Risk_Dangers`, `Risk_WorkAreas`, `Cameras`, `BusinessUnits` и связями. Файлы архивных видео смонтированы из `/data/compose-data2-no-swarm/severstal/archive-videos` в `/videos`; camera configs смонтированы read-only из `/home/vizorlabs/CODE/box3/severstal/camera-configs`. ClickHouse side-path использует таблицы `work_zones`, `csvn_cameras`, `event_severstal_data`, `object_tree_departments`; каноническое хранилище событий остаётся в `st-event-storage`.
Конфигурация	В конфигурации продуктового контура заданы `SETTINGS_FILE=config.settings.production`, `DEBUG=false`, `TZ=Europe/Moscow`, `IS_DEBUG_CSVN=true`, `CAMERAS_CONFIG_SRC=db`, `USE_CLICKHOUSE=true`, `CLICKHOUSE_HOST=st-event-storage-clickhouse`, `KAFKA_HOST=inf-kafka:9092`, `KAFKA_GROUP=severstal-integration`, `POSTGRES_HOST=svr-severstal-integration-postgres`, `POSTGRES_PK_KOT_HOST=svr-postgres-pk-kot`, `SEVERSTAL_ORG_SYNC_URL=http://svr-severstal-org-sync:3000`, `CAMERA_STORAGE_URL=http://st-camera-storage:3000`, `EVENT_DATA_PARSE_INTERVAL_SEC=600`, `CAMERA_TAGS_PARSE_INTERVAL_SEC=300`, `CSVN_CONNECT_TIMEOUT=60`, `PK_KOT_EVENT_STATUSES_FOR_SEND=[2]`, `PK_KOT_EVENT_SCORE_AUTO_SEND=90`, `PK_KOT_IS_SSL_CONNECT=false`. Compose также задаёт `DEPENDS` на `svr-severstal-org-sync:3000`, локальный PostgreSQL, `svr-postgres-pk-kot:5432` и `inf-kafka:9092`. Параметры доступа `POSTGRES_*_PASSWORD`, `PK_KOT_USERNAME`, `PK_KOT_PASSWORD`, `PK_KOT_PUSH_URL` и публичные URL-шаблоны в документации не раскрываются.
Логирование	Приложение пишет Loguru-логи, uvicorn access log и stack trace в stdout/stderr; Docker log driver в конфигурации продуктового контура - `loki` с ротацией. В логах видны обращения к gRPC/REST, запуск и ошибки Kafka consumers, `MakeSeverstalEvent(...)`, `Kafka.SaveRejectedEvent(...)`, `PKKotSenderTask`, CSVN sync/archive операции, ошибки валидаторов и сетевых интеграций. Отдельное файловое лог-хранилище сервиса не предусмотрено; логи могут содержать UUID событий, id камер и диагностические фрагменты payload без параметров доступа.
Мониторинг	Docker healthcheck у application-контейнера отсутствует (`Health=none`), restart policy у `severstal-svr-severstal-integration-1` не задана; у sidecar PostgreSQL healthcheck также отсутствует, но `pg_isready -U dnn -d dnn` в конфигурации продуктового контура возвращает `accepting connections`. Реализованный в gRPC wrapper `GET /metrics` на образе возвращает `500 Internal Server Error` из-за отсутствующего метода `GetPrometheusMetrics`. Практические проверки: контейнер `running`, REST/gRPC read-only методы отвечают, внешний `static/pk_kot_data.json` отдаётся через gateway, consumer group `severstal-integration` имеет lag `0` по основным входным топикам, локальная БД доступна, ожидаемые ClickHouse-таблицы есть, в логах нет свежих ошибок Kafka/PK-КОТ/CSVN.
Критичность	Высокая для продуктового контура «BOX5-DIT-MGSN». Отказ сервиса не останавливает само получение видео и базовый инференс, но нарушает создание прикладных событий BOX5-DIT-MGSN из NRI, хранение rejected events, заполнение ПК-КОТ атрибутов, отправку подтверждённых событий в ПК-КОТ, синхронизацию справочников и рабочих зон, ЦСВН-синхронизацию камер, архивные видео и часть пользовательского API в customer-domain API. Потеря локальной БД приводит к потере очередей отправки, CSVN state/sync-log, rejected-event истории и локального зеркала справочников.
Эксплуатационные особенности и известные ограничения	Для конфигурации продуктового контура закреплён `1.3.21-dev`, а живой контейнер в конфигурации продуктового контура работает на `1.3.23-dev`, поэтому перед разбором инцидентов нужно сверять running image и env. `/metrics` неисправен, Docker healthcheck и restart policy у application-контейнера отсутствуют. Paginated gRPC list-методы при пустом `{}` в конфигурации продуктового контура возвращают `500 division by zero`; клиент должен передавать ненулевые `page` и `pageSize`. Legacy RPC `SendStoredViolationEvent` присутствует, но возвращает `Not implemented yet.`. В конфигурации продуктового контура включён `IS_DEBUG_CSVN=true` и есть виртуальное CSVN-подключение, что нужно учитывать при диагностике реальных ЦСВН интеграций. Внутренний API доверенный, без auth/TLS; внешние ПК-КОТ и ЦСВН вызовы зависят от доступности сетей, учётных данных и схем, а ClickHouse side-path не является каноническим хранилищем событий.

`svr-severstal-integration-postgres`¶

Поле	Описание
Название сервиса	`svr-severstal-integration-postgres`. PostgreSQL 13.1 sidecar сервиса `svr-severstal-integration`; в конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-severstal-integration-postgres-1` с образом `docker.vizorlabs.ru/vizorlabs/postgres:13.1`. Слушает только внутренний Docker-порт `5432/tcp`; host-порт не опубликован.
Назначение	Выделенное PostgreSQL-хранилище `svr-severstal-integration`. Содержит локальное состояние адаптера: зеркала справочников PK-KOT, очередь и статусы отправки событий в PK-KOT, настройки/сессии/журналы CSVN-синхронизации, метаданные архивных видео, customer-specific отклонённые события, defect-события и кэшированные метаданные сценариев. Самостоятельной бизнес-функции, пользовательского API и фоновой обработки у контейнера нет.
Подсистема	`severstal`, контур клиентской интеграции BOX5-DIT-MGSN. Работает как технический sidecar рядом с `svr-severstal-integration`, который также использует `svr-postgres-pk-kot`, `svr-severstal-org-sync`, `inf-kafka` и, при включённом `USE_CLICKHOUSE`, `st-event-storage-clickhouse`.
Основные функции	Принимает PostgreSQL-подключения от `svr-severstal-integration`; хранит схему приложения и данные в `PGDATA`; предоставляет БД для Aerich-миграций при старте parent-сервиса; сохраняет состояние асинхронных workflow: PK-KOT retry queue, CSVN sync runs, archive-video extraction state, rejected-event retention и локальные справочники. SQL-логику, вызовы внешних систем и фоновые задачи выполняет только `svr-severstal-integration`.
Входящие вызовы	PostgreSQL/TCP `5432` из внутренней Docker-сети. Основной клиент - `svr-severstal-integration`: в конфигурации продуктового контура у него заданы `POSTGRES_HOST=svr-severstal-integration-postgres`, `POSTGRES_DATABASE=dnn`, `POSTGRES_USER=dnn` и `DEPENDS=["svr-severstal-org-sync:3000", "svr-severstal-integration-postgres:5432", "svr-postgres-pk-kot:5432", "inf-kafka:9092"]`. Диагностические SQL-подключения возможны из контейнерной сети или через `docker exec`; внешнего опубликованного порта нет.
Исходящие вызовы	Прикладных исходящих HTTP, gRPC, Kafka, ClickHouse, Redis или SQL-вызовов нет. Контейнер выступает сервером PostgreSQL и пишет данные в локальный каталог `/var/lib/postgresql/data`.
Протоколы	PostgreSQL wire protocol поверх TCP `5432` во внутренней сети; локальный Unix-socket PostgreSQL для операций внутри контейнера; файловый ввод-вывод PostgreSQL в `PGDATA`; stdout/stderr процесса PostgreSQL. HTTP/gRPC, REST, gRPC, Kafka, Prometheus endpoint и TLS-терминация напрямую в контейнере не используются.
Хранилища	Основное состояние - PostgreSQL в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/severstal/pgdata-severstal-integration` -> `/var/lib/postgresql/data`. В рабочей БД `dnn` схема `public` содержит таблицы `aerich`, `pk_kot_camera_tags`, `event_kind_sections`, `event_kinds`, `risk_dangers`, `technical_barriers`, `behavioral_barriers`, `basic_rules`, `productions`, `pk_kot_pushed_events`, `pk_kot_event_videos`, `cameras`, `csvn_connection_infos`, `csvn_connection_sessions`, `csvn_sync_logs`, `csvn_sync_log_api_responses`, `csvn_cameras`, `csvn_camera_archive_videos`, `reject_severstal_event_reason`, `rejected_events`, `defect_events`, `scenarios` и связующие таблицы many-to-many. Основной источник PK-KOT-справочников остаётся в `svr-postgres-pk-kot`; здесь хранится рабочее зеркало и состояние обработки.
Конфигурация	Env-only конфигурация стандартного PostgreSQL-образа. В конфигурации продуктового контура заданы `POSTGRES_DB=dnn`, `POSTGRES_USER=dnn`, `PGDATA=/var/lib/postgresql/data`, `PG_MAJOR=13`, `PG_VERSION=13.1-1.pgdg100+1`, `GOSU_VERSION=1.12`, `LANG=en_US.utf8`, `RestartPolicy=always`, Docker log driver `loki`, отсутствие Docker healthcheck; значение `POSTGRES_PASSWORD` в документацию не выносится. Для конфигурации продуктового контура закреплён image-tag `13.1` с pinning `2026-04-13`.
Логирование	У контейнера есть только технологические логи PostgreSQL в stdout/stderr, которые в конфигурации продуктового контура отправляются Docker log driver `loki`. Ошибки миграций, SQLAlchemy/Tortoise-подключений, PK-KOT queue, CSVN-синхронизации и обработки отклонённых событий нужно искать в логах `svr-severstal-integration`, потому что бизнес-контекст в PostgreSQL-sidecar не логируется.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck нет (`Health=none`). Практические проверки: контейнер `severstal-svr-severstal-integration-postgres-1` в состоянии `running`, `pg_isready -U dnn -d dnn` внутри контейнера возвращает `accepting connections`, SQL-подключение к БД успешно, в `public` присутствует ожидаемая схема, а `svr-severstal-integration` проходит стартовую проверку `DEPENDS` и `aerich upgrade`.
Критичность	Высокая для контура `svr-severstal-integration`: при недоступности БД parent-сервис не проходит стартовую зависимость и теряет возможность читать/писать локальные справочники, CSVN-состояние, очередь PK-KOT, архивные видео и отклонённые события. На базовый видеопоток и инференс BOX5-DIT-MGSN контейнер напрямую не влияет, но ломает customer-domain API BOX5-DIT-MGSN и интеграционные workflow вокруг PK-KOT/CSVN. Потеря `PGDATA` означает потерю локального состояния и очередей, даже если часть справочников можно восстановить из `svr-postgres-pk-kot` и Kafka.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без публичного API, выделенных метрик, Docker healthcheck, опубликованного host-порта и собственного backup-helper контейнера в compose. Доступность `pg_isready` доказывает готовность СУБД, но не успешность миграций и бизнес-задач `svr-severstal-integration`; их нужно проверять отдельно. Схема БД управляется Aerich-миграциями parent-сервиса и может меняться вместе с версией образа. Чувствительная информация передаётся через env и в документации не фиксируется.

`svr-severstal-nifi-integration`¶

Поле	Описание
Название сервиса	`svr-severstal-nifi-integration`. NiFi-named FastAPI/Uvicorn-сервис интеграционного контура BOX5-DIT-MGSN; в конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-severstal-nifi-integration-1` с образом `docker.vizorlabs.ru/severstal/severstal-nifi-integration:1.0.0-dev` и внутренним портом `3000/tcp`.
Назначение	Занимает слот адаптера NiFi для BOX5-DIT-MGSN, но в текущей реализации не выполняет маршрутизацию через NiFi и Kafka. Текущий фактический контракт — запуск пустой FastAPI-оболочки с документационными endpoint-ами и владение локальной PostgreSQL-схемой справочников PK-KOT: подразделения, камеры, рабочие зоны, опасности, барьеры, виды нарушений, базовые правила и таблица сопоставления `ImportDepartments`.
Подсистема	`severstal`, интеграционный контур BOX5-DIT-MGSN. Связан с sidecar `svr-severstal-nifi-integration-postgres`; функционально находится рядом с `svr-severstal-integration` и `svr-severstal-org-sync`, но прямых runtime-вызовов к ним в текущей реализации не предусмотрено.
Основные функции	При старте ждёт доступности `svr-severstal-nifi-integration-postgres:5432` через `wait-depends`, выполняет `aerich upgrade`, инициализирует Tortoise ORM и поднимает Uvicorn на `0.0.0.0:3000`. Создаёт и мигрирует таблицы `BusinessUnits`, `Departments`, `ImportDepartments`, `Cameras`, `CameraAdGroups`, `Risk_WorkAreas`, `RiskWorkAreas_Cameras`, `Risk_Dangers`, `TechnicalBarriers`, `BehavioralBarriers`, `RiskDangers_TechnicalBarriers`, `ViolationKindSections`, `ViolationKinds`, `BasicRules`, `BasicRules_RiskDangers`, `aerich`. Бизнес-обработчиков, фоновых NiFi/Kafka worker-ов и зарегистрированных API-роутов в текущем коде нет.
Входящие вызовы	Внутренний HTTP на `3000`: `GET /api/docs/` возвращает Swagger UI, `GET /openapi.json` возвращает OpenAPI-документ с пустым `paths: {}`. В конфигурации продуктового контура оба endpoint-а доступны из контейнера: `/api/docs/` отвечает `200 text/html`, `/openapi.json` отвечает `200` и не содержит бизнес-методов. Kafka consumers, gRPC endpoints, NiFi callbacks, host-published HTTP-порт и mounted file inputs не предусмотрены.
Исходящие вызовы	Единственный runtime-вызов — PostgreSQL-соединение к `svr-severstal-nifi-integration-postgres` для Aerich-миграций и ORM-доступа. Исходящие HTTP/NiFi-клиенты, Kafka producers, gRPC-клиенты, обращения к `svr-severstal-integration`, `svr-severstal-org-sync`, основному `inf-kafka` или внешним API в текущей реализации не предусмотрены.
Протоколы	HTTP/1.1 для FastAPI docs/openapi на `3000`; PostgreSQL wire protocol поверх TCP `5432` к sidecar-БД; stdout/stderr процесса `start-service.sh`, Aerich и Uvicorn для технологических логов. Прикладной REST API, gRPC, Kafka, NiFi Site-to-Site/REST, Redis, Prometheus `/metrics`, TLS-терминация и публичная публикация порта в текущей конфигурации отсутствуют.
Хранилища	Собственных host mounts у app-контейнера в конфигурации продуктового контура нет; состояние хранится в `svr-severstal-nifi-integration-postgres`. В конфигурации продуктового контура в БД `dnn` присутствуют таблицы `BasicRules`, `BasicRules_RiskDangers`, `BehavioralBarriers`, `BusinessUnits`, `CameraAdGroups`, `Cameras`, `Departments`, `ImportDepartments`, `RiskDangers_TechnicalBarriers`, `RiskWorkAreas_Cameras`, `Risk_Dangers`, `Risk_WorkAreas`, `TechnicalBarriers`, `ViolationKindSections`, `ViolationKinds`, `aerich`.
Конфигурация	Env-only конфигурация: `DEBUG`, `PORT`, `TZ`, `SETTINGS_FILE`, `DEPENDS`, `POSTGRES_DATABASE`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`. В коде default `PORT=3000`, `SETTINGS_FILE` по умолчанию выбирает `develop`, `POSTGRES_HOST=postgres`; в compose/deployment `POSTGRES_HOST` переопределяется на `svr-severstal-nifi-integration-postgres`, `DEPENDS=["svr-severstal-nifi-integration-postgres:5432"]`. Для конфигурации продуктового контура закреплён image-tag `1.0.0-dev`, git commit `fd8c7bc`; значения параметров доступа в документацию не выносятся.
Логирование	Сервис пишет технологические сообщения в stdout/stderr: баннер старта, результат `wait-depends`, вывод Aerich (`No upgrade items found` при актуальной схеме), стандартные логи Uvicorn и access-log запросов к `/api/docs/` и `/openapi.json`. В конфигурации продуктового контура Docker log driver app-контейнера — `loki`; отдельного файлового журнала и бизнес-аудита у сервиса нет.
Мониторинг	Собственного `/metrics`, health endpoint и Docker healthcheck у app-контейнера в конфигурации продуктового контура нет (`Health=none`). Практические проверки: контейнер `severstal-svr-severstal-nifi-integration-1` находится в состоянии `Up`, `/openapi.json` отвечает `200` с `paths: {}`, `/api/docs/` отвечает `200`, в логах нет ошибок миграции, а sidecar PostgreSQL доступен и содержит ожидаемую схему. Эти признаки относятся только к shell/schema-holder и не означают наличие NiFi/Kafka-интеграции.
Критичность	Средняя для текущего интеграционного control plane BOX5-DIT-MGSN и низкая для runtime-видеопотока: остановка app-контейнера не блокирует основную видеоаналитику, `inf-kafka`, PK-KOT push или CSVN-синхронизацию, так как таких обработчиков в сервисе сейчас нет. Сервис критичен для сопровождения собственной справочной схемы: без него не выполняются миграции Aerich и недоступны read-only docs/openapi; потеря связанной PostgreSQL-БД означает потерю локальных справочников, если они не восстановлены из бэкапа.
Эксплуатационные особенности и известные ограничения	Название сервиса опережает реализацию: в текущей реализации нет NiFi-транспорта, Kafka/API-маршрутизации, бизнес REST/gRPC endpoint-ов, фоновых задач, метрик, healthcheck и host-публикации порта. OpenAPI содержит пустой набор `paths`, поэтому `/api/docs/` полезен только как признак живого FastAPI shell. Текущий код использует `develop` settings по умолчанию и не имеет app-level backup/restore; фактическая сохранность данных зависит от `svr-severstal-nifi-integration-postgres`.

`svr-severstal-nifi-integration-postgres`¶

Поле	Описание
Название сервиса	`svr-severstal-nifi-integration-postgres`. PostgreSQL 13.1 sidecar сервиса `svr-severstal-nifi-integration`; в конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-severstal-nifi-integration-postgres-1` с образом `docker.vizorlabs.ru/vizorlabs/postgres:13.1`. Слушает внутренний Docker-порт `5432/tcp`; на контейнере продуктового контура host-порт не опубликован.
Назначение	Постоянное PostgreSQL-хранилище для `svr-severstal-nifi-integration`. Хранит схему справочных данных, которую приложение создаёт и обновляет через Aerich/Tortoise ORM: бизнес-единицы, подразделения, камеры, рабочие зоны, опасности, барьеры, виды нарушений, базовые правила и маппинг `ImportDepartments`. Сам контейнер не реализует отдельную бизнес-функцию, NiFi-обмен или пользовательский API.
Подсистема	Контур `severstal` / интеграционные сервисы BOX5-DIT-MGSN. В deployment-контракте сервис отнесён к PostgreSQL-хранилищам домена `severstal`, а прикладной клиент `svr-severstal-nifi-integration` относится к домену `integration`.
Основные функции	Принимает SQL-подключения от `svr-severstal-nifi-integration`; хранит таблицы и историю миграций `aerich`; обеспечивает долговременное состояние справочников для NiFi-named сервиса; переживает рестарт контейнера за счёт host-backed `PGDATA`. Не запускает миграции самостоятельно: миграции выполняет приложение при старте после ожидания зависимости `svr-severstal-nifi-integration-postgres:5432`.
Входящие вызовы	PostgreSQL wire protocol на `5432` из внутренней сети `bx_default`, штатный клиент - `svr-severstal-nifi-integration` с `POSTGRES_HOST=svr-severstal-nifi-integration-postgres` и `POSTGRES_PORT=5432`. В конфигурации продуктового контура заданы network alias `svr-severstal-nifi-integration-postgres`, успешный `pg_isready -U postgres` внутри контейнера и SQL-подключение к БД `dnn`. Публичных HTTP, REST, gRPC, Kafka или Redis-входов нет.
Исходящие вызовы	Сервис-специфичных исходящих сетевых вызовов нет. PostgreSQL отвечает клиентам по уже открытым TCP-соединениям, пишет WAL/табличные файлы в `PGDATA` и технологические сообщения в `stdout`/`stderr`. Kafka, NiFi, HTTP-клиенты, Redis, gRPC и обращения к другим сервисам для этого sidecar не предусмотрены.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`; файловый ввод-вывод PostgreSQL в `PGDATA`; `stdout`/`stderr` для технологических логов. TLS, HTTP, REST, gRPC, Kafka, Redis, Prometheus endpoint и публичный API у sidecar отсутствуют.
Хранилища	Основное состояние - PostgreSQL в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/severstal/pgdata-severstal-nifi-integration` -> `/var/lib/postgresql/data`. Рабочая БД и пользователь в конфигурации продуктового контура - `dnn`, схема - `public`; присутствуют 16 таблиц: `BasicRules`, `BasicRules_RiskDangers`, `BehavioralBarriers`, `BusinessUnits`, `CameraAdGroups`, `Cameras`, `Departments`, `ImportDepartments`, `RiskDangers_TechnicalBarriers`, `RiskWorkAreas_Cameras`, `Risk_Dangers`, `Risk_WorkAreas`, `TechnicalBarriers`, `ViolationKindSections`, `ViolationKinds`, `aerich`.
Конфигурация	Env-only конфигурация стандартного образа PostgreSQL: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, `TZ`. Для конфигурации продуктового контура закреплён image-tag `13.1`; живой контейнер использует `RestartPolicy=always`, Docker log driver `loki`, сеть `bx_default` с alias `svr-severstal-nifi-integration-postgres`, Docker healthcheck не задан. У приложения должны быть согласованы `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST` и `POSTGRES_PORT`; значения параметров доступа в документацию не выносятся.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. Отдельного прикладного журнала у sidecar нет; ошибки ожидания зависимости, Aerich-миграций, Tortoise ORM и FastAPI-старта нужно смотреть в логах `svr-severstal-nifi-integration`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck в конфигурации продуктового контура нет (`Health=none`). Практические проверки: контейнер `severstal-svr-severstal-nifi-integration-postgres-1` находится в состоянии `running`, `pg_isready -U postgres` внутри контейнера возвращает `accepting connections`, SQL-подключение к БД `dnn` успешно, в `public` присутствует ожидаемый набор таблиц. Готовность БД не доказывает готовность приложения: отдельно проверяются старт `svr-severstal-nifi-integration`, результат `aerich upgrade` и его HTTP docs/openapi surface.
Критичность	Средняя для текущего состояния BOX5-DIT-MGSN и высокая внутри связки `svr-severstal-nifi-integration`: при отказе или потере БД приложение не может надёжно выполнить миграции и использовать справочную схему. Так как код NiFi-named сервиса сейчас не содержит бизнес-маршрутов, Kafka/NiFi-обмена и публичной бизнес-функции, отказ sidecar не останавливает основной видеопоток BOX5-DIT-MGSN, но теряет или блокирует данные, на которые рассчитан развивающийся интеграционный контур BOX5-DIT-MGSN.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без собственной бизнес-валидации, публичного API, метрик, Docker healthcheck и отдельного backup-sidecar. Схемой полностью управляет `svr-severstal-nifi-integration`; ручные изменения таблиц могут нарушить Aerich/Tortoise-контракт. Уровень схемы зависит от образа приложения и успешности `aerich upgrade`, поэтому при переносе между контурами нужно сверять image-tag приложения, `POSTGRES_*` у app/sidecar и фактический список таблиц. Потеря host path `pgdata-severstal-nifi-integration` означает потерю справочных данных, если они не восстановлены из бэкапа.

`svr-severstal-org-sync`¶

Поле	Описание
Название сервиса	`svr-severstal-org-sync` (`severstal/severstal-org-sync`). gRPC-сервис применения оргструктуры BOX5-DIT-MGSN к Box-топологии камер; в конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-severstal-org-sync-1` с образом `docker.vizorlabs.ru/severstal/severstal-org-sync:1.0.16-dev`.
Назначение	Принимает от `svr-severstal-integration` нормализованный список CSVN-камер, сопоставляет его с оргструктурой и рабочими зонами из PK-KOT, создаёт или обновляет дерево объектов и камеры в `st-camera-storage`, сохраняет локальную связь Box object id -> department id и возвращает результат синхронизации обратно в `svr-severstal-integration`. Сам сервис не опрашивает CSVN и не является владельцем расписания синхронизации.
Подсистема	Compose-домен `severstal`, функционально контур интеграции BOX5-DIT-MGSN между `svr-severstal-integration`, `svr-postgres-pk-kot`, `st-camera-storage` и статистическим ClickHouse. Локальное состояние обслуживает sidecar `svr-severstal-org-sync-postgres`.
Основные функции	Выполняет RPC `SyncCameras`: строит дерево подразделений по PK-KOT, создаёт корневой объект BOX5-DIT-MGSN и служебный объект для несинхронизированных камер, добавляет и обновляет камеры, переносит камеры из служебного объекта после появления маппинга в PK-KOT, переименовывает конфликтующие не-CSVN камеры с суффиксом, синхронизирует флаги и внешние теги рабочих зон, удаляет устаревшие пустые ветки объектов, переписывает таблицу `object_tree_departments` и best-effort зеркалит её в ClickHouse. Запуск выполняется только по входящему RPC; внутреннего cron/периодического scheduler нет, при `wait_finish=false` создаётся фоновая `asyncio`-задача на время одного sync-запроса.
Входящие вызовы	HTTP/gRPC на внутреннем `3000/tcp`, host-порт в конфигурации продуктового контура не опубликован. Основной вызывающий сервис — `svr-severstal-integration`, который передаёт список CSVN-камер в `SyncCameras`. Read-only RPC `GetObjectTreeDepartmentList` возвращает локальные строки маппинга по фильтрам object id и department id. Maintenance RPC `FlushDb` очищает локальный маппинг и не относится к обычному пользовательскому потоку. HTTP `GET /metrics` отдаёт Prometheus text metrics из того же ASGI-приложения.
Исходящие вызовы	Прямое чтение PostgreSQL `svr-postgres-pk-kot` для таблиц `Departments`, `Cameras`, `RiskWorkAreas_Cameras`, `Risk_WorkAreas`; HTTP/gRPC к `st-camera-storage` для CRUD дерева объектов, камер, привязок, флагов и тегов; HTTP/gRPC callback `SetOrgSyncCSVNCamerasResult` в `svr-severstal-integration`; ClickHouse client к `st-event-statistic-clickhouse` для зеркала `object_tree_departments`. Kafka, Redis, LDAP, внешние CSVN/VMS и пользовательский REST API сервис напрямую не использует.
Протоколы	Входящие: HTTP/gRPC и HTTP `GET /metrics` на `3000/tcp`. Исходящие: HTTP/gRPC к внутренним Box-сервисам, PostgreSQL wire protocol к локальному sidecar и к PK-KOT, ClickHouse native TCP на порт статистического ClickHouse. gRPC, Kafka, Redis, SOAP, LDAP, TLS-терминация и публичные REST endpoints в текущей конфигурации не предусмотрены.
Хранилища	Собственная постоянная БД находится не в app-контейнере, а в `svr-severstal-org-sync-postgres`: таблица `object_tree_departments` хранит one-to-one маппинг `object_observation_id` и `severstal_department_id` с признаком `has_children`, таблица `aerich` хранит состояние миграций. PK-KOT PostgreSQL используется как read-only источник оргструктуры и зон, `st-camera-storage` — как источник истины по объектам/камерам Box, ClickHouse содержит вспомогательное зеркало маппинга для статистического слоя. У app-контейнера bind mounts в конфигурации продуктового контура не предусмотрены.
Конфигурация	Основные env-группы: `DEBUG`, `PORT`, `TZ`, `SETTINGS_FILE`, `DEPENDS`; локальная БД `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`; PK-KOT `POSTGRES_PK_KOT_`; downstream endpoints `CAMERA_STORAGE_URL`, `SEVERSTAL_INTEGRATION_URL`, `GRPC_CLIENT_DEFAULT_TIMEOUT`; имена служебных объектов `CAMERA_STORAGE_ROOT_OBJECT_NAME`, `CAMERA_STORAGE_UNSYNC_CAMERAS_OBJECT_NAME`; политика конфликтов `CAMERA_RENAME_SUFFIX`; optional ClickHouse `EVENT_STATISTIC_CH_`. Значения параметров доступа не документируются. `start-service.sh` ждёт `DEPENDS`, выполняет `aerich upgrade` и запускает `python /service/main.py server`; в конфигурации продуктового контура заданы сеть `bx_default`, log driver `loki`, отсутствие Docker healthcheck и отсутствие host-publish для `3000/tcp`.
Логирование	Приложение пишет логи `loguru` в `stdout`/`stderr`; в конфигурации продуктового контура они собираются Docker log driver `loki`. В логах фиксируются старт/завершение синхронизации, ошибки чтения PK-KOT, операции создания/обновления/удаления объектов и камер, обновление PostgreSQL/ClickHouse-маппинга и ошибки callback в `svr-severstal-integration`. Отдельного файлового журнала или audit-topic у сервиса не предусмотрено.
Мониторинг	Сервис отдаёт Prometheus metrics на `GET /metrics`; в конфигурации продуктового контура endpoint внутри контейнера возвращает счётчики RPC, включая `request_count_total{method="SyncCameras"}`. Docker healthcheck у app-контейнера отсутствует (`Health=none`), поэтому практические проверки: контейнер `severstal-svr-severstal-org-sync-1` в состоянии `Up`, доступность `/metrics`, успешный gRPC-вызов `GetObjectTreeDepartmentList`, отсутствие ошибок `Sync task error`, доступность `svr-severstal-org-sync-postgres`, `svr-postgres-pk-kot`, `st-camera-storage` и callback в `svr-severstal-integration`.
Критичность	Высокая для синхронизации CSVN-камер и оргструктуры BOX5-DIT-MGSN. При отказе сервиса `svr-severstal-integration` может получать и хранить CSVN-инвентарь, но Box-дерево объектов, камеры, флаги, теги рабочих зон и локальный маппинг подразделений не обновляются; статистический срез по `object_tree_departments` также устаревает. Основной видеопоток и уже заведённые камеры могут продолжать работать, но новые/изменённые CSVN-камеры не сходятся с PK-KOT и UI.
Эксплуатационные особенности и известные ограничения	Синхронизация сериализована in-process `asyncio.Lock`: параллельный `SyncCameras` отклоняется сообщением `Sync is already running`, очередь запросов не формируется. При `wait_finish=false` RPC возвращает успех после постановки фоновой задачи, а фактическая ошибка видна только в логах и последующих состояниях. CSVN-камеры без соответствия в PK-KOT помещаются в служебный объект несинхронизированных камер до появления маппинга; ClickHouse-зеркало best-effort и его отказ не прерывает основной apply. `FlushDb` является опасным maintenance RPC. В коде остаются устаревшие defaults для PK-KOT и локальной БД, поэтому на каждом контуре нужно сверять реальные `POSTGRES_`/`POSTGRES_PK_KOT_` без вывода параметров доступа.

`svr-severstal-org-sync-postgres`¶

Поле	Описание
Название сервиса	`svr-severstal-org-sync-postgres`. PostgreSQL 13.1 sidecar сервиса `svr-severstal-org-sync`; в конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-severstal-org-sync-postgres-1` с образом `docker.vizorlabs.ru/vizorlabs/postgres:13.1`. Слушает только внутренний Docker-порт `5432/tcp`, host-порт не опубликован.
Назначение	Постоянное локальное хранилище `svr-severstal-org-sync`. Хранит связь Box object id с идентификаторами подразделений BOX5-DIT-MGSN и служебное состояние Aerich-миграций. Это не отдельная бизнес-функция, не PK-КОТ источник и не API-сервис: бизнес-логику синхронизации выполняет app-контейнер `svr-severstal-org-sync`.
Подсистема	Домен `severstal`, интеграционный контур синхронизации ЦСВН/ПК-КОТ с Box-топологией камер. Sidecar обслуживает только `svr-severstal-org-sync`, который вызывается из `svr-severstal-integration` и дополнительно читает `svr-postgres-pk-kot`, пишет в `st-camera-storage` и зеркалит маппинг в статистический ClickHouse.
Основные функции	Принимает PostgreSQL-подключения от `svr-severstal-org-sync`; хранит таблицу `object_tree_departments` с локальным маппингом `object_observation_id` -> `severstal_department_id` и признаком `has_children`; хранит таблицу `aerich` с версией миграций; обеспечивает сохранность данных между рестартами контейнера за счёт host-backed `PGDATA`. Сам контейнер не запускает миграции: `aerich upgrade` выполняет `svr-severstal-org-sync` при старте.
Входящие вызовы	PostgreSQL wire protocol на `5432/tcp` из внутренней Docker-сети `bx_default`. Штатный клиент - `svr-severstal-org-sync` с `POSTGRES_HOST=svr-severstal-org-sync-postgres` и `POSTGRES_PORT=5432`; диагностические подключения возможны через `docker exec` или из контейнерной сети. В конфигурации продуктового контура заданы `pg_isready -U dnn -d dnn`, таблицы `aerich` и `object_tree_departments`; публичных HTTP, REST, gRPC, Kafka или Redis-входов нет.
Исходящие вызовы	Сервис-специфичных исходящих сетевых вызовов нет. PostgreSQL отвечает клиентам по открытым TCP-соединениям, пишет табличные файлы и WAL в `PGDATA`, а технологические сообщения - в `stdout`/`stderr`. Контейнер не обращается к `svr-severstal-integration`, `svr-postgres-pk-kot`, `st-camera-storage`, ClickHouse, Kafka или внешним системам напрямую.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`; файловый ввод-вывод PostgreSQL в `PGDATA`; `stdout`/`stderr` для технологических логов. TLS, HTTP, REST, gRPC, Kafka, Redis, Prometheus endpoint и пользовательский UI у sidecar отсутствуют.
Хранилища	Основное состояние - PostgreSQL в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/severstal/pgdata-severstal-org-sync` -> `/var/lib/postgresql/data`. Рабочая БД и пользователь в конфигурации продуктового контура - `dnn`; схема `public` содержит `aerich` и `object_tree_departments(created_at, updated_at, id, object_observation_id, severstal_department_id, has_children)`. На момент проверки в `object_tree_departments` было `90` строк; `id` является primary key.
Конфигурация	Env-only конфигурация стандартного PostgreSQL-образа: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA` и общие параметры контейнера. Для конфигурации продуктового контура закреплён image-tag `13.1`; живой контейнер использует `RestartPolicy=always`, Docker log driver `loki`, сеть `bx_default`, внутренний alias `svr-severstal-org-sync-postgres`, Docker healthcheck не задан. У app-контейнера должны быть согласованы `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`; значения параметров доступа в документацию не выносятся.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. Отдельного прикладного журнала у sidecar нет; ошибки ожидания зависимости, Aerich-миграций и операций обновления `object_tree_departments` нужно смотреть в логах `svr-severstal-org-sync`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck в конфигурации продуктового контура нет (`Health=none`). Практические проверки: контейнер `severstal-svr-severstal-org-sync-postgres-1` находится в состоянии `running`, `pg_isready -U dnn -d dnn` возвращает `accepting connections`, SQL-подключение к БД успешно, в `public` присутствуют `aerich` и `object_tree_departments`. Для end-to-end проверки дополнительно проверяется, что `svr-severstal-org-sync` стартовал после `aerich upgrade` и отдаёт `GetObjectTreeDepartmentList`.
Критичность	Высокая для синхронизации оргструктуры и CSVN-камер BOX5-DIT-MGSN. При отказе БД `svr-severstal-org-sync` не может надёжно запускать миграции и сохранять локальный маппинг Box object id -> department id; новые проходы `SyncCameras` деградируют или падают, а уже построенное дерево камер может устаревать. Основной видеопоток и ранее заведённые камеры напрямую не зависят от sidecar, но восстановление корректной связи с ПК-КОТ/статистикой требует доступной БД или бэкапа `PGDATA`.
Эксплуатационные особенности и известные ограничения	Generic PostgreSQL sidecar без собственного API, бизнес-валидации, метрик, healthcheck, резервного контейнера и отдельного backup-sidecar. Схемой полностью управляет `svr-severstal-org-sync`; ручные изменения таблиц могут нарушить Aerich/Tortoise-контракт. Кодовая миграция описывает `object_observation_id` и `severstal_department_id` как уникальные поля, но на продуктовом контуре DB-level unique indexes для них не предусмотрены, поэтому перед ручными исправлениями нужно сверять фактическую схему через `pg_indexes`/`pg_constraint`. Потеря host path `pgdata-severstal-org-sync` означает потерю локального маппинга, если он не восстановлен из бэкапа или повторной синхронизации.

`svr-scenario-storage`¶

Поле	Описание
Название сервиса	`svr-scenario-storage` (`severstal/scenario-storage`). Полное версионированное хранилище сценариев NRI для BOX5-DIT-MGSN; в конфигурации продуктового контура развёрнуто в compose-проекте `severstal` как контейнер `severstal-svr-scenario-storage-1` с образом `docker.vizorlabs.ru/severstal/scenario-storage:dev-fix`. Слушает внутренний Docker-порт `3000/tcp`; host-порт в конфигурации продуктового контура не опубликован.
Назначение	Хранит и версионирует production-сценарии видеоаналитики: карточки сценариев, разделы, версии, атрибуты, комментарии, настройки архива и JSONB `scenario_settings` находятся в PostgreSQL, а полезная нагрузка Node-RED/NRI хранится в MinIO как `<scenario-name>/<version>/flows.json`. Сервис является долговременным источником сценариев для `inf-nri-inference`, `inf-flows-manager`, custom-domain раздела `ui-rest-to-gprc`, sandbox backend и проверок использования моделей в `svr-models-registry`.
Подсистема	Функционально контур управления NRI-сценариями в домене `integration`; связанный PostgreSQL sidecar относится к домену `severstal`. Работает рядом с `svr-scenario-storage-postgres`, `ds-minio`, `inf-kafka`, `inf-flows-manager`, `inf-nri-inference`, `svr-models-registry`, `st-camera-storage`, `ui-rest-to-gprc` и `nr-sbx-backend`.
Основные функции	Предоставляет gRPC CRUD для разделов сценариев, сценариев, версий, атрибутов, комментариев и архивной политики; REST-endpoints для загрузки/скачивания `flows.json`, выдачи объединённого flow из опубликованных неархивных версий, миграции из `svr-lite-scenario-storage`, patch flow-файлов, возврата простого списка сценариев, используемых моделей и `scenario_settings`. При загрузке, миграции и patch отправляет flow в `inf-flows-manager` для извлечения параметров блоков; при публикации, удалении, восстановлении, миграции и patch публикует Kafka-события текущего состава сценариев и настроек; потребляет Kafka-события типов зон и массово переписывает `scenario_settings` через PostgreSQL JSONB-запросы. Стартовая цепочка: `wait-depends` -> `aerich upgrade` -> FastAPI/gRPC server -> инициализация MinIO bucket/policy, Kafka producer queue, трёх zone-type consumers и ежедневного очистителя архива.
Входящие вызовы	HTTP/gRPC на `:3000` от `ui-rest-to-gprc` для CRUD сценариев, версий, атрибутов, комментариев и архива. HTTP REST на том же порту: `GET /api/docs/`, `GET /openapi.json`, `POST /upload-scenario-json/`, `GET /download-flow-json-file/`, `GET /get-flow-json-file/`, `GET /flows/download/`, `GET /flows/json/`, `POST /get-scenarios/simple-info/`, `POST /flows/update-models-info/`, `POST /scenarios/migrate/`, `POST /models/versions/`, `POST /get-scenarios-settings/`, `POST /patch/flows/scenario_versions/`, `GET /scenarios-settings/get-usage-zones/`, `GET /scenarios-settings/get-usage-asutp-type/`, `GET /scenario/simple-names/`. Вызывающие сервисы: `inf-nri-inference` читает `get-scenarios/simple-info` и `get-flow-json-file`; `inf-flows-manager` скачивает flow и вызывает `flows/update-models-info`; `svr-models-registry` читает `models/versions` и gRPC-методы использования моделей; `nr-sbx-backend`/sandbox и пользователи с эксплуатационным доступом используют upload/download/migrate/patch endpoints. В конфигурации продуктового контура read-only запросы из `inf-nri-inference`, `inf-flows-manager` и `svr-models-registry` к `svr-scenario-storage` вернули `200 OK`.
Исходящие вызовы	PostgreSQL wire protocol к `svr-scenario-storage-postgres:5432`; S3/MinIO API к `ds-minio:9000`, bucket `scenario-storage`; HTTP `POST {FLOWS_MANAGER_URL}{FLOWS_MANAGER_PREFIX}models/flows/parameters/extract/` к `inf-flows-manager` для извлечения параметров flow; HTTP `POST {CAMERA_STORAGE_URL}/severstal/scenarios/camera-id-by-scenario-id/` к `st-camera-storage` перед архивированием/удалением версии, чтобы не удалить сценарий, назначенный камерам. Kafka consume из `create_zone_type`, `update_zone_type`, `remove_zone_type`; Kafka produce в `scenario_deleted`, `current_scenarios`, `scenarios_settings_updated`. Прямых исходящих вызовов в `inf-nri-inference`, `svr-models-registry`, MLflow или model registry в текущей реализации нет: эти связи входящие для `svr-scenario-storage` или проходят через сохранённые ссылки моделей и Kafka.
Протоколы	Входящие: HTTP REST и HTTP/gRPC поверх TCP `3000`. Исходящие: PostgreSQL wire protocol, S3-compatible HTTP к MinIO, Kafka protocol, HTTP REST к `inf-flows-manager` и `st-camera-storage`. Также используется файловый bind mount для legacy upload path. gRPC, Redis, ClickHouse, Prometheus endpoint, публичный host-port, TLS-терминация и прямой IPC/NRI callback у сервиса не предусмотрены.
Хранилища	Постоянные метаданные находятся в `svr-scenario-storage-postgres`: таблицы `scenario`, `scenario_version`, `scenario_section`, `attribute`, `thread`, `message`, `archive`, `aerich`; в конфигурации продуктового контура заданы 8 public-таблиц, GIN-индекс `idx_scenario_version_blocks_gin` по `scenario_version.scenario_settings->settings->blocks` и индексы `is_removed` для `scenario`/`scenario_version`. Flow-файлы лежат в MinIO bucket `scenario-storage` по схеме `<scenario-name>/<version>/flows.json`; архивно удаляемые объекты переносятся под `removed/`. В конфигурации продуктового контура bucket содержит 2589 объектов, включая 2182 `flows.json` и 1794 объекта под `removed/`. У app-контейнера задан bind mount `/data/compose-data2-no-swarm/scenario-storage/scenarios -> /uploads`, используемый как `BASE_UPLOAD_DIR=/uploads/`; основное хранилище production flow при этом MinIO, а не локальный каталог.
Конфигурация	Основные env-группы: `DEBUG`, `PORT`, `SETTINGS_FILE`, `DEPENDS`; подключение к БД `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`; Kafka `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_SCENARIO_DELETED`, `KAFKA_TOPIC_CURRENT_SCENARIOS`, `KAFKA_TOPIC_SCENARIO_SETTINGS_UPDATED`, `KAFKA_TOPIC_CREATE_ZONE_TYPE`, `KAFKA_TOPIC_UPDATE_ZONE_TYPE`, `KAFKA_TOPIC_REMOVE_ZONE_TYPE`; MinIO `MINIO_ENDPOINT`, `MINIO_ACCESS_KEY`, `MINIO_SECRET_KEY`, `MINIO_SECURE`, `MINIO_BUCKET`, `MINIO_PREFIX`, `MINIO_CERT_CHECK`; downstream `FLOWS_MANAGER_URL`, `FLOWS_MANAGER_PREFIX`, `CAMERA_STORAGE_URL`; наборы `SCENARIO_SETTINGS_BLOCK_ONLY_ZONE_TYPES` и `SCENARIO_SETTINGS_BLOCK_ZONE_OR_CATEGORY_TYPES`. В конфигурации продуктового контура заданы `DEBUG=false`, `DEPENDS=["svr-scenario-storage-postgres:5432"]`, `POSTGRES_HOST=svr-scenario-storage-postgres`, `KAFKA_HOST=inf-kafka:9092`, `KAFKA_GROUP=severstal-scenario-storage`, `MINIO_ENDPOINT=ds-minio:9000`, `MINIO_BUCKET=scenario-storage`, `BASE_UPLOAD_DIR=/uploads/`; значения параметров доступа не документируются. Compose в конфигурации продуктового контура также задаёт устаревшие `KAFKA_TOPIC_SCENARIOS_DELETED` и `KAFKA_TOPIC_SCENARIOS_FILE_UPDATED`, но текущий код читает singular-названия выше и игнорирует unknown env.
Логирование	Приложение и uvicorn access log пишут в `stdout`/`stderr`; `loguru` настраивается в `config/setup.py` и фиксирует операции MinIO, Kafka, миграции/patch, извлечение параметров flow, ошибки PostgreSQL/HTTP и очистку архива. В конфигурации продуктового контура app- и postgres-контейнеры используют Docker log driver `loki`; отдельного файлового журнала, audit-topic или структурированного business audit внутри самого сервиса не предусмотрено.
Мониторинг	Docker healthcheck у app-контейнера отсутствует (`Health=none`), `/metrics` не является рабочим Prometheus endpoint (в конфигурации продуктового контура вернул `500`). Практические проверки: контейнер `severstal-svr-scenario-storage-1` в состоянии `running`, `GET /api/docs/` и `GET /openapi.json` возвращают `200`, read-only REST endpoints отвечают (`simple-info` - 364 версии, `models/versions` - 364 записи, `get-scenarios-settings` - 425 записей, `flows/json` - 3494 flow-элемента в конфигурации продуктового контура), `GET /get-flow-json-file/` по существующей версии читает MinIO, `svr-scenario-storage-postgres` отвечает на `pg_isready`, bucket `scenario-storage` существует, Kafka topics `create_zone_type`, `update_zone_type`, `remove_zone_type`, `scenario_deleted`, `current_scenarios`, `scenarios_settings_updated` присутствуют, consumer group `severstal-scenario-storage` зарегистрирована.
Критичность	Высокая для управления production-сценариями NRI. При отказе сервиса UI и sandbox теряют операции создания, публикации, обновления, архивации и скачивания сценариев; `inf-flows-manager` не может переписывать сохранённые flow под новые версии моделей; `inf-nri-inference` и `svr-models-registry` не могут надёжно перечитать актуальные сценарии и сведения об использовании моделей. Уже запущенные потоки NRI могут некоторое время работать на локальном/кэшированном состоянии, но управление, повторная синхронизация, восстановление и аудит версий становятся недоступны. Потеря PostgreSQL блокирует метаданные и `scenario_settings`; потеря MinIO блокирует сами `flows.json`.
Эксплуатационные особенности и известные ограничения	В конфигурации продуктового контура фактический образ `dev-fix` отличается от закреплённого тега (`1.1.0-dev-p2`), поэтому перед расследованиями нужно сверять running image, compose и код контейнера. Нет Docker healthcheck, `/metrics`, публичного host-порта, TLS/auth на внутреннем API и прямого callback в исполняющий `inf-nri-inference`; применение изменений зависит от downstream-чтения `svr-scenario-storage`, Kafka-событий и смежных процессов. Операции upload/migrate/patch зависят от `inf-flows-manager`; HTTP-клиент параметров использует `timeout=None`, поэтому зависший flows-manager может подвесить операцию. Запись метаданных в PostgreSQL и файлов в MinIO не образует единой транзакции: возможны рассинхронизации, которые нужно диагностировать сравнением таблиц `scenario_version` и объектов `<scenario>/<version>/flows.json`. Очистка MinIO от лишних объектов присутствует в коде как отдельная задача, но в текущем `config/setup.py` не подключена; архивная логика переносит объекты под `removed/`.

`svr-scenario-storage-postgres`¶

Поле	Описание
Название сервиса	`svr-scenario-storage-postgres`. PostgreSQL 13.1 sidecar сервиса `svr-scenario-storage`; в конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-scenario-storage-postgres-1` с образом `docker.vizorlabs.ru/vizorlabs/postgres:13.1`. Слушает внутренний Docker-порт `5432/tcp`; host-порт на контейнере продуктового контура не опубликован.
Назначение	Постоянное PostgreSQL-хранилище для `svr-scenario-storage`. Хранит реляционный каталог сценариев: разделы, сценарии, версии сценариев, атрибуты, комментарии, политики архивации и JSONB-документы `scenario_settings`, привязанные к версиям. Сам sidecar не реализует отдельную бизнес-функцию, пользовательский API или сценарный workflow; payload-файлы `flows.json` хранятся в MinIO и обслуживаются приложением `svr-scenario-storage`.
Подсистема	Контур `severstal` / управление production-сценариями NRI. Сервис является PostgreSQL-хранилищем домена `severstal`; его единственный штатный прикладной владелец `svr-scenario-storage` относится к интеграционному control-plane для `ui-rest-to-gprc`, `inf-nri-inference`, `inf-flows-manager`, `nr-sbx-backend`, Kafka и MinIO.
Основные функции	Принимает SQL-подключения от `svr-scenario-storage`; хранит таблицы каталога сценариев и историю миграций `aerich`; обеспечивает долговременное состояние через host-backed `PGDATA`; поддерживает JSONB-поиск по `scenario_version.scenario_settings` через GIN-индекс `idx_scenario_version_blocks_gin`. Миграции и создание схемы выполняет не PostgreSQL-контейнер, а приложение `svr-scenario-storage` при старте (`aerich upgrade`, затем инициализация Tortoise ORM).
Входящие вызовы	PostgreSQL wire protocol на `5432` из внутренней сети `bx_default`. Штатный клиент - `svr-scenario-storage` с `POSTGRES_HOST=svr-scenario-storage-postgres`, `POSTGRES_DATABASE=dnn`, `POSTGRES_USER=dnn` и зависимостью `DEPENDS=["svr-scenario-storage-postgres:5432"]`; пароль согласуется между app и sidecar, но в документацию не выносится. В конфигурации продуктового контура заданы network alias `svr-scenario-storage-postgres`, успешный `pg_isready -U dnn -d dnn` внутри контейнера и SQL-подключение к БД `dnn`. Публичных HTTP, REST, gRPC, Kafka, Redis или MinIO-входов у sidecar нет.
Исходящие вызовы	Сервис-специфичных исходящих сетевых вызовов нет. PostgreSQL отвечает клиенту по уже открытым TCP-соединениям, пишет data files/WAL в `PGDATA` и технологические сообщения в `stdout`/`stderr`. Kafka-события, HTTP-вызовы в `inf-flows-manager`/`st-camera-storage`, MinIO-операции с `flows.json` и бизнес-валидация относятся к `svr-scenario-storage`, а не к этому sidecar.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`; файловый ввод-вывод PostgreSQL в `PGDATA`; `stdout`/`stderr` для технологических логов. TLS, HTTP, REST, gRPC, Kafka, Redis, Prometheus endpoint и публичный API у sidecar отсутствуют.
Хранилища	Основное состояние - PostgreSQL в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/severstal/pgdata-scenario-storage` -> `/var/lib/postgresql/data`. Рабочая БД и пользователь в конфигурации продуктового контура - `dnn`, схема - `public`; присутствуют таблицы `aerich`, `archive`, `attribute`, `message`, `scenario`, `scenario_section`, `scenario_version`, `thread`. Для `scenario_version` присутствуют индексы `scenarioversion_pkey`, `idx_scenario_ve_is_remo_fa5742` и GIN-индекс `idx_scenario_version_blocks_gin`.
Конфигурация	Env-only конфигурация стандартного образа PostgreSQL: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, при необходимости `TZ`. В конфигурации продуктового контура sidecar задан как `POSTGRES_DB=dnn`, `POSTGRES_USER=dnn`, `PGDATA=/var/lib/postgresql/data`, `RestartPolicy=always`, Docker log driver `loki`, сеть `bx_default` с alias `svr-scenario-storage-postgres`, Docker healthcheck отсутствует. У приложения должны быть согласованы `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST` и `POSTGRES_PORT`; значения параметров доступа и полный env контейнеров не документируются.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. Отдельного прикладного журнала у sidecar нет; ошибки ожидания зависимости, Aerich-миграций, Tortoise ORM, JSONB raw-SQL операций и бизнес-API нужно смотреть в логах `svr-scenario-storage`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck в конфигурации продуктового контура нет (`Health=none`). Практические проверки: контейнер `severstal-svr-scenario-storage-postgres-1` находится в состоянии `running`, `pg_isready -U dnn -d dnn` внутри контейнера возвращает `accepting connections`, SQL-подключение к БД `dnn` успешно, в `public` присутствует ожидаемый набор таблиц и индекс `idx_scenario_version_blocks_gin`. Готовность БД не доказывает готовность сценарного API: отдельно проверяются старт `svr-scenario-storage`, успешность `aerich upgrade`, доступность его gRPC/REST endpoint и операции с MinIO/Kafka.
Критичность	Высокая для управления production-сценариями и их версионным каталогом. При отказе или потере БД `svr-scenario-storage` не может надёжно стартовать, выполнять миграции, обслуживать CRUD сценариев/версий/комментариев, отдавать metadata для `inf-nri-inference` и `inf-flows-manager` и применять архивные/JSONB-операции. Уже запущенный видеоконтур может не остановиться мгновенно, но управление, публикация и восстановление сценариев становятся недоступны или неконсистентны.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без собственной бизнес-валидации, публичного API, метрик, Docker healthcheck и отдельного backup-sidecar. Схемой полностью управляет `svr-scenario-storage`; ручные изменения таблиц, индексов или `scenario_settings` могут нарушить Aerich/Tortoise-контракт и raw-SQL запросы приложения. В БД хранится каталог и `scenario_settings`, но не сами `flows.json`; при расследованиях нужно отдельно сверять MinIO bucket `scenario-storage` и приложение. Потеря host path `pgdata-scenario-storage` означает потерю каталога сценариев, если он не восстановлен из бэкапа.

`svr-lite-scenario-storage`¶

Поле	Описание
Название сервиса	`svr-lite-scenario-storage` (`severstal/lite-scenario-storage`). В конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-lite-scenario-storage-1` с образом `docker.vizorlabs.ru/severstal/lite-scenario-storage:dev`; слушает FastAPI/uvicorn на внутреннем `3000/tcp`, host-порт не опубликован.
Назначение	Упрощённое хранилище текущего Node-RED `flows.json` для контура BOX5-DIT-MGSN. В отличие от полного `svr-scenario-storage`, сервис не ведёт версионную историю сценариев, не хранит flow-файлы в MinIO и не предоставляет gRPC CRUD; он держит один актуальный `flows.json` на локальном bind-mount, извлекает из него lite-сценарии в PostgreSQL и хранит тонкие настройки сценариев в JSON-файлах.
Подсистема	`integration`/`severstal`, контур публикации и чтения lightweight-сценариев. Работает рядом с `svr-lite-scenario-storage-postgres`, `inf-kafka`, `st-event-storage-clickhouse`, `st-camera-storage`, публичным gateway `ui-rest-to-gprc`, sandbox-компонентами `nr-sbx-backend`/NRI tooling и полным `svr-scenario-storage`, который является отдельным versioned-хранилищем production-сценариев.
Основные функции	Принимает multipart `flows.json` и опциональный `flows_params.json`, сериализует загрузки через in-process `asyncio.Lock`, сохраняет файлы в `BASE_UPLOAD_DIR`, парсит Node-RED tabs (`type=tab`) в каталог lite-сценариев, синхронизирует таблицу `scenarios`, удаляет исчезнувшие сценарии, обновляет локальные файлы `scenario_params/<scenario_instance_id>.json`, публикует Kafka-уведомления, отдаёт текущий flow и каталог сценариев, создаёт, перечисляет и восстанавливает бэкапы с привязками камер и при включённом `USE_CLICKHOUSE` обновляет таблицу `lite_scenarios`.
Входящие вызовы	HTTP REST на `:3000`: `GET /api/docs/`, `GET /openapi.json`, `POST /upload-scenarios/`, `GET /download-json-file/`, `GET /get-json-file/`, `GET /get-json-file-params/`, `POST /get-scenarios/`, `POST /get-scenarios-settings/`, `GET /create-backup/`, `GET /restore-backup/?backup_id=...`, `POST /get-backup-list/`. Основной штатный вызывающий - `ui-rest-to-gprc`, который проксирует внешний префикс `/api/severstal/severstal-lite-scenario-storage/*` и использует чтение lite-сценариев в custom-domain reports/camera-storage helpers. Публикационный путь sandbox (`nr-sbx-backend`) и NRI helper `post_scenarios_to_box.py` отправляют `upload-scenarios/` через Box gateway. В текущем runtime-коде `inf-nri-inference` основные flow читает из полного `svr-scenario-storage`; `lite_scenario_storage_host` остаётся legacy-настройкой и прямой активный runtime-вызов lite-storage не предусмотрен.
Исходящие вызовы	PostgreSQL wire protocol к `svr-lite-scenario-storage-postgres:5432` для таблиц `scenarios`, `camera_scenario_backup` и `aerich`; Kafka produce в `inf-kafka:9092` в топики `scenarios_file_updated`, `scenarios_lite_deleted`, `current_lite_scenarios`, `scenarios_settings_updated`; HTTP `POST {CAMERA_STORAGE_BASE_URL}/severstal/scenarios/cameras/` только при создании backup для снимка привязок камер; HTTP к ClickHouse `st-event-storage-clickhouse:8123` при `USE_CLICKHOUSE=true`. Исходящих вызовов в `svr-scenario-storage`, `svr-models-registry`, MinIO/S3 или gRPC-клиенты в текущей реализации сервиса нет.
Протоколы	HTTP/REST JSON, multipart upload и file download; OpenAPI/FastAPI docs; PostgreSQL через Tortoise ORM/Aerich; Kafka producer; HTTP ClickHouse client; HTTPX к camera-storage при backup; локальный файловый доступ к bind-mount; stdout/stderr Docker logs. gRPC, WebSocket, MinIO/S3, TLS/auth на внутреннем API, Prometheus `/metrics` и опубликованный host-порт в конфигурации продуктового контура отсутствуют.
Хранилища	Локальный bind-mount `/data/compose-data2-no-swarm/lite-scenario-storage/lite-scenarios -> /uploads` хранит `flows.json`, `flows_params.json`, `scenario_params/.json` и `backups/backup_`. PostgreSQL sidecar `svr-lite-scenario-storage-postgres` хранит `scenarios`, `camera_scenario_backup` и `aerich`; на момент контроль в конфигурации продуктового контура было 65 строк `scenarios` и 0 строк `camera_scenario_backup`. При включённом ClickHouse зеркалируется таблица `lite_scenarios` в `st-event-storage-clickhouse`; в конфигурации продуктового контура она также содержала 65 строк. Собственного MinIO bucket и версионного хранилища flow-файлов нет.
Конфигурация	Основные env-группы: `DEBUG`, `PORT`, `TZ`, `SETTINGS_FILE`, `DEPENDS`, `BASE_UPLOAD_DIR`; PostgreSQL `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`; Kafka `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_SCENARIOS_FILE_UPDATED`, `KAFKA_TOPIC_SCENARIOS_LITE_DELETED`, `KAFKA_TOPIC_CURRENT_LITE_SCENARIOS`, `KAFKA_TOPIC_SCENARIO_SETTINGS_UPDATED`; ClickHouse `USE_CLICKHOUSE`, `CLICKHOUSE_HOST`, `CLICKHOUSE_TABLE_NAME`; backup `AUTO_USE_BACKUPS`, `BACKUP_EXPIRE_DAYS`, `CAMERA_STORAGE_BASE_URL`. В конфигурации продуктового контура заданы `DEBUG=false`, `BASE_UPLOAD_DIR=/uploads/`, ожидание `svr-lite-scenario-storage-postgres:5432`, `KAFKA_HOST=inf-kafka:9092`, `USE_CLICKHOUSE=true`, `CLICKHOUSE_HOST=st-event-storage-clickhouse`; значения параметров доступа не документируются. Entry-point выполняет `wait-depends`, `aerich upgrade` и `python /service/main.py server`; `DEBUG=true` переводит контейнер в длительный sleep.
Логирование	Приложение пишет Loguru и uvicorn access/error logs в stdout/stderr; Docker log driver в конфигурации продуктового контура - `loki`. В логах видны старт контейнера, ожидание PostgreSQL, результат `aerich upgrade`, создание/очистка/обновление ClickHouse-таблицы, запуск scheduler-а, ежедневная очистка backup, операции upload/backup/restore, отправка Kafka-событий и ошибки HTTP/PostgreSQL/ClickHouse/Kafka. Отдельного файлового audit-журнала или audit-topic у сервиса не предусмотрено.
Мониторинг	Docker healthcheck отсутствует (`Health=none`). Контрольная проверка в конфигурации продуктового контура: `GET /api/docs/` и `GET /openapi.json` вернули `200 OK`; в OpenAPI доступны все девять REST-путей; `GET /get-json-file/` вернул список из 640 Node-RED узлов, `GET /get-json-file-params/` вернул JSON настроек, `POST /get-scenarios/` и `POST /get-scenarios-settings/` вернули по 65 записей, `POST /get-backup-list/` вернул пустой список; `GET /metrics` вернул `404`. Практический мониторинг - состояние контейнеров app/postgres, доступность read-only REST, строки в PostgreSQL/ClickHouse, ошибки в Loki и успешность Kafka publish после upload/restore.
Критичность	Средняя для уже опубликованного production-инференса, высокая для публикации и обслуживания lightweight-сценариев через sandbox/UI. Отказ сервиса не должен напрямую останавливать текущий видеопоток, если runtime использует полный `svr-scenario-storage`, но блокирует загрузку нового lightweight `flows.json`, чтение lite-каталога и тонких настроек в UI/gateway, backup/restore lite-сценариев, синхронизацию ClickHouse-зеркала и Kafka-уведомления о текущем наборе lite-сценариев.
Эксплуатационные особенности и известные ограничения	`create-backup/` и `restore-backup/` оформлены как `GET`, но меняют состояние, поэтому их нельзя использовать как healthcheck. Нет auth/TLS, gRPC, `/metrics`, Docker healthcheck, host-порта, MinIO, версионной истории и distributed lock; `upload-scenarios/` сериализован только lock-ом внутри одного процесса, а in-flight операции не восстанавливаются после рестарта. Бэкап зависит от ответа `CAMERA_STORAGE_BASE_URL` и не создаёт полноценный снимок, если нет камер со scenario IDs. ClickHouse-зеркало является производным от PostgreSQL/файлов и при ошибках обновления не заменяет источник истины. HTTP-клиенты gateway к сервису используют `timeout=None`, поэтому зависший lite-storage может подвесить соответствующие UI/API операции.

`svr-lite-scenario-storage-postgres`¶

Поле	Описание
Название сервиса	`svr-lite-scenario-storage-postgres`. PostgreSQL 13.1 sidecar сервиса `svr-lite-scenario-storage`; в конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-lite-scenario-storage-postgres-1` с образом `docker.vizorlabs.ru/vizorlabs/postgres:13.1`. Слушает внутренний Docker-порт `5432/tcp`; host-порт в конфигурации продуктового контура не опубликован.
Назначение	Постоянное PostgreSQL-хранилище для `svr-lite-scenario-storage`. Хранит извлечённый каталог lite-сценариев, метаданные backup-снимков и служебное состояние миграций Aerich. Сам контейнер не реализует отдельную бизнес-функцию, REST/gRPC API, обработку `flows.json`, Kafka-уведомления или восстановление backup-файлов: этими процессами управляет приложение `svr-lite-scenario-storage`.
Подсистема	Compose-домен `severstal` / PostgreSQL-хранилища customer-specific контура BOX5-DIT-MGSN. Функционально обслуживает сервис `svr-lite-scenario-storage`, который относится к integration-домену и используется custom-domain маршрутом в `ui-rest-to-gprc`, а также публикацией сценариев из Node-RED sandbox.
Основные функции	Принимает SQL-подключения от `svr-lite-scenario-storage`; хранит таблицы `scenarios`, `camera_scenario_backup` и `aerich`; обеспечивает долговременное состояние каталога lite-сценариев и backup-метаданных; переживает рестарт контейнера за счёт host-backed `PGDATA`. Не запускает миграции самостоятельно: `aerich upgrade`, `Tortoise.generate_schemas()` и прикладные изменения схемы выполняются приложением при старте.
Входящие вызовы	PostgreSQL wire protocol на `5432` из внутренней сети `bx_default`. Штатный клиент - `svr-lite-scenario-storage`, который подключается к alias `svr-lite-scenario-storage-postgres` через Tortoise ORM и использует согласованные `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`. В конфигурации продуктового контура заданы network alias `svr-lite-scenario-storage-postgres`, `pg_isready -U dnn -d dnn` со статусом `accepting connections` и SQL-доступ к БД `dnn`. Публичных HTTP, REST, gRPC, Kafka или Redis-входов у sidecar нет.
Исходящие вызовы	Сервис-специфичных исходящих сетевых вызовов нет. PostgreSQL отвечает клиентам по открытым TCP-соединениям, пишет WAL/табличные файлы в `PGDATA` и технологические сообщения в `stdout`/`stderr`. Kafka, ClickHouse, camera-storage, HTTP-клиенты, gRPC и Redis относятся к приложению `svr-lite-scenario-storage`, а не к этому контейнеру.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`; файловый ввод-вывод PostgreSQL в `PGDATA`; `stdout`/`stderr` для технологических логов. TLS, HTTP, REST, gRPC, Kafka, Redis, Prometheus endpoint и публичный API у sidecar отсутствуют.
Хранилища	Основное состояние - PostgreSQL в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/severstal/pgdata-lite-scenario-storage` -> `/var/lib/postgresql/data`. Рабочая БД в конфигурации продуктового контура - `dnn`, схема - `public`; присутствуют таблицы `aerich`, `camera_scenario_backup`, `scenarios`. Таблица `scenarios` хранит извлечённый список вкладок из загруженного `flows.json`; `camera_scenario_backup` хранит имя backup, Unix timestamp и JSONB-снимок привязок камер к сценариям. Файловые копии `flows.json`, `flows_params.json` и backup-файлы находятся в файловом хранилище app-контейнера `svr-lite-scenario-storage`, не в этом PostgreSQL-контейнере.
Конфигурация	Env-only конфигурация стандартного образа PostgreSQL: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, а также базовые переменные образа `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`, `PATH`. Для конфигурации продуктового контура закреплён image-tag `13.1`; живой контейнер использует `RestartPolicy=always`, Docker log driver `loki`, сеть `bx_default` с alias `svr-lite-scenario-storage-postgres`, Docker healthcheck не задан. У приложения должны быть согласованы `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST` и `POSTGRES_PORT`; значения параметров доступа в документацию не выносятся.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. Отдельного прикладного журнала у sidecar нет; ошибки ожидания зависимости, Aerich-миграций, Tortoise ORM, backup-операций и FastAPI-старта нужно смотреть в логах `svr-lite-scenario-storage`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck в конфигурации продуктового контура нет (`Health=none`). Практические проверки: контейнер `severstal-svr-lite-scenario-storage-postgres-1` находится в состоянии `running`, `pg_isready -U dnn -d dnn` внутри контейнера возвращает `accepting connections`, SQL-подключение к БД `dnn` успешно, в `public` присутствуют таблицы `scenarios`, `camera_scenario_backup`, `aerich`. Готовность БД не доказывает готовность REST-сервиса: отдельно проверяются старт `svr-lite-scenario-storage`, успешность `aerich upgrade`, доступность `/api/docs/` и операции upload/download/backup при необходимости.
Критичность	Высокая для связки `svr-lite-scenario-storage`: при отказе или потере БД приложение не может надёжно вести каталог lite-сценариев, backup-метаданные и миграции. Для всего BOX5-DIT-MGSN критичность средняя: основной видеопоток и уже работающие inference-сценарии не зависят напрямую от этого PostgreSQL-sidecar, но публикация и сопровождение lightweight `flows.json`, список текущих lite-сценариев и restore-процессы деградируют или останавливаются.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без собственной бизнес-валидации, публичного API, метрик, Docker healthcheck и отдельного `pg_dump`/backup-sidecar. Схемой полностью управляет `svr-lite-scenario-storage`; ручные SQL-изменения могут нарушить Aerich/Tortoise-контракт и согласованность локальных файлов приложения. Backup-файлы лежат вне контейнера БД, поэтому сохранность PostgreSQL `PGDATA` сама по себе не гарантирует полный restore `flows.json`/`flows_params.json`. Уровень схемы зависит от версии образа приложения и успешности `aerich upgrade`, поэтому при переносе между контурами нужно сверять image-tag app-контейнера, `POSTGRES_*` у app/sidecar и фактический список таблиц без вывода параметров доступа.

`svr-models-registry`¶

Поле	Описание
Название сервиса	`svr-models-registry` (`docker.vizorlabs.ru/severstal/models-registry`, репозиторий `severstal/model-storage`; в конфигурации продуктового контура используется образ `1.0.9-dev`).
Назначение	Реестр моделей BOX5-DIT-MGSN для контура VLFlow/NRI: хранит каталог ML-моделей, версий, типов задач и моделей, секций, атрибутов, комментариев, типов зон, статусов валидации и политики архивации. Через него NRI, flows-manager, UI и вспомогательные сервисы получают метаданные версий и ссылки на артефакты моделей.
Подсистема	`severstal`/`inference`, control-plane моделей. Работает рядом с `svr-models-registry-postgres`, `ds-minio`, `inf-kafka`, `svr-scenario-storage`, `st-camera-storage`, `inf-nri-inference`, `inf-flows-manager`, `yolo_conversion` и `mm_conversion`; сам инференс и конвертацию не выполняет.
Основные функции	CRUD каталога моделей и версий через gRPC; REST-доступ к спискам моделей/версий и файлам; генерация URL для загрузки/скачивания артефактов MinIO; потоковая загрузка ZIP и отдельных файлов; разбор `model_info.json` и `coco_categories.json`; публикация снимка `models_registry_ready`; обновление статусов версий по Kafka; хранение списка `inference_installed_packages.json`; выдача типов зон; агрегация использования моделей в сценариях и камерах; soft-delete/архивирование неиспользуемых версий.
Входящие вызовы	HTTP/gRPC на порту `3000`, сервис `vzrpc.custom.severstal.services.models_registry.ModelsRegistry`: методы для task/model types, секций, моделей, версий, local storage, атрибутов, комментариев, архива и zone types. REST на том же порту: `GET /api/docs/`, `GET /openapi.json`, `GET /model_with_versions/`, `GET /files/`, `POST /file_urls/`, `POST /generate-upload-urls/`, `POST /process-upload-status/`, `GET /get-all-type-zones/`, `POST /upload-archive/`, `POST /send-stream-to-minio/`, `GET /get-models-info/`, `POST /send-file-stream-to-minio/`, `POST /model-version/revalidate/`, `GET /inference/installed-packages/`, `GET /models-usage/`, `POST /delete-unused-models/`, `GET /model-types-usage/`, `GET /task-types-usage/`. Из известных клиентов: `ui-rest-to-gprc`, `inf-nri-inference` (`VLFLOW_ENDPOINT`), `inf-flows-manager`, `svr-asset-storage`, `svr-launch-storage`, административные скрипты и операции загрузки моделей.
Исходящие вызовы	PostgreSQL к `svr-models-registry-postgres:5432` через Tortoise ORM/Aerich; MinIO/S3 к `ds-minio:9000`, bucket `models-registry`; Kafka produce в `models_registry_ready`, `model_version_uploaded`, `model_version_deleted`, `model_version_updated`, `model_version_ready`, `ws_model_version_change_status`, `zone_types_updated`, `create_zone_type`, `update_zone_type`, `remove_zone_type`; Kafka consume из `model_version_change_status` и `inference_installed_packages`; HTTP/gRPC и REST к `svr-scenario-storage:3000` для проверки сценариев и агрегирования использования; HTTP/REST к `st-camera-storage:3000` для связи сценариев с камерами. Прямых исходящих вызовов из `svr-models-registry` в `inf-nri-inference`, `inf-flows-manager`, `yolo_conversion`, `mm_conversion` или MLflow в текущей реализации и env контура не предусмотрено: эти сервисы сами читают реестр или локальные/MLflow-источники.
Протоколы	HTTP/1.1 REST, gRPC поверх HTTP, PostgreSQL wire protocol, S3-compatible MinIO API, Kafka protocol; внутри NRI/flows-manager связь с конвертерами моделей идёт отдельно по Unix socket `YOLO_CONVERSION_URI`/`MMLAB_CONVERSION_URI`, а не через `svr-models-registry`.
Хранилища	`svr-models-registry-postgres` — реляционные таблицы `mlmodel`, `modelversion`, `modelsection`, `modeltype`, `tasktype`, `category`, `file`, `attribute`, `thread`, `message`, `archive`, `zonetype`, `aerich`; в конфигурации продуктового контура таблицы `mlmodel`, `modelversion`, `zonetype`, `file` содержат данные. `ds-minio` bucket `models-registry` — артефакты `<model>/<version>/...`, mirror `weight/<model>/<version>/...`, временные stream ZIP и служебный объект `inference_installed_packages.json`. Локальный bind `/uploads` используется только для legacy/local-storage helpers; в конфигурации продуктового контура `STORAGE_TYPE=minio`, файлов в `/uploads` не предусмотрено.
Конфигурация	Базовые env: `DEBUG`, `PORT=3000`, `SETTINGS_FILE`, `DEPENDS`; PostgreSQL `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`; MinIO `MINIO_ENDPOINT`, `MINIO_ACCESS_KEY`, `MINIO_SECRET_KEY`, `MINIO_SECURE`, `MINIO_BUCKET`, `MINIO_PREFIX`, `MINIO_CERT_CHECK`; Kafka `KAFKA_HOST`, `KAFKA_GROUP` и `KAFKA_TOPIC_*`; внешние endpoints `SCENARIO_STORAGE_URL`, `CAMERA_STORAGE_URL`; `STORAGE_TYPE`, `BASE_UPLOAD_DIR`, `GRPC_CLIENT_DEFAULT_TIMEOUT`, `HTTPX_CLIENT_TIMEOUT`, `HTTPX_VERIFY_REQUEST`, `MAX_QUEUE_SIZE`, `MAX_ARCHIVE_CHECK_RETRIES`, `ARCHIVE_CHECK_RETRY_DELAY`. `start-service.sh` ждёт `DEPENDS`, выполняет `aerich upgrade` и запускает `python /service/main.py server`; при `DEBUG=true` контейнер уходит в sleep. Значения параметров доступа не документируются.
Логирование	Приложение использует `loguru` в `stdout`/`stderr`, uvicorn пишет access/error logs; в конфигурации продуктового контура Docker log driver — `loki`. В логах фиксируются старт сервиса, миграции, ошибки REST/gRPC, загрузка и перезапись файлов в MinIO, отправка Kafka-событий, очистка архива, ошибки получения usage из scenario/camera storage и ошибки `/metrics`. Отдельного файлового audit-журнала у сервиса не предусмотрено.
Мониторинг	Docker healthcheck отсутствует (`Health=none`), host-порт для `3000` не опубликован; проверять нужно из Docker-сети/контейнера. Read-only проверки в конфигурации продуктового контура вернули `200 OK` для `/api/docs/`, `/openapi.json`, `/model_with_versions/`, `/get-all-type-zones/`, `/get-models-info/`, `/inference/installed-packages/`, `/models-usage/`, `/model-types-usage/`, `/task-types-usage/`. Практические проверки: контейнер `Up`, доступность Postgres/MinIO/Kafka, bucket `models-registry`, наличие `inference_installed_packages.json`, успешный `GET /get-models-info/`, отсутствие ошибок Kafka/MinIO/Postgres в Loki. `GET /metrics` в контейнере продуктового контура возвращал `500 Internal Server Error`, поэтому Prometheus endpoint требует отдельной проверки перед использованием как SLO-сигнала.
Критичность	Высокая для управления моделями и раскатки версий: при отказе сервиса UI/административные операции не смогут читать и менять каталог, NRI/flows-manager теряют доступ к VLFlow-метаданным и ссылкам на артефакты, не публикуются события жизненного цикла моделей и типы зон. Уже загруженные и локально закэшированные модели в `/models` могут продолжать работать, но обновление, revalidate, скачивание новых версий и безопасное удаление/архивирование деградируют.
Эксплуатационные особенности и известные ограничения	Сервис не является runtime-инференсом, не управляет GPU и не конвертирует веса; конвертацию выполняют `yolo_conversion`/`mm_conversion`, а выбор `filesystem`/`vlflow`/`mlflow` находится в NRI/flows-manager/vlmodels. В конфигурации окружения самого `svr-models-registry` нет `MLFLOW_*`, поэтому MLflow не является его прямой зависимостью. Часть REST-операций изменяет состояние (`generate-upload-urls` с `is_upload=true`, upload/revalidate/delete), поэтому для диагностики использовать только read-only endpoints. `GET /metrics` в конфигурации продуктового контура возвращал `500`; Docker healthcheck отсутствует. Потоковая загрузка ZIP ожидает корректные `model_info.json` и `coco_categories.json`, а локальный режим `/uploads` — legacy/fallback и не основной путь в конфигурации продуктового контура.

`svr-models-registry-postgres`¶

Поле	Описание
Название сервиса	`svr-models-registry-postgres` (`docker.vizorlabs.ru/vizorlabs/postgres:13.1`; в конфигурации продуктового контура контейнер `severstal-svr-models-registry-postgres-1`).
Назначение	PostgreSQL-sidecar для `svr-models-registry`: хранит реляционный каталог моделей, версий, файловых метаданных, категорий, атрибутов, комментариев, типов зон, политики архивации и служебную историю миграций Aerich. Сервис не имеет собственной бизнес-логики и не является публичным API реестра моделей.
Подсистема	Домен `severstal`, storage-sidecar для integration-сервиса `svr-models-registry`. Работает в Docker-сети `bx_default` с alias `svr-models-registry-postgres`; прикладной контракт задаётся app-сервисом `svr-models-registry`, который выполняет Aerich/Tortoise-миграции и использует БД как основной источник метаданных моделей.
Основные функции	Приём PostgreSQL-подключений от `svr-models-registry`; долговременное хранение `PGDATA`; обеспечение транзакционного чтения/записи таблиц каталога моделей; хранение служебной таблицы `aerich` для версии схемы; поддержка старта app-контейнера после выполнения миграций. Конвертацией моделей, MinIO-операциями, Kafka-событиями и REST/gRPC-контрактом занимается `svr-models-registry`, а не sidecar.
Входящие вызовы	Только PostgreSQL wire protocol на `5432/tcp` из Docker-сети, основной клиент — `svr-models-registry` с host `svr-models-registry-postgres`. Host-порт в конфигурации продуктового контура не опубликован (`5432/tcp: null`). Входящих HTTP, gRPC, REST, Kafka, S3 или Prometheus-вызовов у sidecar нет.
Исходящие вызовы	Прикладных исходящих сетевых вызовов нет. Контейнер пишет данные только в смонтированный каталог PostgreSQL; вызовы к `svr-models-registry`, MinIO, Kafka, `svr-scenario-storage`, `st-camera-storage`, NRI, flows-manager или MLflow отсутствуют.
Протоколы	PostgreSQL wire protocol поверх TCP внутри Docker-сети; файловый доступ PostgreSQL к `PGDATA`. HTTP/REST, gRPC, Kafka, S3/MinIO, gRPC и Prometheus endpoint не используются.
Хранилища	База `dnn` в PostgreSQL 13.1; `PGDATA=/var/lib/postgresql/data`. В конфигурации продуктового контура задан bind-mount `/data/compose-data2-no-swarm/severstal/pgdata-models-registry` в `/var/lib/postgresql/data`. В `public` присутствуют таблицы `aerich`, `archive`, `attribute`, `category`, `file`, `message`, `mlmodel`, `modelsection`, `modeltype`, `modelversion`, `tasktype`, `thread`, `zonetype`; таблицы `attribute`, `category`, `file`, `mlmodel`, `modelversion` и `thread` содержат данные.
Конфигурация	Env-only конфигурация стандартного образа PostgreSQL: `POSTGRES_DB=dnn`, `POSTGRES_USER=dnn`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA=/var/lib/postgresql/data`, а также переменные образа `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`, `PATH`. В конфигурации продуктового контура контейнер использует `RestartPolicy=always`, Docker log driver `loki`, сеть `bx_default` и image-tag `13.1`; Docker healthcheck не задан. У `svr-models-registry` должны быть согласованы `POSTGRES_HOST=svr-models-registry-postgres`, `POSTGRES_DATABASE`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD` и порт PostgreSQL по умолчанию `5432`.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. Отдельного прикладного журнала у sidecar нет; ошибки ожидания зависимости, Aerich-миграций, Tortoise ORM, SQL-запросов и старта API нужно смотреть в логах `svr-models-registry`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck нет (`Health=none`, `Healthcheck=null`). Практический контроль: контейнер `severstal-svr-models-registry-postgres-1` в состоянии `running`, `pg_isready -U dnn -d dnn` возвращает `accepting connections`, SQL-запрос к `information_schema.tables` видит ожидаемые таблицы, а из app-контейнера `svr-models-registry` TCP-подключение к `svr-models-registry-postgres:5432` успешно. Готовность БД не доказывает готовность реестра моделей: отдельно проверяются старт `svr-models-registry`, успешность `aerich upgrade` и read-only REST/gRPC endpoints приложения.
Критичность	Высокая для `svr-models-registry`: при отказе или потере данных app-сервис не может читать и менять каталог моделей, версии, файлы, типы зон, комментарии и archive-состояния, а миграции Aerich не смогут привести схему к версии образа. Для runtime-инференса возможна временная работа уже загруженных и закэшированных моделей, но UI/административные операции, загрузка новых версий, revalidate, публикация lifecycle-событий и чтение VLFlow-метаданных для NRI/flows-manager деградируют или останавливаются.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL-sidecar без публичного API, `/metrics`, healthcheck, бизнес-валидации и отдельного backup-sidecar. Схемой управляет только `svr-models-registry`; ручные SQL-изменения могут нарушить Tortoise/Aerich-контракт и согласованность с объектами в MinIO bucket `models-registry`. Сохранность bind-mount `PGDATA` защищает только реляционные метаданные: артефакты моделей, stream ZIP и служебный объект `inference_installed_packages.json` находятся в MinIO и требуют отдельной проверки. При переносе между контурами нужно сверять image-tag app-контейнера, список таблиц и согласованность `POSTGRES_*` без вывода конфиденциальных значений.

`svr-asset-storage`¶

Поле	Описание
Название сервиса	`svr-asset-storage` (`docker.vizorlabs.ru/severstal/asset-storage`, репозиторий `severstal/asset-storage`; в конфигурации продуктового контура развёрнут контейнер `severstal-svr-asset-storage-1` с образом `1.0.6-dev`). Это app-сервис, не PostgreSQL-sidecar; sidecar описывается отдельно в `svr-asset-storage-postgres`.
Назначение	Сервис управления ассетами BOX5-DIT-MGSN для продуктового контура: хранит разделы ассетов, ассеты, версии ассетов, папки, метаданные медиафайлов, комментарии, атрибуты, зоны детекции и политику архива. Байты изображений, видео, превью и JSON-sidecar файлов хранятся в MinIO или в локальной файловой системе в зависимости от режима `STORAGE_TYPE`.
Подсистема	Compose-домен `severstal` / интеграционный control-plane ассетов. Относится к domain `integration`; используется custom-domain маршрутом в `ui-rest-to-gprc`, Node-RED sandbox backend `nr-sbx-backend` и `svr-launch-storage` для выбора asset version и передачи медиа в launch-процессы.
Основные функции	CRUD разделов ассетов, ассетов и версий; загрузка видео/изображений напрямую и через presigned MinIO URL; регистрация успешной загрузки `UploadFileSuccess`; просмотр локального хранилища; управление папками версии ассета; комментарии и thread-связи; атрибуты ассетов/версий; добавление, обновление, удаление и JSON-сериализация зон; upload JSON-sidecar `zones` и `camera-params`; генерация превью и длительности видео через ffmpeg/OpenCV/MoviePy; архивирование ассетов и asset versions, возврат из архива и ежедневная очистка архивных записей.
Входящие вызовы	HTTP/gRPC на порту `3000`, сервис `vzrpc.custom.severstal.services.asset_storage.AssetStorage`: группы методов для asset sections, assets, asset versions, local storage, folders, comments, zones, attributes и archive. REST на том же порту: `GET /api/docs/`, `GET /openapi.json`, `GET /metrics`, `GET /asset_versions/download/tar_archive/{asset_version_id}`, `GET /asset_versions/download/file/{file_id}`, `GET /asset_versions/stream_media_file/{media_file_id}`, `GET /asset_versions/get_file/{file_id}`, `GET /asset_versions/get_preview_video/{file_id}`, `POST /asset_versions/upload-json-file/`. Из известных клиентов: `ui-rest-to-gprc` по gRPC и REST pass-through, `svr-launch-storage` через gRPC `GetAssetVersion`, `nr-sbx-backend` через gateway REST, пользовательский UI и административные операции загрузки ассетов.
Исходящие вызовы	PostgreSQL к `svr-asset-storage-postgres:5432` через Tortoise ORM/Aerich; MinIO/S3 к `ds-minio` bucket `asset-storage` для медиа, превью, зон и camera-params JSON; HTTP/gRPC к `svr-models-registry:3000` (`GetZoneTypes`) при импорте/перезаписи зон, чтобы сопоставить `zid` с типами зон. Прямых Kafka, Redis, ClickHouse, NRI, camera-storage или launch-storage исходящих вызовов в текущей реализации сервиса не предусмотрено.
Протоколы	HTTP/1.1 REST, gRPC поверх HTTP, PostgreSQL wire protocol, S3-compatible MinIO API, файловый ввод-вывод в режиме `STORAGE_TYPE=local`, `stdout`/`stderr` для логов. Kafka и WebSocket интерфейсы у сервиса отсутствуют.
Хранилища	Основное состояние - `svr-asset-storage-postgres`: таблицы `asset`, `assetsection`, `assetversion`, `folder`, `updfile`, `attribute`, `thread`, `message`, `zone`, `archive`, `aerich`. Объектное хранилище - bucket MinIO `asset-storage`: медиа под `<asset_version_id>/<folder_id>/<file_name>`, превью `<stem>_preview.jpg`, зоны `<stem>.json`, параметры камеры `<stem>__camera-params.json`, удаляемые версии переносятся под `removed/<asset_version_id>/...`. В локальном режиме используется `BASE_UPLOAD_DIR/<asset_id>/` и кэш TAR-архивов `BASE_UPLOAD_DIR/tar_archives/`; в конфигурации продуктового контура app-контейнер работает как внутренний сервис без опубликованного host-порта `3000`.
Конфигурация	Env-only конфигурация приложения: `DEBUG`, `PORT`, `SETTINGS_FILE`, `DEPENDS`; PostgreSQL `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`; хранилище `STORAGE_TYPE`, `BASE_UPLOAD_DIR`, `USE_HTTPS`, `UPLOAD_FILE_MAX_SIZE`; MinIO `MINIO_ENDPOINT`, `MINIO_ACCESS_KEY`, `MINIO_SECRET_KEY`, `MINIO_SECURE`, `MINIO_BUCKET`, `MINIO_PREFIX`, `MINIO_UPLOAD_PREFIX`, `MINIO_CERT_CHECK`; внешний endpoint `SEVERSTAL_MODELS_STORAGE`; архивные defaults `EXPIRE_DAYS_DEFAULT`, `EXPIRE_VERSION_DEFAULT`. `start-service.sh` ждёт `DEPENDS`, выполняет `aerich upgrade` и запускает `python /service/main.py server`; при `DEBUG=true` контейнер уходит в sleep. Значения параметров доступа в документацию не выносятся.
Логирование	Приложение использует `loguru` и uvicorn, выводит технологические и прикладные сообщения в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver - `loki`. В логах ожидаемы старт сервиса, миграции, ошибки gRPC/REST, операции с MinIO, генерация превью, импорт зон, запуск scheduler и архивная очистка. Отдельного файлового audit-журнала у сервиса не предусмотрено; пользовательский аудит при необходимости формируется на уровне gateway/смежных сервисов.
Мониторинг	Docker healthcheck отсутствует (`Health=none`), host-порт `3000` не опубликован; проверять нужно внутри Docker-сети или из контейнера. В конфигурации продуктового контура контроль вернули `200 OK` для `/api/docs/` и `/openapi.json`, PostgreSQL sidecar отвечает `pg_isready`, container restart policy `always`, сеть `bx_default` с alias `svr-asset-storage`. `GET /metrics` в контейнере продуктового контура возвращает `500 Internal Server Error`: custom gRPC wrapper ожидает `GetPrometheusMetrics`, которого нет в классе `AssetStorage`, поэтому этот endpoint нельзя использовать как рабочий SLO-сигнал без отдельного исправления.
Критичность	Высокая для сценариев подготовки и запуска ассетов: при отказе сервиса UI и sandbox не могут полноценно просматривать/загружать asset versions, `svr-launch-storage` не сможет разрешить выбранную asset version для запуска, а зоны и media metadata перестанут обновляться. Уже запущенный runtime-инференс и ранее сконфигурированные потоки могут продолжить работу, если не требуют новых ассетов, но публикация и тестирование новых медиа деградируют или останавливаются.
Эксплуатационные особенности и известные ограничения	Сервис не выполняет инференс, не управляет камерами и не является модельным реестром; типы зон только запрашиваются из `svr-models-registry`. В MinIO-режиме прямые REST download/stream endpoints для файлов и TAR-архива намеренно возвращают `403`, использовать нужно MinIO URL или presigned upload/download flow. Docker healthcheck отсутствует, `/metrics` в конфигурации продуктового контура неисправен. Консистентность архива зависит от успешного переименования MinIO-префиксов и состояния PostgreSQL; ручные изменения таблиц или объектов bucket могут нарушить связи `assetversion`/`folder`/`updfile`/`zone`. `app/tasks/clearing_minio.py` есть в репозитории, но scheduled job в `config/setup.py` закомментирован: активная очистка идёт через archive scheduler.

`svr-asset-storage-postgres`¶

Поле	Описание
Название сервиса	`svr-asset-storage-postgres`. PostgreSQL 13.1 sidecar сервиса `svr-asset-storage`; в конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-asset-storage-postgres-1` с образом `docker.vizorlabs.ru/vizorlabs/postgres:13.1`. Слушает внутренний Docker-порт `5432/tcp`; host-порт в конфигурации продуктового контура не опубликован.
Назначение	Постоянное реляционное хранилище для `svr-asset-storage`. Хранит метаданные разделов, ассетов, версий ассетов, папок, загруженных файлов, комментариев, атрибутов, зон разметки и политики архивирования. Сам контейнер не реализует бизнес-API, загрузку медиа, генерацию preview, работу с MinIO или lookup типов зон: этим управляет приложение `svr-asset-storage`.
Подсистема	Compose-домен `severstal` / PostgreSQL-хранилища customer-specific контура BOX5-DIT-MGSN. Функционально обслуживает `svr-asset-storage`, который относится к integration-домену и используется custom-domain маршрутом в `ui-rest-to-gprc`, sandbox backend и `svr-launch-storage` для каталога ассетов и выбора asset version.
Основные функции	Принимает SQL-подключения от `svr-asset-storage`; хранит таблицы `asset`, `assetsection`, `assetversion`, `folder`, `updfile`, `attribute`, `thread`, `message`, `zone`, `archive` и служебную таблицу `aerich`; обеспечивает сохранность метаданных между рестартами за счёт host-backed `PGDATA`. Не запускает миграции самостоятельно: `aerich upgrade`, `Tortoise.generate_schemas()` и прикладные изменения схемы выполняются app-контейнером при старте.
Входящие вызовы	PostgreSQL wire protocol на `5432` из внутренней сети `bx_default`. Штатный клиент - `svr-asset-storage`, который подключается к alias `svr-asset-storage-postgres` через Tortoise ORM; в конфигурации продуктового контура у app-контейнера заданы `DEPENDS=["svr-asset-storage-postgres:5432"]`, `POSTGRES_HOST=svr-asset-storage-postgres`, БД `dnn` и пользователь `dnn` без вывода параметров доступа. Контрольная проверка `pg_isready -U dnn -d dnn` вернула `accepting connections`. Публичных HTTP, REST, gRPC, Kafka, Redis или MinIO-входов у sidecar нет.
Исходящие вызовы	Сервис-специфичных исходящих сетевых вызовов нет. PostgreSQL отвечает клиентам по открытым TCP-соединениям, пишет WAL/табличные файлы в `PGDATA` и технологические сообщения в `stdout`/`stderr`. Обращения к MinIO, `svr-models-registry`, REST/gRPC-клиентам и архивному scheduler-у относятся к приложению `svr-asset-storage`, а не к этому контейнеру.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`; файловый ввод-вывод PostgreSQL в `PGDATA`; `stdout`/`stderr` для технологических логов. HTTP, REST, gRPC, Kafka, Redis, S3/MinIO, Prometheus endpoint и публичный API у sidecar отсутствуют.
Хранилища	Основное состояние - PostgreSQL в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/severstal/pgdata-asset-storage` -> `/var/lib/postgresql/data`. Рабочая БД в конфигурации продуктового контура - `dnn`, схема - `public`; присутствуют таблицы `aerich`, `archive`, `asset`, `assetsection`, `assetversion`, `attribute`, `folder`, `message`, `thread`, `updfile`, `zone`. Медиафайлы, preview, zones JSON и camera-params JSON в штатном режиме `STORAGE_TYPE=minio` лежат в MinIO bucket `asset-storage`, а не в PostgreSQL-sidecar.
Конфигурация	Env-only конфигурация стандартного образа PostgreSQL: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, а также переменные образа `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`, `PATH`. Для конфигурации продуктового контура закреплён image-tag `13.1`; живой контейнер использует `RestartPolicy=always`, Docker log driver `loki`, сеть `bx_default` с alias `svr-asset-storage-postgres`, Docker healthcheck не задан. У приложения должны быть согласованы `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST` и `POSTGRES_PORT`; значения параметров доступа в документацию не выносятся.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. В live-логах видны повторное использование существующего каталога БД, старт PostgreSQL 13.1, listen на `0.0.0.0:5432`, Unix socket и состояние `ready to accept connections`. Отдельного прикладного журнала у sidecar нет; ошибки ожидания зависимости, Aerich-миграций, Tortoise ORM, MinIO и REST/gRPC-операций нужно смотреть в логах `svr-asset-storage`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint и Docker healthcheck в конфигурации продуктового контура нет (`Health=none`); `NetworkSettings.Ports` показывает `5432/tcp` без host-публикации. Практические проверки: контейнер `severstal-svr-asset-storage-postgres-1` находится в состоянии `running`, `pg_isready -U dnn -d dnn` возвращает `accepting connections`, SQL-подключение к БД `dnn` успешно, таблицы схемы `public` соответствуют моделям `svr-asset-storage`, mount `PGDATA` присутствует. Готовность БД не доказывает готовность сервиса ассетов: отдельно проверяются старт `svr-asset-storage`, успешность `aerich upgrade`, `/api/docs/`, `/openapi.json` и read-only операции каталога при необходимости.
Критичность	Высокая для `svr-asset-storage`: при отказе или потере БД приложение не может надёжно вести каталог ассетов, версий, файлов, комментариев, зон и архивных состояний, а старт app-контейнера может остановиться на ожидании зависимости или миграциях. Для всего BOX5-DIT-MGSN отказ обычно не останавливает уже запущенный inference-поток напрямую, но блокирует или деградирует UI/API-операции с ассетами, загрузку новых медиа, импорт зон и разрешение asset version для sandbox/launch flows.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без собственной бизнес-валидации, публичного API, метрик, Docker healthcheck и отдельного `pg_dump`/backup-sidecar. Схемой полностью управляет `svr-asset-storage`; ручные SQL-изменения могут нарушить Aerich/Tortoise-контракт и согласованность MinIO-объектов с метаданными `updfile`/`folder`. Сохранность одного `PGDATA` не равна полному backup ассетов, потому что медиа, preview и JSON-sidecar файлы хранятся отдельно в MinIO или local storage. Sidecar не имеет host-порта и рассчитан на доступ только из внутренней Docker-сети.

`svr-launch-storage`¶

Поле	Описание
Название сервиса	`svr-launch-storage` (`severstal/launch-storage`). App-сервис управления sandbox-запусками сценариев и моделей; в конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-launch-storage-1` с образом `docker.vizorlabs.ru/severstal/launch-storage:1.0.6-dev`. Слушает внутренний Docker-порт `3000/tcp`, host-порт в конфигурации продуктового контура не опубликован.
Назначение	Создаёт, хранит и сопровождает "launch" - пробные запуски версии сценария или модели на выбранных asset/media-файлах через Node-RED sandbox. Сервис хранит состояние запуска, файлов, комментариев и связанного sandbox session id в PostgreSQL, отдаёт результаты и артефакты из MinIO, принимает статусы выполнения из Kafka и предоставляет gRPC API для UI/API-клиентов и диагностических операций. Production-инференс сам не выполняет.
Подсистема	Контур BOX5-DIT-MGSN управления NRI-сценариями и моделями, функционально домен `integration`; в развёрнутом решении расположен в compose-домене `severstal`. Работает рядом с `svr-launch-storage-postgres`, `svr-asset-storage`, `svr-models-registry`, `svr-scenario-storage`, `nr-sbx-backend`, `inf-kafka` и `ds-minio`. Не является PostgreSQL-sidecar: БД описывается отдельно в секции `svr-launch-storage-postgres`.
Основные функции	Запускает, перезапускает, останавливает, удаляет, фильтрует и возвращает launch-записи; меняет итоговый результат запуска; создаёт sandbox-сессию в `nr-sbx-backend`; для многофайловых asset-версий запрашивает продолжение обработки следующего media-файла через Kafka; хранит media-file context; отдаёт session log, frame log, frame message, кадры, количество кадров и detection events из bucket `launch-storage`; ведёт comment threads (`thread`, `message`) для запусков. При старте выполняет `wait-depends`, `aerich upgrade`, инициализацию Tortoise ORM/MinIO/Kafka и запуск gRPC ASGI-сервера.
Входящие вызовы	HTTP/gRPC на внутреннем `3000/tcp`, префикс `/grpc/box.custom.severstal.launch_storage.LaunchStorage/*`. Основные RPC: `StartLaunch`, `RestartLaunch`, `StopLaunch`, `RemoveLaunch`, `FilterLaunches`, `GetLaunches`, `ChangeLaunchResult`, `FetchMediaFileContext`, `GetFrameLog`, `GetFrameMessage`, `FetchFrame`, `GetFrameCount`, `GetSessionLog`, `GetDetectionEvents`, а также comment RPC `AddMessage`, `UpdateMessage`, `GetMessage`, `GetMessages`, `GetAllMessage`, `DeleteMessage`; `RemoveAllLaunch` является maintenance/dev-операцией. Kafka-вход: topic `change_launch_status` от sandbox backend с `launch_uuid`, `session_id`, `status`, optional `error_message`, `media_url`, `total_steps`, `frame_index_step`. В live-логах присутствуют POST-вызовы `FilterLaunches`; `nr-sbx-backend` взаимодействует с сервисом преимущественно через Kafka status flow и HTTP-сессии, которые инициирует сам `svr-launch-storage`.
Исходящие вызовы	HTTP/gRPC к `svr-asset-storage` (`GetAssetVersion`) перед созданием запуска; HTTP/gRPC к `svr-models-registry` (`GetModelVersion`) для запусков `entity_type=model`; HTTP/gRPC к `svr-scenario-storage` (`GetScenarioVersion`) для запусков `entity_type=scenario`; HTTP/REST к `nr-sbx-backend` для `start_launch_session`, `close_session` и `stop_inference`; Kafka produce в `continue_launch` для обработки следующего файла и в `ws_launch_progress` для прогресса/ошибок UI/websocket-потребителей; PostgreSQL к `svr-launch-storage-postgres`; S3/MinIO к `ds-minio`, bucket `launch-storage`. Прямых вызовов в NRI runtime, `st-camera-storage`, `st-event-storage`, ClickHouse, Redis или MLflow в текущей конфигурации не предусмотрено.
Протоколы	Входящие: gRPC поверх HTTP/1.1 и технический HTTP `GET /metrics` на том же ASGI-приложении. Исходящие: HTTP/gRPC к registry/asset/scenario storage, HTTP/REST к sandbox backend, Kafka protocol к `inf-kafka`, PostgreSQL wire protocol к sidecar, S3-compatible MinIO API. Публичный REST API для бизнес-операций, Redis, ClickHouse и прямой NRI-протокол для app-сервиса не предусмотрены.
Хранилища	Собственная постоянная БД находится в `svr-launch-storage-postgres`: live-схема `public` содержит `aerich`, `launch`, `media_file`, `media_file_context`, `message`, `thread`; таблица `launch` содержит данные. MinIO bucket `launch-storage` хранит артефакты запусков: `log.txt`, `events.json`, `frames/<frame>/image.jpg`, `image_vis.jpg`, `last_execution_log.txt`, `last_message.json` под префиксом launch/media. Для image-запусков сервис нормализует артефакты в frame `000000`. У app-контейнера в конфигурации продуктового контура bind mounts не предусмотрены.
Конфигурация	Основные env-группы: `DEBUG`, `PORT`, `SETTINGS_FILE`, `DEPENDS`; PostgreSQL `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`; Kafka `KAFKA_HOST`, `KAFKA_GROUP`, `KAFKA_TOPIC_CHANGE_LAUNCH_STATUS`, `KAFKA_TOPIC_CONTINUE_LAUNCH`, `KAFKA_TOPIC_WS_LAUNCH_PROGRESS`; MinIO `MINIO_ENDPOINT`, `MINIO_ACCESS_KEY`, `MINIO_SECRET_KEY`, `MINIO_SECURE`, `MINIO_BUCKET`, `MINIO_PREFIX`, `MINIO_CERT_CHECK`; upstream endpoints `ASSET_STORAGE_URL`, `MODELS_REGISTRY_URL`, `SCENARIO_STORAGE_URL`, `NODE_RED_SANDBOX_URL`, `NODE_RED_SANDBOX_PREFIX`; timeouts `GRPC_CLIENT_DEFAULT_TIMEOUT`, `HTTPX_CLIENT_TIMEOUT`. Значения параметров доступа не документируются. В конфигурации продуктового контура заданы сеть `bx_default`, alias `svr-launch-storage`, `RestartPolicy=always`, Docker log driver `loki`, отсутствие host-publish для `3000/tcp` и отсутствие Docker healthcheck.
Логирование	Приложение пишет `loguru` и uvicorn access/error logs в `stdout`/`stderr`; Docker собирает их через log driver `loki`. В логах фиксируются ожидание зависимостей `svr-launch-storage-postgres`, `ds-minio`, `inf-kafka`, результат `aerich upgrade`, старт Kafka consumer `change_launch_status`, присоединение consumer group `launch-storage`, запуск uvicorn и gRPC access logs, включая `FilterLaunches`. Отдельного файлового бизнес-журнала или audit-topic у сервиса не предусмотрено.
Мониторинг	Docker healthcheck отсутствует (`Health=none`). ASGI wrapper содержит `GET /metrics`, но в конфигурации продуктового контура endpoint возвращает `500 Internal Server Error`, поэтому Prometheus-экспозицию нельзя считать рабочим SLO-сигналом без дополнительного исправления. Практический контроль: контейнер `severstal-svr-launch-storage-1` в состоянии `running`, `svr-launch-storage-postgres` отвечает `pg_isready`, порт `3000/tcp` доступен во внутренней сети, в логах нет циклических ошибок Kafka/MinIO/Postgres, consumer group `launch-storage` подписана на `change_launch_status`, gRPC-вызовы чтения (`FilterLaunches`, `GetLaunches`, артефактные методы) успешно завершаются.
Критичность	Высокая для пользовательского контура тестирования сценариев и моделей перед переносом в production: при отказе сервиса нельзя создать/остановить/перезапустить launch, посмотреть прогресс, логи, кадры, события и комментарии, а запущенные sandbox-сессии могут остаться без корректного закрытия. Для уже опубликованного production NRI-инференса критичность ниже: сам runtime и обработка боевых потоков напрямую от `svr-launch-storage` не зависят.
Эксплуатационные особенности и известные ограничения	Сервис зависит одновременно от доступности Postgres, MinIO, Kafka, `svr-asset-storage` и `nr-sbx-backend`; для model/scenario launch также обязательны `svr-models-registry` или `svr-scenario-storage`. Статусы выполнения асинхронны и приходят через Kafka, поэтому рассинхронизация topic `change_launch_status`, потеря `session_id` или отказ sandbox backend приводит к зависшим/устаревшим launch-состояниям. `RemoveAllLaunch` является опасной maintenance/dev-операцией. `/metrics` на live-контуре возвращает `500`, Docker healthcheck отсутствует. Сервис не валидирует и не строит NRI-сценарии сам, а только управляет sandbox-сессией и читает артефакты; прямых связей с `st-camera-storage` и production NRI runtime нет.

`svr-launch-storage-postgres`¶

Поле	Описание
Название сервиса	`svr-launch-storage-postgres`. PostgreSQL 13.1 sidecar сервиса `svr-launch-storage`; в конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-launch-storage-postgres-1` с образом `docker.vizorlabs.ru/vizorlabs/postgres:13.1`. Слушает только внутренний Docker-порт `5432/tcp`; host-port в конфигурации продуктового контура не опубликован.
Назначение	Постоянное PostgreSQL-хранилище для launch/session control flow: запусков sandbox-проверок сценариев и моделей, комментариев к запускам и состояния обработки медиафайлов. Сам sidecar не реализует бизнес-логику запуска, gRPC API, Kafka-обработку, работу с MinIO или вызовы Node-RED sandbox: этим управляет app-сервис `svr-launch-storage`.
Подсистема	Compose-домен `severstal` / integration control-plane BOX5-DIT-MGSN. Функционально обслуживает `svr-launch-storage`, который связывает sandbox-запуски с `svr-asset-storage`, `svr-models-registry`, `svr-scenario-storage`, `nr-sbx-backend`, `inf-kafka` и `ds-minio`.
Основные функции	Принимает SQL-подключения от `svr-launch-storage`; хранит таблицы `launch`, `thread`, `message`, `media_file_context`, `media_file` и `aerich`; обеспечивает долговременное состояние запусков, comment threads и per-media progress; переживает рестарт контейнера за счёт host-backed `PGDATA`. Миграции и создание схемы выполняет приложение через `aerich upgrade` при старте, а не сам PostgreSQL-контейнер.
Входящие вызовы	PostgreSQL wire protocol на `5432` из внутренней сети `bx_default`. Штатный клиент - `svr-launch-storage`, который в конфигурации продуктового контура подключается к alias `svr-launch-storage-postgres`, БД `dnn`, пользователю `dnn`; `POSTGRES_PASSWORD` задан, но значение не документируется. Заданы network aliases `svr-launch-storage-postgres` и `severstal-svr-launch-storage-postgres-1`, `pg_isready -U dnn -d dnn` со статусом `accepting connections`, SQL-доступ к БД `dnn`. Публичных HTTP, REST, gRPC, Kafka, Redis или Prometheus-входов у sidecar нет.
Исходящие вызовы	Сервис-специфичных исходящих сетевых вызовов нет. PostgreSQL отвечает клиентам по открытым TCP/Unix socket-соединениям, пишет WAL и табличные файлы в `PGDATA`, а технологические сообщения - в `stdout`/`stderr`. Kafka, MinIO, gRPC-вызовы в asset/model/scenario storage и REST-вызовы в Node-RED sandbox относятся к app-контейнеру `svr-launch-storage`, а не к этому sidecar.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`, Unix socket PostgreSQL внутри контейнера, файловый ввод-вывод PostgreSQL в `PGDATA`, `stdout`/`stderr` для технологических логов. TLS, HTTP, REST, gRPC, Kafka, Redis, S3/MinIO и Prometheus endpoint у sidecar отсутствуют.
Хранилища	Основное состояние - PostgreSQL в `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/severstal/pgdata-launch-storage` -> `/var/lib/postgresql/data`. Рабочая БД - `dnn`, схема - `public`; присутствуют таблицы `aerich`, `launch`, `media_file`, `media_file_context`, `message`, `thread`. Таблица `launch` хранит UUID запуска, статус, прогресс, результат, asset/entity JSON и `sandbox_session_id`; `thread`/`message` - комментарии; `media_file_context`/`media_file` - текущий файл, порядок обработки, длительности, статусы, счётчики детекций и шаги кадров. Артефакты запусков (`log.txt`, `events.json`, кадры) лежат в MinIO bucket `launch-storage`, не в этом PostgreSQL-контейнере.
Конфигурация	Env-only конфигурация стандартного образа PostgreSQL: `POSTGRES_DB`, `POSTGRES_USER`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA`, а также базовые переменные образа `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`, `PATH`. В конфигурации продуктового контура контейнер использует `RestartPolicy=always`, Docker log driver `loki`, сеть `bx_default`, exposed port `5432/tcp` без `PortBindings`, Docker healthcheck не задан (`Health=none`). У app-сервиса согласуются `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST=svr-launch-storage-postgres` и стандартный порт PostgreSQL; значения параметров доступа в документацию не выносятся.
Логирование	Штатные логи PostgreSQL пишутся в `stdout`/`stderr` контейнера и собираются Docker log driver `loki`. В конфигурации продуктового контура в логах видны повторное использование существующего data directory, старт PostgreSQL 13.1, прослушивание `0.0.0.0:5432`, Unix socket и переход в состояние `ready to accept connections`. Отдельного прикладного или audit-журнала у sidecar нет; ошибки `aerich upgrade`, ORM-запросов, gRPC/Kafka/MinIO/Node-RED операций нужно смотреть в логах `svr-launch-storage`.
Мониторинг	Собственного `/metrics`, HTTP health endpoint, публичного API и Docker healthcheck в конфигурации продуктового контура нет. Практический контроль: контейнер `severstal-svr-launch-storage-postgres-1` находится в состоянии `running`, `pg_isready -U dnn -d dnn` возвращает `accepting connections`, SQL-подключение к БД `dnn` успешно, в `public` присутствуют таблицы `aerich`, `launch`, `media_file`, `media_file_context`, `message`, `thread`. Готовность БД не доказывает готовность launch flow: отдельно проверяются app-контейнер `svr-launch-storage`, успешность `aerich upgrade`, gRPC-методы сервиса, Kafka topic `change_launch_status` и доступность MinIO/Node-RED sandbox при функциональной диагностике.
Критичность	Высокая для `svr-launch-storage`: при отказе или потере БД сервис не может надёжно создавать, фильтровать, перезапускать, останавливать и удалять sandbox-запуски, хранить комментарии, связывать запуск с `sandbox_session_id` и продолжать multi-file обработку. Для уже работающего production-инференса критичность ниже: текущие видеопотоки не должны напрямую зависеть от этого PostgreSQL-sidecar, но деградируют пробные запуски сценариев/моделей, история запусков и инспекция артефактов.
Эксплуатационные особенности и известные ограничения	Это generic PostgreSQL sidecar без собственной бизнес-валидации, публичного API, метрик, host-порта, Docker healthcheck в конфигурации продуктового контура и отдельного `pg_dump`/backup-sidecar. Схемой полностью управляет `svr-launch-storage`; ручные SQL-изменения могут нарушить Aerich/Tortoise-контракт и каскадные связи `launch` -> `media_file_context`/`media_file`, `thread` -> `message`. Сохранность PostgreSQL `PGDATA` не включает MinIO-артефакты запусков, поэтому для полного восстановления launch history нужно учитывать и bucket `launch-storage`. В repository-local `docker-compose.yml` у Postgres описан `pg_isready` healthcheck, но в конфигурации продуктового контура он отсутствует.

`svr-translations-store`¶

Поле	Описание
Название сервиса	`svr-translations-store` (`docker.vizorlabs.ru/severstal/translations-store:dev`, репозиторий `severstal/translations-store`, рабочая ветка `dev`). В конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-translations-store-1`; слушает внутренний Docker-порт `3000/tcp`, host-порт не опубликован.
Назначение	Каталог переводов для customer-domain интерфейса BOX5-DIT-MGSN: хранит типы переводимых объектов, языки, текущие локализованные названия, сокращённые названия, дополнительные параметры и историю изменений для подписей моделей, категорий и зон. Через сервис UI/gateway получает и изменяет словарь переводов; PostgreSQL-sidecar описывается отдельно в секции `svr-translations-store-postgres`.
Подсистема	Compose-домен `severstal`, функционально - integration/control-plane контур переводов пользовательского интерфейса. Основные соседи: `ui-rest-to-gprc` как клиент gRPC API и `svr-translations-store-postgres` как единственное постоянное хранилище. Сервис не участвует в runtime-инференсе, обработке видеопотока и конвертации моделей.
Основные функции	CRUD типов объектов перевода (`MODEL`, `CATEGORY`, `ZONE`), языков и переводов; выдача переводов JSON-структурой, сгруппированной по `model`/`category`/`zone`, имени объекта и коду языка; экспорт и импорт каталога в YAML; запись истории перед обновлением или удалением перевода; запуск Aerich-миграций и опциональный импорт YAML-файлов из `/service/migrations/` при старте; служебный `FlushDb`, который очищает прикладные таблицы.
Входящие вызовы	HTTP/gRPC на `3000`, сервис `vzrpc.custom.severstal.services.translations_store.TranslationsStore`, path prefix `/grpc/box.custom.severstal.translations_store.TranslationsStore`. Методы: `GetObjectTypes`, `AddObjectType`, `UpdateObjectType`, `DeleteObjectType`, `GetLanguage`, `AddLanguage`, `UpdateLanguage`, `DeleteLanguage`, `GetTranslations`, `AddTranslation`, `UpdateTranslation`, `DeleteTranslation`, `GetTranslationHistory`, `ExportTranslations`, `ImportTranslations`, служебный `FlushDb`. Известный клиент - `ui-rest-to-gprc`, где custom-domain слой использует `TranslationsStoreClientAsync` для REST-дерева `/severstal-translations-store/*`; также возможны служебные скрипты и ручные gRPC-вызовы из Docker-сети. OpenAPI/FastAPI REST у самого сервиса не предусмотрен.
Исходящие вызовы	PostgreSQL к `svr-translations-store-postgres:5432` через Tortoise ORM и Aerich: таблицы `type`, `language`, `translation_object`, `translation_history`, `migration`, `aerich`. На старте `start-service.sh` ожидает `DEPENDS`, выполняет `aerich upgrade`, затем запускает `python /service/main.py server`; приложение дополнительно читает YAML-файлы из `/service/migrations/`, если каталог присутствует. Активных исходящих HTTP, Kafka consumer/producer, Redis, MinIO/S3, ClickHouse, gRPC или shared-memory контрактов в текущей реализации нет; `KAFKA_*` остаются dormant-настройками, запуск consumer-ов закомментирован.
Протоколы	Входящий gRPC поверх HTTP/1.1 на `3000`; служебный `GET /metrics` на том же ASGI-приложении задуман как Prometheus text endpoint, но в конфигурации продуктового контура возвращает `500 Internal Server Error`; PostgreSQL wire protocol для БД; файловое чтение YAML-миграций из `/service/migrations/`; `stdout`/`stderr` для логов. TLS, публичный REST, WebSocket, Kafka, Redis и S3 не являются активными протоколами сервиса.
Хранилища	Единственное постоянное прикладное состояние должно храниться в `svr-translations-store-postgres`: `type` хранит поддерживаемые типы (`MODEL`, `CATEGORY`, `ZONE`), `language` - коды и названия языков, `translation_object` - текущие переводы с уникальностью по `(type_id, language_id, name)` и уникальным `full_name`, `translation_history` - снимки старых переводов, `migration` - применённые YAML-файлы, `aerich` - метаданные миграций. В app-контейнере в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/translations-store/translations` -> `/uploads`, но код читает `/service/migrations/`, а не `/uploads/`. При текущем некорректном значении `POSTGRES_HOST` миграции приложения не создают прикладную схему в БД `dnn`; до исправления hostname ожидаемые таблицы `public` отсутствуют.
Конфигурация	Основные env: `DEBUG`, `PORT`, `TZ`, `SETTINGS_FILE`, `DEPENDS`; PostgreSQL `POSTGRES_DATABASE`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`; dormant-настройки `KAFKA_HOST`, `EXTENDED_KAFKA_HOST`, `KAFKA_GROUP`, служебная `RUN_SERVER_FOR_TESTS`. В конфигурации продуктового контура заданы `DEBUG=false`, `SETTINGS_FILE=config.settings.production`, `DEPENDS=["svr-translations-store-postgres:5432"]` и некорректное значение `POSTGRES_HOST` без последней буквы в alias; значения параметров доступа не документируются. При `DEBUG=true` entrypoint уходит в длительный sleep вместо запуска миграций и сервера.
Логирование	Приложение настраивает Loguru в `stdout`, uvicorn пишет access/error logs в `stdout`/`stderr`; Docker log driver в конфигурации продуктового контура - `loki`. В логах видны старт контейнера, ожидание зависимостей, результат Aerich, `Migrating yaml files`, отсутствие `/service/migrations`, старт uvicorn, DNS-ошибки PostgreSQL и ошибки ASGI при обращении к `/metrics`. Отдельного файлового audit-журнала или Kafka audit-topic у сервиса не предусмотрено.
Мониторинг	Docker healthcheck отсутствует (`Health=none`), host-порт не опубликован. Контрольная проверка в конфигурации продуктового контура: app и postgres контейнеры `Up 2 days`, restart count `0`, `svr-translations-store-postgres` возвращает `pg_isready ... accepting connections`, но `GET /metrics` внутри app-контейнера возвращает `500`. Практические проверки: состояние контейнеров app/postgres, корректность `POSTGRES_HOST`, успешность `aerich upgrade`, наличие прикладных таблиц в PostgreSQL, безопасные read-only gRPC-вызовы после восстановления БД и отсутствие ошибок DNS/ASGI в Loki.
Критичность	Средняя для уже работающего видеоконтура, высокая для пользовательского control-plane переводов. Отказ сервиса не должен останавливать текущие inference-процессы и видеопотоки, но блокирует чтение и сопровождение переводов моделей, категорий и зон в custom-domain UI/gateway BOX5-DIT-MGSN, YAML import/export и историю изменений переводов.
Эксплуатационные особенности и известные ограничения	В compose задан некорректный `POSTGRES_HOST` без последней буквы в alias, из-за чего DB-backed RPC и Aerich-миграции зависят от исправления hostname или дополнительного alias; в конфигурации продуктового контура это проявляется отсутствием прикладных таблиц в БД и DNS-ошибками в логах. `/metrics` зарегистрирован, но текущий handler вызывает отсутствующий `GetPrometheusMetrics` и возвращает `500`, поэтому его нельзя использовать как SLO-сигнал. Нет Docker healthcheck, host-порта, auth/TLS на самом сервисе, OpenAPI REST, активной Kafka-интеграции, Redis, MinIO/S3 и ClickHouse. Логический каталог ограничен `model`, `category`, `zone`; `ImportTranslations` создаёт отсутствующие типы, но не создаёт отсутствующие языки; `FlushDb` является destructive maintenance helper. В gateway helper удаления перевода ошибочно вызывает `DeleteObjectType` вместо `DeleteTranslation`, поэтому REST-клиентский слой нужно сверять с серверным gRPC-контрактом перед эксплуатацией delete-сценариев.

`svr-translations-store-postgres`¶

Поле	Описание
Название сервиса	`svr-translations-store-postgres` (`docker.vizorlabs.ru/vizorlabs/postgres:13.1`, общий репозиторий образа `docker-images/postgres`). В конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-translations-store-postgres-1`; exposed port `5432/tcp`, host-порт не опубликован.
Назначение	PostgreSQL-sidecar для `svr-translations-store`: хранит реляционный каталог переводов для интерфейса BOX5-DIT-MGSN - типы переводимых объектов, языки, текущие локализованные названия, историю изменений и служебные таблицы миграций. Бизнес-логика, gRPC API и YAML import/export находятся в app-сервисе; sidecar отвечает только за PostgreSQL-хранилище.
Подсистема	Compose-домен `severstal`, control-plane контур переводов пользовательского интерфейса. Единственный штатный владелец схемы и клиент - `svr-translations-store`; сервис не участвует в runtime-инференсе, обработке видеопотока, Kafka-flow и хранении файловых артефактов.
Основные функции	Принимает SQL-подключения на `5432`, создаёт БД/пользователя при первом старте через стандартный bootstrap PostgreSQL, хранит таблицы приложения в `PGDATA`, WAL и runtime-состояние сервера. Схему (`type`, `language`, `translation_object`, `translation_history`, `migration`, `aerich`) создаёт и обновляет `svr-translations-store` через Aerich; сам PostgreSQL-контейнер не выполняет прикладных миграций и не импортирует YAML-файлы.
Входящие вызовы	PostgreSQL wire protocol из внутренней сети `bx_default`. Заданы network aliases `svr-translations-store-postgres`, `severstal-svr-translations-store-postgres-1` и container-id alias; `pg_isready -U dnn -d dnn` внутри контейнера возвращает `accepting connections`. Штатный клиент должен обращаться к alias `svr-translations-store-postgres:5432`; в конфигурации продуктового контура `DEPENDS` у app-сервиса указывает верный alias, но фактический `POSTGRES_HOST` задан с опечаткой. Публичных HTTP, REST, gRPC, Kafka, Redis, MinIO/S3 или Prometheus-входов у sidecar нет.
Исходящие вызовы	Сервис-специфичных исходящих сетевых вызовов нет. PostgreSQL отвечает клиентским сессиям, пишет данные/WAL в `PGDATA`, а технологические сообщения - в `stdout`/`stderr`. Подключения к `ui-rest-to-gprc`, Kafka, MinIO, ClickHouse, Redis и внешним HTTP-сервисам относятся к другим контейнерам и не являются контрактом этого sidecar.
Протоколы	PostgreSQL wire protocol поверх TCP `5432`, Unix socket PostgreSQL внутри контейнера, файловый ввод-вывод PostgreSQL в `PGDATA`, `stdout`/`stderr` для логов. TLS, HTTP, gRPC, REST/OpenAPI, gRPC, Kafka, Redis, S3/MinIO, shared memory и Prometheus endpoint у sidecar отсутствуют.
Хранилища	Основное состояние - PostgreSQL `PGDATA=/var/lib/postgresql/data`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/severstal/pgdata-translations-store` -> `/var/lib/postgresql/data`. Рабочая БД - `dnn`, пользователь - `dnn`; пароль не документируется. Ожидаемые прикладные таблицы после успешных миграций: `type`, `language`, `translation_object`, `translation_history`, `migration`, `aerich`. При текущем некорректном app-side `POSTGRES_HOST` прикладная схема `public` не инициализируется; ожидаемые таблицы отсутствуют до исправления hostname и успешного запуска миграций. YAML-файлы импортов находятся в app-контейнере, а не в этом PostgreSQL-sidecar.
Конфигурация	Env-only конфигурация стандартного PostgreSQL-образа: `POSTGRES_DB=dnn`, `POSTGRES_USER=dnn`, параметр доступа `POSTGRES_PASSWORD`, `PGDATA=/var/lib/postgresql/data`, а также базовые переменные образа `PG_MAJOR`, `PG_VERSION`, `GOSU_VERSION`, `LANG`, `PATH`. В конфигурации продуктового контура заданы `RestartPolicy=always`, Docker log driver `loki`, сеть `bx_default`, `Ports={"5432/tcp":null}`, `Health=none`. Отдельных `postgresql.conf`, SQL bootstrap-скриптов и service-specific config-файлов в контракте sidecar не предусмотрено.
Логирование	PostgreSQL пишет технологические логи в `stdout`/`stderr`, которые в конфигурации продуктового контура собираются Docker log driver `loki`. В логах sidecar ожидаются сообщения старта PostgreSQL, прослушивания `0.0.0.0:5432`, Unix socket и готовности принимать подключения; ошибки Aerich, ORM, gRPC и YAML-импорта нужно смотреть в `svr-translations-store`, потому что миграциями и бизнес-операциями управляет app-сервис. Отдельного прикладного audit-журнала у sidecar нет.
Мониторинг	Собственного `/metrics`, HTTP health endpoint, публичного API и Docker healthcheck нет. Практический контроль: состояние контейнера `running`, образ `docker.vizorlabs.ru/vizorlabs/postgres:13.1`, `pg_isready -U dnn -d dnn` со статусом `accepting connections`, SQL-доступ к БД `dnn`, наличие ожидаемых таблиц после успешной миграции приложения, корректность app-side `POSTGRES_HOST`. Готовность sidecar сама по себе не означает готовность сервиса переводов: при текущем typo-hostname БД жива, но схема `public` пустая.
Критичность	Средняя для уже работающего видеоконтура и высокая для control-plane переводов. Отказ или потеря данных sidecar не должны останавливать текущие inference-потоки, но блокируют чтение/обновление переводов моделей, категорий и зон, историю изменений, YAML import/export и связанные REST/gRPC-сценарии через `ui-rest-to-gprc` и `svr-translations-store`.
Эксплуатационные особенности и известные ограничения	Generic PostgreSQL sidecar без публичного API, метрик, host-порта, Docker healthcheck в конфигурации продуктового контура, отдельного `pg_dump`/backup-sidecar и собственной бизнес-валидации. Схемой полностью управляет `svr-translations-store`; ручные SQL-изменения могут нарушить Aerich/Tortoise-контракт. В compose app-сервис использует некорректный `POSTGRES_HOST`, поэтому фактические DB-backed операции зависят от исправления hostname или добавления совместимого alias; в конфигурации продуктового контура это проявляется пустой схемой `public` при живом PostgreSQL. Сохранность `PGDATA` не покрывает app-side YAML-файлы и не заменяет резервное копирование каталога переводов.

`svr-security-notice`¶

Поле	Описание
Название сервиса	`svr-security-notice` (`docker.vizorlabs.ru/severstal/severstal-security-notice:dev`, репозиторий `severstal/severstal-security-notice`). В конфигурации продуктового контура сервис присутствует и запущен как контейнер `severstal-svr-security-notice-1` в compose-проекте `severstal`; внутренний порт `3000/tcp`, host-порт не опубликован.
Назначение	Технический audit-consumer BOX5-DIT-MGSN: читает общий Kafka-поток пользовательского аудита (`add_audit_record`) и формирует укороченное представление события в формате security notice. В текущем продуктовом контуре прикладной экспорт во внешний контур security notice не включён; сервис не обрабатывает события нарушений, не генерирует пользовательские уведомления и не является основным хранилищем audit history.
Подсистема	Compose-домен `severstal`, технический audit-consumer без применяемого внешнего audit-export контура. Источник сообщений - `ui-rest-to-gprc` и другие producer-ы audit topic; параллельный канонический потребитель и хранилище audit history - `st-audit`; брокер - `inf-kafka`. Локального PostgreSQL-sidecar, Redis, MinIO или ClickHouse у сервиса нет.
Основные функции	Запуск FastAPI/Uvicorn shell с документацией `/api/docs/` и служебным route `/severstal_security_notice/`; запуск Kafka consumer group `security_notice`; чтение protobuf `Audit` из topic `add_audit_record`; разбор полей `id`, `date`, `user`, `service`, `message`, `action`, `etc_json`, `ip_address`; формирование укороченной структуры security notice для технической обработки audit-сообщений. В текущей конфигурации сервис не отправляет данные во внешний export-контур.
Входящие вызовы	HTTP на `3000`: `GET /severstal_security_notice/` возвращает `{"success": true}` и используется как простая проверка доступности; `GET /api/docs/` отдаёт Swagger UI; `GET /openapi.json` описывает единственный business route `/severstal_security_notice/`. Основной рабочий вход - Kafka consumer из `inf-kafka:9092`, topic `add_audit_record`, group `security_notice`, protobuf payload `vzrpc.statistic.datatype.audit_pb2.Audit`. В конфигурации продуктового контура доступны `/severstal_security_notice/`, `/api/docs/`, `/openapi.json`; topic `add_audit_record` присутствует, consumer group имеет lag `0`.
Исходящие вызовы	Фактических прикладных исходящих сетевых вызовов в текущей конфигурации нет: сервис читает Kafka, отвечает на собственный HTTP route проверки и пишет технологические логи. Исходящих Kafka producer-ов, gRPC клиентов, SQL-подключений, Redis, S3/MinIO и ClickHouse-вызовов в текущей реализации продуктового контура нет.
Протоколы	Входящие HTTP/1.1 FastAPI на `3000`; Kafka protocol для чтения `add_audit_record`; файловый доступ к mounted `/service/keys` как к служебному каталогу контейнера; `stdout`/`stderr` для логов. Внутренний HTTP API сервиса без собственной auth/TLS-терминации и не опубликован на host-порт.
Хранилища	Собственного постоянного хранилища нет: сервис не имеет БД, Redis, MinIO bucket или local state volume. Audit history хранится в профильном контуре `st-audit`; `svr-security-notice` только потребляет сообщения и пишет результат обработки в runtime-логи. Единственный mount у app-контейнера - `/home/vizorlabs/CODE/box3/severstal/keys` -> `/service/keys`; значения ключей и параметров доступа не документируются.
Конфигурация	Основные env: `DEBUG`, `PORT`, `SETTINGS_FILE`, `DEPENDS`, `KAFKA_HOST`, `KAFKA_PORT`, `KAFKA_GROUP`, `KAFKA_AUTO_OFFSET_RESET`, `KAFKA_MAX_RECORDS`, `KAFKA_TOPIC_ADD_AUDIT_RECORD` и служебные параметры отключённого внешнего export-режима. В конфигурации продуктового контура заданы `DEBUG=false`, `SETTINGS_FILE=config.settings.production`, `DEPENDS=["inf-kafka:9092"]`, `KAFKA_HOST=inf-kafka`, `KAFKA_GROUP=security_notice`, `KAFKA_TOPIC_ADD_AUDIT_RECORD=add_audit_record`; внешний export-режим отключён. Чувствительная информация и внешние URL в документацию не выносятся.
Логирование	Приложение пишет Loguru-логи и uvicorn access/error logs в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver - `loki`. В логах фиксируются старт consumer-а, получение audit-записи, сериализованный audit payload и результат технической обработки сообщения. Отдельного файлового журнала и отдельного audit topic у самого сервиса нет; его логи могут содержать пользовательские идентификаторы, названия сервисов, камер/сценариев и текст audit-событий, поэтому при публикации диагностических фрагментов требуется редактирование чувствительных данных.
Мониторинг	Docker healthcheck отсутствует (`Health=none`), `RestartCount=0`, restart policy у контейнера не задана, host-порт не опубликован. Проверочные сигналы: контейнер `running`, `GET /severstal_security_notice/ -> 200`, `GET /openapi.json -> 200`, наличие consumer group `security_notice` на topic `add_audit_record`, lag consumer group и отсутствие ошибок Kafka в Loki. В конфигурации продуктового контура `GET /metrics` возвращает `404 Not Found`, поэтому Prometheus endpoint у сервиса отсутствует.
Критичность	Низкая для текущего продуктового контура: прикладной export-контур security notice не используется, а отказ сервиса не останавливает видео, инференс, UI и каноническое хранение аудита в `st-audit`. Если в будущем внешний audit-export контур будет включён отдельным требованием, критичность сервиса нужно пересмотреть.
Эксплуатационные особенности и известные ограничения	В конфигурации продуктового контура сервис запущен как технический Kafka consumer audit topic, но не является пользовательским API или основным audit-хранилищем. У сервиса нет собственного persistent storage, Docker healthcheck, `/metrics`, host-порта, inbound auth/TLS, retry/DLQ-хранилища поверх Kafka и пользовательского API кроме служебного route проверки. OpenAPI содержит только `/severstal_security_notice/`; вспомогательные операции export-режима не зарегистрированы как live API продуктового контура. Документ security notice заполняется частично: `dvc_vendor` и `dvc_product` пустые, `dvc_domain` и `dvc_org` имеют значение `unknown`, а `event_category` берётся из текста audit message.

`svr-postgres-pk-kot`¶

Поле	Описание
Название сервиса	`svr-postgres-pk-kot` - PostgreSQL-источник импортных справочников ПК-КОТ для BOX5-DIT-MGSN. В конфигурации продуктового контура развёрнут в compose-проекте `severstal` как контейнер `severstal-svr-postgres-pk-kot-1`, образ `docker.vizorlabs.ru/severstal/postgres-pk-kot:16.1`, внутренний порт `5432/tcp`, порт хоста не опубликован. Репозиторий образа - `severstal/postgres-pk-kot`.
Назначение	Предоставляет BOX5-DIT-MGSN локальную импортную копию клиентской БД ПК-КОТ: справочники нарушений, разделов, рисков, барьеров, базовых правил, производств, подразделений, камер и рабочих зон. Это не app-сервис, а специализированный PostgreSQL-контейнер с предзагруженным дампом; бизнес-логику чтения, нормализации и синхронизации выполняют потребители.
Подсистема	Compose-домен `severstal` (техническое имя customer-specific домена), интеграционный контур ПК-КОТ/ЦСВН BOX5-DIT-MGSN. База является внешним по отношению к Box-приложениям источником данных для `svr-severstal-integration` и `svr-severstal-org-sync`; локальное состояние этих сервисов хранится в их собственных PostgreSQL-sidecar и описывается отдельно.
Основные функции	Поднимает PostgreSQL с БД `default` и схемами ПК-КОТ; хранит предзагруженный клиентский дамп в постоянном `PGDATA`; отдаёт Box-потребителям таблицы `ViolationKinds`, `ViolationKindSections`, `Risk_Dangers`, `TechnicalBarriers`, `BehavioralBarriers`, `RiskDangers_TechnicalBarriers`, `BasicRules`, `BasicRules_RiskDangers`, `Risk_WorkAreas`, `Cameras`, `BusinessUnits`, `Departments`, `RiskWorkAreas_Cameras` для чтения; обеспечивает низкоуровневую проверку готовности через `pg_isready`. Собственных HTTP/gRPC/Kafka API, миграций Box-схемы и фоновых прикладных задач нет.
Входящие вызовы	PostgreSQL/TCP `5432` только из внутренней Docker-сети. Клиенты по конфигурации контура: `svr-severstal-integration` с `POSTGRES_PK_KOT_HOST=svr-postgres-pk-kot`, `POSTGRES_PK_KOT_DATABASE=default`, `POSTGRES_PK_KOT_USER=postgres` и зависимостью `svr-postgres-pk-kot:5432`; `svr-severstal-org-sync` с тем же host/database/user и зависимостью `svr-postgres-pk-kot:5432`. Диагностические подключения только для чтения возможны через `docker exec`/psql внутри контейнерной сети. Публичного API, опубликованного порта хоста, HTTP endpoint готовности и `/metrics` нет.
Исходящие вызовы	Сервис-специфичных исходящих сетевых вызовов нет: контейнер только принимает PostgreSQL-соединения, пишет табличные файлы и WAL в `PGDATA`, а технологические сообщения - в `stdout`/`stderr`. Он не обращается напрямую к `svr-severstal-integration`, `svr-severstal-org-sync`, `st-camera-storage`, Kafka, ClickHouse, Redis, MinIO/S3, ЦСВН или внешнему ПК-КОТ API.
Протоколы	PostgreSQL wire protocol на `5432/tcp` во внутренней Docker-сети; Docker healthcheck `CMD-SHELL pg_isready -U postgres` с интервалом 5 секунд, timeout 5 секунд и 5 retries; файловый доступ PostgreSQL к `PGDATA`; `stdout`/`stderr` для логов. HTTP, gRPC, REST, WebSocket, Kafka, Redis, ClickHouse-native, S3 и TLS endpoint самим контейнером не экспонируются.
Хранилища	Основное хранилище - PostgreSQL `PGDATA=/var/lib/postgresql/data/pgdata`; в конфигурации продуктового контура задан bind mount `/data/compose-data2-no-swarm/severstal/pgdata-postgres-pk-kot` -> `/var/lib/postgresql/data`. В БД `default` присутствуют схемы `public` и `ss_kot`, расширения `plpgsql` и `postgres_fdw`, в `public` - 774 таблицы. В составе дампа ожидаются контрактные таблицы `ViolationKindSections`, `ViolationKinds`, `Risk_Dangers`, `Risk_WorkAreas`, `Cameras`, `BusinessUnits`, `Departments`, `RiskWorkAreas_Cameras`; объёмы строк являются данными конкретного загруженного дампа и в документе не фиксируются. Также присутствуют `TechnicalBarriers`, `BehavioralBarriers`, `RiskDangers_TechnicalBarriers`, `BasicRules`, `BasicRules_RiskDangers`.
Конфигурация	В конфигурации продуктового контура заданы `POSTGRES_DB=default`, `POSTGRES_USER=postgres`, `PGDATA=/var/lib/postgresql/data/pgdata`, образ `docker.vizorlabs.ru/severstal/postgres-pk-kot:16.1`, compose workdir `/home/vizorlabs/CODE/box3/severstal` и compose service `svr-postgres-pk-kot`. Параметры доступа, включая пароль PostgreSQL, в документации не раскрываются.
Логирование	Логи генерирует стандартный PostgreSQL entrypoint/server в `stdout`/`stderr`; Docker log driver в конфигурации продуктового контура - `loki` с локальной ротацией. Отдельного прикладного audit-журнала, файловых бизнес-логов, Kafka log-topic или структурированного API-логирования нет. Для диагностики проверяются Docker logs контейнера, healthcheck output и PostgreSQL-состояние; содержимое таблиц ПК-КОТ в логи сервиса штатно не выводится.
Мониторинг	В конфигурации продуктового контура контейнер `running`, `restart=0`, `Health=healthy`, `pg_isready -U postgres -d default` возвращает готовность принимать подключения; `docker port` не показывает опубликованных портов. Собственного Prometheus `/metrics` и HTTP endpoint готовности нет. Практический контроль: состояние контейнера и healthcheck, `pg_isready`, SQL-подключение к БД `default`, наличие схем `public`/`ss_kot`, наличие контрактных таблиц и совпадение клиентских переменных `POSTGRES_PK_KOT_*` у `svr-severstal-integration` и `svr-severstal-org-sync`. Healthcheck показывает доступность PostgreSQL, но не оценивает актуальность импортного дампа ПК-КОТ и бизнес-синхронизацию в потребителях.
Критичность	Высокая для интеграционного контура BOX5-DIT-MGSN: при недоступности БД `svr-severstal-integration` перестаёт обновлять ПК-КОТ справочники, рабочие зоны и набор для `st-event-storage`, а `svr-severstal-org-sync` не может разрешать подразделения, камеры и связи рабочих зон. Это приводит к устареванию валидации прикладных событий BOX5-DIT-MGSN, деградации ПК-КОТ статусов/данных и остановке применения camera/object topology из ЦСВН. На базовый видеопоток и инференс BOX5-DIT-MGSN база напрямую не влияет, но ломает клиентские workflow вокруг ПК-КОТ и ЦСВН.
Эксплуатационные особенности и известные ограничения	Это статичная импортная БД, а не управляемый app-сервис: актуальность данных зависит от процедуры обновления дампа или `PGDATA`, в образе нет полноценной Box-миграции, публичного API, `/metrics`, порта хоста и отдельного backup-sidecar для этой БД. PostgreSQL healthcheck не гарантирует полноту и актуальность справочников. Потребители читают общий набор ПК-КОТ таблиц напрямую, поэтому изменение схемы/имен таблиц в дампе или ручные SQL-правки могут сломать парсеры `svr-severstal-integration` и `svr-severstal-org-sync`. Восстановление пустого volume требует отдельного restore-процесса из дампа; простого запуска контейнера недостаточно, если `PGDATA` не предзагружен.

`kafka-domain`¶

Назначение: основная событийная шина решения.

`inf-kafka`¶

Поле	Описание
Название сервиса	`inf-kafka`
Назначение	Основной брокер Apache Kafka для событийной шины BOX5-DIT-MGSN. Принимает сообщения от сервисов инференса, статистики, интеграций, синхронизации, UI gateway и сервисов integration/NRI, хранит их в топиках и отдаёт потребителям по consumer groups. Не реализует прикладной REST/gRPC API и не владеет схемами сообщений: схемы принадлежат сервисам-производителям и сервисам-потребителям.
Подсистема	Compose-домен `kafka-domain`, функционально — общая событийная шина решения. В конфигурации продуктового контура это основной Kafka-брокер, отдельный от `svr-asutp-kafka` и `node-red-sandbox-kafka`.
Основные функции	Kafka broker и KRaft controller в одном контейнере; bootstrap для producers, consumers и admin-клиентов; хранение topic logs, offsets consumer groups и метаданных кластера; доставка системных событий камер, объектов, моделей, событий нарушений, мониторинга, audit/websocket-уведомлений и BOX5-DIT-MGSN/NRI launch/status-потоков; поддержка крупных сообщений до `15728640` байт для медиа/инференс-сценариев.
Входящие вызовы	Kafka protocol на `inf-kafka:9092` из внутренней Docker-сети `bx_default`. Клиенты продуктового контура — сервисы статистики (`st-auth`, `st-access`, `st-camera-storage`, `st-event-storage`, отчётные сервисы), инференса (`inf-monitoring`, NRI/Node-RED inference consumers), интеграции `svr-*` и `ui-rest-to-gprc`. KRaft controller listener `inf-kafka:9093` используется внутренним single-node quorum `1@inf-kafka:9093`. Host-порт в конфигурации продуктового контура не опубликован.
Исходящие вызовы	Прикладных исходящих HTTP, gRPC, PostgreSQL, Redis, MinIO или внешних Kafka-вызовов нет. Брокер отвечает клиентам Kafka в рамках открытых TCP-соединений, ведёт KRaft controller traffic внутри собственного single-node кластера и пишет данные в локальный Kafka data directory.
Протоколы	Kafka protocol over TCP `9092`, KRaft controller protocol over TCP `9093`, локальный файловый ввод-вывод в `/bitnami/kafka`, `stdout`/`stderr` для технологических логов. На текущем контуре слушатели plaintext: `PLAINTEXT://inf-kafka:9092` и `CONTROLLER://:9093`; TLS/SASL, REST, gRPC, SQL и Prometheus endpoint у брокера не предусмотрены.
Хранилища	Kafka data directory `/bitnami/kafka`, смонтированный из `/data/compose-data2-no-swarm/kafka3.4/kafka-data`. В конфигурации продуктового контура этот каталог лежит на `tmpfs` размером `2G`. В каталоге хранятся логи топиков, offsets, consumer-group state и метаданные KRaft. Внешняя БД, Redis и S3 не используются.
Конфигурация	Образ `docker.vizorlabs.ru/docker-images/kafka:3.4`, `restart: always`, сеть `bx_default`, alias `inf-kafka`. Kafka настроена переменными окружения: `KAFKA_ENABLE_KRAFT=yes`, `KAFKA_CFG_NODE_ID=1`, `KAFKA_CFG_PROCESS_ROLES=broker,controller`, `KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093`, `KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://inf-kafka:9092`, `KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@inf-kafka:9093`, `ALLOW_PLAINTEXT_LISTENER=yes`, `KAFKA_CFG_MESSAGE_MAX_BYTES=15728640`, `KAFKA_CFG_MAX_REQUEST_SIZE=15728640`, `KAFKA_CFG_MAX_PARTITION_FETCH_BYTES=15728640`. В конфигурации продуктового контура также заданы `KAFKA_CFG_LOG_CLEANER_ENABLE=true`, `KAFKA_CFG_LOG_RETENTION_POLICY=delete`, `KAFKA_CFG_LOG_RETENTION_HOURS=24`, `KAFKA_CFG_LOG_RETENTION_BYTES=203718400`.
Логирование	Kafka пишет системные логи broker/controller startup, network, group coordination, topic/partition operations и ошибки клиентов в `stdout`/`stderr`; Docker log driver в конфигурации продуктового контура — `loki`. Отдельного прикладного audit-журнала у брокера нет: audit-события передаются через Kafka topic `add_audit_record`, но их формируют и потребляют другие сервисы.
Мониторинг	Docker healthcheck у контейнера не задан (`Health=none`), хотя в образе присутствует `/usr/bin/kafka-health-check`. Практический контроль: контейнер `kafka-domain-inf-kafka-1` в состоянии `running`, `RestartCount=0`, `kafka-broker-api-versions.sh --bootstrap-server inf-kafka:9092` отвечает, `kafka-topics.sh --list` возвращает топики, `kafka-consumer-groups.sh --list` возвращает consumer groups. Среди используемых topic families — `camera_`, `statistic_camera_`, `statistic_cmd_camera_`, `models_storage_ready`, `detection_event_update`, `make_defect_event`, `finish_defect_event`, `change_launch_status`, `continue_launch`, `ws_launch_progress`, `websocket_`, `add_audit_record`.
Критичность	Высокая. Отказ `inf-kafka` нарушает асинхронную доставку событий между инференсом, статистикой, UI gateway, отчётами, синхронизацией, мониторингом и integration/NRI flow: producers не могут публиковать сообщения, consumers не получают обновления, replay/rebuild состояния из топиков останавливается. Уже сохранённые данные в PostgreSQL/MinIO остаются у владельцев, но downstream-процессы могут перейти в устаревшее состояние до восстановления брокера и повторной доставки.
Эксплуатационные особенности и известные ограничения	Single-node KRaft broker без ZooKeeper, репликации и отказоустойчивого quorum; у топика `detection_event_update` `ReplicationFactor=1`. Доступ plaintext без TLS/SASL внутри Docker-сети, host-порт не опубликован. Хранилище в конфигурации продуктового контура ограничено `tmpfs` `2G`, а retention дополнительно ограничен `24h` и `203718400` байтами, поэтому при всплеске сообщений возможны быстрые удаления старых данных или заполнение data directory. Брокер не валидирует payload schemas и не заменяет проверки владельцев топиков.

`data-storage`¶

Назначение: общее временное файловое и объектное хранилище решения.

`ds-data-temporary-storage`¶

Поле	Описание
Название сервиса	`ds-data-temporary-storage`, application-сервис временного хранения бинарных данных (`data-temporary-storage`).
Назначение	Короткоживущее объектное хранилище для передачи изображений, видеофрагментов и других бинарных вложений между сервисами BOX5-DIT-MGSN. Сервис принимает bytes и `content_type`, возвращает UUID и позволяет downstream-клиентам получить данные по этому UUID, пока не истёк TTL в Redis.
Подсистема	`data-storage`, общий контур временного файлового и объектного хранения. Работает как прикладной фасад над отдельным Redis sidecar `ds-data-temporary-storage-redis`; долговременным хранилищем не является.
Основные функции	gRPC `SetData`: валидация непустых `content` и `content_type`, генерация UUID, запись контента и MIME-типа во временное хранилище с TTL. gRPC `GetData`: чтение контента и MIME-типа по UUID, возврат `not_found` после истечения TTL или потери ключа. Служебная выдача Prometheus-метрик через `GET /metrics`. ASGI/gRPC-обёртка допускает размер входящего сообщения до `1 GiB`, но это не отменяет практические лимиты Redis, памяти и сети.
Входящие вызовы	HTTP/gRPC на `3000`, service path `/grpc/box.data_storage.data_temporary_storage.DataTemporaryStorage/<Method>`. Методы: `SetData(Data {content, content_type}) -> DataInfo {uuid}`, `GetData(DataInfo {uuid}) -> Data {content, content_type}`. `GET /metrics` отдаёт Prometheus text exposition. Известные клиенты продуктового контура: `inf-mediaserver`, `inf-image-storage`, `inf-load-balancer`, `st-event-storage`, `inf-report-video-extractor`, `svr-severstal-integration`.
Исходящие вызовы	Только Redis RESP/TCP к `REDIS_HOST:6379`. При `SetData` сервис пишет пару ключей `<uuid>-content` и `<uuid>-content_type` с `ex=DATA_LIFE_TIME`; при `GetData` читает ту же пару ключей. Чтение не продлевает TTL. Исходящих Kafka, PostgreSQL, ClickHouse, MinIO/S3, GPU, filesystem-mount или внешних HTTP-вызовов в runtime-пути нет.
Протоколы	Входящий HTTP/1.1 + gRPC/protobuf JSON/binary encoding; Prometheus text exposition на `/metrics`; Redis protocol к sidecar; stdout/stderr для логов через Docker log driver. Прямой browser-facing REST, WebSocket, gRPC over HTTP/2, S3/MinIO API, Kafka и TLS/auth на самом приложении не используются.
Хранилища	Собственной БД и постоянных mounts у app-контейнера нет. Временные данные хранятся в Redis sidecar как два ключа на объект: bytes в `<uuid>-content` и MIME type в `<uuid>-content_type`; оба ключа имеют одинаковый TTL `DATA_LIFE_TIME`. В конфигурации продуктового контура у app-контейнера mounts отсутствуют, а Redis sidecar держит `/data` в Docker volume; описание sidecar вынесено в отдельную секцию `ds-data-temporary-storage-redis`. Финальная долговременная запись медиа выполняется другими сервисами, например `st-event-storage` в `ds-minio`.
Конфигурация	Env-only сервис: `PORT`, `SETTINGS_FILE`, `DEBUG`, `DEPENDS`, `REDIS_HOST`, `DATA_LIFE_TIME`. В конфигурации продуктового контура заданы image tag `1.0.5`, `SETTINGS_FILE=config.settings.production`, `DEBUG=false`, `DEPENDS=["ds-data-temporary-storage-redis:6379"]`, `REDIS_HOST=ds-data-temporary-storage-redis`, `DATA_LIFE_TIME=900`, `restart=always`, Docker log driver `loki`, host-port `3003 -> 3000`. Переменных с чувствительной информацией у app-сервиса в конфигурации окружения не предусмотрено. При `DEBUG=true` entrypoint не запускает сервер, а уходит в длительный sleep для ручной отладки.
Логирование	Приложение использует Loguru в `stdout`, uvicorn пишет server/access/error output в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver — `loki`. Ошибки `SetData`/`GetData` логируются как технические сообщения, отдельного audit-журнала, файлового лога и Kafka audit-topic у сервиса нет. Штатный код не логирует полный payload, но логи и диагностические ответы всё равно не должны публиковаться без проверки содержимого.
Мониторинг	`GET /metrics` на `:3000` возвращает `200 text/plain`; в конфигурации продуктового контура заданы метрики `request_count_total`, `request_traffic_total`, `response_traffic_total`, `request_duration`, `request_error_total`, `cpu_usage`, `memory_usage`, `uptime`. Docker healthcheck отсутствует (`Health=none`), `GET /health` не реализован и возвращает gRPC `bad_route`. Практический контроль: контейнер app и Redis `running`, `/metrics` отвечает, `GetData` с заведомо отсутствующим UUID возвращает gRPC `not_found`, Redis sidecar отвечает `PONG`, логи проверяются на повторяющиеся ошибки подключения к Redis.
Критичность	Высокая для media hand-off между inference/statistics/integration сервисами: при отказе `SetData` новые события, кадры, офлайн-видео, evidence и интеграционные вложения не смогут корректно передать бинарные данные downstream-сервисам. Уже сохранённые в MinIO/PostgreSQL/ClickHouse события и основная работа сервисов без temporary-storage payload могут продолжать обслуживаться, но новые медиа-вложения деградируют или теряются.
Эксплуатационные особенности и известные ограничения	Хранилище временное: в конфигурации продуктового контура TTL составляет `900` секунд, чтение TTL не продлевает, Redis restart/eviction/expiry безвозвратно делает UUID недоступным. Нет репликации, долговременной persistence на уровне app-сервиса, transactional hand-off, streaming/range API, multipart upload, auth/TLS, `/health` и Docker healthcheck. Пустые `content` или `content_type` отклоняются как internal gRPC-ошибка. Большие payload до теоретического лимита `1 GiB` проходят через память приложения и Redis, поэтому могут упираться в RAM, network и лимиты Redis; для долговременного хранения сервис должен использоваться только как промежуточная ступень перед `st-event-storage`/`ds-minio` или другим постоянным хранилищем.

`ds-data-temporary-storage-redis`¶

Поле	Описание
Название сервиса	`ds-data-temporary-storage-redis`. Redis 6 sidecar сервиса `ds-data-temporary-storage`; в конфигурации продуктового контура развёрнут в compose-проекте `data-storage` как контейнер `data-storage-ds-data-temporary-storage-redis-1` с образом `docker.vizorlabs.ru/docker-images/redis-6:master`. Слушает только внутренний Docker-порт `6379/tcp`, host-порт не опубликован.
Назначение	Runtime-хранилище временных бинарных объектов для `ds-data-temporary-storage`: хранит raw bytes и MIME type по UUID до истечения Redis TTL или потери данных контейнера. Самостоятельной бизнес-функции, пользовательского API и логики долговременного хранения не выполняет.
Подсистема	`data-storage`, общий контур временного файлового и объектного хранения. Работает как технический Redis-бэкенд только для app-сервиса `ds-data-temporary-storage`; gRPC-контракт `SetData`/`GetData` описан у app-сервиса, а не у sidecar.
Основные функции	Принимает Redis-команды от `ds-data-temporary-storage`; хранит в DB `0` пару ключей на объект: `<uuid>-content` с бинарным содержимым и `<uuid>-content_type` с MIME type. Оба ключа записываются app-сервисом с `EX=DATA_LIFE_TIME` и автоматически удаляются Redis после истечения TTL. Чтение ключей не продлевает срок жизни, отдельного delete/stream/queue-контракта в текущей конфигурации не предусмотрено.
Входящие вызовы	Redis RESP/TCP на `6379` из внутренней Docker-сети `bx_default`. Контрактный клиент - `ds-data-temporary-storage`, который в конфигурации продуктового контура запускается с `REDIS_HOST=ds-data-temporary-storage-redis` и `DEPENDS=["ds-data-temporary-storage-redis:6379"]`. Операционный контроль выполняется через `redis-cli PING`, `DBSIZE` и `INFO keyspace` внутри контейнера. HTTP/gRPC, REST, Kafka и пользовательских входящих бизнес-вызовов у sidecar нет.
Исходящие вызовы	Сервис-специфичных исходящих HTTP, gRPC, Kafka, PostgreSQL, ClickHouse, MinIO/S3 или внешних Redis-вызовов нет. Контейнер отвечает клиентам по входящему Redis-соединению и пишет локальное состояние Redis в `/data`.
Протоколы	Redis RESP поверх TCP `6379`; файловый ввод-вывод Redis в `/data`; stdout/stderr для технологических логов контейнера. TLS, Redis ACL/password auth, Pub/Sub, Redis Streams, HTTP/gRPC, Prometheus endpoint и Docker healthcheck как внешний контракт в конфигурации продуктового контура не предусмотрены.
Хранилища	Redis DB `0` является единственным runtime-хранилищем временных объектов app-сервиса. В конфигурации продуктового контура присутствует, что все ключи в keyspace имеют TTL (`INFO keyspace` показывал `db0:keys=1115,expires=1115`); значения ключей не читались. Каталог `/data` смонтирован как anonymous Docker volume, custom bind mount или named volume в compose не задан. AOF выключен (`appendonly no`), действует стандартная RDB-политика `save 3600 1 300 100 60 10000`; из-за TTL-семантики и disposable-volume модели это не долговременное хранилище.
Конфигурация	Compose задаёт образ `docker.vizorlabs.ru/docker-images/redis-6:master`, `restart: always`, label `vizorlabs_container_name=ds-data-temporary-storage-redis` и подключение к сети `bx_default` с alias `ds-data-temporary-storage-redis`. Service-specific env overrides, custom `redis.conf`, command override и healthcheck у Redis-контейнера не предусмотрены; видимые переменные окружения относятся к базовому Redis-образу. Тег `master` закреплён в deployment-конфигурации для конфигурации продуктового контура; TTL задаётся не здесь, а в app-сервисе через `DATA_LIFE_TIME=900`.
Логирование	Штатные логи Redis пишутся в stdout/stderr и в конфигурации продуктового контура собираются Docker log driver `loki`. Redis-sidecar не знает бизнес-контекст UUID, камер или событий, поэтому ошибки `SetData`/`GetData`, истечения TTL и недоступности Redis нужно коррелировать с логами app-сервиса `ds-data-temporary-storage` и downstream-клиентов. Отдельного audit-журнала и файлового log-volume у sidecar нет.
Мониторинг	Собственного HTTP endpoint, Prometheus-метрик и Docker healthcheck нет (`Health=none`, `RestartPolicy=always`). Базовые проверки: контейнер `Up`, `redis-cli PING` возвращает `PONG`, `DBSIZE`/`INFO keyspace` показывают ожидаемые TTL-ключи, а `ds-data-temporary-storage` успешно отвечает на свои `/metrics` и gRPC read/write пути. Рост key count, memory usage и повторяющиеся ошибки подключения должны проверяться через Redis `INFO`, Docker/Loki-логи и метрики app-сервиса.
Критичность	Высокая для временного media hand-off: при отказе Redis app-сервис `ds-data-temporary-storage` не может надёжно выполнять `SetData`/`GetData`, поэтому новые кадры, изображения событий, offline-video/evidence вложения и интеграционные медиа могут не дойти до downstream-сервисов. Уже перенесённые в долговременные хранилища данные не зависят от этого Redis, но все UUID-ссылки на временные объекты становятся недоступны после expiry, eviction или потери volume.
Эксплуатационные особенности и известные ограничения	Это generic Redis sidecar без собственной бизнес-логики, публичного API, auth/TLS/ACL, репликации, кластеризации, immutable release tag, healthcheck и выделенных метрик. Хранение временное: в конфигурации продуктового контура TTL задаётся app-сервисом как `900` секунд, чтение TTL не продлевает, а restart/eviction/удаление anonymous volume может безвозвратно удалить ещё не считанные объекты. Redis принимает payload целиком в память и на диск `/data`, поэтому большие бинарные объекты ограничены RAM, network и лимитами Redis; сервис нельзя использовать как архив, очередь или источник истины вместо `st-event-storage`/`ds-minio` и других постоянных хранилищ.

`ds-minio`¶

Поле	Описание
Название сервиса	`ds-minio`, MinIO object storage в compose-проекте `data-storage`. В конфигурации продуктового контура контейнер `data-storage-ds-minio-1` запущен из образа `docker.vizorlabs.ru/minio:RELEASE.2022-10-24T18-35-07Z`.
Назначение	Общее S3-совместимое объектное хранилище BOX5-DIT-MGSN для долговременных бинарных данных: медиа событий, файлов сценариев, артефактов моделей, материалов запусков, asset-файлов и вспомогательных загрузок. Сам сервис не содержит бизнес-логики Box: он предоставляет MinIO API, persistent storage и служебные health/metrics endpoints.
Подсистема	`data-storage`, домен `data`. Работает рядом с `ds-data-temporary-storage` и `ds-domain-gateway`; gateway публикует объектные URL под `/api/s3/`, а прикладные сервисы ходят в MinIO напрямую по `ds-minio:9000` или через gateway URL.
Основные функции	Приём, чтение, удаление и листинг объектов через S3-compatible API; хранение bucket-ов, которые инициализируют прикладные сервисы; выдача объектных URL через связку `MINIO_PREFIX` + bucket; служебные unauthenticated health checks MinIO. В конфигурации продуктового контура в каталоге данных есть bucket-и `asset-storage`, `event-storage`, `launch-storage`, `models-registry`, `scenario-storage`; также могут присутствовать bucket-и для running-сервисов, которые создаются по мере появления данных, например `camera-storage`, `rest-to-grpc` и MLflow buckets.
Входящие вызовы	HTTP/S3 API на `9000/tcp`: прямые внутренние клиенты используют `MINIO_ENDPOINT=ds-minio:9000`, внешний объектный путь `/api/s3/<bucket>/<object>` проксируется `ds-domain-gateway` на `ds-minio:9000/<bucket>/<object>`. Известные клиенты продуктового контура: `st-event-storage`, `st-camera-storage`, `st-report-email`, `st-report-pdf-xlsx-generator`, `svr-asset-storage`, `svr-launch-storage`, `svr-models-registry`, `svr-scenario-storage`, `nr-sbx-backend`, `inf-flows-manager`. Health endpoints на том же порту: `/minio/health/live`, `/minio/health/ready`, `/minio/health/cluster`, `/minio/health/cluster/read`.
Исходящие вызовы	Основной исходящий ресурс — файловая запись и чтение persistent mount `/data1`. Box-internal HTTP/gRPC/Kafka/PostgreSQL/Redis исходящих зависимостей у самого MinIO нет. Upstream MinIO может иметь собственные служебные механизмы обновления/metrics/console, но в текущем compose они не используются как контракт BOX5-DIT-MGSN.
Протоколы	HTTP/1.1 S3-compatible API на `9000/tcp`; unauthenticated HTTP health endpoints; MinIO Prometheus metrics endpoints `/minio/v2/metrics/cluster` и `/minio/v2/metrics/node`, которые в конфигурации продуктового контура без авторизации возвращают `403`; stdout/stderr через Docker log driver `loki`. TLS на самом `ds-minio` не включён, внешний HTTPS при необходимости завершается на edge/gateway-уровне. Отдельный gRPC, Kafka, SQL и Redis protocol не используются.
Хранилища	Основные данные: bind mount `/data/compose-data2-no-swarm/data-storage/minio_data:/data1:rw` в конфигурации продуктового контура. Дополнительно образ объявляет Docker volume `/data`, но текущий запуск пишет рабочие bucket-и в `/data1`. Внутри `/data1` есть служебный каталог `.minio.sys` и bucket directories; в конфигурации продуктового контура диск `/data` занят на 89%, поэтому свободное место является операционным риском. Репликации или распределённого erasure set в текущем запуске нет: команда `server /data1` поднимает single-node single-drive MinIO.
Конфигурация	Compose-конфигурация задаёт image tag, host-port `9000 -> 9000`, command `server /data1`, label `vizorlabs_container_name=ds-minio` и volume `${COMPOSE_DATA}/data-storage/minio_data:/data1:rw`. В конфигурации продуктового контура заданы env-переменные по именам без значений: `MINIO_ACCESS_KEY`, `MINIO_SECRET_KEY`, `MINIO_ACCESS_KEY_FILE`, `MINIO_SECRET_KEY_FILE`, `MINIO_ROOT_USER_FILE`, `MINIO_ROOT_PASSWORD_FILE`, `MINIO_CONFIG_ENV_FILE`, `MINIO_KMS_SECRET_KEY_FILE`, `MINIO_UPDATE_MINISIGN_PUBKEY`, `PATH`, `container`. Значения ключей доступа относятся к параметрам доступа и в документации не приводятся. `MINIO_CONSOLE_ADDRESS` не задан, `docker inspect` показывает только exposed port `9000/tcp`; отдельная консоль MinIO в текущем deployment-контракте не опубликована.
Логирование	MinIO пишет startup/runtime/error output в stdout/stderr контейнера; в конфигурации продуктового контура Docker log driver — `loki`. Файлового log-volume и отдельного audit-сервиса у `ds-minio` нет. Диагностика выполняется через Docker logs/Loki, но логи и env нельзя публиковать без редактирования, потому что они могут содержать имена bucket-ов, object keys, access-контекст или чувствительные URL.
Мониторинг	Контрольная проверка в конфигурации продуктового контура: контейнер `running`, Docker healthcheck отсутствует (`Health=none`), `/minio/health/live`, `/ready`, `/cluster`, `/cluster/read` на `127.0.0.1:9000` возвращают `200`, `/api/s3/` через gateway возвращает S3 XML `403` без учётных данных. Metrics endpoints MinIO существуют, но без авторизации возвращают `403`; явных ссылок на `ds-minio` в конфигурациях Prometheus не предусмотрено. Практический мониторинг должен включать статус контейнера, health endpoints, ошибки в Loki, рост bucket-ов и свободное место на `/data`.
Критичность	Высокая. При отказе `ds-minio` сервисы могут продолжать читать часть уже сохранённых metadata из PostgreSQL/ClickHouse/Kafka, но новые и существующие бинарные вложения становятся недоступны: медиа событий, документы, сценарии, модели, launch artifacts, asset-файлы, карты и отчётные вложения не записываются или не читаются. Деградация MinIO быстро проявляется как ошибки в `st-event-storage`, интеграционных сервисах, scenario/model registry и UI-ссылках `/api/s3/...`.
Эксплуатационные особенности и известные ограничения	Текущий deployment — single-node single-drive без MinIO replication/erasure coding, отдельного backup-контракта, lifecycle/versioning политики и Docker healthcheck. Host-port `9000` опубликован напрямую, поэтому доступ должен ограничиваться сетевым контуром и учётными данными MinIO; отдельные учётные данные и RBAC в compose не выделены, используется общая пара учётных данных MinIO. Bucket-и создаются прикладными сервисами по мере старта/использования, поэтому отсутствие bucket directory не всегда означает ошибку. Metrics требуют отдельной авторизации/настройки scrape. Нехватка места на `/data` и потеря bind mount приводят к отказам всех клиентов объектного хранения.

`ds-domain-gateway`¶

Поле	Описание
Название сервиса	`ds-domain-gateway` (`data-storage/ds-domain-gateway`). В конфигурации продуктового контура развёрнут как контейнер `data-storage-ds-domain-gateway-1` с образом `docker.vizorlabs.ru/docker-images/nginx-1.18:master`; это generic Nginx-контейнер со смонтированной конфигурацией домена data-storage.
Назначение	Тонкий Nginx-шлюз для объектных URL домена data-storage. Публикует внутренний HTTP-префикс `/api/s3/` на listener `:8000` и проксирует запросы в MinIO `ds-minio:9000`, удаляя префикс `/api/s3/`. Прикладным app-gateway, gRPC/REST API или фасадом над `ds-data-temporary-storage` не является.
Подсистема	`data-storage`, контур доступа к S3-compatible объектному хранилищу. Работает рядом с `ds-minio` и отдельным временным хранилищем `ds-data-temporary-storage`, но в текущем маршрутизаторе взаимодействует только с `ds-minio`.
Основные функции	HTTP reverse proxy для `location /api/s3/`; преобразование `/api/s3/<bucket>/<object>` в запрос к `http://ds-minio:9000/<bucket>/<object>`; передача `X-Forwarded-For` и `Host`; отключение `proxy_redirect`; приём крупных запросов до `client_max_body_size 500M`; Nginx access/error логирование. Другие активные `location` в конфиге отсутствуют.
Входящие вызовы	Внутренний HTTP на `:8000` от контейнеров общей сети Box, которые обращаются к `http://ds-domain-gateway:8000/api/s3/...`. В конфигурации продуктового контура host-порты не опубликованы (`Ports={"80/tcp":null}`), Docker image экспонирует `80/tcp`, но фактический Nginx-конфиг слушает `8000`. Запросы вне `/api/s3/` не обслуживаются бизнес-роутами.
Исходящие вызовы	Единственный активный upstream - HTTP к `ds-minio:9000` для всех запросов под `/api/s3/`. Прямых вызовов к `ds-data-temporary-storage`, Redis, PostgreSQL, ClickHouse, Kafka, gRPC, `ui-rest-to-gprc` или внешним сервисам в текущем исходном и live-конфиге нет.
Протоколы	HTTP/1.x reverse proxy; S3-compatible HTTP upstream MinIO; чтение Nginx-конфига из файловой системы контейнера; `stdout`/`stderr` для логов через Docker log driver. TLS, авторизация, gRPC, WebSocket, Kafka, PostgreSQL, Redis и Prometheus exposition сервисом не используются.
Хранилища	Собственного persistent storage нет. Контейнер читает только `/etc/nginx/conf.d/default.conf`, смонтированный из `/home/vizorlabs/CODE/box3/data-storage/configs/nginx.conf`; объектные данные находятся в `ds-minio` и не принадлежат `ds-domain-gateway`. БД, Redis, Kafka state, локальные media volume и каталоги временных данных не подключены.
Конфигурация	Источник истины - `box3/box3-data-storage`: compose-сервис `ds-domain-gateway` с `restart: always`, внешней сетью `${NETWORK_NAME}`, Docker config `ds_nginx_config` для swarm-режима и bind mount `./configs/nginx.conf:/etc/nginx/conf.d/default.conf` для non-swarm. Собственных runtime env-переменных для маршрутов не задаётся; в конфигурации продуктового контура заданы только унаследованные от образа `NGINX_VERSION=1.18.0`, `NJS_VERSION=0.4.4`, `PKG_RELEASE=2~buster`, `PATH`. Рабочие параметры маршрута заданы в Nginx: `listen 8000`, `client_max_body_size 500M`, `fastcgi_read_timeout 300`, `proxy_read_timeout 300`, `proxy_pass http://ds-minio:9000/`.
Логирование	Nginx пишет `access.log` в `/dev/stdout` и `error.log` в `/dev/stderr`; в конфигурации продуктового контура Docker log driver - `loki`, поэтому записи доступны через Docker logs и централизованный сбор логов. Логи содержат HTTP-метод, путь, код ответа и ошибки upstream; объектные URL, bucket/object key и query-параметры нельзя публиковать без редактирования. Отдельного audit-журнала у сервиса нет.
Мониторинг	Docker healthcheck не задан (`Health=null`), `/metrics`, `/health` и `stub_status` не настроены. Read-only проверки в конфигурации продуктового контура: контейнер `running`, `nginx -t` успешен, `GET /api/s3/` через внутренний IP возвращает upstream-ответ MinIO `403 application/xml`, а `GET /`, `/metrics`, `/health` возвращают `404 text/html`. Практический мониторинг - состояние контейнера, доступность `ds-minio:9000`, HTTP-коды `/api/s3/...` и ошибки Nginx в Loki/docker logs.
Критичность	Средняя. Отказ сервиса ломает только те объектные ссылки и операции с S3-объектами, которые идут через `ds-domain-gateway`; сам `ds-minio`, `ds-data-temporary-storage` и сервисы с прямым доступом к MinIO продолжают работать. Для клиентов, завязанных на `http://ds-domain-gateway:8000/api/s3/...`, недоступность шлюза проявляется как потеря доступа к изображениям, документам, видеофрагментам и другим объектам data-storage.
Эксплуатационные особенности и известные ограничения	Активный маршрутный набор минимален: только `/api/s3/ -> ds-minio:9000`, без проксирования к `ds-data-temporary-storage` и без API-роутов домена. Нет собственной авторизации, TLS, rate limiting, healthcheck, метрик, `stub_status` и проверки готовности MinIO перед стартом; контейнер может быть `running`, пока `/api/s3/` уже отдаёт ошибки upstream. Фактический контракт задаёт смонтированный `nginx.conf`, поэтому тег generic Nginx-образа и `ExposedPorts=80/tcp` не описывают реальный listener и маршруты. Префикс `/api/s3/` удаляется при proxy_pass, что важно учитывать при формировании object URL.

`elk-log`¶

Назначение: сбор, хранение и выдача метрик и логов продуктового контура.

`log-prometheus`¶

Поле	Описание
Название сервиса	`log-prometheus`. Сервер Prometheus домена `elk-log`; в конфигурации продуктового контура развёрнут как контейнер `elk-log-log-prometheus-1` с образом `docker.vizorlabs.ru/box-inference/inf-prometheus:master`. Слушает HTTP `9090/tcp` только во внутренней Docker-сети `bx_default`, host-порт не опубликован.
Назначение	Сбор, хранение и выдача метрик решения BOX5-DIT-MGSN. Сервис скрапит `/metrics` у инфраструктурных и прикладных targets, пишет временные ряды в локальную Prometheus TSDB и отдаёт HTTP UI/API. Это компонент наблюдаемости, а не пользовательский бизнес-API и не часть видеопотока.
Подсистема	Compose-домен `elk-log`, контур наблюдаемости. Источники метрик находятся в основном в домене `inference`, включая `inf-pushgateway`; значимый для продуктового контура контракт - Prometheus API и локальная TSDB.
Основные функции	Читает mounted `prometheus.yml`; выполняет HTTP scrape targets по `static_configs` каждые 15 секунд; ведёт состояние targets и метрику `up`; сохраняет WAL, head и block-данные TSDB; предоставляет Prometheus UI, query API, status/config API и endpoint reload `POST /-/reload`, включённый флагом `--web.enable-lifecycle`. Alert rules и Alertmanager в конфигурации продуктового контура не настроены.
Входящие вызовы	HTTP `9090/tcp` из внутренней Docker-сети: операционные проверки используют `GET /-/ready`, `GET /-/healthy`, `GET /api/v1/query`, `GET /api/v1/targets`, `GET /api/v1/status/config`, `GET /api/v1/status/runtimeinfo` и `GET /metrics`. Внешнего маршрута через host-порт, TLS и встроенной аутентификации у контейнера не предусмотрено.
Исходящие вызовы	Периодические HTTP `GET /metrics` к configured scrape targets. В конфигурации продуктового контура активные targets, входящие в состав продуктового контура, включают `inf-load-balancer:3000`, `inf-image-storage:3000`, `inf-monitoring:3000` и `inf-pushgateway:80`. Kafka, SQL, Redis, gRPC, S3/MinIO и внешние HTTP API сервис не вызывает.
Протоколы	HTTP API Prometheus на `9090/tcp`; Prometheus text exposition format при scrape и на собственном `/metrics`; PromQL поверх HTTP API; Docker DNS/static target resolution; файловый ввод-вывод TSDB; stdout/stderr для логов контейнера. TLS, mTLS, Basic Auth, Kafka, PostgreSQL, Redis, ClickHouse, gRPC и WebSocket в конфигурации продуктового контура отсутствуют.
Хранилища	Основное хранилище - локальная Prometheus TSDB. Compose монтирует `/data/compose-data2-no-swarm/elk-log/prometheus` в `/prometheus`; рабочий каталог контейнера - `/prometheus`, флаг `storage.tsdb.path` имеет значение по умолчанию `data/`, поэтому фактические WAL и blocks лежат в `/prometheus/data`. Внешних БД, object storage и remote_write хранилищ нет.
Конфигурация	Compose задаёт образ `docker.vizorlabs.ru/box-inference/inf-prometheus:master`, `restart: always`, label `vizorlabs_container_name=inf-prometheus`, bind mounts TSDB и `/etc/prometheus/prometheus.yml`, команду `--web.enable-lifecycle --config.file=/etc/prometheus/prometheus.yml`. Env-переменных, `depends_on`, опубликованных портов и Docker healthcheck нет. Mounted config задаёт `scrape_interval: 15s`, `evaluation_interval: 15s` и перечисленные static scrape jobs. Для конфигурации продуктового контура закреплён тег `master` с pinning `2026-04-13`.
Логирование	Prometheus пишет технологические сообщения в stdout/stderr; Docker log driver контейнера в конфигурации продуктового контура - `loki`. В последних логах видны регулярные TSDB-операции: запись blocks, compaction, Head GC и WAL checkpoint. Логи не являются хранилищем метрик и не содержат пользовательских событий; диагностика метрик выполняется через Prometheus API.
Мониторинг	В конфигурации продуктового контура `Health=none`; readiness/liveness проверяются через `GET /-/ready` и `GET /-/healthy`, состояние scrape targets - через Prometheus query/API, а наличие правил и активных предупреждений - через `/api/v1/rules` и `/api/v1/alerts`. Практический контроль: контейнер `running`, конфигурация загружена без ошибок, scrape targets продуктового контура имеют ожидаемый статус `up`.
Критичность	Средняя для бизнес-функций и высокая для эксплуатации. Отказ `log-prometheus` не останавливает камеры, инференс, Kafka или пользовательские API, но теряет оперативную видимость `up`, latency/error/resource метрик и создаёт разрыв в локальной истории TSDB на время недоступности. Из-за отсутствия alert rules/Alertmanager сервис сам не выполняет активное оповещение.
Эксплуатационные особенности и известные ограничения	Single-node Prometheus без HA-пары, федерации и remote_write; история хранится локально на одном bind mount и ограничена retention `15d` без size limit. Scrape service discovery статический: отсутствующие или переименованные контейнеры могут оставаться в конфиге как `down` до ручного изменения `prometheus.yml` и reload/restart; в реестре фиксируются только targets, соответствующие составу продуктового контура. Нет встроенной аутентификации/TLS, Docker healthcheck, Alertmanager/rule files и immutable release tag: используется `master`, а доступ защищён только внутренней Docker-сетью.

`log-loki`¶

Поле	Описание
Название сервиса	`log-loki`. В конфигурации продуктового контура развёрнут как контейнер `elk-log-log-loki-1` с образом Loki `2.7.0`; HTTP API опубликован на host-порту `3100/tcp`.
Назначение	Локальное хранилище логов стека `elk-log` на базе Loki. Принимает потоки логов от Docker Loki logging driver, хранит их на файловой системе контура и отдаёт LogQL/label/query API для эксплуатационных проверок.
Подсистема	`elk-log`, домен `observability`. Работает рядом с `log-prometheus`; значимый для продуктового контура контракт - хранение и выдача логов через Loki API, а Prometheus может снимать метрики самого Loki через `/metrics`.
Основные функции	Приём батчей логов через `POST /loki/api/v1/push`; индексация потоков по labels `compose_project`, `compose_service`, `container_name`, `filename`, `host`, `source`; выполнение instant/range LogQL-запросов и выдача labels/series; хранение WAL, BoltDB index и chunks; служебная диагностика процесса через `/ready`, `/metrics`, `/services`, `/config`, `/loki/api/v1/status/buildinfo`.
Входящие вызовы	Основной ingest-клиент в конфигурации продуктового контура — host Docker daemon с default `log-driver=loki`, отправляющий контейнерные логи в `http://172.17.0.1:3100/loki/api/v1/push`. Для ручной диагностики доступны HTTP endpoints Loki на `127.0.0.1:3100` и опубликованном host-порту `3100`. Compose `depends_on` не задаёт.
Исходящие вызовы	Прикладных сетевых исходящих вызовов не предусмотрено: сервис не обращается к Kafka, PostgreSQL, Redis, ClickHouse, MinIO/S3 или внешнему object storage. В single-binary конфигурации ring использует `kvstore.store: inmemory`, поэтому Consul/Etcd/memberlist как внешняя зависимость не используются. Основная исходящая активность — локальные записи в `/loki`.
Протоколы	HTTP API Loki на `3100/tcp`: ingest `POST /loki/api/v1/push`, query endpoints `/loki/api/v1/query`, `/query_range`, `/labels`, `/label/<name>/values`, `/series`, `/index/stats`, websocket tail `/loki/api/v1/tail`, health `/ready`, Prometheus text `/metrics`. Внутренние gRPC-компоненты Loki работают внутри single-binary процесса и не являются отдельным межсервисным контрактом Box.
Хранилища	Постоянное состояние хранится в bind mount `${COMPOSE_DATA}/elk-log/loki:/loki`; в конфигурации продуктового контура это `/data/compose-data2-no-swarm/elk-log/loki`. Текущий конфиг пишет WAL в `/loki/wal`, BoltDB index в `/loki/index`, chunks в `/loki/chunks`; внешняя БД и объектное хранилище не используются. Потеря каталога `/loki` означает потерю локальной истории логов.
Конфигурация	Compose-сервис `log-loki` запускает Loki `2.7.0` с командой `-config.file=/mnt/config/loki-config.yaml`, монтирует `elk-log/configs/loki/loki-config.yaml` в `/mnt/config/loki-config.yaml`, публикует `3100:3100`, `restart: always`, а для собственных логов контейнера задаёт `logging.driver: local`, чтобы не делать рекурсивный self-ingest в Loki. В YAML включены `auth_enabled: false`, `server.http_listen_port: 3100`, `ring.kvstore.store: inmemory`, `replication_factor: 1`, `schema_config.store: boltdb`, `object_store: filesystem`, `schema: v11`, `index.period: 72h`, `storage_config.filesystem.directory: /loki/chunks`, `limits_config.reject_old_samples: true`, `reject_old_samples_max_age: 72h`.
Логирование	Сам Loki пишет технологические логи в stdout/stderr контейнера; в конфигурации продуктового контура они показывают flush потоков и checkpoint WAL в `/loki/wal/checkpoint.*`. Из-за `logging.driver: local` логи самого `log-loki` не отправляются обратно в Loki через Docker driver, а остальные контейнеры контура при default `log-driver=loki` отправляют свои stdout/stderr в `POST /loki/api/v1/push`.
Мониторинг	Проверки живости: контейнер `elk-log-log-loki-1` в состоянии `Up`, `GET /ready` возвращает `ready`, `GET /loki/api/v1/status/buildinfo` показывает версию `2.7.0`, `GET /services` показывает running-компоненты `server`, `distributor`, `ingester`, `querier`, `store`, `query-frontend`. `/metrics` отдаёт Prometheus-метрики, включая `loki_build_info` и счётчики `loki_request_duration_seconds_count` для `POST /loki/api/v1/push`, query endpoints и `/ready`.
Критичность	Средняя для выполнения видеоаналитики и высокая для эксплуатации. Отказ `log-loki` не останавливает инференс, UI, Kafka или базы данных, но ломает централизованное хранение и поиск контейнерных логов, усложняет разбор инцидентов и может создавать ошибки/ретраи у Docker Loki driver при доставке логов.
Эксплуатационные особенности и известные ограничения	Развёртывание single-node/single-binary без репликации и внешнего object storage; `auth_enabled: false` требует сетевой изоляции опубликованного `3100/tcp`; retention как удаление старых данных явно не настроен, а `reject_old_samples_max_age: 72h` только отклоняет слишком старые входящие записи. История ограничена ёмкостью и сохранностью локального `/loki`; при проблемах с правами на bind mount Loki не сможет создать `/loki/chunks` и уйдёт в restart loop. Query API может возвращать ограничения/ошибки при тяжёлых range-запросах, поэтому прямой поиск по Loki API зависит от объёма локальных chunks и текущей нагрузки.

`node-red-sandbox`¶

Назначение: среда разработки, запуска и отладки Node-RED/NRI сценариев до их переноса в продуктовый контур.

`nr-sbx-backend`¶

Поле	Описание
Название сервиса	`nr-sbx-backend` (`backend` в compose-проекте `node-red-sandbox`). FastAPI + Socket.IO backend репозитория `node-red-integration/node-red-sandbox`, путь `services/backend`; в конфигурации продуктового контура развёрнут как контейнер `node-red-sandbox-backend-1` с образом `docker.vizorlabs.ru/vizorlabs/node-red-sandbox-backend:v1.19.2`. Слушает `5000/tcp` только во внутренних Docker-сетях, host-порт не опубликован; внешний доступ идёт через `nr-sbx-nginx` по `/sandbox/backend/` и `/sandbox/socket.io/`.
Назначение	Control-plane Node-RED sandbox: создаёт и ведёт пользовательские и launch-сессии, принимает медиа/JSON-файлы, управляет per-session Node-RED-редакторами, запускает sandbox-инференс через Celery, отдаёт логи/кадры/результаты и связывает sandbox-запуски с Box-сервисами хранения. Сам сервис не выполняет NRI-инференс и не конвертирует модели: вычисления выполняют `nr-sbx-celery`/`nr-sbx-nri` и conversion sidecar-ы.
Подсистема	Домен `node-red-sandbox` решения BOX5-DIT-MGSN. Контейнер включён одновременно в сети `node-red-sandbox` и `bx_default`, поэтому обслуживает изолированную sandbox-среду (`nr-sbx-frontend`, `nr-sbx-node-red-vl`, `nr-sbx-celery`, `nr-sbx-redis`, `nr-sbx-kafka`) и обращается к основному контуру Box (`svr-scenario-storage`, `svr-asset-storage`, `svr-launch-storage`, `inf-flows-manager`, `ds-minio`, `inf-kafka`).
Основные функции	Создание/закрытие сессии; старт launch-сессии по запросу `svr-launch-storage`; загрузка медиа, LabelMe zones, camera params и JSON-артефактов; привязка media/params из MinIO asset storage; запуск и остановка Celery-задачи `tasks.process_session`; получение списка групп/flow, создание flow и проксирование файлов `node-red-vl-configs`; запуск/остановка per-session Node-RED instance через manager `nr-sbx-node-red-vl`; скачивание `flows.json` версии сценария из `svr-scenario-storage`; публикация изменённого сценария обратно в storage; синхронизация зон/моделей из Box; выдача session log, video visualization, frame count, frame image, frame log и frame message; загрузка launch-артефактов в MinIO и публикация статусов launch в Kafka.
Входящие вызовы	HTTP/REST на `5000/tcp`: `/api/hello`, `/api/docs/`, `/openapi.json`, `/api/create_session`, `/api/start_launch_session/`, `/api/close_session`, `/api/get_groups_and_flows`, `/api/create_flow`, `/api/node-red-config/file/{path}`, `/api/node-red-config/upload/file/{path}`, `/api/upload_media_file`, `/api/upload_labelme_zones`, `/api/upload_json_file/`, `/api/set_media_file_from_asset`, `/api/set_params_from_asset`, `/api/inference`, `/api/stop_inference`, `/api/get_log`, `/api/get_video_vis`, `/api/get_frame_count`, `/api/get_frame`, `/api/get_frame_log`, `/api/get_frame_message`, `/api/update_zones_and_models_from_box`, `/api/post_scenarios`, `/api/assets/items/`, `/api/assets/asset_versions/`, `/api/push-scenario/`. Socket.IO на пути `/sandbox/socket.io/`: события `connect` и `join_session`, серверные события `task_progress`/`task_error`. Kafka-входы: локальный `processings_status_topic` от `nr-sbx-celery`; Box topic `continue_launch` от `svr-launch-storage`; при `USING_KAFKA_MODELS_CONSUMERS=True` также `model_version_updated`, `model_version_deleted`, `model_version_ready`. В конфигурации продуктового контура заданы HTTP `200` для `/api/hello`, `/api/docs/`, `/openapi.json`, локальные topics `processings_status_topic`/`processings_control_topic` и Box topics `continue_launch`, `change_launch_status`, `model_version_*`.
Исходящие вызовы	Redis `nr-sbx-redis` для `session:<id>` и `next_session_id`; Celery dispatch через Redis broker/result backend (`tasks.process_session`, `tasks.get_groups_and_flows`, `tasks.update_zones_and_models_from_box`, `tasks.push_flow_parameters_to_box`, `tasks.create_scenario_for_model`, `tasks.model_version_*`, `tasks.delete_model_version`); HTTP к `nr-sbx-node-red-vl` на `1880` (`POST /flow`) и `5000` (`/api/start-instance/`, `/api/stop-instance/`, `/api/get-scenario-flows/`); HTTP к Box gateway `BOX_URL` для asset storage, lite scenario storage, scenario storage и flows-manager; Kafka produce в `change_launch_status` для `svr-launch-storage`; S3/MinIO операции с bucket `launch-storage` и `asset-storage`. Прямые вызовы в PostgreSQL, ClickHouse, gRPC или production `inf-nri-inference` в коде backend не предусмотрены.
Протоколы	HTTP/1.1 REST/FastAPI, Socket.IO поверх WebSocket/HTTP polling, Kafka protocol, Redis protocol, Celery поверх Redis, S3-compatible MinIO API, локальный файловый ввод-вывод в смонтированных volume. Внешний TLS завершается вне контейнера; собственных gRPC, PostgreSQL wire protocol, ClickHouse protocol и Prometheus exposition endpoint у сервиса нет.
Хранилища	Собственной SQL-БД нет. Операционное состояние хранится в Redis DB `0`: `session:<id>` с JSON-сессией и счётчик `next_session_id`; в Redis присутствуют session-ключи и `next_session_id`. Файлы сессий лежат в `/data/sessions/<session_name>/`, в конфигурации продуктового контура это bind-backed volume `node-red-sandbox-data` (`/data/sandbox-compose-data/node-red-sandbox-data`). Flow-файлы per-session пишутся в `/node-red-vl-data/sessions/<session_name>/flows.json`, общие configs читаются/пишутся в `/node-red-vl-configs`; оба volume также bind-backed под `/data/sandbox-compose-data/`. Launch-артефакты (`log.txt`, `events.json`, frame images/messages/logs) выгружаются в MinIO bucket `launch-storage`; asset-backed media/params читаются из `asset-storage`.
Конфигурация	Основные env-группы: `PORT`, `DEBUG`, `DATA_DIR`, `NODE_RED_DATA_DIR`, `NODE_RED_CONFIG_DATA`, `REACT_APP_SOCKET_IO_PATH`; Redis/Celery `REDIS_HOST`, `REDIS_PORT`, `SESSION_KEY_PREFIX`, `CELERY_BROKER_URL`, `CELERY_RESULT_BACKEND`, `CELERY_TIMEOUT_TASK`; локальный Kafka `KAFKA_HOST`, `KAFKA_PORT`, `KAFKA_STATUS_TOPIC`, `KAFKA_CONTROL_TOPIC`; Box gateway prefixes `BOX_URL`, `BOX__PREFIX`; Box Kafka `USING_KAFKA_CONSUMERS`, `USING_KAFKA_MODELS_CONSUMERS`, `BOX_KAFKA_HOST`, `BOX_KAFKA_PORT`, `BOX_KAFKA_GROUP`, `KAFKA_TOPIC_`; Node-RED `NODE_RED_HOST`, `NODE_RED_PORT`, `NODE_RED_USED_FASTAPI_MANAGER`, `NODE_RED_FAST_API_MANAGER_PORT`; MinIO `MINIO_ENDPOINT`, `MINIO_ACCESS_KEY`, `MINIO_SECRET_KEY`, `MINIO_SECURE`, `MINIO_CERT_CHECK`, `MINIO_BUCKET`, `MINIO_BUCKET_ASSET_STORAGE`. Значения параметров доступа не документируются. В конфигурации продуктового контура заданы `USING_KAFKA_CONSUMERS=True`, `USING_KAFKA_MODELS_CONSUMERS=True`, `NODE_RED_USED_FASTAPI_MANAGER=True`, `BOX_URL=<base-url>`, `MINIO_ENDPOINT=ds-minio:9000`, `RestartPolicy=always`, log driver `loki`, `Health=none`; для backend в конфигурации продуктового контура всё ещё закреплён тег `v1.19.0`, что отличается от живого образа `v1.19.2`.
Логирование	Приложение пишет `loguru`-логи и uvicorn access/error logs в `stdout`/`stderr`; Docker собирает их через log driver `loki`. В live-логах присутствуют access-записи FastAPI для `/api/hello`, `/api/docs/`, `/openapi.json`. В коде startup логирует объект настроек целиком, поэтому при эксплуатационном разборе сырые стартовые логи нужно просматривать с редактированием параметров доступа и не переносить значения `BOX_`, `MINIO_`, `_SECRET`, `_PASSWORD`, `*_TOKEN` в документацию. Отдельного файлового audit-журнала у backend не предусмотрено; бизнес-артефакты launch пишутся в MinIO, а не в логи.
Мониторинг	Docker healthcheck отсутствует, `/metrics` на live-контейнере возвращает `404`, а конфигурация Prometheus в конфигурации продуктового контура не содержит scrape-target для sandbox backend. Практические проверки: контейнер `node-red-sandbox-backend-1` в состоянии `running`; `/api/hello`, `/api/docs/`, `/openapi.json` отвечают `200`; контейнер подключён к сетям `node-red-sandbox` и `bx_default`; локальный Kafka содержит `processings_status_topic`, Box Kafka содержит `continue_launch`/`change_launch_status`; Redis доступен и содержит session state; логи backend доступны через Loki/Docker logs; смежный `nr-sbx-node-red-vl` имеет `healthy`, тогда как у backend собственного health-сигнала нет.
Критичность	Высокая для sandbox-разработки и проверочных launch-процессов: при отказе нельзя создать/закрыть сессию, открыть per-session Node-RED, запустить/остановить sandbox-инференс, увидеть прогресс, собрать launch-артефакты или вернуть статус в `svr-launch-storage`. Для уже работающего production-инференса критичность ниже: боевой NRI runtime напрямую от backend не зависит, но пользовательский контур подготовки, отладки и аудируемого запуска сценариев деградирует полностью.
Эксплуатационные особенности и известные ограничения	Нет собственного Docker healthcheck, `/metrics` и Prometheus scrape; готовность приходится проверять синтетическими HTTP/Kafka/Redis проверками. Сервис сильно связан с `nr-sbx-redis`, `nr-sbx-kafka`, `nr-sbx-celery`, `nr-sbx-node-red-vl`, `ds-minio` и Box gateway: отказ любой из этих зависимостей ломает часть сценария. Сессии не имеют SQL-хранилища и зависят от Redis и локальных volume; `close_session` удаляет каталог сессии и отзывает Celery task. `stop_inference` использует Celery revoke, а локальный `processings_control_topic` backend-кодом не используется. HTTP-клиенты в коде используют `verify=False`, CORS открыт на `*`, а startup-лог может содержать конфигурационный объект с чувствительными полями, поэтому сырые логи нельзя переносить в документацию. Deployment-пины могут отставать от контура по версии образа backend.

`nr-sbx-celery`¶

Поле	Описание
Название сервиса	`nr-sbx-celery` (`node-red-sandbox/celery`). В конфигурации продуктового контура развёрнут в compose-проекте `node-red-sandbox` как контейнер `node-red-sandbox-celery-1`; это не backend API, а отдельный GPU-enabled Celery worker для задач песочницы Node-RED/NRI.
Назначение	Асинхронное выполнение NRI-задач песочницы: запуск `LocalInference` по загруженным медиа и выбранному `flows.json`, синхронизация зон и моделей с подключённым Box-контуром, генерация шаблонных сценариев для моделей, выгрузка параметров flow и обработка событий жизненного цикла версий моделей.
Подсистема	`node-red-sandbox`, изолированный контур разработки и проверки NRI-сценариев. Работает за `nr-sbx-backend`, использует локальные `nr-sbx-redis` и `nr-sbx-kafka`, общий `nr-sbx-node-red-vl`, GPU/model cache и sandbox-конвертеры `nr-sbx-yolo-conversion`/`nr-sbx-mm-conversion`.
Основные функции	Исполняет Celery tasks `tasks.process_session`, `tasks.get_groups_and_flows`, `tasks.update_zones_and_models_from_box`, `tasks.push_flow_parameters_to_box`, `tasks.create_scenario_for_model`, `tasks.model_version_ready`, `tasks.model_version_updated`, `tasks.delete_model_version`; перед стартом worker в конфигурации продуктового контура запускает `python -m nri.integration.tools.sync_zones_from_box`; читает flow из `/node-red-vl-data`, запускает NRI `LocalInference`, пишет результаты и `log.txt` в сессионные каталоги `/data/sessions/...`, публикует прогресс и ошибки выполнения в sandbox Kafka.
Входящие вызовы	Основной вход — Celery-задачи от `nr-sbx-backend` через Redis broker `redis://redis:6379/0`. Для `process_session` также создаётся Kafka consumer group `process_session_<session_id>` на `processings_control_topic`, но в backend stop-поток останавливает задачу через Celery revoke, а не через Kafka control-сообщение. Дополнительный вход — общие файлы сессий и flow: `/data/sessions/...`, `/node-red-vl-data/flows.json`, `/node-red-vl-data/sessions/<session_name>/flows.json`. Публичного HTTP/gRPC API и host-портов у worker нет.
Исходящие вызовы	Публикует progress/error-сообщения в `nr-sbx-kafka` topic `processings_status_topic` через фиксированный bootstrap `kafka:9092`; обращается к Box gateway (`BOX_URL`) при синхронизации зон/моделей и работе NRI helper-ов; скачивает/проверяет модели через filesystem/VLFlow/MLflow/GitLab registry-настройки; вызывает sandbox-конвертеры моделей по Unix-socket HTTP endpoints `YOLO_CONVERSION_URI` и `MMLAB_CONVERSION_URI`; читает и обновляет файлы в `/node-red-vl-data` и `/models`. Прямые запросы к `nr-sbx-backend` как к API-сервису не являются основным контрактом worker.
Протоколы	Celery поверх Redis RESP/TCP; Kafka protocol для локальных топиков песочницы; HTTP/REST к Box gateway и registry/storage endpoint-ам; S3-compatible HTTP для MLflow/VLFlow/MinIO-backed артефактов при соответствующей конфигурации; HTTP поверх Unix domain sockets к model conversion helpers; файловый ввод-вывод в bind-mounted каталогах; Docker stdout/stderr и файловый `log.txt` внутри результатов сессии.
Хранилища	Собственной БД нет. В конфигурации продуктового контура смонтированы `/data`, `/models`, `/node-red-vl-data`, `/node-red-vl-configs`, `/tmp` и checkout `/opt/node-red-inference/nri`; Redis `db=0` хранит broker/result metadata Celery и session state, Kafka хранит короткоживущие progress/control topics, модели лежат в `/models` и внешних registry/artifact storage, результаты инференса — в `/data/sessions/<session_name>/results`.
Конфигурация	Compose-сервис `celery` из `/home/vizorlabs/CODE/node-red-sandbox`, `restart: always`, `runtime: nvidia`, сеть `node-red-sandbox`, host-порты не опубликованы, Docker healthcheck не задан. В конфигурации продуктового контура команда запуска: `python -m nri.integration.tools.sync_zones_from_box && celery -A tasks worker --loglevel=info --concurrency=2 --max-tasks-per-child=1`. Ключевые env-группы: `CELERY_BROKER_URL`/`CELERY_RESULT_BACKEND`, `MAX_WORKERS_COUNT`, `FLOWS_PATH`, `MODELS_PATH`/`MODEL_REGISTRIES_PRIORITY`, `MLFLOW_`, `VLFLOW_`, `AWS_`, `GITLAB_TOKEN`, `BOX_URL`/`BOX_LOGIN`/`BOX_PASSWORD`, `REACT_APP_NODE_RED_BACKEND_URL`, `YOLO_CONVERSION_URI`, `MMLAB_CONVERSION_URI`, `PROC_MOUNT_PATH`, `IS_USE_GPU`, `ZONE_STORAGE_WORK_MODE=sandbox`, `INCONSISTENCE_`, `ASUTP_METHOD`, `USE_TSM_INFERENCE_DOWNLOAD`, `DO_NOT_EXPORT_3D_BLOCKS`. Значения параметров доступа в документации не фиксируются.
Логирование	Celery/NRI/Loguru пишут основной runtime log в stdout/stderr контейнера; в конфигурации продуктового контура Docker log driver — `loki`. Для каждой inference-сессии task `process_session` инициализирует отдельный `log.txt` в каталоге результата, куда попадают сообщения выполнения flow, события и ошибки. В логах возможны URL, имена моделей, параметры сценариев и сведения о зонах, поэтому при публикации диагностических фрагментов требуется редактирование чувствительных данных.
Мониторинг	Отдельного `/health`/`/metrics` endpoint и Docker healthcheck у worker нет. Практическая проверка: контейнер `node-red-sandbox-celery-1` в состоянии `Up`, `RestartCount=0`, Redis отвечает `PONG`, в sandbox Kafka существуют topics `processings_status_topic` и `processings_control_topic`, Flower (`nr-sbx-flower`) может смотреть broker/worker state через `redis://redis:6379/0`, а backend получает progress из `processings_status_topic` и передаёт его в Socket.IO.
Критичность	Средняя для всего решения и высокая для песочницы Node-RED. Отказ worker не останавливает основной production-инференс `inf-nri-inference` и пользовательский UI BOX5-DIT-MGSN, но ломает запуск sandbox-сессий, синхронизацию зон/моделей из Box, генерацию сценариев по моделям и обработку model-version событий, из-за чего подготовка и проверка NRI-сценариев перед переносом в основной контур становится недоступной.
Эксплуатационные особенности и известные ограничения	Worker завязан на GPU runtime, общий `/tmp` для Unix-socket конвертеров, доступность `nr-sbx-redis`, `nr-sbx-kafka`, `nr-sbx-node-red-vl`, model registry/storage и корректный `BOX_URL`; при недоступности этих зависимостей задачи падают или зависают на синхронизации/конвертации/скачивании моделей. В коде Celery wrapper собственные Kafka produce/consume используют жёсткий `kafka:9092`, поэтому переменная `KAFKA_HOST` покрывает не все пути. `--max-tasks-per-child=1` снижает накопление GPU-памяти, но увеличивает стоимость частых задач. `processings_control_topic` предусмотрен, однако штатный backend stop сейчас использует Celery revoke. Redis `db=0` общий для Celery metadata и session state; отдельного durable queue, Prometheus-метрик и публичного healthcheck нет.

`nr-sbx-nri`¶

Поле	Описание
Название сервиса	`nr-sbx-nri` (`node-red-sandbox` / встроенный `node-red-inference`). В compose-проекте `node-red-sandbox` соответствует сервису `nri`; в конфигурации продуктового контура развёрнут как контейнер `node-red-sandbox-nri-1` с образом семейства `docker.vizorlabs.ru/vizorlabs/node-red-sandbox-celery`, то есть использует тот же runtime-слой, что и `nr-sbx-celery`, но другую команду запуска.
Назначение	Интерактивная sandbox-среда Node-RED Inference для инженерных пробных запусков: Jupyter Notebook с NRI-кодом, ноутбуками, `local_inference`, утилитами синхронизации Node-RED flows, скачивания и конвертации моделей. Не является production runtime: штатное выполнение сценариев камер в основном контуре выполняет `inf-nri-inference`, а пользовательские фоновые запуски sandbox обрабатывает `nr-sbx-celery`.
Подсистема	`node-red-sandbox`, изолированный контур разработки, проверки и отладки NRI-сценариев перед переносом в основные сервисы BOX5-DIT-MGSN. Работает рядом с `nr-sbx-backend`, `nr-sbx-frontend`, `nr-sbx-node-red-vl`, `nr-sbx-celery`, `nr-sbx-kafka`, `nr-sbx-redis`, `nr-sbx-mm-conversion`, `nr-sbx-yolo-conversion` и `nr-sbx-nginx`; для внешних Box-данных может обращаться к live gateway и сервисам хранения сценариев/моделей.
Основные функции	Открывает Jupyter Notebook в рабочем каталоге `/opt/node-red-inference`; позволяет запускать notebooks из NRI-пакета, локальный инференс по контрольным данным, экспорт NRI-нод и параметров в Node-RED, синхронизацию `flows.json`, массовое скачивание/конвертацию моделей и диагностические сценарии с зонами, assets и customer-specific данными. Используется как ручной runtime sandbox для проверки гипотез и подготовки flow/model artifacts, а не как очередь задач или постоянный сервис инференса.
Входящие вызовы	HTTP/WebSocket Jupyter Notebook на `8888/tcp`; в конфигурации продуктового контура опубликован как `18889->8888/tcp`. Доступ защищается токеном Jupyter из `NOTEBOOK_APP_TOKEN`; значение токена в документации не фиксируется. Специализированного REST/gRPC API для других сервисов нет. Основные пользователи - инженеры через браузер/Jupyter или внутренний nginx-маршрут sandbox; `nr-sbx-backend` штатно отправляет пользовательские задачи в `nr-sbx-celery`, а не в notebook-контейнер.
Исходящие вызовы	По команде пользователя/notebook выполняет HTTP-запросы к `REACT_APP_NODE_RED_BACKEND_URL` / `nr-sbx-node-red-vl` (`GET /flows`, `POST /flows`, `GET /update-custom-nodes`) и может переписывать общие Node-RED файлы. Для конвертации моделей обращается по Unix domain socket в `/tmp` к `nr-sbx-yolo-conversion` и `nr-sbx-mm-conversion` (`/start-process/`, `/status/{process_id}`). Для моделей использует `MODELS_PATH`, VLFlow/`svr-models-registry`, MLflow/S3/MinIO и артефакты из GitLab при наличии настроенных учётных данных. Для sandbox-диагностики может обращаться к Box API (`BOX_URL`) за зонами, сценариями и helper-операциями публикации; Kafka не является постоянным входящим контрактом сервиса, но notebook/local-inference код может использовать sandbox/Box Kafka-настройки при запуске соответствующих NRI-потоков.
Протоколы	HTTP/WebSocket Jupyter; HTTP/REST к Node-RED manager, Box API, registry/storage сервисам и MLflow; S3-compatible API для артефактов; Unix domain socket HTTP через `requests_unixsocket` для conversion helpers; файловый доступ к shared volumes; Docker stdout/stderr. В штатном контракте сервиса нет gRPC, собственного Kafka consumer, PostgreSQL/Redis client API, Prometheus endpoint или публичного API выдачи моделей.
Хранилища	Собственной БД нет. Подключены общие sandbox volumes: `/node-red-vl-data` для `flows.json`, `/node-red-vl-configs` для сгенерированных конфигураций custom-нод, `/models` для моделей и результатов конвертации, `/node-red-sandbox-data` для рабочих данных и временных запусков, `/opt/tests/nri-assets` для контрольных assets, `/tmp` для Unix-сокетов конвертеров. В конфигурации продуктового контура эти mounts используются; долговременным источником production-сценариев остаётся `svr-scenario-storage`, а не notebook-контейнер.
Конфигурация	Compose-сервис `nri` запускает Jupyter командой вида `jupyter notebook --ip 0.0.0.0 --port 8888 --no-browser --allow-root --NotebookApp.token=...`, рабочая директория - `/opt/node-red-inference`, Docker healthcheck не задан, в конфигурации продуктового контура Docker log driver - `loki`. Основные группы env: `NOTEBOOK_APP_TOKEN`, `REACT_APP_NODE_RED_BACKEND_URL`, `MODELS_PATH`, `TESTS_ASSETS_DIR`, `TESTS_WORK_DIR`, `SELECTED_MODELS_PATH`, `IS_EXTERNAL_TESTS`, `SKIP_TSM_INFERENCE_TESTS`, `IS_USE_GPU`, `PROC_MOUNT_PATH`, `YOLO_CONVERSION_URI`, `MMLAB_CONVERSION_URI`, `BOX_URL`/учётные данные Box, `MLFLOW_`, `AWS_`, `GITLAB_TOKEN`, customer-specific `INCONSISTENCE_`/`ASUTP_`. Значения параметров доступа не документируются.
Логирование	Jupyter и запускаемые из notebooks Python-процессы пишут stdout/stderr в Docker logs; в конфигурации продуктового контура логи отправляются через Docker Loki driver. При выполнении NRI-утилит в журнал попадают сообщения загрузки моделей, синхронизации Node-RED, конвертации и stack trace notebook-команд. Отдельного централизованного audit log для действий пользователя внутри Jupyter не предусмотрено.
Мониторинг	Docker health status отсутствует (`Health=none`), `/metrics` как контракт сервиса не заявлен. Практические проверки: контейнер `node-red-sandbox-nri-1` в состоянии `Up`, процесс `jupyter-notebook` жив, host-port `18889` отвечает Jupyter, доступны shared volumes `/models`, `/node-red-vl-data`, `/node-red-vl-configs` и `/tmp`, нет ошибок в Docker/Loki logs, conversion helper sockets доступны при запуске модельных операций. Для задач, которые уходят в `nr-sbx-celery`, наблюдение выполняется через `nr-sbx-flower`, backend Socket.IO и sandbox Kafka topics, но это не monitoring самого `nr-sbx-nri`.
Критичность	Низкая для production-видеоаналитики и средняя для разработки/сопровождения NRI. Отказ `nr-sbx-nri` не останавливает `inf-nri-inference`, камеры, основную Kafka-шину или пользовательские Celery-запуски sandbox, но лишает инженеров интерактивной проверки notebooks, ручной синхронизации flows/configs и подготовки моделей в isolated sandbox.
Эксплуатационные особенности и известные ограничения	Сервис предназначен только для разработки: результаты ручных notebook-действий нужно явно переносить в управляемые сценарии/хранилища, иначе они останутся локальными для sandbox volumes. Нет собственного healthcheck, Prometheus-метрик, RBAC/audit trail, REST API для автоматизации и изоляции от ошибок пользователя: notebook может переписать общий `flows.json` или `node-red-vl-configs`. Производительность и воспроизводимость зависят от GPU runtime, доступности `/models`, учётных данных MLflow/S3/GitLab, conversion helper sockets и согласованности shared mounts с `nr-sbx-celery`. Опубликованный Jupyter-порт требует сетевой изоляции и корректного токена; контейнер не должен рассматриваться как безопасный внешний интерфейс. Фактический image/tag в конфигурации продуктового контура может отличаться от закреплённого тега, поэтому перед расследованиями нужно сверять `docker ps`/compose.

`nr-sbx-frontend`¶

Поле	Описание
Название сервиса	`nr-sbx-frontend` (`node-red-integration/node-red-sandbox/services/frontend`), compose-сервис `frontend`. В конфигурации продуктового контура контейнер `node-red-sandbox-frontend-1` запущен из образа `docker.vizorlabs.ru/vizorlabs/node-red-sandbox-frontend:v1.19.2` и слушает только внутренний `3000/tcp`.
Назначение	Browser UI песочницы Node-RED/NRI для подготовки и проверки сценариев до переноса в основной контур BOX5-DIT-MGSN. Это не основной React UI решения: сервис обслуживает sandbox-интерфейс и static bundle, а пользовательский вход публикуется через `nr-sbx-nginx` под `/sandbox/`.
Подсистема	Домен `node-red-sandbox`, контур разработки и тестирования NRI-сценариев. Работает вместе с `nr-sbx-nginx`, `nr-sbx-backend`, `nr-sbx-node-red-vl`, `nr-sbx-redis`, `nr-sbx-kafka`, `nr-sbx-celery`, `nr-sbx-nri`, `nr-sbx-flower` и sandbox-конвертерами моделей.
Основные функции	Отдаёт React-приложение и static assets для `/sandbox/`; перед стартом приложения требует runtime-конфиг `/sandbox/config.json`; создаёт sandbox-сессию; открывает embedded Node-RED editor в iframe; загружает видео, зоны и параметры камер; выбирает asset/version из Box-каталога; запускает и останавливает sandbox-инференс; показывает прогресс, кадры, визуализацию, логи сессии, frame log и frame message; отправляет сценарий в backend для публикации и синхронизирует зоны/модели из Box.
Входящие вызовы	HTTP от `nr-sbx-nginx`: маршрут `/sandbox/` проксируется на `frontend:3000/sandbox/`, static bundle доступен, например, как `/sandbox/static/js/bundle.js`. В конфигурации продуктового контура `GET http://127.0.0.1:81/sandbox/`, `/sandbox/config.json` и `/sandbox/static/js/bundle.js` вернули `200`; прямой host-порт `3000` не опубликован. `/sandbox/config.json` отдаёт `nr-sbx-nginx` из файла `/etc/nginx/sandbox/config.json`, а не сам frontend-контейнер.
Исходящие вызовы	У контейнера нет server-to-server вызовов: он обслуживает browser app. После загрузки браузер по `FRONTEND_SETTINGS.BACKEND_URL` вызывает `nr-sbx-backend` через `/sandbox/backend/`: `create_session`, `close_session`, `upload_video`, `get_frame_count`, `get_frame`, `inference`, `stop_inference`, `set_video_from_asset`, `upload_json_file`, `set_params_from_asset`, `get_log`, `get_frame_log`, `get_frame_message`, `get_groups_and_flows`, `push-scenario`, `update_zones_and_models_from_box`, `assets/items`, `assets/asset_versions`, `get_video_vis`. Прогресс идёт через Socket.IO на `FRONTEND_SETTINGS.SOCKET_IO_BACKEND_URL` с путём `/sandbox/socket.io/`. Node-RED открывается в iframe по `FRONTEND_SETTINGS.NODE_RED_BACKEND_URL + node_red_url`, обычно через `/sandbox/node-red/<session_id>/`, который проксирует `nr-sbx-nginx` к `nr-sbx-node-red-vl`.
Протоколы	Входящий HTTP/1.1 от sandbox nginx к React dev server на `3000/tcp`; HTTP для загрузки HTML/JS/CSS/assets; browser HTTP/REST и multipart upload к backend; Socket.IO поверх WebSocket/polling для прогресса; iframe HTTP/WebSocket-трафик к Node-RED через nginx. gRPC, PostgreSQL, Redis, Kafka, S3/MinIO и Unix socket протоколы самим frontend-контейнером не используются.
Хранилища	Собственной БД и долговременных server-side хранилищ нет. В конфигурации продуктового контура у frontend-контейнера не предусмотрены bind/volume mounts; static bundle находится внутри образа. Runtime-конфиг хранится как deployment-local файл `/home/vizorlabs/CODE/node-red-sandbox/services/frontend/config.json` и монтируется в `nr-sbx-nginx`, а не во frontend. В браузере используются in-memory state и локальный флаг `localStorage.isProcessing`; состояние сессий, flow, файлов, задач и результатов находится в `nr-sbx-backend`, Redis, Node-RED volumes, MinIO/Box-сервисах и worker-компонентах.
Конфигурация	Compose задаёт `NODE_ENV=production`, `PUBLIC_URL=/sandbox`, `REACT_APP_FRONT_ROUTE=/sandbox`, `REACT_APP_BACKEND_URL`, `REACT_APP_NODE_RED_BACKEND_URL`, `REACT_APP_SOCKET_IO_BACKEND_URL`, `REACT_APP_SOCKET_IO_PATH`, `CHOKIDAR_USEPOLLING=true`. Фактический browser runtime берётся из `/sandbox/config.json`: `FRONT_ROUTE`, `BACKEND_URL`, `SOCKET_IO_BACKEND_URL`, `SOCKET_IO_PATH` при наличии, `NODE_RED_BACKEND_URL`, `FRAME_DISPLAY_FREQUENCY`. Если конфиг не загружен, приложение не стартует и показывает `Ошибка загрузки конфигурации`.
Логирование	Контейнер пишет stdout/stderr React dev server (`react-scripts start`) и сообщения сборки; в конфигурации продуктового контура Docker log driver для контейнера - `loki`, поэтому централизованное хранение идёт через Loki. В браузере есть console logs/errors для загрузки config, ошибок API, Socket.IO и iframe Node-RED; это не заменяет серверный audit trail. Отдельного структурированного application log у frontend нет.
Мониторинг	Docker healthcheck отсутствует. Практический контроль: контейнер `node-red-sandbox-frontend-1` в состоянии `running`, `restart=always`, подключён к сети `node-red-sandbox`, host-порт не опубликован; через `nr-sbx-nginx` возвращаются `200` для `/sandbox/`, `/sandbox/config.json` и JS bundle. Выделенного `/metrics` или `/health` нет: `/sandbox/metrics` и `/sandbox/health` в конфигурации продуктового контура возвращают SPA HTML и не являются проверкой здоровья сервиса.
Критичность	Высокая для пользовательской работы с sandbox: без frontend нельзя удобно создать сессию, открыть Node-RED editor, загрузить видео/ассеты, запустить проверку и посмотреть результаты. Для уже опубликованного production-инференса критичность низкая: отказ сервиса не должен останавливать основной видеопоток BOX5-DIT-MGSN, Kafka, NRI runtime или хранение боевых событий, но блокирует интерактивную подготовку и проверку новых сценариев через sandbox UI.
Эксплуатационные особенности и известные ограничения	Сервис не является основным UI BOX5-DIT-MGSN и зависит от `nr-sbx-nginx` для публичного маршрута `/sandbox/` и runtime-конфига. Образ запускает Create React App dev server (`npm start`/`react-scripts start`), а не отдельную production nginx-раздачу static build. Отсутствуют собственные healthcheck и Prometheus-метрики. UI жёстко зависит от корректного `/sandbox/config.json`; при ошибке файла, абсолютных URL или префикса `/sandbox` приложение не загружается. Доступность frontend не доказывает доступность `nr-sbx-backend`, Socket.IO, Node-RED manager или worker-контура: при их отказе страница может открыться, но сессии, iframe, запуск инференса и логи работать не будут.

`nr-sbx-node-red-vl`¶

Compose-сервис: node-red-vl.

Поле	Описание
Название сервиса	`nr-sbx-node-red-vl` (`node-red-vl` в compose-проекте `node-red-sandbox`). Репозиторий `node-red-integration/node-red-vl`; в конфигурации продуктового контура развёрнут контейнером `node-red-sandbox-node-red-vl-1` с образом `docker.vizorlabs.ru/vizorlabs/node-red-vl:v1.11.0`. Слушает внутренние порты `1880/tcp` (общий Node-RED editor/runtime) и `5000/tcp` (FastAPI manager); host-порт не опубликован, внешний доступ идёт через `nr-sbx-nginx` по `/sandbox/node-red/`.
Назначение	Node-RED VL editor/manager для sandbox-разработки NRI-сценариев: показывает общий редактор, хранит рабочий `flows.json`, загружает VizorLabs custom nodes из JSON-конфигов и поднимает изолированные per-session Node-RED-инстансы для пользовательских sandbox-сессий. Это не production `inf-nri-inference` и не боевой runtime видеопотока: сервис обслуживает подготовку, проверку и публикацию сценариев.
Подсистема	Домен `node-red-sandbox` решения BOX5-DIT-MGSN. Работает в сети `node-red-sandbox` под alias `node-red-vl` рядом с `nr-sbx-nginx`, `nr-sbx-frontend`, `nr-sbx-backend`, `nr-sbx-celery`, `nr-sbx-nri`, `nr-sbx-redis`, `nr-sbx-kafka` и sandbox-конвертерами. В отличие от `nr-sbx-backend`, контейнер не подключён к `bx_default`; связь с основным Box-контуром проходит через backend/celery и общие файлы/flow, а не через прямые REST-вызовы из `node-red-vl`.
Основные функции	Общий Node-RED editor на `1880`; чтение и замена `/data/flows.json`; создание flow tab через `POST /flow`; выдача списка nodes и helper-route-ов custom nodes (`/configs/list`, `/custom-node-template/...`, `/custom-node-script/...`, `/<node>/models`, `/<node>/versions`, `/<node>/params`); запуск и остановка per-session Node-RED-процессов через FastAPI manager; подготовка `/data/sessions/<session_name>/` с `flows.json`, `.config.nodes.json` и `settings.js`; проксирование HTTP/WebSocket-трафика браузера к per-session editor; запись в Redis назначенного порта, PID и `node_red_url`.
Входящие вызовы	Через `nr-sbx-nginx`: `/sandbox/node-red/` проксируется в общий Node-RED `:1880`, `/sandbox/node-red/api/` в manager `:5000`, `/sandbox/node-red/<session_id>/...` в manager proxy. От `nr-sbx-backend`: `POST /flow` на `1880`, `POST /api/start-instance/?session_id=...`, `POST /api/stop-instance/?session_id=...`, `GET /api/get-scenario-flows/?session_id=...` на `5000`. От браузера в iframe приходят editor HTTP/WebSocket-запросы. В конфигурации продуктового контура `200` возвращают `GET /`, `/flows`, `/nodes`, `/configs/list` на `1880` и `GET /api/hello`, `/api/docs/` на `5000`.
Исходящие вызовы	FastAPI manager читает и обновляет Redis `nr-sbx-redis` (`session:<id>`): `session_name`, metadata сценария, порт, PID и URL редактора. Он запускает локальные процессы `node-red -u /data/sessions/<session_name> --port <port>` и проксирует HTTP/WebSocket на `NODE_RED_HOST`/per-session port (`1881-1999` на allocator). Основной исходящий канал сервиса - файловый ввод-вывод в `/data` и `/opt/node-red-vl/nodes-configs`. Прямых вызовов из `node-red-vl` в Box gateway, Kafka, MinIO, PostgreSQL, ClickHouse, `nr-sbx-celery` или production `inf-nri-inference` не предусмотрено.
Протоколы	HTTP/1.1 REST/admin API Node-RED, HTTP/1.1 FastAPI, WebSocket для editor/proxy, Redis protocol, локальное управление процессами `node-red`, файловый ввод-вывод в Docker volumes. Собственных gRPC, Kafka, S3/MinIO, PostgreSQL wire protocol, ClickHouse protocol и Prometheus exposition endpoint у сервиса нет.
Хранилища	Собственной БД нет. Постоянное состояние хранится в bind-backed Docker volumes: `node-red-sandbox_node-red-vl-data` (`/data/sandbox-compose-data/node-red-vl-data` -> `/data`) и `node-red-sandbox_node-red-vl-configs` (`/data/sandbox-compose-data/node-red-vl-configs` -> `/opt/node-red-vl/nodes-configs`). В `/data` лежат общий `flows.json`, `.config.nodes.json`, `settings.js` и per-session каталоги `/data/sessions/<session_name>/...`; в `nodes-configs` лежат JSON-описания custom nodes. Операционное состояние per-session manager хранит в Redis `session:<id>`. Production-источником сценариев остаётся `svr-scenario-storage`, а не локальный `flows.json` sandbox-редактора.
Конфигурация	Основные параметры: compose-переменная `NODE_RED_VL_IMAGE`; `NODE_ENV`; `DATA_DIR`; `NODE_RED_FAST_API_MANAGER_PORT`; Redis `REDIS_HOST`, `REDIS_PORT`, `SESSION_KEY_PREFIX`; manager/proxy `NODE_RED_HOST`, `NODE_RED_BASE_INSTANCE_PORT`, `NODE_RED_MAX_INSTANCE_PORT`, `NODE_RED_PREFIX_URL`, `NODE_RED_RETURN_INSTANCE_DELAY`; `LOGGER_LEVEL`; `DEBUG`. В конфигурации продуктового контура заданы `RestartPolicy=always`, log driver `loki`, Docker healthcheck `node /healthcheck.js`, image tag `v1.11.0`, отсутствие published host ports и только сеть `node-red-sandbox`. Значения параметров доступа в документации не приводятся.
Логирование	Общий Node-RED, FastAPI manager и запущенные per-session `node-red` процессы пишут в stdout/stderr одного контейнера; Docker отправляет логи через driver `loki`. В логах могут оказаться сообщения Node-RED flows, ошибки proxy/manager и содержимое пользовательских function-node/script-node обработчиков, поэтому сырые логи нельзя переносить в документацию без редактирования чувствительных данных. Отдельного файлового audit-журнала сервиса не предусмотрено.
Мониторинг	В конфигурации продуктового контура контейнер в состоянии `running`, Docker health status `healthy`; healthcheck задан как `node /healthcheck.js`. Практические проверки: HTTP `200` для общего editor API (`/`, `/flows`, `/nodes`, `/configs/list`) и manager API (`/api/hello`, `/api/docs/`), наличие процессов `node-red`, `/service/main.py server` и per-session `node-red`-дочерних процессов, доступность volumes `/data` и `/opt/node-red-vl/nodes-configs`. `/metrics/` и `/health/` на manager возвращают `404`; выделенного Prometheus scrape-контракта нет.
Критичность	Высокая для sandbox-разработки и проверочных launch-сессий: без сервиса нельзя открыть Node-RED editor, создать/изменить flow, запустить per-session editor из backend UI или получить актуальные custom-node формы. Для уже работающего production-инференса критичность ниже: отказ `nr-sbx-node-red-vl` не должен останавливать основной NRI runtime и обработку боевых видеопотоков, но блокирует подготовку, отладку и перенос новых сценариев.
Эксплуатационные особенности и известные ограничения	Сервис зависит от `nr-sbx-redis`, `nr-sbx-nginx` и двух shared volumes; потеря Redis ломает управление per-session процессами, а потеря `/data`/`nodes-configs` ломает редактор и custom nodes. Per-session Node-RED-процессы живут внутри того же контейнера и ограничены пулом портов `1881-1999`; allocator трактует верхнюю границу как exclusive. `nodes-configs/*.json` генерируются NRI/celery-процессами и могут быть перезаписаны при синхронизации зон/моделей, Kafka-событии версии модели или рестарте worker; долговременные изменения нужно делать на стороне генератора, а не вручную в volume. Часть шаблонов и common-кода custom nodes встроена в образ, поэтому изменения требуют rebuild/bump image. Собственных Prometheus-метрик, RBAC/audit trail и прямой интеграции с production `inf-nri-inference` у сервиса нет.

`nr-sbx-kafka`¶

Compose-сервис: kafka.

Поле	Описание
Название сервиса	`nr-sbx-kafka` (`kafka` в compose-проекте `node-red-sandbox`).
Назначение	Локальный Kafka-брокер песочницы Node-RED Sandbox для обмена статусами и управляющими сообщениями запуска NRI-сценариев. Сервис намеренно отделён от основной шины `inf-kafka`, чтобы sandbox-запуски не смешивались с production-потоком событий BOX5-DIT-MGSN.
Подсистема	Домен `node-red-sandbox`. Контейнер подключён только к сети `node-red-sandbox` и обслуживает sandbox-клиентов `nr-sbx-backend` и `nr-sbx-celery`; к `bx_default` и основным доменам Box напрямую не подключается.
Основные функции	Kafka 3.4 single-node broker/controller в KRaft-режиме; внутренний bootstrap endpoint `kafka:9092`; локальный controller listener `localhost:9093`; приём produce/fetch/metadata-запросов от sandbox-сервисов; хранение topic logs, offsets и KRaft metadata; короткое хранение сообщений для прогресса задач; поддержка увеличенного лимита сообщения/запроса около `15 MiB` для payload-ов с прогрессом и данными кадров.
Входящие вызовы	Kafka protocol `PLAINTEXT://kafka:9092` из сети `node-red-sandbox`. `nr-sbx-backend` ожидает доступность `processings_status_topic`, читает статусы и ошибки выполнения и передаёт их в Socket.IO. `nr-sbx-celery` публикует progress/error payload-ы в `processings_status_topic` и создаёт per-session consumer group вида `process_session_<session_id>` для `processings_control_topic`. В конфигурации продуктового контура заданы topics `processings_status_topic`, `processings_control_topic`, `change_launch_status` и служебный `__consumer_offsets`; основные sandbox topics имеют `PartitionCount=1`, `ReplicationFactor=1`, `max.message.bytes=15728640`. KRaft controller-трафик идёт внутри контейнера на `localhost:9093`.
Исходящие вызовы	Прикладных исходящих вызовов нет: брокер не вызывает HTTP/REST, gRPC, PostgreSQL, Redis, MinIO/S3, ClickHouse и основной `inf-kafka`. Он отвечает Kafka-клиентам на metadata/produce/fetch-запросы и пишет данные брокера в локальный mount `/bitnami/kafka`.
Протоколы	Kafka protocol поверх TCP `9092` внутри Docker-сети; KRaft controller protocol поверх TCP `9093` внутри контейнера; локальный файловый ввод-вывод в `/bitnami/kafka`; Docker stdout/stderr для логов. ZooKeeper не используется. TLS, SASL, HTTP API, gRPC, PostgreSQL wire protocol, Redis protocol и Prometheus exposition endpoint не предоставляются.
Хранилища	Собственной SQL/NoSQL БД нет. В конфигурации продуктового контура bind mount `/data/sandbox-compose-data/kafka3.4/kafka-data:/bitnami/kafka` хранит логи топиков, consumer offsets и KRaft metadata. Данные недолговечные по назначению sandbox: `KAFKA_CFG_LOG_RETENTION_HOURS=2`, replication factor `1`, один broker/controller.
Конфигурация	Образ `docker.vizorlabs.ru/docker-images/kafka:3.4`, `restart: always`, host-порты не опубликованы. Основные параметры: `KAFKA_ENABLE_KRAFT=yes`, `KAFKA_CFG_NODE_ID=1`, `KAFKA_CFG_PROCESS_ROLES=broker,controller`, `KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER`, `KAFKA_LISTENERS=PLAINTEXT://kafka:9092,CONTROLLER://localhost:9093`, `KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://kafka:9092`, `KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@localhost:9093`, `KAFKA_CONTROLLER_QUORUM_VOTERS=1@localhost:9093`, `ALLOW_PLAINTEXT_LISTENER=yes`, `KAFKA_CFG_LOG_RETENTION_HOURS=2`, `KAFKA_CFG_MESSAGE_MAX_BYTES=15728640`, `KAFKA_CFG_MAX_PARTITION_FETCH_BYTES=15728640`, `KAFKA_CFG_MAX_REQUEST_SIZE=15728640`. Базовый каталог данных задаётся через `COMPOSE_DATA_DIR`; в конфигурации продуктового контура присутствует `/data/sandbox-compose-data`.
Логирование	Kafka пишет broker/controller логи в `stdout`/`stderr`; в конфигурации продуктового контура Docker log driver — `loki`, поэтому централизованное хранение идёт через Loki, а локальная диагностика — через Docker logs контейнера `node-red-sandbox-kafka-1`. Отдельного application audit log у брокера нет; содержимое топиков не считается журналом аудита.
Мониторинг	Docker healthcheck отсутствует (`Health=none`), `/metrics` endpoint не заявлен. Практический контроль: контейнер `node-red-sandbox-kafka-1` в состоянии `Up`, `RestartCount=0`, внутренний порт `9092/tcp`, сеть `node-red-sandbox`, `kafka-topics.sh --list/--describe` для `processings_status_topic` и `processings_control_topic`, `kafka-consumer-groups.sh --list` для активных групп `process_session_*`. В конфигурации продуктового контура также заданы `PartitionCount=1`, `Leader=1`, `Isr=1` для двух основных topics.
Критичность	Средняя для решения в целом и высокая для интерактивной работы sandbox. Отказ не останавливает основной production-инференс, камеры, события и `inf-kafka`, но ломает публикацию и чтение прогресса sandbox-задач, может задерживать старт `nr-sbx-backend` на ожидании Kafka topic и делает ненадёжным control-path `nr-sbx-celery` для текущих сессий.
Эксплуатационные особенности и известные ограничения	Single-node KRaft без отказоустойчивости: один broker/controller, replication factor `1`, нет ZooKeeper, нет multi-broker quorum. Слушатель plaintext без TLS/SASL и без внешней публикации host-порта; доступ рассчитан только на доверенную Docker-сеть sandbox. Retention всего `2` часа, поэтому сервис не подходит для долговременного хранения событий. Нет Docker healthcheck, Prometheus-метрик и отдельного web-интерфейса для этого локального брокера. Часть клиентов завязана на alias `kafka:9092`: у `nr-sbx-celery` progress/control Kafka-код захардкожен на этот endpoint, поэтому `KAFKA_HOST` покрывает не все пути. `processings_control_topic` предусмотрен, но штатный stop-flow backend сейчас использует Celery revoke, а не Kafka stop-сообщение.

`nr-sbx-mm-conversion`¶

Поле	Описание
Название сервиса	`nr-sbx-mm-conversion`. В compose-файле `node-red-sandbox` сервис называется `mm_conversion`; в конфигурации продуктового контура развёрнут как контейнер `node-red-sandbox-mm_conversion-1` с образом `docker.vizorlabs.ru/vizorlabs/mm-conversion-image:v2.0.0`. Это sandbox-экземпляр MM/MMLab-конвертера, отдельный от основного `mm-conversion` контура `inference` и от `nr-sbx-yolo-conversion`.
Назначение	Внутренний helper песочницы Node-RED/NRI для конвертации MMLAB/MMDeploy-моделей при первом использовании или принудительной пересборке артефактов. Сервис принимает команду от `vlmodels` в `nr-sbx-celery` или `nr-sbx-nri`, запускает packaged MMDeploy export-скрипты и сохраняет ONNX/TensorRT-архивы в общий каталог моделей sandbox.
Подсистема	`node-red-sandbox`, изолированный контур разработки и проверки NRI-сценариев. Работает рядом с `nr-sbx-celery`, `nr-sbx-nri`, `nr-sbx-node-red-vl`, `nr-sbx-redis`, `nr-sbx-kafka`, `nr-sbx-yolo-conversion` и `nr-sbx-nginx`; не обслуживает production-инференс `inf-nri-inference`.
Основные функции	Запускает FastAPI-приложение из общего `mscmodels_converter`, слушает HTTP API поверх Unix domain socket, создаёт `process_id`, стартует одну shell-команду конвертации в `multiprocessing.Process`, хранит статус процесса в памяти и отдаёт его по polling API. В образе `v2.0.0` присутствуют entrypoint-скрипты `python3 /opt/converter/mmpose/export.py` и `python3 /opt/converter/mmpretrain/export.py`; они используют MMDeploy-профили из `/opt/mmlab/mmdeploy/configs`, читают исходные `weights.pth`/`config.py` из `/models/.../model/artifacts` и пишут результат обратно в shared model tree.
Входящие вызовы	Основные клиенты - `nr-sbx-celery` и `nr-sbx-nri`, которые через `vlmodels.external.mscmodels_converter` обращаются к `MMLAB_CONVERSION_URI=${SNDBX_MMLAB_CONVERSION_URI}`. В конфигурации продуктового контура endpoint слушает `uvicorn main:app --uds /tmp/sdx_mm_conversion_sock`; socket-файл присутствует в общем `/tmp`. API: `POST /start-process/` с JSON `{"command": "<shell command>"}`, `GET /status/{process_id}`, `GET /status_server`. Host-порты не опубликованы, входящих HTTP/TCP, gRPC, Kafka, Redis или PostgreSQL контрактов нет.
Исходящие вызовы	Сервис не ходит в Kafka, Redis, PostgreSQL, MinIO/S3, MLflow, GitLab, Box API или внешние HTTP/gRPC upstream. Единственные runtime side effects - локальный запуск shell-команд, выполнение MMDeploy через `/opt/mmlab/mmdeploy/tools/deploy.py` с `--device cuda`, чтение/запись файлов в `/models` и временная работа в `/tmp/mmpose/<output-stem>` или `/tmp/mmpretrain/<output-stem>`. Скачивание моделей и выбор registry выполняют вызывающие `nr-sbx-celery`/`nr-sbx-nri`, а не сам конвертер.
Протоколы	HTTP/1.1 + JSON поверх Unix domain socket `/tmp/sdx_mm_conversion_sock`; локальная файловая система; shell subprocess; Docker stdout/stderr. Для клиентов используется `requests_unixsocket`; в текущем sandbox-контракте нет TCP listener на `:8000`, публичного nginx-маршрута, WebSocket, Prometheus exposition, Kafka protocol, SQL или Redis protocol.
Хранилища	Собственной БД и долговременного состояния нет. В конфигурации продуктового контура заданы bind mounts `/data/mlflow-models -> /models` и `/tmp -> /tmp`; через них сервис получает исходные model artifacts, возвращает converted weights и публикует Unix socket для клиентов. `process_status` хранится только в памяти процесса FastAPI и теряется при рестарте контейнера.
Конфигурация	Compose-сервис `mm_conversion` из `/home/vizorlabs/CODE/node-red-sandbox/docker-compose.yaml`, сеть `node-red-sandbox`, aliases `mm_conversion` и `node-red-sandbox-mm_conversion-1`, host-порты не заданы. Команда запуска: `uvicorn main:app --uds $SNDBX_MMLAB_CONVERSION_URI`; ключевые параметры: `MM_CONVERTER_IMAGE`, `MODELS_PATH`, `SNDBX_MMLAB_CONVERSION_URI`, env `MODELS_PATH=/models`. Контейнер запущен с `runtime: nvidia`; в конфигурации продуктового контура `torch.cuda.is_available() = True` и видна одна GPU. Docker healthcheck отсутствует, restart policy для сервиса не задана. В вызывающих `nr-sbx-celery` и `nr-sbx-nri` обязательно должно быть проброшено `MMLAB_CONVERSION_URI=${SNDBX_MMLAB_CONVERSION_URI}`, иначе `vlmodels` в socket mode вернётся к generic default `/tmp/mm_conversion_sock`.
Логирование	Uvicorn, FastAPI/Loguru и дочерние export-процессы пишут в stdout/stderr контейнера; в конфигурации продуктового контура Docker log driver - `loki`. Отдельного файлового журнала, audit log или структурированного события о завершении конвертации сервис не ведёт; подробные параметры команды могут содержать пути к моделям и должны публиковаться только после проверки на чувствительные данные.
Мониторинг	Собственных `/metrics`, Prometheus exporter и Docker healthcheck нет. Минимальный контроль в конфигурации продуктового контура: контейнер `node-red-sandbox-mm_conversion-1` в состоянии `Up`, socket `/tmp/sdx_mm_conversion_sock` существует, `GET /status_server` через Unix socket возвращает `{"status":"200","error":false}`, GPU доступна, а `/opt/converter/mmpose/export.py`, `/opt/converter/mmpretrain/export.py` и MMDeploy config-каталоги присутствуют в образе. Прикладной контроль успешности выполняют клиенты через polling `GET /status/{process_id}` и по появлению ожидаемого архива в `/models/.../artifacts`.
Критичность	Средняя для всего решения и высокая для sandbox-запусков, которым нужны MMLAB-модели без готовых converted artifacts. Отказ сервиса не останавливает production-видеопотоки, основной `inf-nri-inference`, Kafka или пользовательский UI BOX5-DIT-MGSN, но ломает конвертацию `mmpose`/`mmpretrain` моделей в песочнице и может блокировать проверку соответствующих Node-RED/NRI-сценариев до ручного восстановления артефактов.
Эксплуатационные особенности и известные ограничения	API исполняет произвольную shell-команду от доверенных внутренних клиентов, поэтому его нельзя публиковать наружу или проксировать через nginx. Статусы не персистентны: после рестарта старые `process_id` становятся `unknown`, а `/status_server` проверяет только живость FastAPI, не зависшие MMDeploy-процессы, GPU/TensorRT-совместимость или доступность `/models`. Сервис критичен к совпадению socket path и shared mounts `/tmp`/`/models` у сервера и клиентов; CPU-only режим для рабочих команд не предусмотрен, потому что packaged deploy wrapper запускает MMDeploy с `--device cuda`. В текущем образе поддерживаются только `mmpose` и `mmpretrain`; YOLO, DEIM, `abob_classifier` и прочие non-MMLAB конвертации относятся к `nr-sbx-yolo-conversion`, а не к этому сервису.

`nr-sbx-yolo-conversion`¶

Compose-сервис: yolo_conversion.

Поле	Описание
Название сервиса	`nr-sbx-yolo-conversion`, compose-сервис `yolo_conversion`. В конфигурации продуктового контура развёрнут в compose-проекте `node-red-sandbox` как контейнер `node-red-sandbox-yolo_conversion-1`; при контрольной проверке контейнер работал с образом `docker.vizorlabs.ru/vizorlabs/yolo-conversion-image:demo-2082-convert-deim-trt-dynamic-batch`, без published host-портов.
Назначение	Внутренний sandbox-helper конвертации non-MMLAB моделей для Node-RED Sandbox/NRI. По запросу `nr-sbx-celery` или `nr-sbx-nri` запускает packaged export-команды для YOLOv5, YOLOv7, YOLOv8, DEIM и `abob_classifier`, чтобы при первом использовании модели материализовать ONNX/TensorRT/TorchScript-артефакты в общем каталоге моделей.
Подсистема	`node-red-sandbox`, изолированный контур разработки и проверки NRI-сценариев. Сервис работает рядом с `nr-sbx-celery`, `nr-sbx-nri`, `nr-sbx-node-red-vl`, `nr-sbx-backend`, `nr-sbx-mm-conversion` и общим model cache; это sandbox-аналог основного `yolo-conversion`, а не часть production-контура `inference`.
Основные функции	Поднимает FastAPI-приложение `mscmodels_converter`; принимает команду конвертации, создаёт `process_id`, запускает shell-команду в отдельном `multiprocessing.Process` через `subprocess.run(..., shell=True, check=True)`, хранит статус процесса в памяти и отдаёт его по polling API. В образе присутствуют export entrypoints `/opt/converter/yolov5/export.py`, `/opt/converter/yolov7/export.py`, `/opt/converter/yolov8/export.py`, `/opt/converter/deim/export.py`, `/opt/converter/abob_classifier/export.py`.
Входящие вызовы	Основные клиенты - `nr-sbx-celery` и `nr-sbx-nri`, у которых в конфигурации продуктового контура задано `YOLO_CONVERSION_URI=/tmp/sbx_yolo_conversion_sock` и общий bind mount `/tmp`. Клиент `vlmodels.external.mscmodels_converter` вызывает `POST /start-process/` с JSON `{"command": "<shell command>"}` и затем каждые 5 секунд опрашивает `GET /status/{process_id}`; для ручной проверки доступен `GET /status_server`. Прямых входящих вызовов от UI/backend, Kafka, Redis или внешней сети не предусмотрено.
Исходящие вызовы	Сетевых исходящих интеграций у API-слоя нет: сервис не обращается к Kafka, Redis, PostgreSQL, MinIO/S3, MLflow, GitLab, Box API, gRPC или gRPC. Все side effects локальные: запуск conversion subprocess, чтение исходных весов/конфигов из `/models`, запись сконвертированных артефактов обратно в `/models/<model>/<version>/model/artifacts` и временная работа в `/tmp`. Доступ к registry и построение команды выполняют вызывающие `celery`/`nri` через `vlmodels`.
Протоколы	В конфигурации песочницы - HTTP/1.1 + JSON поверх Unix domain socket `/tmp/sbx_yolo_conversion_sock`, команда запуска `uvicorn main:app --uds /tmp/sbx_yolo_conversion_sock`. Образ также умеет работать как TCP HTTP API на `:8000`, но для `nr-sbx-yolo-conversion` этот режим не используется: `Ports={}`, host-порт не опубликован. gRPC, Kafka, Redis protocol, WebSocket, TLS и публичный REST API отсутствуют.
Хранилища	Собственной БД, очереди и persistent state нет. В конфигурации продуктового контура заданы bind mounts `/data/mlflow-models -> /models` и `/tmp -> /tmp`; `/models` хранит исходные и сконвертированные model artifacts, `/tmp` используется для Unix socket и временных файлов. `process_status` хранится только в памяти процесса uvicorn, поэтому после рестарта старые `process_id` становятся `unknown`.
Конфигурация	Compose-файл `/home/vizorlabs/CODE/node-red-sandbox/docker-compose.yaml` задаёт `image: ${YOLO_CONVERTER_IMAGE}`, `runtime: nvidia`, `environment: MODELS_PATH=/models`, volumes `${MODELS_PATH}:/models` и `/tmp:/tmp`, command `uvicorn main:app --uds $SNDBX_YOLO_CONVERSION_URI`, сеть `node-red-sandbox` и alias `yolo_conversion`. В конфигурации продуктового контура socket раскрыт как `/tmp/sbx_yolo_conversion_sock`; в client-контейнерах должны совпадать `YOLO_CONVERSION_URI` и общий `/tmp`, иначе `vlmodels` будет смотреть не в sandbox socket. Контейнер запущен с `NVIDIA_VISIBLE_DEVICES=all`, `NVIDIA_DRIVER_CAPABILITIES=compute,utility`, `CUDA_VERSION=12.6.1`; контейнер видит GPU `NVIDIA RTX A2000`.
Логирование	Логи пишутся в stdout/stderr контейнера: uvicorn startup/access logs, Loguru-сообщения обработчиков и stdout/stderr дочерних export-процессов. В конфигурации продуктового контура Docker log driver - `loki`, отдельного файлового log volume нет. Логи могут содержать shell-команды и пути к артефактам моделей, поэтому при публикации диагностики их нужно просматривать на предмет чувствительных параметров.
Мониторинг	Docker healthcheck отсутствует (`Health=none`), `/metrics` и `/health` возвращают `404`. Практические проверки: контейнер `running`, наличие socket-файла `/tmp/sbx_yolo_conversion_sock`, успешный `GET /status_server` через `curl --unix-socket` (`{"process_id":null,"status":"200","error":false}`), совпадение socket path у `celery`/`nri`, доступность GPU/CUDA и появление ожидаемых артефактов в `/models`. Косвенный мониторинг идёт через статусы Celery-задач, ошибки `vlmodels` и логи `nr-sbx-celery`/`nr-sbx-nri`.
Критичность	Высокая для sandbox-проверок, первого запуска новых non-MMLAB моделей и forced reconversion: без сервиса `nr-sbx-celery`/`nr-sbx-nri` не смогут подготовить отсутствующие converted artifacts. Для уже сконвертированных моделей критичность ниже: сценарии, которым не требуется новая конвертация, могут использовать готовые файлы из `/models`. Отказ сервиса не должен напрямую останавливать production-видеопоток BOX5-DIT-MGSN, но блокирует подготовку и проверку части sandbox-сценариев.
Эксплуатационные особенности и известные ограничения	API доверенный и исполняет произвольную shell-команду от внутреннего клиента, поэтому socket нельзя публиковать наружу и нельзя использовать с недоверенным вводом; auth/TLS нет. Статусы процессов не персистентны, отдельной очереди, лимитов параллелизма, Prometheus-метрик и healthcheck нет; несколько тяжёлых конвертаций могут конкурировать за GPU/CPU/диск. Работоспособность зависит от совпадения shared mounts `/tmp` и `/models` у converter и caller-контейнеров, корректного `YOLO_CONVERSION_URI`, доступности CUDA/TensorRT и прав на запись в model cache. Несмотря на имя `yolo`, сервис обслуживает только non-MMLAB ветку `vlmodels`; MMDeploy/MMLAB export-команды (`mmpose`, `mmpretrain`) относятся к `nr-sbx-mm-conversion`. CPU-only режим для штатной TRT-конвертации в конфигурации продуктового контура не предусмотрен.

`nr-sbx-nginx`¶

Поле	Описание
Название сервиса	`nr-sbx-nginx` (`node-red-integration/node-red-sandbox/nginx`), compose-сервис `nginx`. В конфигурации продуктового контура развёрнут как контейнер `node-red-sandbox-nginx-1` из образа `nginx:latest`.
Назначение	HTTP gateway песочницы Node-RED/NRI. Публикует единый browser-facing вход `/sandbox/`, отдаёт runtime-конфиг `/sandbox/config.json` и проксирует трафик к sandbox frontend, backend, Socket.IO, Node-RED manager/runtime и Flower. Это отдельный gateway домена `node-red-sandbox`, не основной `ui-nginx` BOX5-DIT-MGSN и не frontend/backend-приложение.
Подсистема	Домен `node-red-sandbox`, изолированный контур разработки и проверки NRI-сценариев. Работает рядом с `nr-sbx-frontend`, `nr-sbx-backend`, `nr-sbx-node-red-vl`, `nr-sbx-flower`, `nr-sbx-celery`, `nr-sbx-redis`, `nr-sbx-kafka`, `nr-sbx-nri` и sandbox-конвертерами моделей.
Основные функции	Слушает `81/tcp`; задаёт `client_max_body_size 1000M` для загрузок через sandbox UI; проксирует `/sandbox/` в `frontend:3000/sandbox/`; отдаёт `/sandbox/config.json` из `/etc/nginx/sandbox/config.json` с запретом кеширования; проксирует `/sandbox/backend/` в `backend:5000/`; проксирует `/sandbox/socket.io/` в `backend:5000/sandbox/socket.io/`; переписывает `/sandbox/node-red/api/` в `/api/` на `node-red-vl:5000`; переписывает `/sandbox/node-red/<session_id>/` в `/<session_id>/` на `node-red-vl:5000`; проксирует `/sandbox/node-red/` в общий Node-RED runtime `node-red-vl:1880/`; проксирует `/sandbox/flower/` в `flower:5555/`. Для frontend, backend, Socket.IO и Node-RED включает HTTP/1.1 WebSocket upgrade headers.
Входящие вызовы	HTTP от браузеров и верхнего gateway контура на опубликованный порт sandbox nginx. В конфигурации продуктового контура задана публикация `0.0.0.0:81->81/tcp` и `:::81->81/tcp`; пользовательский URL песочницы доступен через маршрут `/sandbox/`, а прямой sandbox endpoint - через опубликованный порт `81`. Read-only проверки через порт 81: `/sandbox/`, `/sandbox/config.json`, `/sandbox/static/js/bundle.js` и `/sandbox/node-red/` вернули `200`; `/sandbox/backend/` вернул `404` от backend root, что соответствует проксированию; `/sandbox/socket.io/` без Socket.IO handshake вернул `400`; `/sandbox/flower/` без учётных данных вернул `401`.
Исходящие вызовы	Только reverse-proxy и static-file доступ: HTTP к `frontend:3000`, `backend:5000`, `node-red-vl:1880`, `node-red-vl:5000`, `flower:5555`; чтение `/etc/nginx/sandbox/config.json`. Прямых обращений к PostgreSQL, Redis, Kafka, MinIO/S3, MLflow, Box API, production frontend/backend или inference runtime у сервиса нет.
Протоколы	Входящий и исходящий HTTP/1.1 внутри Docker-сети `node-red-sandbox`; WebSocket upgrade для frontend dev server, Socket.IO и Node-RED-трафика; статическая отдача JSON-файла. TLS, gRPC, PostgreSQL wire protocol, Redis RESP, Kafka protocol и S3 API сервисом не используются.
Хранилища	Собственной БД и пользовательского долговременного хранилища нет. В конфигурации продуктового контура заданы только read-only bind mounts: `/home/vizorlabs/CODE/node-red-sandbox/nginx/nginx.conf` -> `/etc/nginx/nginx.conf` и `/home/vizorlabs/CODE/node-red-sandbox/services/frontend/config.json` -> `/etc/nginx/sandbox/config.json`. Состояние sandbox-сессий, файлы, flow и результаты находятся в других сервисах домена.
Конфигурация	Compose запускает `nginx:latest`, `restart: always`, сеть `node-red-sandbox`, `depends_on: frontend`, портовую публикацию `${NGINX_HOST_PORT}:${NGINX_HOST_PORT}` и два read-only mounts. В конфигурации продуктового контура `NGINX_HOST_PORT=81`, compose project `node-red-sandbox`, service `nginx`; mounted `nginx/nginx.conf` жёстко содержит `listen 81`, поэтому значение переменной и конфиг должны совпадать. `services/frontend/config.json` содержит объект `FRONTEND_SETTINGS` с runtime-настройками маршрута и upstream-URL браузерного клиента (`FRONT_ROUTE`, `HOST_NAME`, `BACKEND_URL`, `SOCKET_IO_BACKEND_URL`, `NODE_RED_BACKEND_URL`, `FRAME_DISPLAY_FREQUENCY`). Basic Auth в nginx-конфиге предусмотрен, но строки `auth_basic` закомментированы; защита Flower задаётся самим `nr-sbx-flower`.
Логирование	Nginx пишет access/error log в stdout/stderr контейнера; в конфигурации продуктового контура Docker log driver для контейнера - `loki`, поэтому `LogPath` пустой, а просмотр выполняется через `docker logs` или Loki. В access log попадают IP клиента, время, метод, путь, статус, размер ответа и user-agent; тела запросов не логируются, но query-параметры с идентификаторами сессий или сценариев перед публикацией нужно редактировать.
Мониторинг	Docker healthcheck отсутствует (`health=none`), собственного `/health`, `/metrics` или `stub_status` не настроено. Практические проверки: контейнер `node-red-sandbox-nginx-1` в состоянии `Up`, порт `81/tcp` опубликован, `nginx -T` показывает ожидаемую route map, `/sandbox/` и `/sandbox/config.json` возвращают `200`, `/sandbox/socket.io/` отвечает `400` без handshake, `/sandbox/flower/` отвечает `401` без учётных данных. Пути `/sandbox/health` и `/sandbox/metrics` в конфигурации продуктового контура возвращают SPA HTML через frontend fallback и не являются health/metrics nginx.
Критичность	Высокая для песочницы Node-RED: при отказе `nr-sbx-nginx` пользователь теряет публичный доступ к sandbox UI, runtime-конфигу, backend API, Socket.IO-прогрессу, Node-RED editor/manager и Flower. Для production-видеоаналитики BOX5-DIT-MGSN критичность низкая: отказ gateway песочницы не должен останавливать основной `inf-nri-inference`, камеры, Kafka основного контура или хранение боевых событий.
Эксплуатационные особенности и известные ограничения	В конфиге жёстко задан `listen 81`, поэтому изменение `NGINX_HOST_PORT` без синхронного изменения `nginx.conf` ломает публикацию. `config.json` является deployment-local файлом и не находится в образе; при его отсутствии или ошибочных URL frontend не стартует. `depends_on` ждёт только запуска frontend-контейнера и не проверяет готовность backend, Socket.IO, Node-RED или Flower. Нет встроенного TLS, включённого Basic Auth, rate limit, healthcheck, Prometheus-метрик и HA-схемы. Dynamic Node-RED proxy распознаёт только числовой `<session_id>`; остальные пути под `/sandbox/node-red/` уходят в общий runtime. Наличие `200` на `/sandbox/` проверяет только gateway/frontend и не доказывает работоспособность sandbox backend, worker, Redis/Kafka, Node-RED manager или model conversion services.

`nr-sbx-redis`¶

Поле	Описание
Название сервиса	`nr-sbx-redis` (`redis` в compose-проекте `node-red-sandbox`). В конфигурации продуктового контура развёрнут как контейнер `node-red-sandbox-redis-1` с образом `redis:latest`; слушает только внутренний Docker-порт `6379/tcp`, host-порт не опубликован.
Назначение	Выделенный Redis sidecar песочницы Node-RED/NRI: хранит состояние sandbox-сессий и одновременно служит брокером Celery и result backend для фоновых задач. Это отдельный контур `node-red-sandbox`; он не является Redis sidecar сервиса `ds-data-temporary-storage` и не хранит временные media objects этого сервиса.
Подсистема	`node-red-sandbox`, изолированная среда разработки, запуска и отладки NRI-сценариев перед переносом в основной контур BOX5-DIT-MGSN. Основные клиенты Redis: `nr-sbx-backend` для session state и dispatch Celery-задач, `nr-sbx-celery` для получения задач и записи task metadata, `nr-sbx-flower` для просмотра состояния broker/worker/task. В спецификациях также указан FastAPI manager в `nr-sbx-node-red-vl`, который использует Redis для восстановления занятых per-session портов.
Основные функции	Принимает Redis-команды от sandbox-клиентов; хранит JSON-документы сессий в ключах `session:<id>`; ведёт монотонный счётчик `next_session_id` через `INCR`; держит стандартные Celery/Kombu структуры очередей, binding-и и metadata результатов, включая `_kombu.binding.celery` и `celery-task-meta-*`; отдаёт broker state в Flower; сохраняет состояние в `/data` по штатным настройкам upstream Redis.
Входящие вызовы	Redis RESP/TCP на `redis:6379` внутри Docker-сети `node-red-sandbox`. Клиенты по конфигурации: `nr-sbx-backend` через кодовые defaults `REDIS_HOST=redis`, `REDIS_PORT=6379`, `SESSION_KEY_PREFIX=session:`, `CELERY_BROKER_URL=redis://redis:6379/0`, `CELERY_RESULT_BACKEND=redis://redis:6379/0`; `nr-sbx-celery` через `redis://redis:6379/0`; `nr-sbx-flower` через `redis://redis:6379/0`. HTTP, Kafka, gRPC, PostgreSQL и внешний пользовательский API у Redis-контейнера отсутствуют.
Исходящие вызовы	Собственных исходящих HTTP/Kafka/gRPC/DB-вызовов сервис не выполняет. Возвращает Redis-ответы клиентам по тем же TCP-соединениям и пишет runtime-состояние в локальный `/data` volume контейнера.
Протоколы	Redis Serialization Protocol поверх TCP `6379`; Celery/Kombu transport и Celery result backend поверх Redis DB `0`; стандартные Redis persistence-механизмы RDB/AOF из upstream image. TLS, ACL/password-auth, Redis Cluster, Sentinel, Streams/PubSub как отдельный Box-контракт, REST и Prometheus exposition endpoint не настроены.
Хранилища	Единственная используемая logical DB — Redis DB `0`: session state (`session:<id>`), счётчик `next_session_id`, Celery/Kombu ключи очередей и результатов. В конфигурации продуктового контура `INFO keyspace` показал `db0` с активными ключами, `DBSIZE=20`; sample-типы: `next_session_id`/`session:`/`celery-task-meta-` как `string`, `_kombu.binding.celery` как `set`. Docker монтирует `/data` как anonymous local volume, а не как управляемый bind mount из compose; `CONFIG GET` показывает `appendonly no` и стандартные RDB `save` checkpoints.
Конфигурация	В корневом `docker-compose.yaml` sandbox сервис задан минимально: `image: redis:latest`, сеть `node-red-sandbox`, `restart: always`; service-specific env, custom `redis.conf`, command/entrypoint override, healthcheck и published ports не предусмотрены. В конфигурации продуктового контура заданы `restart=always`, log driver `loki`, `Health=none`, network alias `redis` в сети `node-red-sandbox`, volume mount `/data`. Box-side параметры подключения задаются в клиентах, а не в Redis-контейнере.
Логирование	Redis пишет стандартные startup/runtime logs в `stdout`/`stderr`; Docker собирает их через log driver `loki`. Отдельного файлового application log, audit log или бизнес-журнала у sidecar нет. При диагностике нельзя переносить в документацию значения параметров доступа соседних клиентов, например настроек Flower basic auth или Box/MinIO/model-registry.
Мониторинг	Собственные Docker healthcheck, `/metrics` и Prometheus scrape-target не предусмотрены. Практический контроль: контейнер `node-red-sandbox-redis-1` в состоянии `Up`, `redis-cli PING` возвращает `PONG`, `INFO keyspace`/`DBSIZE` показывают DB `0`, `CLIENT LIST` видит активные команды Celery/Flower/backend-клиентов (`brpop`, `lpush`, `publish`, `psubscribe`, `get`, `set`, `ping`). Очереди и worker/task state дополнительно смотрятся через `nr-sbx-flower`, который сам зависит от этого Redis.
Критичность	Высокая для песочницы Node-RED/NRI: при отказе `nr-sbx-backend` не создаёт и не восстанавливает сессии, Celery-задачи не попадают к `nr-sbx-celery`, Flower теряет broker/worker/task view, а per-session Node-RED состояние и stop/revoke-сценарии деградируют. Для уже запущенного production-инференса критичность ниже: основной `inf-nri-inference` не должен напрямую зависеть от sandbox Redis, но контур разработки, проверки и launch-backed sandbox-запусков становится недоступен.
Эксплуатационные особенности и известные ограничения	Используется `redis:latest`, поэтому фактическая minor-версия upstream Redis может меняться при pull без явного pin. Нет password/TLS/ACL, healthcheck, метрик, managed bind mount, custom `redis.conf` и разделения logical DB: session state и Celery metadata делят DB `0`, что осложняет очистку и расследования. Долговечность состояния зависит от anonymous Docker volume и стандартных RDB-снимков; при пересоздании контейнера с удалением volume сессии, task metadata и broker state теряются. Redis недоступен с host-сети напрямую, поэтому операционные проверки выполняются через `docker exec` или из контейнеров сети `node-red-sandbox`.

`nr-sbx-flower`¶

Поле	Описание
Название сервиса	`nr-sbx-flower` (`flower` в compose-проекте `node-red-sandbox`). В конфигурации продуктового контура запущен как контейнер `node-red-sandbox-flower-1` из upstream-образа `mher/flower:latest`; слушает `5555/tcp` только во внутренней сети, host-порт не опубликован.
Назначение	Flower UI/API для наблюдения за Celery-контуром песочницы Node-RED/NRI: показывает состояние worker `nr-sbx-celery`, очереди, задачи, события broker-а и предоставляет broker-backed control API. Сервис не выполняет inference-задачи и не является бизнес-API BOX5-DIT-MGSN.
Подсистема	Домен `node-red-sandbox`, инженерный контур разработки и проверки NRI-сценариев. Работает рядом с `nr-sbx-backend`, `nr-sbx-celery`, `nr-sbx-redis`, `nr-sbx-nginx`, `nr-sbx-frontend`, `nr-sbx-node-red-vl` и sandbox-конвертерами моделей.
Основные функции	Web UI `/`, `/workers`, `/worker/<worker_name>`, `/tasks`, `/task/<task_uuid>`, `/broker`; JSON API `/api/workers`, `/api/tasks`, `/api/task/info/<task_uuid>`, `/api/queues/length`; control API для Celery remote-control команд: revoke/timeout/rate-limit задач, shutdown worker, управление pool/autoscale и consumer-очередями; `/metrics` и `/healthcheck` для эксплуатационной проверки.
Входящие вызовы	HTTP на внутреннем `flower:5555`; внешний маршрут предоставляет `nr-sbx-nginx`: `/sandbox/flower/` проксируется на `http://flower:5555/` через опубликованный nginx-порт `81`. В конфигурации продуктового контура UI и прикладные API без учётных данных возвращают `401` с `Basic realm="flower"`; `/sandbox/flower/healthcheck` и `/sandbox/flower/metrics` отвечают `200`. Прямого host-порта у Flower нет.
Исходящие вызовы	Подключается к Redis/Celery broker `redis://redis:6379/0` (`nr-sbx-redis`) для чтения очередей, worker heartbeat/task state и отправки Celery remote-control команд. Через broker может влиять на live-задачи `nr-sbx-celery`, если аутентифицированный пользователь вызывает control API. Исходящих вызовов в PostgreSQL, ClickHouse, Kafka, MinIO/S3, gRPC или Box business API не предусмотрено.
Протоколы	HTTP/1.1 для UI, JSON API, `/healthcheck` и Prometheus text exposition `/metrics`; Celery remote control и broker inspection поверх Redis RESP/TCP; Docker stdout/stderr для логов. TLS завершается вне контейнера, если маршрут дополнительно публикуется внешним reverse proxy.
Хранилища	Собственного бизнес-хранилища нет. Redis используется как broker/result backend Celery и источник runtime-состояния, но не принадлежит Flower. В конфигурации продуктового контура у контейнера есть anonymous Docker volume `/data` из upstream-образа; Flower persistent mode, отдельная БД, bind mount конфигурации или бизнес-данные в `/data` не предусмотрены.
Конфигурация	Compose задаёт `CELERY_BROKER_URL=redis://redis:6379/0` и `FLOWER_BASIC_AUTH` для Basic Auth; значение учётных данных в документации не фиксируется. Контейнер запускается командой `celery flower`, подключён только к сети `node-red-sandbox`, имеет `restart: always`, Docker log driver `loki`, `Health=none`. В nginx настроен маршрут `/sandbox/flower/` -> `flower:5555/`; `FLOWER_URL_PREFIX` не задан, поэтому при смене subpath нужно отдельно проверять reverse proxy.
Логирование	Flower пишет runtime/access-логи в stdout/stderr контейнера; в конфигурации продуктового контура они собираются Docker log driver-ом `loki`. Отдельного application audit log действий в UI/control API и отдельного файлового журнала не предусмотрено. В логи потенциально могут попадать имена worker-ов, task id и broker-события; учётные данные и чувствительные env-значения публиковать нельзя.
Мониторинг	`/sandbox/flower/healthcheck` в конфигурации продуктового контура возвращает `200 OK`; `/sandbox/flower/metrics` возвращает Prometheus text. Docker healthcheck отсутствует, поэтому базовая проверка - container state `running`, `RestartCount=0`, доступность `nr-sbx-redis`, наличие живого `nr-sbx-celery` и HTTP-ответы через `nr-sbx-nginx`. Сам Flower используется как технический мониторинг Celery, а не как единая система мониторинга домена.
Критичность	Средняя для эксплуатации песочницы: отказ не останавливает уже запущенный production-инференс BOX5-DIT-MGSN и не мешает `nr-sbx-backend` напрямую ставить задачи в Redis, но ухудшает наблюдаемость Celery, диагностику очередей и ручное управление зависшими задачами. Для безопасной эксплуатации control API критичен корректный Basic Auth и сетевое ограничение маршрута.
Эксплуатационные особенности и известные ограничения	Сервис построен на стороннем `mher/flower:latest`, без VizorLabs wrapper-а и без pinned version в compose. Basic Auth даёт только общий доступ к UI/API, без ролевой модели и аудита действий; control API способен отзывать задачи и управлять worker-ами. Состояние UI восстанавливается из Redis broker/event stream и может быть неполным после рестарта или потери Redis. `/healthcheck` и `/metrics` проверяют доступность Flower, но не гарантируют успешное выполнение sandbox inference. Публикация под другим URL-префиксом требует проверки reverse-proxy настроек, потому что `FLOWER_URL_PREFIX` в текущем развёртывании не задан.

Вспомогательные компоненты контура¶

В конфигурации продуктового контура также запущен compose-проект jmeter-script с сервисом jmeter. Он используется для нагрузочных проверок и не учитывается как сервис решения BOX5-DIT-MGSN.

Приложение Г. Реестр сервисов и компонентов¶

Группы сервисов¶

Реестр по доменам¶

ui-rest¶

ui-react¶

ui-rest-to-gprc¶

ui-nginx¶

statistics¶

st-auth¶

st-auth-postgres¶

st-auth-postgres-backup¶

st-auth-redis¶

st-auth-report-pdf-xlsx-generator¶

st-access¶

st-access-postgres¶

st-access-postgres-backup¶

st-camera-storage¶

st-camera-storage-postgres¶

st-event-storage¶

st-event-storage-postgres¶

st-event-storage-clickhouse¶

st-event-statistic¶

st-event-statistic-clickhouse¶

st-report-email¶

st-report-email-postgres¶

st-report-pdf-xlsx-generator¶

st-report-pdf-xlsx-generator-postgres¶

st-audit¶

st-audit-postgres¶

st-comments¶

st-comments-postgres¶

st-ex-statistics¶

st-ex-statistics-clickhouse¶

st-object-visit-zone-counter¶

st-object-visit-zone-counter-postgres¶

st-virt-cam-video-upload¶

st-virt-cam-video-upload-postgres¶

st-domain-gateway¶

inference¶

inf-nri-inference¶

inf-mediaserver¶

inf-load-balancer¶

inf-load-balancer-postgres¶

inf-load-balancer-redis¶

inf-monitoring¶

inf-monitoring-postgres¶

inf-monitoring-redis¶

inf-image-storage¶

inf-image-storage-redis¶

inf-report-video-extractor¶

inf-pushgateway¶

inf-domain-gateway¶

inf-coturn¶

inf-guardant-control-center¶

mm-conversion¶

yolo-conversion¶

extended-inference¶

inf-flows-manager¶

inf-vl-resource-manager¶

inf-vl-resource-manager-redis¶

severstal¶

svr-asutp¶

svr-asutp-kafka¶

svr-asutp-postgres¶

svr-asutp-redis¶

svr-asutp-schema-registry¶

svr-severstal-integration¶

svr-severstal-integration-postgres¶

svr-severstal-nifi-integration¶

svr-severstal-nifi-integration-postgres¶

svr-severstal-org-sync¶

svr-severstal-org-sync-postgres¶

svr-scenario-storage¶

svr-scenario-storage-postgres¶

svr-lite-scenario-storage¶

svr-lite-scenario-storage-postgres¶

svr-models-registry¶

svr-models-registry-postgres¶

svr-asset-storage¶

svr-asset-storage-postgres¶