Для будущих студентов курса «DevOps практики и инструменты» подготовили перевод интересного материала.

Также приглашаем всех желающих поучаствовать в открытом вебинаре на тему «Prometheus: быстрый старт». На занятии участники рассмотрят архитектуру Prometheus и то, как она работает с метриками, а также разберут, как формировать алерты и события в системе.

Недавно в 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 МБ/с.

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

• Для скрайпинга 3400 node_exporter используется 1,5–1,75 ядер vCPU. Это означает, что мощности системы с четырьмя vCPU достаточно для скрайпинга  дополнительных 4000 node_exporter.

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

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

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 бесплатная и с открытым исходным кодом (включая кластерную версию). Если вам нужны корпоративные возможности и поддержка, посетите сайт.

Узнать подробнее о курсе «DevOps практики и инструменты».

Смотреть открытый вебинар на тему «Prometheus: быстрый старт».