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

Мақала
10/15/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 Monitor для Prometheus есть ограничения и квоты по умолчанию для приема. Когда вы достигнете ограничений приема, регулирование может произойти. Вы можете запросить увеличение этих ограничений. Сведения об ограничениях метрик Prometheus см. в разделе об ограничениях службы Azure Monitor.

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

Дополнительные сведения о мониторинге и оповещении о метриках приема см. в статье "Мониторинг приема метрик рабочей области Azure Monitor".

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

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

Состояние pod

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

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

При правильном выполнении службы возвращаются следующие списки модулей pod в формате ama-metrics-xxxxxxxxxx-xxxxx :

ama-metrics-operator-targets-*
ama-metrics-ksm-*
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 выполняются должным образом, следующее место для проверки — это журналы контейнеров.

Проверка настроек повторной маркировки

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

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

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

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-mode true с инструкциями ниже.

При включении все метрики 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 Monitor. В портал Azure можно проверить текущее использование для любой рабочей области Azure Monitor. Текущие метрики использования можно просмотреть в Metrics меню рабочей области Azure Monitor. Следующие метрики использования доступны как стандартные метрики для каждой рабочей области Azure Monitor.

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

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

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

Сбой создания рабочей области Azure Monitor из-за Политика Azure оценки

Если создание рабочей области Azure Monitor завершается ошибкой с сообщением "Ресурс-имя-xyz" было запрещено политикой, может возникнуть политика Azure, которая предотвращает создание ресурса. Если существует политика, которая применяет соглашение об именовании для ресурсов Или групп ресурсов Azure, необходимо создать исключение для соглашения об именовании для создания рабочей области Azure Monitor.

При создании рабочей области Azure Monitor по умолчанию правило сбора данных и конечная точка сбора данных в форме "azure-monitor-workspace-name" автоматически будет создана в группе ресурсов в форме "MA_azure-monitor-workspace-name_location_managed". В настоящее время нет способа изменить имена этих ресурсов, и вам потребуется задать исключение для Политика Azure, чтобы исключить указанные выше ресурсы из оценки политики. См. Политика Azure структуру исключения.

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

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

Бөлісу құралы: