С чего все началось

В рамках расширения функциональности модуля аналитики, мы приняли решение активно развивать направление инфраструктурного мониторинга. Это направление представляет собой важный компонент нашей системы, так как при работе с большим количеством разнообразных платформ виртуализации и публичных облаков в одном эндпоинте (которым является платформа Cloudlink), возникает немало сложностей в получении информации об утилизации оборудования непосредственно с платформ.

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

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

И, наконец, глубина данных и временные ряды метрик также являются индивидуальными для каждой подключаемой к системе платформы. Это требует гибкости и настройки для каждого конкретного случая.

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

1. Prometheus, как одно из лидирующих решений в этой области
2. Victoria Metrics, как современную и улучшенную альтернативу.

Prometheus

Prometheus - комплексное решение, в состав которого входят и фреймворк для мониторинга, и собственная темпоральная база данных.

Принцип работы:

• Сервер считывает и сохраняет метрики в базе данных с использованием механизма pull, при котором сам получает метрики из указанных эндпоинтов
• Есть возможность сбора метрик с помощью механизма push, используя компонент Pushgateway. Механизм push полезен, когда невозможно собрать метрики с помощью pull по разным причинам, например, из-за ограничений фаерволла или короткой продолжительности жизни объектов
• Также Prometheus предоставляет удобный механизм обнаружения объектов для мониторинга - discovering. Вместо указания конкретных адресов объектов, достаточно указать их тип. Prometheus сам найдет активные объекты и добавит их в мониторинг. Это особенно удобно в Kubernetes, где объекты могут динамически меняться
• Сбор метрик осуществляется с помощью экспортеров. Экспортеры - программы, снимающие метрики с процессов и представляющие их в виде человекочитаемых данных на определенном http-порту. Prometheus поддерживает множество экспортеров для различных метрик, снимаемых с процессов в операционной системе и программного обеспечения, таких как веб-серверы, SQL-СУБД, хеш-СУБД и т.д. Экспортеры можно устанавливать из официальных репозиториев или собирать из исходников. Также есть сообщество разработчиков экспортеров для разработки собственных экспортеров
• Метрики хранятся в темпоральной базе данных Prometheus, использующей LevelDB для хранения индексов. Prometheus хранит агрегированные метрики о сервисах, отличаясь от других баз данных временных рядов, которые собирают необработанные метрики. Данные в Prometheus хранятся в формате временных рядов, состоящем из имени метрики, временной метки и значений

Однако, Prometheus не подходит для длительного хранения метрик из-за большого потребления ресурсов CPU и RAM, поэтому рекомендуется использовать внешние хранилища, такие как InfluxDB или ClickHouse.
Также Prometheus оптимизирован для работы в одной ноде, для поддержки кластеризации требуется сложная настройка

VictoriaMetrics

VictoriaMetrics - изначально быстрая и масштабируемая СУБД для хранения и обработки временных рядов (запись времени и соответствующих значений), но с разработкой vmagent-а она, как и Prometheus, также становится комплексным решением

Основные особенности Vmagent:

• Сбор метрик как по pull-модели, так и по push моделям. Vmagent отправляет http-запросы на цели и получает список метрик. Он также может получать метрики по push-модели от разных клиентов (Telegraf, statsd и другие)
• Фильтрация собранных метрик с возможностью модификации имен и лейблов
• Сохранение метрик в удаленные хранилища через remote_write-протокол. Можно настроить репликацию в несколько хранилищ, такие как VictoriaMetrics, Vmagent, Cortex и другие
• Vmagent имеет дисковый буфер, чтобы не потерять метрики при недоступности хранилища.
• Сниженное потребление ресурсов
• Нативная поддержка кластеризации и репликации
• Возможность долгосрочного хранения данных без разрастающихся требований к ресурсам

Prometheus vs VictoriaMetrics

Основные недостатки Prometheus, решенные в VictoriaMetrics

• Для долгосрочного хранения в Prometheus требуется выгрузка в другие СУБД
• Большее потребление ресурсов
• Невозможно ограничить потребление памяти
• Prometheus спроектирован как система для одной ноды. Не поддерживается работа в кластере нативно, требуется сложная настройка двух одинаковых нод

Важно отметить, что VictoriaMetrics работает с экпортерами Prometheus, которых как официально, так и в рамках сообщества, написано большое количество практически под любые задачи.

Что мы выбрали

Рассматривая оба этих варианта, мы решили использовать VictoriaMetrics. Это более легковесное решение, которое основано на проверенной логике работы Prometheus, но при ее разработке учтены текущие проблемы конкурентов. При этом в VictoriaMetrics есть полноценная поддержка экспортеров prometheus и других популярных решений/форматов метрик.