Мониторинг может оказаться дорогим делом из-за огромных объемов данных, которые необходимо обрабатывать. В этой статье вы узнаете о лучших способах хранения и обработки метрик мониторинга для снижения расходов и о том, как VictoriaMetrics может в этом помочь.

В этой статье рассматриваются только решения с открытым исходным кодом. VictoriaMetrics — проект с открытым исходным кодом. Вы получите максимальную пользу от этой статьи, если знакомы с Prometheus, Thanos, Mimir или VictoriaMetrics.

См. вторую статью из этой серии — Как снизить расходы на мониторинг: более разумный подход к данным.

Прежде чем мы сможем говорить о снижении расходов на мониторинг, нам сначала нужно понять системы мониторинга. Ниже приведена типичная архитектура мониторинга:

В приведенной выше архитектуре есть система мониторинга, которая отвечает за периодический сбор метрик со служб, о которых ей известно. Эта архитектура называется моделью pull, так как система мониторинга активно запрашивает данные. Модель pull была популяризирована Prometheus и также поддерживается VictoriaMetrics.

Дополнением к модели pull является модель push:

Модель push является обратной по отношению к модели pull. В модели push приложения знают о системе мониторинга и отвечают за отправку метрик в нее. Модель push поддерживается VictoriaMetrics с самого начала, поддерживается Mimir, и недавно Prometheus ввел поддержку для нее за флагом функции.

Можно смешивать и сочетать две модели:

В смешанной топологии обычно есть агент, который отвечает за сбор метрик, подобно системе мониторинга в модели pull. Агент размещается как можно ближе к приложениям, в идеале в одном кластере. После сбора метрик агент отвечает за их отправку в систему мониторинга, как это делало бы приложение в модели push.

Независимо от того, какую архитектуру вы выберете, в конце месяца будут четыре фактора, которые повлияют на ваш счет за инфраструктуру:

• Процессор

• Память

• Диск

• Сеть

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

Замена Prometheus на VictoriaMetrics

Эквивалент приобретения более быстрого автомобиля в мониторинге — это замена вашей текущей базы данных на более эффективную. В этом разделе мы рассмотрим замену Prometheus на VictoriaMetrics.

VictoriaMetrics является заменой Prometheus «из коробки», практически без необходимости изменения конфигурации. Во многих случаях вы можете просто заменить бинарные файлы. Если вам интересно попробовать VictoriaMetrics с вашей системой, ознакомьтесь с документацией для получения дополнительной информации.

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

Для целей бенчмаркинга мы используем наш инструмент Remote write benchmark, который мы уже упоминали в предыдущих статьях:

• Как генерировать 100 миллионов семплов/с данных, похожих на данные с прода

• Grafana Mimir и VictoriaMetrics: тесты производительности

Этот бенчмарк был разработан для тестирования баз данных временных рядов путем отправки данных. Хотя Prometheus поддерживает как модели push, так и pull, его модель pull сейчас кажется намного более эффективной и оптимизированной. Поэтому, чтобы сделать бенчмарк честным, мы настроили Prometheus и одноузловой VictoriaMetrics на сбор данных с одного и того же списка целей, используя одну и ту же конфигурацию, и выполнение одного и того же списка запросов на чтение, генерируемых автономным ruler:

Вот некоторые из спецификаций для этого бенчмарка:

• VictoriaMetrics и Prometheus работают на одной и той же конфигурации экземпляра (3 vCPU, 12 GiB RAM);

• 1000 целей Node Exporter для симуляции мониторинга 1000 экземпляров, каждая цель предоставляет около 1200 уникальных временных рядов;

• Интервал сбора данных 15 с, определяет, как часто собирать данные с целей. Для 1000 целей по 1200 временных рядов каждая, прием данных должен составлять около 1000 * 1200 / 15 с = 80 тыс. семплов/с;

• Интервал оценки правил 30 с, определяет, как часто отправлять запросы на чтение. Для этого набора правил бенчмарк будет генерировать около 1 запроса на чтение в секунду;

• Churn rate 5% каждые 10 минут, определяет, сколько целей изменит свои метки в течение 10-минутного интервала. Другими словами, каждые 10 минут будет генерироваться 1000 целей * 5% * 1200 = 60 тыс. новых временных рядов. (Churn rate можно перевести как "частота изменений", "интенсивность изменений" или "скорость обновления данных").

Churn rate выше симулирует изменение целей метрик с течением времени. Это представляет особый интерес при мониторинге приложений, развернутых в Kubernetes. В Kubernetes есть понятие pod-ов, которые являются эфемерными экземплярами приложения. Всякий раз, когда развертывается новая версия приложения или требуется перезапуск, создается новый pod. Поскольку каждый pod имеет случайно сгенерированное имя, воссоздание pod-а создает новую цель метрик и делает старую недействительной.

Результаты

Бенчмарк выполнялся в течение семи дней в этом эксперименте. Метрики системы как для Prometheus, так и для VictoriaMetrics были зафиксированы на снимке Grafana здесь.

В среднем скорость приема данных как для Prometheus, так и для VictoriaMetrics составляла около ~80 тыс. семплов в секунду:

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

Хотя две линии выглядят совершенно по-разному, это связано только с тем, как две базы данных измеряют активные временные ряды. VictoriaMetrics имеет скользящее временное окно, в то время как Prometheus (Thanos и Mimir) имеет фиксированные двухчасовые интервалы для сбора метрик и их сброса на диск.

С точки зрения процессора, VictoriaMetrics и Prometheus вели себя одинаково:

Хотя приведенные выше результаты были сопоставимы между VictoriaMetrics и Prometheus, результаты становятся интересными, когда мы смотрим на задержку запроса. VictoriaMetrics была в среднем в 16 раз быстрее, чем Prometheus, используя тот же список правил оповещения и тот же набор данных:

Приведенный выше график находится на 50-м процентиле. Это означает, что медианное время, которое требуется VictoriaMetrics для обработки запроса, в 16 раз меньше, чем среднее время, которое требуется Prometheus. Этот разрыв сокращается, когда мы смотрим на 99-й процентиль, т. е. самые медленные запросы, но VictoriaMetrics все еще в 1,9 раза быстрее:

Помимо более быстрой обработки запросов на чтение, VictoriaMetrics также использовала на 1,7x меньше памяти, чем Prometheus:

VictoriaMetrics использует улучшенную версию метода сжатия Gorilla, который использует Prometheus, как описано нашим техническим директором, Александром Валялкиным, в этой статье. В результате VictoriaMetrics использует в 2,5 раза меньше дискового пространства для одних и тех же данных:

Ниже приведена сводка результатов этого эксперимента:

Замена Prometheus на VictoriaMetrics может обеспечить огромный прирост при минимальных усилиях! Это одна из самых простых вещей, которые можно сделать для снижения расходов на мониторинг. Однако VictoriaMetrics предоставляет дополнительные инструменты и функции для повышения экономичности и производительности. См. вторую статью из этой серии — Как снизить расходы на мониторинг: более разумный подход к данным.