Удаление метрик Prometheus в большом масштабе в Azure Monitor

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

ЦП и память

Использование ЦП и памяти сопоставляется с количеством байтов каждой выборки и числом сломанных выборок. Эти тесты производительности основаны на сломанных целевых объектах по умолчанию, объеме пользовательских метрик и количестве узлов, модулей pod и контейнеров. Эти числа предназначены для ссылки, так как использование по-прежнему может значительно различаться в зависимости от количества временных рядов и байтов на метрику.

Максимальный объем на модуль pod в настоящее время составляет около 3–3,5 миллиона выборок в минуту в зависимости от количества байтов на выборку. Это ограничение будет устранено при добавлении сегментирования в будущем.

Агент состоит из развертывания с одним реплика и DaemonSet для очистки метрик. DaemonSet выполняет очистку всех целевых объектов на уровне узла, таких как cAdvisor, kubelet и средство экспорта узлов. Его также можно настроить для очистки любых пользовательских целевых объектов на уровне узла с помощью статических конфигураций. Набор реплик выполняет очистку всего остального, например kube-state-metrics или пользовательских заданий очистки, использующих обнаружение служб.

Сравнение малого и большого кластера для реплика

Целевые объекты для очистки Отправленные примеры в минуту Node Count Pod Count Prometheus-Collector загрузка ЦП (ядра) Использование памяти Prometheus-Collector (байты)
целевые объекты по умолчанию 11,344 3 40 12,9 мс 148 Mi
целевые объекты по умолчанию 260,000 340 13 000 1.10 c 1,70 ГБ
целевые объекты по умолчанию
+ пользовательские целевые объекты
3,56 миллиона 340 13 000 5.13 c 9,52 ГБ

Сравнение небольших и больших кластеров для DaemonSets

Целевые объекты для очистки Отправленные примеры за минуту Отправленные примеры, минуты, pod Node Count Pod Count Prometheus-Collector общий объем использования ЦП (ядра) Prometheus-Collector общий объем использования памяти (байты) Prometheus-Collector загрузка ЦП и pod (ядра) использование памяти Prometheus-Collector / pod (байты)
целевые объекты по умолчанию 9,858 3,327 3 40 41,9 мс 581 Mi 14,7 мс 189 Mi
целевые объекты по умолчанию 2,3 миллиона 14 400 340 13 000 805 mc 305,34 ГБ 2,36 мс 898 Mi

Для дополнительных пользовательских метрик один модуль pod ведет себя так же, как реплика pod в зависимости от объема пользовательских метрик.

Планирование ama-metrics реплика pod в пуле узлов с дополнительными ресурсами

Для большого объема метрик на модуль pod требуется достаточно большой узел, чтобы иметь возможность обрабатывать необходимые ресурсы ЦП и памяти. Если ama-metrics реплика pod не запланировано на узле или в пуле узлов с достаточным объемом ресурсов, он может продолжать получать OOMKilled и перейти к CrashLoopBackoff. Чтобы устранить эту проблему, если у вас есть узел или пул узлов в кластере с большими ресурсами (в пуле системных узлов) и вы хотите получить реплика, запланированные на этом узле, можно добавить метку azuremonitor/metrics.replica.preferred=true на узел, и реплика pod будет запланирован на этом узле. Кроме того, при необходимости можно создать дополнительные системные пулы с большими узлами и добавить такую же метку к узлам или пулу узлов. Кроме того, лучше добавлять метки в пул узлов , а не узлы, чтобы новые узлы в том же пуле также можно было использовать для планирования, если эта метка применима ко всем узлам в пуле.

kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"

Дальнейшие действия