Обзор Arenadata Monitoring

Дмитрий Булгаков

Функции

Arenadata Monitoring (ADM) — централизованная система мониторинга и наблюдения для экосистемы Arenadata, построенная на современном стеке компонентов с открытым исходным кодом.

Основные функциональные возможности ADM перечислены ниже:

  • Полный цикл работы с метриками для наблюдения и мониторинга, от сбора данных до их анализа и визуализации.

  • Централизованное долгосрочное хранение метрик в отказоустойчивой распределенной базе данных временных рядов (Time Series Database, TSDB) на основе VictoriaMetrics Cluster.

  • Активный мониторинг и единая модель оценки состояния продуктов Arenadata (healthy, degraded, critical).

  • Поддержка дашбордов, поставляемых вместе с продуктами Arenadata.

  • Открытая архитектура с возможностью интеграции внешних систем сбора метрик и визуализации.

Архитектура

Основными компонентами архитектуры ADM являются:

  • VictoriaMetrics. Высокопроизводительная база данных временных рядов и платформа для хранения данных мониторинга, включающая распределенное хранилище и вспомогательные компоненты для сбора, хранения и выполнения запросов к данным. ADM использует следующие компоненты VictoriaMetrics:

    • VictoriaMetrics Insert — получение данных.

    • VictoriaMetrics Storage — постоянное хранение, сжатие и извлечение данных временных рядов.

    • VictoriaMetrics Select — выполнение запросов к базе данных.

  • Grafana. Платформа визуализации и мониторинга, используемая для отображения метрик, журналов и трассировок, получаемых из различных источников данных.

Чтобы метрики были доступны для экспорта из кластера-источника данных, в нем должны быть установлены следующие компоненты:

  • Экспортеры метрик (Node Exporter, JMX Exporter). Агенты для сбора и передачи метрик операционной системы и сервисных метрик.

  • Один из следующих компонентов:

    • VictoriaMetrics Agent. Легковесный агент для сбора метрик из различных источников, их маркировки и фильтрации, а также передачи на хранение в VictoriaMetrics Storage или любую другую систему хранения метрик через Prometheus-совместимый протокол remote_write.

      ПРИМЕЧАНИЕ

      В данный момент VictoriaMetrics Agent недоступен в некоторых продуктовых бандлах Arenadata.
      Архитектура мониторинга (рекомендуемые компоненты)
      Архитектура мониторинга (рекомендуемые компоненты)
      Архитектура мониторинга (рекомендуемые компоненты)
      Архитектура мониторинга (рекомендуемые компоненты)

    • Prometheus. Платформа визуализации и мониторинга, которая используется для отображения метрик, логов и трассировок, полученных из различных источников данных.

      Архитектура мониторинга (альтернативные компоненты)
      Архитектура мониторинга (альтернативные компоненты)
      Архитектура мониторинга (альтернативные компоненты)
      Архитектура мониторинга (альтернативные компоненты)

Процесс работы мониторинга

  1. Процесс мониторинга начинается с генерации метрик на узлах и сервисах инфраструктуры. Компоненты Node Exporter каждого хоста собирают метрики операционной системы (CPU, RAM, дисковые показатели, сетевой ввод-вывод). JMX Exporter получает данные из JMX MBeans, предоставляемых приложениями на базе JVM, и экспортирует метрики приложений в формате Prometheus. Таким образом становятся доступны метрики Java-сервисов.

  2. Для сбора метрик и их передачи в долговременное хранилище может использоваться один из следующих компонентов:

    • VictoriaMetrics Agent периодически опрашивает (scrape) экспортеры по HTTP, может применять разметку и фильтрацию метрик, после чего отправляет данные через механизм remote_write в центральный кластер VictoriaMetrics. VictoriaMetrics Agent не хранит данные локально и выступает как легковесный сборщик метрик единого edge-слоя. Такой подход снижает потребление ресурсов на стороне кластера и упрощает эксплуатацию мониторинга.

    • Альтернативным компонентом для сбора метрик является Prometheus. Prometheus опрашивает экспортеры, сохраняет метрики в свою локальную TSDB и параллельно передает их в центральный кластер VictoriaMetrics с помощью remote_write. Наличие локального хранилища позволяет обеспечить автономность кластера и взаимодействие с существующей Prometheus-совместимой инфраструктурой. Использование этого варианта позволяет выполнять локальный анализ метрик с помощью локальной Grafana, подключенной к серверу Prometheus.

  3. После отправки все метрики поступают в компонент VictoriaMetrics Insert кластера VictoriaMetrics. Он принимает входящий поток данных и распределяет временные ряды между шардами хранения в соответствии с алгоритмом шардинга кластера.

  4. Затем данные сохраняются в VictoriaMetrics Storage. Этот компонент отвечает за долговременное хранение метрик, сжатие данных, политики хранения (retention policy) и, при соответствующей настройке, репликацию. Благодаря высокой степени сжатия VictoriaMetrics позволяет хранить большие объемы данных временных рядов при относительно низком потреблении дискового пространства и памяти.

  5. Когда пользователь открывает дашборд в Grafana, запрос поступает в компонент VictoriaMetrics Select. Он выполняет распределенный запрос, агрегирует данные со всех узлов хранения и возвращает результат клиенту. Для пользователя система выглядит как единое централизованное хранилище метрик независимо от того, из какого кластера поступили данные и каким способом они были собраны. Grafana подключается к VictoriaMetrics как к единому источнику данных. На дашбордах отображаются как инфраструктурные метрики Node Exporter, так и метрики приложений, полученные через JMX Exporter. Это обеспечивает централизованное наблюдение за всей распределенной системой из единого интерфейса.

Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней