Метрики Design Time

Метрики Design Time отражают процессы проектирования и конфигурирования потоков в Bercut ESB: создание и изменение версий, валидацию и публикацию конфигураций. Позволяют отслеживать частоту правок, выявлять ошибки конфигурации до попадания артефактов в Runtime, контролировать версионность и согласованность настроек.

Стандартные метрики OOB

Метрики Node.js

Компоненты на Node.js (включая ESB Core и отдельные адаптеры) предоставляют стандартный набор метрик среды исполнения, позволяющий оценивать нагрузку на процесс, выявлять утечки памяти, блокировки Event Loop и другие проблемы производительности до того, как они начнут влиять на обработку интеграционных сообщений. Подробнее читайте в документации nodejs (официальная документация по Performance Hooks и сбору метрик в Node.js).

DB Connection Pool метрики (на примере pg-pool)

Пул соединений к СУБД (в Bercut ESB реализуется через pg‑pool в связке с Node.js) предоставляет метрики, критически важные для стабильности работы State Collector, Configuration Server и других компонентов, активно взаимодействующих с хранилищем: по этим данным можно отследить исчерпание пула, рост очередей на получение соединения и ошибки выделения ресурсов. Это позволяет своевременно масштабировать или корректировать настройки пула. Подробнее читайте в документации node-postgres.

Метрики Nginx

Nginx выполняет роль входного балансировщика и обратного прокси для API Gateway и O&M UI, а его стандартные метрики позволяют отделять сетевые и инфраструктурные проблемы от сбоев в бизнес‑логике: по показателям активных соединений, распределению HTTP‑кодов и upstream‑задержкам можно локализовать узкие места - от перегрузки ESB Runtime до ошибок маршрутизации на стороне API Gateway. Подробнее читайте в документации nginx (документация модуля stub_status для получения стандартных метрик Nginx).

Для того, чтобы администратор мог фильтровать, агрегировать и строить алерты точечно, а не «по всей системе сразу» применяются лейблы (labels). Они задают контекст каждой метрике.

Набор лейблов для всех метрик Design Time

Ниже приведён базовый набор лейблов, применяемых ко всем метрикам Design Time. Они обеспечивают единообразную идентификацию и фильтрацию данных в Grafana и позволяют сопоставлять показатели с конкретными компонентами и средами развёртывания.

Лейбл	Описание	Пример значения
instance	Имя виртуальной машины, на которой размещён сервис. Позволяет локализовать проблему на уровне инфраструктуры.	vm-esb-dt-03
environment	Имя окружения ESB. Необходим для разделения продуктивной и тестовых сред, чтобы не смешивать метрики и не срабатывали алерты на тестах.	main, dev1, dev2
group	Имя функциональной группы контейнера: указывает, к какому слою архитектуры относится компонент. Задаётся жёстко в конфигурации.	ESB-DESIGNTIME
container	Имя Docker‑контейнера. В случае, если на одной виртуальной машине запущено несколько экземпляров сервиса - позволяет смотреть нагрузку по каждому контейнеру отдельно.	esb-design-time-v2-8
service	Логическое имя сервиса ESB. Помогает группировать метрики по ключевым сервисам платформы и отличать их от сторонних компонентов.	ESB-BACKEND

Кастомные метрики

Ниже приведены кастомные метрики Design Time. Они позволяют контролировать операции управления версиями и активациями потоков, оценивать частоту изменений в продуктивной среде, а также выявлять аномалии по длительности операций.

Метрика	Описание	Тип
route_activation_count	Счётчик успешных активаций версий потоков. Увеличивается на 1 при каждой успешной активации, в том числе при каскадной активации зависимых дочерних потоков. Позволяет отслеживать частоту деплоев и динамику изменений в продуктивной среде.	Счётчик (count)
route_deactivation_count	Счётчик успешных деактиваций маршрутов. Увеличивается на 1 при каждой деактивации версии потока, включая каскадные отключения дочерних потоков при деактивации родительского. Помогает оценить частоту откатов, отключений и изменений топологии.	Счётчик (count)
route_activation_time_sec	Длительность операции активации маршрута (версии потока) в секундах. Фиксирует время выполнения всей цепочки действий: проверки зависимостей, согласования версий, каскадных операций и записи изменений в Configuration Server. Используется для выявления аномально долгих активаций.	Гистограмма (histogram)
route_deactivation_time_sec	Длительность операции деактивации маршрута (версии потока) в секундах. Включает время проверки зависимостей, каскадного отключения дочерних потоков, обновления статусов и записи изменений в Configuration Server. Позволяет оценить производительность операций управления версиями и выявить задержки.	Гистограмма (histogram)

К стандартному набору лейблов для кастомных метрик добавляется свой набор лейблов:

Лейбл	Описание	Пример значения
status	Статус операции: успех или ошибка. Используется для расчёта доли ошибок, построения rate‑алертов и быстрой фильтрации проблемных событий.	success, error
route_id	Уникальный идентификатор интеграционного потока. Ключевой лейбл для точечной диагностики: по нему можно собрать полную картину по одному потоку (активации, latency, ошибки).	54d19232-1b48-4485-9110-bb3a83c3e846
route_name	Человекочитаемое имя потока. Используется в дашбордах и отчётах .	OrderToERP_v2
domain_id	Идентификатор домена, к которому принадлежит поток.	4e50c22c-c7eb-4a7a-ae5d-5872b00ab311