Архитектура мониторинга

Архитектура мониторинга#

Мониторинг Astra Automation строится на централизованном сборе метрик, проверках доступности и анализе журналов компонентов. Архитектура зависит от варианта развертывания платформы: из deb-пакетов на виртуальных машинах или в кластере Kubernetes.

Компоненты системы мониторинга#

Для централизованного мониторинга обычно используют следующие инструменты:

  • Prometheus – сбор и хранение метрик. Prometheus получает данные из различных источников, сохраняет их во внутренней базе временных рядов (TSDB, time-series database) и предоставляет средства для выполнения запросов.

  • Grafana – визуализация данных и построение панелей мониторинга. Grafana получает данные из Prometheus и строит графики, диагностические панели и отчеты.

  • Alertmanager – обработка сигналов оповещения и отправка уведомлений. Alertmanager получает сигналы оповещения от Prometheus, группирует их, подавляет повторы и отправляет уведомления администраторам.

Архитектура мониторинга для ВМ#

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

Prometheus получает данные непосредственно от компонентов платформы, как представлено на следующей схеме:

../../../_images/arch-vm-light.svg ../../../_images/arch-vm-dark.svg

Схема разделяет узлы Astra Automation и узел мониторинга. На узле мониторинга размещаются Prometheus, Grafana, Alertmanager и blackbox_exporter. Prometheus обращается к компонентам платформы, инфраструктурным сервисам и экспортерам по сетевым адресам, указанным в конфигурации сбора метрик. Grafana получает данные из Prometheus, а Alertmanager обрабатывает сигналы оповещения.

В представленной системе источниками данных являются:

  • метрики Automation Controller;

  • метрики Private Automation Hub;

  • метрики операционной системы узлов;

  • метрики PostgreSQL;

  • метрики Redis;

  • проверки доступности сервисов;

  • журналы компонентов.

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

Архитектура мониторинга для Kubernetes#

При развертывании платформы в кластере Kubernetes компоненты мониторинга обычно размещают внутри кластера. Для подключения источников данных и обнаружения сервисов используют механизмы Kubernetes и Prometheus Operator.

../../../_images/arch-k8s-light.svg ../../../_images/arch-k8s-dark.svg

Схема показывает два основных пространства имен: пространство имен Astra Automation и пространство имен системы мониторинга. В пространстве имен мониторинга находятся Prometheus Operator, Prometheus, Grafana, Alertmanager, blackbox_exporter, kube-state-metrics и node_exporter. В пространстве имен Astra Automation находятся сервисы и поды платформы, а также ресурсы ServiceMonitor и Probe; правила оповещений задаются ресурсом PrometheusRule.

В этой системе Prometheus получает данные от сервисов и компонентов платформы через ресурсы Kubernetes для автоматического обнаружения источников данных. Кроме метрик компонентов платформы, контролируйте состояние узлов Kubernetes, контейнеров и постоянных томов.

Обязательный уровень мониторинга#

Для базового контроля работоспособности платформы собирайте данные по компонентам, перечисленным в таблице ниже.

Источник

Объект контроля

Назначение

Gateway

Доступность сервисов и API

Контроль доступности платформы

Automation Controller

Выполнение заданий, емкость узлов, обработка событий

Контроль основных функций платформы

Private Automation Hub

Импорт коллекций, выгрузка артефактов и обработка запросов

Контроль операций управления контентом

Event-Driven Automation

Доступность сервиса и состояние узла

Контроль событийной автоматизации

PostgreSQL

Подключения, блокировки и производительность запросов

Контроль активности СУБД

Redis

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

Контроль обработки внутренних событий

Узлы платформы

Процессор, память, диски и сеть

Контроль использования ресурсов

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

Ошибки и диагностические сообщения

Анализ причин возникновения неисправностей

Дополнительный уровень мониторинга#

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

Источник

Назначение

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

Контроль доступности пользовательских сценариев и точек доступа API

Мониторинг сертификатов

Контроль сроков действия сертификатов TLS

Контроль резервного копирования

Проверка актуальности и успешности резервного копирования

Централизованное хранение журналов

Корреляция событий мониторинга и записей журналов

Долговременное хранение метрик

Анализ исторических данных за длительный период