Удаление метрик 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"