Удаление метрик Prometheus в масштабе в Azure Monitor
В этой статье приводятся рекомендации по производительности, которые можно ожидать, если метрики сбора в большом масштабе для управляемой службы Azure Monitor для Prometheus.
ЦП и память
Использование ЦП и памяти коррелирует с количеством байтов каждого примера и числом выборок. Эти тесты основаны на целевых объектах по умолчанию, объеме пользовательских метрик, скребированных и количестве узлов, модулей pod и контейнеров. Эти числа предназначены в качестве ссылки, так как использование по-прежнему может значительно отличаться в зависимости от количества временных рядов и байтов на метрики.
Максимальное ограничение тома на модуль pod в настоящее время составляет около 3–3,5 миллиона выборок в минуту в зависимости от количества байтов на выборку. Это ограничение решается при добавлении сегментирования в будущем.
Агент состоит из развертывания с одной репликой и DaemonSet для очистки метрик. DaemonSet отменяет все целевые объекты уровня узла, такие как cAdvisor, kubelet и экспортер узлов. Вы также можете настроить его для удаления любых пользовательских целевых объектов на уровне узла со статическими конфигурациями. Набор реплик удаляет все остальное, например метрики kube-state-metrics или пользовательские задания слома, которые используют обнаружение служб.
Сравнение между небольшим и большим кластером для реплики
| Скребки целевых объектов | Примеры, отправленные / минуты | Node Count | Число модулей Pod | Использование ЦП Prometheus-Collector (ядра) | Использование памяти Prometheus-Сборщик (байт) |
|---|---|---|---|---|---|
| целевые объекты по умолчанию | 11,344 | 3 | 40 | 12.9 mc | 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 | Общее количество ресурсов ЦП prometheus-Collector (ядер) | Общий объем использования памяти Prometheus-Сборщик (байт) | Использование ЦП Prometheus-Сборщик / Pod (ядра) | Использование памяти Prometheus-Collector / Pod (байты) |
|---|---|---|---|---|---|---|---|---|
| целевые объекты по умолчанию | 9,858 | 3,327 | 3 | 40 | 41,9 mc | 581 Mi | 14,7 mc | 189 Mi |
| целевые объекты по умолчанию | 2,3 миллиона | 14 400 | 340 | 13 000 | 805 mc | 305,34 ГБ | 2.36 mc | 898 Mi |
Для получения дополнительных пользовательских метрик один модуль pod ведет себя так же, как и модуль pod реплики в зависимости от объема пользовательских метрик.
Планирование реплики pod ama-metrics в пуле узлов с дополнительными ресурсами
Для каждого модуля pod требуется большой объем метрик с достаточным объемом ЦП и памяти. Если модуль pod ama-metrics реплики не запланирован на пуле узлов или узлов с достаточным количеством ресурсов, он может получить OOMKilled и перейти в CrashLoopBackoff. Чтобы устранить эту проблему, можно добавить метку azuremonitor/metrics.replica.preferred=true в пул узлов или узлов в кластере с более высокими ресурсами (в пуле системных узлов). Это гарантирует, что модуль pod реплики будет запланирован на этом узле. Вы также можете создать дополнительные системные пулы с большими узлами и добавить ту же метку. Лучше пометить пулы узлов, а не отдельные узлы, чтобы новые узлы в пуле также можно использовать для планирования.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"
Следующие шаги
- Устранение неполадок с сбором данных Prometheus.