Источники данных мониторинга

Содержание

Источники данных мониторинга#

В зависимости от типа контролируемой информации компоненты предоставляют данные в виде метрик, ответов API, записей потока активности или журналов компонентов. Основными источниками данных мониторинга являются:

Метрики Prometheus;
Проверка состояния сервисов;
Поток активности;
Журналы компонентов.

Каждый источник данных закрывает отдельный класс задач, поэтому используйте источники совместно.

Обзор источников данных#

Внешняя система мониторинга может получать данные из нескольких источников одновременно.

Источник данных	Способ получения	Назначение
Automation Controller	Метрики Prometheus	Контроль выполнения заданий, нагрузки и состояния внутренних сервисов
Private Automation Hub	Метрики Prometheus	Контроль операций с коллекциями и обработки запросов
Gateway	API проверки состояния	Контроль доступности основных компонентов платформы. Gateway не предоставляет точку доступа метрик Prometheus, поэтому его состояние проверяется через API состояния или синтетические проверки.
Event-Driven Automation	API проверки состояния и журналы	Контроль работоспособности событийной автоматизации. Event-Driven Automation не предоставляет точку доступа метрик Prometheus, поэтому для него обязательно используйте проверку состояния и метрики узла или пода.
Узлы платформы	Метрики операционной системы	Контроль использования вычислительных ресурсов
PostgreSQL	Метрики Prometheus	Контроль состояния базы данных
Redis	Метрики Prometheus	Контроль очередей и внутренних сервисов обработки событий
Проверки доступности	`blackbox_exporter`	Контроль доступности графических консолей, API и сетевых сервисов
Поток активности	Графическая консоль и API	Аудит действий пользователей и изменений конфигурации
Журналы компонентов	Файлы журналов	Диагностика неисправностей

Метрики Prometheus#

Метрики дают основную количественную информацию о работе платформы. Они содержат числовые значения и временные ряды, по которым можно контролировать состояние компонентов, анализировать нагрузку и выявлять отклонения в работе сервисов.

Automation Controller и Private Automation Hub публикуют данные в формате Prometheus, поэтому внешняя система мониторинга может получать их напрямую. С помощью метрик Automation Controller и Private Automation Hub можно контролировать следующие аспекты:

выполнение заданий;
использование емкости узлов;
размер очередей обработки событий;
производительность сервисов;
использование ресурсов операционной системы;
состояние PostgreSQL;
состояние Redis.

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

Automation Controller#

Automation Controller предоставляет метрики с помощью следующего запроса к API Gateway:

GET https://<gateway_address>/api/controller/v2/metrics/

Здесь <gateway_address> – IP-адрес или FQDN Gateway. Для доступа к метрикам требуется токен с правами чтения, если анонимный доступ к метрикам явно не включен. В производственной среде используйте токен и не включайте анонимный доступ.

Метрики Automation Controller позволяют контролировать следующие аспекты:

количество выполняемых и ожидающих заданий;
использование емкости узлов;
обработку событий;
состояние внутренних сервисов контроллера.

Private Automation Hub#

Private Automation Hub предоставляет метрики с помощью следующего запроса к собственному API:

GET https://<hub_address>/metrics

Здесь <hub_address> – FQDN или IP-адрес узла Private Automation Hub. Если точка доступа не требует авторизации, ограничьте доступ к ней на уровне межсетевого экрана, списка разрешенных источников или сетевых политик Kubernetes.

Метрики Private Automation Hub позволяют контролировать следующие аспекты:

импорт коллекций;
выгрузку артефактов;
обработку запросов HTTP;
использование ресурсов процесса.

Event-Driven Automation#

Event-Driven Automation не предоставляет точку доступа метрик Prometheus. Для контроля состояния Event-Driven Automation используйте проверку состояния сервиса, метрики операционной системы и журналы компонента.

PostgreSQL и Redis#

PostgreSQL и Redis относятся к важным инфраструктурным компонентам платформы. Для получения их метрик используйте специализированные экспортеры Prometheus.

Метрики PostgreSQL позволяют контролировать следующие аспекты:

количество подключений;
блокировки;
задержки выполнения запросов;
репликацию.

Метрики Redis позволяют контролировать следующие аспекты:

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

Метрики операционной системы#

Для контроля состояния узлов используется сервис node_exporter.

node_exporter – экспортер Prometheus для сбора метрик операционной системы. Администратор устанавливает сервис на каждый узел платформы. node_exporter периодически считывает информацию из операционной системы и публикует ее по HTTP в формате Prometheus.

Сам node_exporter не выполняет хранение, анализ или обработку данных. Его задача заключается только в предоставлении метрик внешней системе мониторинга.

С помощью node_exporter можно получать информацию о следующих характеристиках операционной системы:

загрузка процессора;
использование оперативной памяти;
использование файловых систем;
свободное место на дисках;
сетевая активность;
нагрузка на устройства хранения данных;
время работы узла.

Эти метрики помогают своевременно выявлять нехватку ресурсов, перегрузку узлов и инфраструктурные проблемы, влияющие на работу платформы.

Проверки доступности сервисов#

Метрики не всегда позволяют определить, доступен ли сервис для пользователей или внешних систем. Например, процесс приложения может продолжать работать, однако графическая консоль или точка доступа API могут быть недоступны из-за сетевых проблем, ошибок маршрутизации или некорректной конфигурации.

Для контроля подобных ситуаций используется blackbox_exporter.

blackbox_exporter – экспортер Prometheus, который выполняет внешние проверки сервисов и публикует результаты в формате Prometheus. blackbox_exporter позволяет получать информацию о результатах следующих проверок:

доступность сервисов, работающих по HTTP и HTTPS;
доступность точек доступа API;
доступность портов TCP;
корректность сертификатов TLS;
время отклика сервисов.

Используйте результаты проверок для построения панелей мониторинга и формирования сигналов оповещения о недоступности сервисов.

Проверка состояния сервисов#

Для контроля доступности основных компонентов платформы используются точки доступа проверки состояния.

Общая точка доступа#

Точку доступа проверки состояния предоставляет Gateway. В ответе содержится агрегированная информация о состоянии компонентов платформы.

Для получения данных используйте запрос с токеном доступа:

curl -sk \
  -H "Authorization: Bearer <token>" \
  https://<gateway_address>/api/gateway/v1/status/

Здесь:

<token> – токен доступа с правами чтения;
<gateway_address> – IP-адрес или FQDN Gateway.

Пример ответа:

{
  "status": "good",
  "services": [
    {"service_type": "controller", "status": "good"},
    {"service_type": "hub", "status": "good"},
    {"service_type": "eda", "status": "good"},
    {"service_type": "redis", "status": "good"}
  ]
}

Состояние good означает, что соответствующий компонент доступен и готов к работе.

Точка доступа Event-Driven Automation#

Event-Driven Automation не предоставляет точку доступа метрик Prometheus, поэтому контролируйте этот компонент с помощью проверки состояния, системных метрик узла или пода (pod) и журналов компонента.

Для контроля Event-Driven Automation дополнительно используйте следующую точку доступа состояния сервиса:

curl -sk https://<gateway_address>/api/eda/v1/status/

Эти проверки можно выполнять вручную, через blackbox_exporter или через отдельный экспортер синтетических проверок, если нужно проверять не только код HTTP, но и значение поля status в ответе.

Поток активности#

Поток активности (Activity Stream) хранит данные для аудита действий пользователей и изменений конфигурации платформы. В отличие от метрик, поток активности отражает не текущее состояние системы, а историю изменений объектов платформы.

Используйте поток активности при расследовании инцидентов и анализе изменений конфигурации.

Журналы компонентов#

Журналы компонентов дают детальную техническую информацию о работе платформы. Используйте их в следующих целях:

анализ ошибок выполнения заданий;
диагностика проблем API;
расследование инцидентов;
анализ взаимодействия компонентов платформы.

В отличие от метрик журналы позволяют восстановить последовательность отдельных операций и получить подробную информацию о причинах возникновения ошибок.

Полный перечень журналов компонентов см. в справочнике.