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

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

Реплика pod собирает метрики из kube-state-metrics, пользовательских целевых объектов сбора в ama-metrics-prometheus-config configmap и пользовательских целевых объектов сбора, определенных в Пользовательских Ресурсах. Pods DaemonSet собирают метрики из следующих целевых объектов на соответствующем узле: kubelet, cAdvisor, node-exporter, и пользовательских целевых объектов в configmap ama-metrics-prometheus-config-node. Под, для которого вы хотите просмотреть журналы и пользовательский интерфейс Prometheus, зависит от того, какой целевой объект запросов 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 и иметь количество перезапусков, равное количеству изменений configmap, которые были применены. Модуль pod ama-metrics-operator-targets-* может иметь дополнительный перезапуск в начале, что ожидаемо.

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

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

• Эта команда предоставляет причину перезапуска. Ожидаются перезапуски pod, если были внесены изменения в configmap. Если причиной перезагрузки является 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. Перенаправьте порт в под реплики или один из подов управляющей программы, чтобы проверить конфигурацию, обнаружение служб и целевые конечные точки, как описано здесь, с целью подтвердить корректность пользовательских конфигураций, убедиться, что предполагаемые целевые объекты были обнаружены для каждого задания, и убедиться, что нет ошибок при извлечении данных с конкретных целевых объектов.

Выполните команду 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, чтобы просмотреть все задания, время последней обработки конечной точки для этого задания и любые ошибки

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

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

Настройка

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

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

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

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

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

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

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

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

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

Сбор метрик в настоящее время имеет ограничения, указанные в следующей таблице.

Проверка квоты приема в рабочей области 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.

Аспекты высокого масштаба

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

• Проверьте рекомендации по сбору метрик в большом масштабе.
• Горизонтальное автоматическое масштабирование pod для набора реплик сборщика

Диаграммы зависают в состоянии загрузки

Эта проблема возникает, если сетевой трафик для рабочей области Azure Monitor заблокирован. Основная причина этого обычно связана с политиками сети, такими как программное обеспечение блокировки рекламы. Чтобы устранить эту проблему, отключите блокировку рекламы или добавьте monitor.azure.com в белый список и перезагрузите страницу.