Как снизить расходы на мониторинг: более разумный подход к данным

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

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

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

Трассировка запросов для поиска узких мест

Пользователи PostgreSQL должны быть знакомы с EXPLAIN — командой, используемой для понимания того, как база данных будет выполнять запрос. Информация, предоставляемая EXPLAIN ANALYZE, может помочь выяснить, почему запрос выполняется медленно, и что можно сделать для его ускорения.

VictoriaMetrics имеет очень похожий инструмент, известный как трассировка запросов. Трассировка запросов помогает избавиться от догадок при ускорении запросов VictoriaMetrics, показывая, где именно тратится время на обработку запроса. Если вы хотите поэкспериментировать с трассировкой запросов, вы можете посетить play.victoriametrics.com и попробовать сами.

В качестве примера возьмем следующий запрос:

sum(rate(grpc_server_handled_total[5m]))

Выполнение этого запроса для данных за последние 30 дней занимает около 4 секунд:

Чтобы выяснить причину, мы можем включить переключатель Trace query в пользовательском интерфейсе и повторно запустить запрос. Это покажет шаги, которые VictoriaMetrics предприняла при обработке запроса, и продолжительность каждого шага:

На скриншоте выше синие полосы представляют процент времени, затраченного на каждый шаг. Дочерние шаги представлены с отступом, а абсолютная продолжительность каждого шага отображается под шагом. Помимо отображения в пользовательском интерфейсе, информация о трассировке отправляется в формате JSON. Это означает, что вы также можете программно анализировать трассировки.

Если посмотреть на трассировку дальше, то окажется, что 91% времени было потрачено на vmselect при агрегации ~9400 временных рядов, содержащих 13 миллионов семплов данных:

vmselect — это frontend обработки запросов VictoriaMetrics, и в среде playground ему выделен только один процессор. Похоже, что этот запрос выполняется медленно, потому что он обрабатывает огромное количество данных на одном процессоре. Следовательно, чтобы ускорить запрос, мы можем сделать одну из двух вещей:

1. Выделить больше ресурсов для vmselect.

2. Более разумно подходить к данным.

В следующем разделе мы рассмотрим cardinality explorer — инструмент, который помогает нам понять объем хранимых данных и где мы можем их сократить.

Cardinality explorer

Почему для нашего запроса выше возвращается более 9000 временных рядов и так много семплов? Чтобы понять наши данные, мы можем использовать инструмент под названием cardinality explorer, доступный через пользовательский интерфейс VictoriaMetrics. Для тех, кто следит за playground, он доступен через «Explore» > «Explore cardinality».

Cardinality explorer показывает информацию о метриках, хранящихся в VictoriaMetrics. Представление по умолчанию отображает top имена метрик по количеству временных рядов, и, как видно из скриншота выше, grpc_server_handled_total — одна из самых больших метрик, которые мы храним.

Вы можете заметить, что cardinality explorer сообщает, что у него только 1500 временных рядов. Это связано с тем, что cardinality explorer показывает однодневное представление, в то время как запрос, который мы выполняли ранее, был за 30 дней. Со временем, по мере развертывания и повторного развертывания приложений, старые временные ряды становятся неактивными, и создаются новые. Этот эффект известен как churn rate и увеличивает количество хранимых временных рядов с течением времени. *(Churn rate можно перевести как «частота изменений», «интенсивность изменений» или «скорость обновления данных»).

Нажатие на имя метрики приведет вас к детализированному представлению, которое показывает метки, хранящиеся для метрики. Ниже показано, как это выглядит для grpc_server_handled_total:

Наиболее «дорогостоящая» метка для этой метрики — grpc_method, поскольку она имеет 63 уникальных значения. Хотя 63 звучит как не очень много, количество уникальных временных рядов, которые нам нужно хранить для метрики, т. е. кардинальность , рассчитывается путем умножения количества уникальных значений в каждой метке. Это означает, что grpc_method делает количество временных рядов, которые должен извлекать наш запрос, в 63 раза больше.

Запросу, который мы изначально запускали, не нужна точность, которую обеспечивает grpc_method. Поскольку нам не нужна эта конкретная метка, мы можем избавиться от нее, и наш запрос будет выполняться значительно быстрее. Контроль кардинальности — мощный инструмент при работе с базами данных временных рядов. Подробнее см. нашу статью о cardinality explorer.

Cardinality explorer позволяет определить:

• Имена метрик с наибольшим количеством временных рядов.

• Метки с наибольшим количеством временных рядов.

• Значения с наибольшим количеством временных рядов для выбранной метки.

• Пары label=name с наибольшим количеством временных рядов.

• Метки с наибольшим количеством уникальных значений.

Cardinality explorer дает ценную информацию о том, почему метрика, которую мы хотим исследовать, является дорогостоящей, и подсказки о том, как сделать ее дешевле. Он доступен по умолчанию в VictoriaMetrics, и вы даже можете запрашивать Prometheus с помощью cardinality explorer, начиная с VictoriaMetrics v1.94.0.

Потоковая агрегация vs. правила записи

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

Правила записи работают с данными, которые уже были записаны в базу данных, и записывают агрегированную версию этих данных обратно в базу данных. Это означает, что правила записи увеличивают общий объем данных, которые вам нужно хранить. Правила записи необходимо выполнять через определенные промежутки времени, что увеличивает общую нагрузку на базу данных.

VictoriaMetrics предоставляет альтернативу правилам записи в виде потоковой агрегации. Потоковая агрегация — это концепция, аналогичная правилам записи, за исключением того, что агрегация происходит до того, как данные попадут в базу данных.

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

- match: "grpc_server_handled_total"   # селектор временных рядов   interval: "2m"                       # с интервалом 2 минуты   outputs: [ "total" ]                 # агрегировать как счетчик   without: [ "grpc_method" ]           # группировать без метки  # Результат: #   grpc_server_handled_total:2m_without_grpc_method_total 

Вышеприведенная конфигурация уже доступна на playground, так что вы можете запросить ее, если следите за ней. Запрос к этой метрике вместо неагрегированной метрики сокращает время выполнения с 4 секунд до долей секунды:

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

1. Агрегирует входящие семплы в потоковом режиме до записи данных в удаленное хранилище.

2. Работает как с метриками из любого поддерживаемого протокола приема данных, так и с метриками, собранными с совместимых с Prometheus целей.

3. Является альтернативой statsd.

4. Является альтернативой правилам записи.

5. Уменьшает количество хранимых семплов.

6. Уменьшает количество хранимых временных рядов.

7. Совместима с любым инструментом, поддерживающим протокол удаленной записи Prometheus.

Потоковая агрегация доступна в vmagent, инструменте сбора метрик из экосистемы VictoriaMetrics. Совместимость со стандартами Prometheus означает, что vmagent и потоковая агрегация могут использоваться с Prometheus или любой другой системой, которая поддерживает протокол удаленной записи Prometheus.

Вы можете прочитать больше в документации по потоковой агрегации.

Уменьшение значащих цифр

Операции с числами с плавающей запятой имеют тенденцию давать результаты с высокой энтропией, ошибками измерения или ложной точностью.

Например, давайте рассмотрим распространенное правило записи, которое вычисляет среднее использование процессора:

rules:   - record: instance:cpu_utilization:ratio_avg     expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100) 

Это правило записи выдаст следующие результаты на playground:

{"instance":"10.71.0.8:9101"}   37.12491991997818 {"instance":"10.142.0.48:9100"} 37.12499331333188 

Если бы вас спросили, какой экземпляр потреблял больше ресурсов процессора в приведенных выше результатах, вы, вероятно, пошли бы цифра за цифрой и остановились бы на первой цифре, которая отличалась. Аналогично, если бы вас спросили, каково среднее потребление экземпляра 10.71.0.8:9101, вы, вероятно, сказали бы 37%, а не 37.12491991997818%. В обоих случаях нам не нужна полная «длина» чисел, чтобы дать ответ. Но хранение семплов с такими значениями сильно влияет на коэффициент сжатия в отрицательную сторону из-за высокой энтропии значений.

VictoriaMetrics позволяет настроить количество значащих цифр, которые вы хотите сохранить. Уменьшение количества значащих цифр уменьшает количество возможных значений и увеличивает вероятность того, что два значения будут одинаковыми. Это улучшает коэффициент сжатия собираемых метрик.

Согласно тестам, описанным в этой статье, переход с 13 значащих цифр на 8 уменьшает сжатый размер каждого семпла с 1.2B до 0.8B, экономя треть пропускной способности сети/использования диска. Если бы вы взяли первый семпл сверху и установили для него 8 значащих цифр, он бы изменился с 37.12491991997818 на 37.12492. Для большинства приложений эта потеря точности едва заметна.

Экономия расходов на оплату трафика

Использование сети также является статьей расходов на мониторинг. Обычно это бесплатно в пределах зоны сети одного облачного провайдера, но оплачивается между различными зонами доступности.

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

vmagent VictoriaMetrics использует улучшенную версию протокола удаленной записи Prometheus с лучшим сжатием:

Выше приведен скриншот использования сети до и после того, как клиент VictoriaMetrics перешел на собственный протокол remote_write VictoriaMetrics. Пользователь добился в 4,5 раза меньшего использования сети, чем со стандартным протоколом remote_write Prometheus, что непосредственно повлияло на их счета у облачного провайдера.

Помимо достижения меньшего использования сети «из коробки», VictoriaMetrics также можно настроить для дальнейшего снижения использования сети путем обмена процессорного времени, задержки или точности на меньшее использование сети:

Подробнее мы написали в целой статье о снижении расходов на оплату трафика с помощью VictoriaMetrics.

Заключение

Мониторинг может быть дорогостоящим и создавать большую нагрузку на инженеров. VictoriaMetrics помогает снизить стоимость мониторинга «из коробки», а небольшие изменения конфигурации могут еще больше снизить ваши расходы. Более того, VictoriaMetrics — полностью открытый проект, и поддержку оказывает команда, которая его написала.