Для будущих студентов курса «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 достаточно для скрайпинга дополнительных 4000node_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: быстрый старт».
