Устранение неполадок с коллекцией метрик Prometheus в Azure Monitor

Статья
02/28/2024

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

Реплика pod ломает метрики из kube-state-metricsпользовательских целевых объектов слома в ama-metrics-prometheus-config конфигурационном рисунке и пользовательских целевых объектах слома, определенных в пользовательских ресурсах. Модули pod daemonSet удаляют метрики из следующих целевых объектов на соответствующем узле: kubelet, cAdvisor, node-exporterи пользовательские целевые объекты слома в конфигурационном рисунке ama-metrics-prometheus-config-node . Модуль pod, который вы хотите просмотреть журналы и пользовательский интерфейс Prometheus, зависит от того, какой целевой объект вы изучаете.

Устранение неполадок с помощью скрипта PowerShell

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

Регулирование метрик

В портал Azure перейдите к рабочей области Azure Monitor. Metrics Перейдите и убедитесь, что метрики Active Time Series % Utilization и Events Per Minute Ingested % Utilization ниже 100 %.

Если одно из них превышает 100 %, прием в эту рабочую область регулируется. В той же рабочей области перейдите к New Support Request созданию запроса, чтобы увеличить ограничения. Выберите тип проблемы как Service and subscription limits (quotas) и тип Managed Prometheusквоты.

Временные пробелы в сборе данных метрик

Во время обновлений узла может отображаться интервал в метриках на 1–2 минуты для метрик, собранных сборщиком уровней кластера. Этот разрыв обусловлен тем, что узел, на котором он работает, обновляется в рамках обычного процесса обновления. Он влияет на целевые объекты на уровне кластера, такие как метрики kube-state-metrics и пользовательские целевые объекты приложений, которые указаны. Это происходит при обновлении кластера вручную или с помощью автоматического обновления. Это поведение ожидается и происходит из-за того, что узел выполняется при обновлении. Ни одно из рекомендуемых правил генерации оповещений не влияет на это поведение.

Состояние pod

Проверьте состояние pod с помощью следующей команды:

kubectl get pods -n kube-system | grep ama-metrics

В кластере должно быть одно ama-metrics-xxxxxxxxxx-xxxxx реплика pod, один ama-metrics-operator-targets-*ama-metrics-ksm-* модуль pod и ama-metrics-node-* модуль pod для каждого узла в кластере.
Каждое состояние pod должно быть Running и иметь равное количество перезапусков в количестве примененных изменений конфигурации. Модуль pod ama-metrics-operator-targets-* может иметь дополнительный перезапуск в начале, и это ожидается:

Если каждое состояние pod имеет Running только один или несколько модулей pod, выполните следующую команду:

kubectl describe pod <ama-metrics pod name> -n kube-system

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

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

Журналы контейнеров

Просмотрите журналы контейнеров с помощью следующей команды:

kubectl logs <ama-metrics pod name> -n kube-system -c prometheus-collector

При запуске все начальные ошибки печатаются красным цветом, а предупреждения печатаются желтым цветом. (Для просмотра цветных журналов требуется по крайней мере powerShell версии 7 или дистрибутив Linux.)

Проверьте, возникла ли проблема с получением маркера проверки подлинности:
- Сообщение "Нет конфигурации" для ресурса AKS регистрируется каждые 5 минут.
- Модуль pod перезапускается каждые 15 минут, чтобы повторить попытку с ошибкой: конфигурация не существует для ресурса AKS.
  - В этом случае проверка, что в группе ресурсов существует правило сбора данных и конечная точка сбора данных.
  - Кроме того, убедитесь, что рабочая область Azure Monitor существует.
  - Убедитесь, что у вас нет частного кластера AKS и что он не связан с областью Приватный канал Azure Monitor для любой другой службы. Этот сценарий в настоящее время не поддерживается.

Обработка конфигурации

Просмотрите журналы контейнеров с помощью следующей команды:

kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c config-reader

Убедитесь, что нет ошибок при синтаксическом анализе конфигурации Prometheus, слиянии с любыми целевыми объектами слома по умолчанию и проверке полной конфигурации.
Если вы включили настраиваемую конфигурацию Prometheus, убедитесь, что она распознана в журналах. Если нет:
- Убедитесь, что в файле configmap есть правильное имя: ama-metrics-prometheus-config в kube-system пространстве имен.
- Убедитесь, что в конфигурации конфигурации конфигурация Prometheus находится в разделе, который называется prometheus-config следующим data образом:
```
kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config
  namespace: kube-system
data:
  prometheus-config: |-
    scrape_configs:
    - job_name: <your scrape job here>
```
Если вы создали пользовательские ресурсы, во время создания мониторов pod или служб должны были возникнуть ошибки проверки. Если метрики из целевых объектов по-прежнему не отображаются, убедитесь, что журналы не отображают ошибки.

kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c targetallocator

Убедитесь, что нет ошибок при MetricsExtension проверке подлинности в рабочей области Azure Monitor.
Убедитесь, что из-за слома целевых объектов нет ошибок OpenTelemetry collector .

Выполните следующую команду:

kubectl logs <ama-metrics pod name> -n kube-system -c addon-token-adapter

Эта команда показывает ошибку, если возникла проблема с проверкой подлинности в рабочей области Azure Monitor. В приведенном ниже примере показаны журналы без проблем:

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

Интерфейс Prometheus

Каждый ama-metrics-* модуль pod имеет пользовательский интерфейс в режиме агента Prometheus, доступный через порт 9090. Пользовательские целевые объекты конфигурации и пользовательских ресурсов удаляются модулем pod и целевыми ama-metrics-* объектами ama-metrics-node-* узла pod. Перенаправляйте порт на конечные точки pod реплика или одну из управляющей программы pod для проверка конфигурации, обнаружения служб и целевых точек, как описано здесь, чтобы проверить правильность пользовательских конфигураций, целевые объекты были обнаружены для каждого задания, и нет ошибок с удалением определенных целевых объектов.

Выполните команду kubectl port-forward <ama-metrics pod> -n kube-system 9090.

Откройте браузер для адреса 127.0.0.1:9090/config. Этот пользовательский интерфейс имеет полную конфигурацию слома. Убедитесь, что все задания включены в конфигурацию.
Перейдите к 127.0.0.1:9090/service-discovery просмотру целевых объектов, обнаруженных объектом обнаружения служб, и то, что relabel_configs отфильтровал целевые объекты. Например, если отсутствуют метрики из определенного модуля pod, можно найти, был ли обнаружен этот модуль pod и что такое универсальный код ресурса (URI). Затем этот универсальный код ресурса (URI) можно использовать при просмотре целевых объектов, чтобы узнать, существуют ли ошибки слома.
Перейдите к 127.0.0.1:9090/targets просмотру всех заданий, время последнего слома конечной точки для этого задания и любых ошибок

Настраиваемые ресурсы

Если вы включили настраиваемые ресурсы, убедитесь, что они отображаются в разделе конфигурации, обнаружения служб и целевых объектов.

Настройка

Обнаружение служб

Целевые объекты

Если нет проблем и предполагаемые целевые объекты удаляются, вы можете просмотреть точные метрики, сломав, включив режим отладки.

Режим отладки

Предупреждение

Этот режим может повлиять на производительность и должен быть включен только в течение короткого времени для отладки.

Надстройка метрик можно настроить для запуска в режиме отладки, изменив параметр enabled конфигурации в соответствии debug-modetrue с инструкциями ниже.

При включении все метрики Prometheus, которые удаляются, размещаются в порту 9091. Выполните следующую команду:

kubectl port-forward <ama-metrics pod name> -n kube-system 9091

127.0.0.1:9091/metrics Перейдите в браузер, чтобы узнать, были ли метрики удалены сборщиком OpenTelemetry. Доступ к этому пользовательскому интерфейсу можно получить для каждого ama-metrics-* модуля pod. Если метрики отсутствуют, может возникнуть проблема с длинами метрик или меток или количеством меток. Кроме того, проверка превышение квоты приема для метрик Prometheus, как указано в этой статье.

Имена метрик, имена меток и значения меток

В настоящее время очистка на основе агента имеет ограничения в следующей таблице:

Свойство	Лимит
Длина имени метки	Меньше или равно 511 символам. Если это ограничение превышается для любого временных рядов в задании, все задание слома завершается ошибкой, и метрики удаляются из этого задания перед приемом. Вы можете увидеть up=0 для этого задания, а также целевой Ux показывает причину up=0.
Длина значения метки	Меньше или равно 1023 символам. Если это ограничение превышается для любого временных рядов в задании, весь слом завершается ошибкой, и метрики удаляются из этого задания перед приемом. Вы можете увидеть up=0 для этого задания, а также целевой Ux показывает причину up=0.
Количество меток на временные ряды	Меньше или равно 63. Если это ограничение превышается для любого временных рядов в задании, все задание слома завершается ошибкой, и метрики удаляются из этого задания перед приемом. Вы можете увидеть up=0 для этого задания, а также целевой Ux показывает причину up=0.
Длина имени метрики	Меньше или равно 511 символам. Если это ограничение превышается для всех временных рядов в задании, удаляются только определенные ряды. MetricextensionConsoleDebugLog содержит трассировки для удаленной метрики.
Имена меток с различными регистрами	Две метки в одном и том же образце метрик, при разных регистрах обрабатываются как наличие повторяющихся меток и удаляются при приеме. Например, временные ряды `my_metric{ExampleLabel="label_value_0", examplelabel="label_value_1}` удаляются из-за повторяющихся меток, так как `ExampleLabel` и рассматриваются как одно и `examplelabel` то же имя метки.

Проверка квоты приема в рабочей области Azure Monitor

Если отсутствуют метрики, сначала можно проверка, если превышение ограничений приема для рабочей области Azure Monitor. В портал Azure можно проверка текущее использование для любой рабочей области Azure Monitor. Текущие метрики использования можно просмотреть в Metrics меню рабочей области Azure Monitor. Следующие метрики использования доступны как стандартные метрики для каждой рабочей области Azure Monitor.

Активные временные ряды — количество уникальных временных рядов, которые недавно были приема в рабочую область за предыдущие 12 часов
Ограничение активных временных рядов — ограничение на количество уникальных временных рядов, которые можно активно принимать в рабочую область.
Активное использование временных рядов — процент использования текущих активных временных рядов
События в минуту приема — количество событий (выборок) в минуту недавно полученных
Количество событий в минуту приема — максимальное количество событий в минуту, которое можно получить перед регулированием
События в минуту приема % использования — процент текущего ограничения скорости приема метрик, используемый

Ознакомьтесь с квотами служб и ограничениями квот по умолчанию, а также сведения о том, что можно увеличить на основе использования. Вы можете запросить увеличение квоты для рабочих областей Azure Monitor с помощью Support Request меню для рабочей области Azure Monitor. Убедитесь, что вы включаете идентификатор, внутренний идентификатор и регион для рабочей области Azure Monitor в запрос на поддержку, который можно найти в меню "Свойства" для рабочей области Azure Monitor в портал Azure.

Следующие шаги

Проверьте рекомендации по сбору метрик в большом масштабе.