Бенчмарк Prometheus vs VictoriaMetrics на метриках node_exporter

[Kate]

Недавно в VictoriaMetrics появилась возможность скрейпинга целевых объектов Prometheus. И теперь мы можем сравнивать яблоки с яблоками: сколько ресурсов используют Prometheus и VictoriaMetrics при скрейпинге большого количества node_exporter.

Настройка бенчмарка​

Тестирование проводилось в Google Compute Engine на четырех машинах (инстансах):

• Инстанс с node exporter v1.0.1 для скрейпинга. Машина e2-standard-4 со следующей конфигурацией: 4 vCPU, 16 ГБ RAM, 1 ТБ HDD. Первоначальные тесты показали, что node_exporter не может обрабатывать больше нескольких сотен запросов в секунду. Prometheus и VictoriaMetrics во время тестов создавали слишком большую нагрузку на node_exporter. Поэтому было решено перед node_exporter разместить nginx с односекундным кешированием ответов. Это позволило снизить нагрузку на node_exporter до разумных значений, чтобы он смог обрабатывать все поступающие запросы без ошибок скрейпинга.
• Два отдельных инстанса e2-highmem-4 для Prometheus v2.22.2 и VictoriaMetrics v1.47.0 со следующей конфигурацией: 4 vCPU, 32 ГБ RAM, 1 ТБ. Как VictoriaMetrics, так и Prometheus запускались с настройками по умолчанию, за исключением пути к файлу с конфигурациями скрейпинга (-promscrape.config = prometheus.yml для VictoriaMetrics и -config.file = prometheus.yml для Prometheus). Файл prometheus.yml был сгенерирован по следующему шаблону Jinja2:

global:
scrape_interval: 10s
scrape_configs:
- job_name: node_exporter
static_configs:
{% for n in range(3400) %}
- targets: ['host-node-{{n}}:9100']
labels:
host_number: cfg_{{n}}
role: node-exporter
env: prod
{% endfor %}
Все host-node-{{n}} указывали на машину с node_exporter. Это было сделано через /etc/hosts. Таким образом мы эмулировали скрейпинг 3400 node_exporter.

• Машина e2-standard-2 для мониторинга VictoriaMetrics и Prometheus. Инстанс VictoriaMetrics на этой машине был сконфигурирован для получения специфичных метрик приложения, а также метрик node_exporter от машин с VictoriaMetrics и Prometheus. На основе этих метрик были построены приведенные ниже графики.

Мы выбрали node_exporter по следующим причинам:

• node_exporter — самый распространенный экспортер, который используется большинством инсталляций Prometheus.
• node_exporter экспортирует реальные метрики под нагрузкой (использование процессора, памяти, дискового ввода-вывода, сети и т. д.), поэтому результаты тестов могут быть экстраполированы на инсталляции Prometheus в продакшн.

И VictoriaMetrics, и Prometheus скрайпили один и тот nodeexporter и были запущены одновременно. Бенчмарк длился 24 часа.

Статистика хранилища​

Для VictoriaMetrics и Prometheus статистика одинаковая:

• Скорость приема (ingestion rate): 280 тыс. измерений / сек.
• Количество активных временных рядов (active time series): 2,8 миллиона
• Количество сохраненных измерений (samples scraped and stored): 24,5 миллиарда

Результаты тестов​

Использование дискового пространства:

Использование дискового пространства.
Prometheus с регулярными интервалами генерирует пики использования дискового пространства в 15 ГБ, а VictoriaMetrics — редкие и гораздо меньшие всплески. Максимальный всплеск для VictoriaMetrics составляет 4 ГБ. Давайте посмотрим на итоговую статистику использования дискового пространства:

• VictoriaMetrics: 7,2 ГБ. Это соответствует 0,3 байтам на одно измерение (7,2 ГБ / 24,5 миллиарда измерений).
• Prometheus: 52,3 ГБ (32,3 ГБ данных + 18 ГБ WAL). Это соответствует 52,3 ГБ / 24,5 миллиарда измерений = 2,1 байта на измерение. Получается, что Prometheus требует в 7 раз (2,1 / 0,3) больше места для хранения тех же объемов данных.

Использование дискового ввода-вывода:

Дисковый ввод-вывод: байт, записанных в секунду.

Дисковый ввод-вывод: байт, прочитанных в секунду.
Что касается чтения с диска, то Prometheus генерирует всплески до 95 МБ/с через равные интервалы времени, в то время как максимальный всплеск для VictoriaMetrics составляет 15 МБ/с.

Использование процессора:

Использование CPU, ядер vCPU.

• Для скрайпинга 3400 node_exporter используется 1,5–1,75 ядер vCPU. Это означает, что мощности системы с четырьмя vCPU достаточно для скрайпинга дополнительных 4000 node_exporter.
• Пиковые нагрузки на процессор в обоих случаях связаны с фоновым сжатием данных. Эти всплески для VictoriaMetrics в целом безвредны, но то же время могут привести к OOM (out of memory) для Prometheus. Подробнее о фоновом сжатии (также называемом слиянием) в VictoriaMetrics смотрите в этой статье.

Использование памяти:

Использование RSS-памяти.
VictoriaMetrics постоянно использует 4,3 ГБ RSS-памяти, в то время как у Prometheus память начинается с 6,5 ГБ и стабилизируется на уровне 14 ГБ со всплесками до 23 ГБ. Эти всплески использования памяти часто приводят к падению с OOM и потере данных, если на машине нет достаточного количества памяти или есть ограничения по памяти для подов Kubernetes с Prometheus. К счастью, на тестовой машине было 32 ГБ ОЗУ, поэтому сбоев не наблюдалось. Если вы хотите узнать подробнее о том, почему Prometheus может потерять данные после некорректного завершения работы, например, из-за OOM, то прочтите эту статью.

Согласно приведенному выше графику, Prometheus требует в 5,3 раза (23 ГБ / 4,3 ГБ) больше оперативной памяти, чем VictoriaMetrics.

Выводы​

И Prometheus, и VictoriaMetrics могут собирать миллионы метрик с тысяч целевых объектов на машине с парой ядер vCPU. В соответствии с этими бенчмарками это гораздо лучший результат, чем InfluxDB и TimescaleDB.

VictoriaMetrics требует до 5 раз меньше оперативной памяти и до 7 раз меньше дискового пространства по сравнению с Prometheus при скрайпинге тысяч node_exporter. Это приводит к значительной экономии на инфраструктуре.

P.S. Если вы еще не использовали VictoriaMetrics, то самое время попробовать. VictoriaMetrics бесплатная и с открытым исходным кодом (включая кластерную версию). Если вам нужны корпоративные возможности и поддержка, посетите сайт.


Источник статьи: https://habr.com/ru/company/otus/blog/541640/