[DevOps] Бенчмарк Prometheus vs VictoriaMetrics на метриках node_exporter (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Для будущих студентов курса «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 МБ/с.Использование процессора:
Использование 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 бесплатная и с открытым исходным кодом (включая кластерную версию). Если вам нужны корпоративные возможности и поддержка, посетите сайт.
Узнать подробнее о курсе «DevOps практики и инструменты».
Смотреть открытый вебинар на тему «Prometheus: быстрый старт».
===========
Источник:
habr.com
===========
===========
Автор оригинала: Aliaksandr Valialkin
===========Похожие новости:
- [Hadoop, Data Engineering] Почему ваши приложения Spark работают медленно или выходят из строя (перевод)
- [Тестирование IT-систем, JavaScript] Перестаньте использовать Page Objects (РО) и начните использовать App Actions (перевод)
- [Информационная безопасность, Сетевые технологии] Исследование вредоносного трафика
- [IT-компании, Микросервисы] Микросервисы VS монолит: баттл адептов
- [Разработка под iOS, Swift] Создание пользовательских функций запросов с key paths (перевод)
- [Программирование, Java] Шпаргалка по Spring Boot WebClient (перевод)
- [Data Engineering] Что такое фильтр Блума? (перевод)
- [Математика] Новые квантовые алгоритмы, совершившие прорыв в нелинейных уравнениях (перевод)
- [Хостинг, Хранение данных, DevOps, Облачные сервисы] Вебинар «Выбираем облачные системы хранения для ваших сервисов» 25 февраля от Mail.ru Group
- [Тестирование IT-систем, Тестирование веб-сервисов, Управление разработкой, DevOps] Как мы строили параллельные вселенные для нашего (и вашего) CI/CD пайплайна в Octopod
Теги для поиска: #_devops, #_devops, #_prometheus, #_victoriametrics, #_monitoring, #_benchmarking, #_blog_kompanii_otus (
Блог компании OTUS
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:53
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Для будущих студентов курса «DevOps практики и инструменты» подготовили перевод интересного материала.
Также приглашаем всех желающих поучаствовать в открытом вебинаре на тему «Prometheus: быстрый старт». На занятии участники рассмотрят архитектуру Prometheus и то, как она работает с метриками, а также разберут, как формировать алерты и события в системе.  Недавно в VictoriaMetrics появилась возможность скрейпинга целевых объектов Prometheus. И теперь мы можем сравнивать яблоки с яблоками: сколько ресурсов используют Prometheus и VictoriaMetrics при скрейпинге большого количества node_exporter.Настройка бенчмаркаТестирование проводилось в Google Compute Engine на четырех машинах (инстансах):
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 %}
 Использование дискового пространства.Prometheus с регулярными интервалами генерирует пики использования дискового пространства в 15 ГБ, а VictoriaMetrics — редкие и гораздо меньшие всплески. Максимальный всплеск для VictoriaMetrics составляет 4 ГБ. Давайте посмотрим на итоговую статистику использования дискового пространства:
 Дисковый ввод-вывод: байт, записанных в секунду.  Дисковый ввод-вывод: байт, прочитанных в секунду.Что касается чтения с диска, то Prometheus генерирует всплески до 95 МБ/с через равные интервалы времени, в то время как максимальный всплеск для VictoriaMetrics составляет 15 МБ/с.Использование процессора:  Использование CPU, ядер vCPU.
 Использование 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 бесплатная и с открытым исходным кодом (включая кластерную версию). Если вам нужны корпоративные возможности и поддержка, посетите сайт. Узнать подробнее о курсе «DevOps практики и инструменты».
Смотреть открытый вебинар на тему «Prometheus: быстрый старт». =========== Источник: habr.com =========== =========== Автор оригинала: Aliaksandr Valialkin ===========Похожие новости:
Блог компании OTUS ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:53
Часовой пояс: UTC + 5