Приложение. Метрики мониторинга¶

Приложение дополняет подраздел 2.1.4 «Мониторинг состояния системы» в разделе 2. В основном разделе приведены оперативные проверки UI, API, контейнеров, дисков, GPU и inference-контура. Здесь зафиксированы технические метрики Prometheus, бизнес-метрики ClickHouse, источники их сбора, health-check механизмы, логирование и ограничения текущей реализации BOX5-DIT-MGSN.

1. Общая схема сбора¶

Метрики делятся на два класса:

• бизнес-метрики - все показатели, которые хранятся или рассчитываются в ClickHouse: события, счётчики, статистика нарушений, витрины, отчётные и dashboard-агрегаты;
• технические метрики - всё, что собирается вне ClickHouse: Prometheus /metrics, up, CPU, память, uptime, health/readiness endpoints, состояние контейнеров, дисков, GPU, Kafka, Redis, PostgreSQL, MinIO и журналы Loki.

Технические метрики собираются внутренним контуром elk-log. Сервис log-prometheus опрашивает /metrics у настроенных targets и хранит временные ряды в локальной TSDB. Журналы контейнеров собираются в log-loki и используются вместе с метриками для диагностики.

Исходный Mermaid-код схемы: И3-MER-005. 1. Общая схема сбора.

Внешняя Grafana заказчика не является сервисом BOX5-DIT-MGSN. Она может получать показатели из согласованных источников: аналитические и прикладные показатели из ClickHouse, технические метрики - из Prometheus или из экспортированного набора временных рядов, если такой доступ настроен эксплуатационно. Публиковать внутренние /metrics сервисов наружу без отдельного сетевого ограничения не следует.

2. Классификация метрик¶

При описании мониторинга BOX5-DIT-MGSN используется следующее правило: если показатель лежит в ClickHouse или рассчитывается запросом к ClickHouse, это бизнес-метрика; если источник не ClickHouse, это техническая метрика.

Бизнес-метрики не заменяют технический мониторинг: отсутствие новых событий в ClickHouse может быть следствием бизнес-сценария, недоступности камеры, отказа Kafka, заполнения диска или ошибки модели. Поэтому инцидент проверяется с двух сторон: сначала техническая доступность сервисов и потоков, затем корректность бизнес-данных в ClickHouse.

3. Проверка Prometheus и Loki¶

Проверки выполняются из внутренней сети контура или на узле поставки. Конкретный способ доступа зависит от deployment-профиля: Docker Compose, Docker Swarm и сетевых правил площадки.

Штатная конфигурация log-prometheus монтируется как /etc/prometheus/prometheus.yml; исходный файл находится в дереве поставки elk-log/configs/prometheus/prometheus.yml. Локальное хранилище Prometheus монтируется в контейнер как /prometheus.

4. Формат endpoint /metrics¶

Сервисы, поддерживающие Prometheus, отдают метрики в формате text exposition:

# HELP request_count_total Total Request Count
# TYPE request_count_total counter
request_count_total{method="AddCamera"} 1.0

Типовые элементы ответа:

Типовые labels:

5. Типовые семейства метрик¶

Пример фрагмента ответа:

request_count_total{method="AddObjectObservation"} 1.0
request_count_total{method="DeleteCamera"} 2.0
request_error_total{code="Errors.NotFound",method="DeleteCamera"} 1.0
request_duration_bucket{le="0.05",method="DeleteCamera"} 2.0
cpu_usage 21.4
memory_usage 1.27717376e+08
uptime 1.77666508638e+09

6. Источники метрик текущей реализации¶

В текущей реализации наличие маршрута /metrics зависит от конкретного сервиса и версии образа. Нельзя считать /metrics универсальной проверкой работоспособности всех контейнеров. Метрики из таблицы ниже относятся к техническому мониторингу, если они собираются через Prometheus/Loki, и к бизнес-мониторингу, если тот же показатель рассчитывается из ClickHouse.

Основные targets Prometheus для inference-контура: inf-load-balancer, inf-image-storage, inf-monitoring, inf-pushgateway. Набор targets в промышленном контуре определяется активной конфигурацией поставки, поэтому при диагностике сначала проверяется текущий /etc/prometheus/prometheus.yml внутри log-prometheus.

7. Ограничения и альтернативные проверки¶

Часть контейнеров не имеет собственного Prometheus endpoint, а у части сервисов маршрут /metrics может возвращать 404 или 500 в текущей версии. В таких случаях для эксплуатационного контроля применяются профильные проверки.

Для состояния камер, распределения по нодам и FPS основным источником остаются прикладные API из подраздела 2.1.4:

• POST /api/inference/monitoring/light - состояние камер и heartbeat;
• GET /api/inference/load-balancer/info2/ - распределение камер по нодам;
• GET /api/inference/load-balancer/info/with_monitoring/ - распределение вместе с состоянием, если используется соответствующий UI/API-сценарий.

Prometheus показывает состояние сервисов и технических endpoints, но не заменяет эти API при расследовании отказа конкретной камеры или сценария.

8. Health-check механизмы¶

В поставке нет единого Kubernetes-стиля с обязательными livenessProbe и readinessProbe для каждого сервиса. Используются несколько механизмов: Docker healthcheck для отдельных контейнеров, HTTP readiness/health endpoints инфраструктурных сервисов, Prometheus /metrics как технический liveness сигнал и прикладные read-only API для проверки зависимостей.

В промышленной поставке Docker Health может быть задан только у части контейнеров. У большинства application-сервисов состояние в docker ps - просто Up, а готовность зависимостей проверяется через профильные команды и API.

Для новых проверок в эксплуатационном регламенте следует явно указывать, какой уровень они покрывают:

• liveness - процесс отвечает и контейнер не завис;
• readiness - сервис готов принимать штатные запросы;
• custom functional check - проверен конкретный бизнес- или интеграционный путь с зависимостями.

9. Система логирования¶

Основной канал логирования - stdout/stderr контейнеров. В промышленном контуре централизованная агрегация строится через Docker log driver loki: контейнеры отправляют логи в http://172.17.0.1:3100/loki/api/v1/push. Исключения возможны для сервисов, где явно выбран локальный или отключённый driver, например для отдельных gateway/observability/Redis-контейнеров.

Исходный Mermaid-код схемы: И3-MER-006. 9. Система логирования.

Хранилища и точки поиска:

Фактические обязательные поля для поиска в Loki задаются Docker/Compose labels, а не единым JSON-форматом строки:

Единый обязательный trace_id или service_name в application-строках сейчас не закреплён для всех сервисов. В качестве service_name при поиске используются compose_service и container_name. Отдельные gateway-запросы могут иметь заголовки x-request-id и x-correlation-id, а ui-rest-to-gprc пишет trace-строки для некоторых GraphQL/API операций, но эти идентификаторы не являются сквозным обязательным контрактом для всего контура.

Распределение уровней логирования:

Интерпретация уровней:

• INFO - штатные запросы, heartbeat, синхронизации, завершённые операции;
• WARNING/WARN - деградация, retry, пропущенные необязательные данные, предупреждения healthcheck и нестабильные зависимости;
• ERROR - исключения, отказ обязательной зависимости, неуспешная отправка в Kafka/БД/MinIO/внешнюю систему, stack trace;
• DEBUG - подробная диагностика, допустимая в промышленном контуре только временно по инциденту.

При расследовании инцидента минимальный фильтр Loki:

{compose_project="statistics", compose_service="st-auth"} |= "ERROR"

Если контейнер не отправляет логи в Loki, используется docker logs:

docker logs <container> --since 30m --tail 300

Общие ограничения на публикацию диагностических данных приведены в разделе 4. При передаче фрагментов /metrics или LogQL-результатов оставляются только технически необходимые поля: имя метрики, service/job/instance, метод, код ошибки, время и значение.

10. Практические PromQL-запросы¶

Пороговые значения для предупреждений задаются эксплуатационным регламентом площадки. Для промышленного контура они должны учитывать количество камер, распределение по вычислительным нодам, активные сценарии и плановые технологические окна.