Поделиться через

Запрос метрик Prometheus с помощью API и PromQL

  • Статья

Управляемая служба Azure Monitor для Prometheus собирает метрики из кластеров Azure Kubernetes и сохраняет их в рабочей области Azure Monitor. PromQL (язык запросов Prometheus) — это функциональный язык запросов, позволяющий запрашивать и агрегировать данные временных рядов. Используйте PromQL для запроса и агрегирования метрик, хранящихся в рабочей области Azure Monitor.

В этой статье описывается, как запросить рабочую область Azure Monitor с помощью PromQL через REST API. Дополнительные сведения о PromQL см. в разделе "Запрос prometheus".

Необходимые компоненты

Чтобы запросить рабочую область Azure Monitor с помощью PromQL, необходимо выполнить следующие предварительные требования:

  • Кластер Azure Kubernetes или удаленный кластер Kubernetes.
  • Управляемая служба Azure Monitor для метрики очистки Prometheus из кластера Kubernetes.
  • Рабочая область Azure Monitor, в которой хранятся метрики Prometheus.

Проверка подлинности

Чтобы запросить рабочую область Azure Monitor, выполните проверку подлинности с помощью идентификатора Microsoft Entra. API поддерживает проверку подлинности Microsoft Entra с помощью учетных данных клиента. Зарегистрируйте клиентское приложение с помощью идентификатора Microsoft Entra и запросить токен.

Чтобы настроить проверку подлинности Microsoft Entra, выполните следующие действия.

  1. Зарегистрируйте приложение с помощью идентификатора Microsoft Entra.
  2. Предоставьте приложению доступ к рабочей области Azure Monitor.
  3. Запрос маркера.

Регистрация приложения с помощью идентификатора Microsoft Entra

  1. Чтобы зарегистрировать приложение, выполните действия, описанные в разделе "Регистрация приложения", чтобы запросить маркеры авторизации и работать с API

Разрешить приложению доступ к рабочей области

Назначьте роль средства чтения данных мониторинга, чтобы оно могли запрашивать данные из рабочей области Azure Monitor.

  1. Откройте рабочую область Azure Monitor в портал Azure.

  2. На странице обзора запишите конечную точку запроса для использования в запросе REST.

  3. Выберите Управление доступом (IAM).

  4. Выберите "Добавить", а затем добавьте назначение ролей на странице контроль доступа (IAM).

    Снимок экрана: страница обзора рабочей области Azure Monitor.

  5. На странице "Добавление назначения ролей" найдите мониторинг.

  6. Выберите средство чтения данных мониторинга, а затем перейдите на вкладку "Элементы".

    Снимок экрана: страница добавления назначения ролей.

  7. Выберите Выбрать участников.

  8. Найдите зарегистрированного приложения и выберите его.

  9. Выберите Выбрать.

  10. Выберите Проверить + назначить.

    Снимок экрана, на котором показана страница

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

Запрос маркера

Отправьте следующий запрос в командной строке или с помощью клиента, например "Бессонница" или "Вызов PowerShell-RestMethod"

curl -X POST 'https://login.microsoftonline.com/<tenant ID>/oauth2/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=<your apps client ID>' \
--data-urlencode 'client_secret=<your apps client secret>' \
--data-urlencode 'resource=https://prometheus.monitor.azure.com'

Пример текста ответа:

{
    "token_type": "Bearer",
    "expires_in": "86399",
    "ext_expires_in": "86399",
    "expires_on": "1672826207",
    "not_before": "1672739507",
    "resource": "https:/prometheus.monitor.azure.com",
    "access_token": "eyJ0eXAiOiJKV1Qi....gpHWoRzeDdVQd2OE3dNsLIvUIxQ"
}

Сохраните маркер доступа из ответа для использования в следующих HTTP-запросах.

Конечная точка запроса

Найдите конечную точку запроса рабочей области Azure Monitor на странице обзора рабочей области Azure Monitor.

Снимок экрана: создание конечной точки запроса на странице обзора рабочей области Azure Monitor.

Поддерживаемые API

Поддерживаются следующие запросы:

Мгновенные запросы

Дополнительные сведения см. в разделе "Мгновенные запросы"

Путь: /api/v1/query.
Примеры:

POST https://k8s-02-workspace-abcd.eastus.prometheus.monitor.azure.com/api/v1/query  
--header 'Authorization:  Bearer <access token>'
--header 'Content-Type: application/x-www-form-urlencoded' 
--data-urlencode 'query=sum( \
    container_memory_working_set_bytes \
    * on(namespace,pod) \
    group_left(workload, workload_type) \
    namespace_workload_pod:kube_pod_owner:relabel{ workload_type="deployment"}) by (pod)'


GET 'https://k8s02-workspace-abcd.eastus.prometheus.monitor.azure.com/api/v1/query?query=container_memory_working_set_bytes' 
--header 'Authorization:  Bearer <access token>'

Запросы диапазона

Дополнительные сведения см. в разделе "Запросы диапазона"
Путь: /api/v1/query_range.
Примеры:

GET 'https://k8s02-workspace-abcd.eastus.prometheus.monitor.azure.com/api/v1/query_range?query=container_memory_working_set_bytes&start=2023-03-01T00:00:00.000Z&end=2023-03-20T00:00:00.000Z&step=6h'
--header 'Authorization: Bearer <access token>

POST 'https://k8s02-workspace-abcd.eastus.prometheus.monitor.azure.com/api/v1/query_range' 
--header 'Authorization:  Bearer <access token>'
--header 'Content-Type: application/x-www-form-urlencoded' 
--data-urlencode 'query=up' 
--data-urlencode 'start=2023-03-01T20:10:30.781Z' 
--data-urlencode 'end=2023-03-20T20:10:30.781Z' 
--data-urlencode 'step=6h'

Series

Дополнительные сведения см. в разделе "Серия"

Путь: /api/v1/series.
Примеры:

POST 'https://k8s02-workspace-abcd.eastus.prometheus.monitor.azure.com/api/v1/series' 
--header 'Authorization: Bearer <access token>
--header 'Content-Type: application/x-www-form-urlencoded' 
--data-urlencode 'match[]=kube_pod_info{pod="bestapp-123abc456d-4nmfm"}'


GET 'https://k8s02-workspace-abcd.eastus.prometheus.monitor.azure.com/api/v1/series?match[]=container_network_receive_bytes_total{namespace="default-1669648428598"}'

Наклейки

Дополнительные сведения см. в разделе "Путь к меткам" : /api/v1/labels
Примеры:

GET 'https://k8s02-workspace-abcd.eastus.prometheus.monitor.azure.com/api/v1/labels'


POST 'https://k8s02-workspace-abcd.eastus.prometheus.monitor.azure.com/api/v1/labels'

Значения меток

Дополнительные сведения см. в разделе "Значения меток"
Путь: /api/v1/label/__name__/values..

Примечание.

__name__ является единственной поддерживаемой версией этого API и возвращает все имена метрик. Другие значения /api/v1/label/<label_name>/values не поддерживаются.

Пример:

GET 'https://k8s02-workspace-abcd.eastus.prometheus.monitor.azure.com/api/v1/label/__name__/values'

Полные спецификации API-интерфейсов prom OSS см. в разделе HTTP API Prometheus.

Ограничения API

В дополнение к приведенным ниже ограничениям в спецификации Prometheus.

  • Запрос должен быть ограничен метрикой
    Запросы на получение временных рядов (/series или /query или /query_range) должны содержать сопоставление меток __name__. То есть каждый запрос должен быть ограничен метрикой. В запросе может быть только один __name__ сопоставления меток.
  • Запрос /серия не поддерживает фильтр регулярных выражений
  • Поддерживаемый диапазон времени
    • API /query_range поддерживает диапазон времени в 32 дня. Это максимальный диапазон времени, включая селекторы диапазонов, указанные в самом запросе. Например, запрос rate(http_requests_total[1h] за последние 24 часа фактически означает, что данные запрашиваются в течение 25 часов. Это происходит из 24-часового диапазона плюс 1 час, указанный в самом запросе.
    • API /series извлекает данные для максимального диапазона времени в 12 часов. Если endTime это не указано, endTime = time.now(). Если время ярости больше 12 часов, startTime установлено значение endTime – 12h
  • Пропущенный диапазон времени
    Время начала и окончания, предоставленное /labels и /label/__name__/values игнорируемое, и все сохраненные данные в рабочей области Azure Monitor запрашиваются.
  • Экспериментальные функции
    Экспериментальные функции, такие как примеры, не поддерживаются.

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

Учет регистра

Управляемая служба Azure Monitor для Prometheus — это система без учета регистра. Он обрабатывает строки (например, имена метрик, имена меток или значения меток) как те же временные ряды, если они отличаются от других временных рядов только в случае строки.

Примечание.

Это поведение отличается от собственного prometheus с открытым исходным кодом, который является системой с учетом регистра. Самоуправляемые экземпляры Prometheus, работающие в виртуальных машинах Azure, масштабируемых наборах виртуальных машин или Служба Azure Kubernetes кластерах, являются системами с учетом регистра.

В управляемой службе Prometheus следующие временные ряды считаются одинаковыми:

diskSize(cluster="eastus", node="node1", filesystem="usr_mnt")
diskSize(cluster="eastus", node="node1", filesystem="usr_MNT")

Приведенные выше примеры представляют собой один временный ряд в базе данных временных рядов. Действуют следующие ограничения:

  • Любые образцы, которые приемываются против них, хранятся так же, как если бы они сломали или приема по одной временной серии.
  • Если предыдущие примеры обрабатываются с той же меткой времени, один из них случайно удаляется.
  • Регистр, хранящийся в базе данных временных рядов и возвращаемый запросом, непредсказуем. Один и тот же временный ряд может возвращать разные регистры в разное время.
  • Любое имя метрик или сопоставление меток и значения, присутствующих в запросе, извлекается из базы данных временных рядов с помощью сравнения без учета регистра. Если в запросе используется сопоставление с учетом регистра, он автоматически обрабатывается как нечувствительный в сравнении строк.

Рекомендуется использовать один согласованный случай для создания или слома временных рядов.

Prometheus с открытым исходным кодом обрабатывает предыдущие примеры как две разные временные ряды. Все образцы, сломанные или приеманные против них, хранятся отдельно.

Часто задаваемые вопросы

В этом разделы приводятся ответы на часто задаваемые вопросы.

Я пропускаю все или некоторые из моих метрик. Как устранить проблему?

Здесь можно использовать руководство по устранению неполадок для приема метрик Prometheus из управляемого агента.

Почему отсутствуют метрики, имеющие две метки с одинаковым именем, но разные регистры?

Управляемый Prometheus Azure — это нечувствительная система регистра. Оно обрабатывает строки, такие как имена метрик, имена меток или значения меток, как одинаковые временные ряды, если они отличаются от других временных рядов только по регистру строки. Дополнительные сведения см. в обзоре метрик Prometheus.

Я вижу некоторые пробелы в данных метрик, почему это происходит?

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

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

Обзор рабочей области Azure Monitor
Управление рабочей областью Azure Monitor
Обзор управляемой службы Azure Monitor для Prometheus
Запрос метрик Prometheus с помощью книг Azure