Подключение самостоятельно управляемого Prometheus к управляемой службе Azure Monitor для Prometheus

Управляемая служба Azure Monitor для Prometheus предназначена для замены самостоятельно управляемого Prometheus , поэтому вам не нужно управлять сервером Prometheus в кластерах Kubernetes. Вы можете столкнуться с ситуациями, когда вы хотите продолжать использовать самоуправляемый Prometheus в ваших кластерах Kubernetes, одновременно отправляя данные в управляемый Prometheus для долгосрочного хранения данных и создания централизованного представления по вашим кластерам. Это может быть временным решением при переходе на Managed Prometheus или долгосрочное решение, если у вас есть конкретные требования для самостоятельно управляемого Prometheus.

Architecture

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

Эта конфигурация представлена на следующей схеме: Правило сбора данных (DCR) в Azure Monitor предоставляет конечную точку для самоуправляемого экземпляра Prometheus для отправки метрик и определяет рабочую область Azure Monitor, в которой будут отправляться данные.

Это важно

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

Типы аутентификации

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

Тип	Поддерживаемые кластеры
Назначаемый системой управляемый идентификатор	Служба Azure Kubernetes (AKS) Виртуальная машина и масштабируемый набор виртуальных машин Azure
Управляемая идентификация, назначаемая пользователем	Служба Azure Kubernetes (AKS) Kubernetes с поддержкой Arc Виртуальная машина и масштабируемый набор виртуальных машин Azure
Майкрософт Ентра айди	Служба Azure Kubernetes (AKS) Кластер Kubernetes с поддержкой Arc Кластер, работающий в другом облаке или локальной среде Виртуальная машина и масштабируемый набор виртуальных машин Azure Серверы с поддержкой Arc Виртуальная машина, запущенная в другом облаке или локальной среде
Идентификация рабочей нагрузки Microsoft Entra	Служба Azure Kubernetes (AKS) Кластер Kubernetes с поддержкой Arc

Предпосылки

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

Prometheus версии 2.45 или более поздней необходим для аутентификации назначенной пользователем управляемой идентичности.
Для проверки подлинности приложения Microsoft Entra требуется Prometheus версии 2.48 или более поздняя.
Для проверки подлинности управляемого удостоверения, назначенного системой, требуется версия Prometheus 3.50 или более поздняя.
Для проверки подлинности удостоверения рабочей нагрузки Microsoft Entra требуется версия 3.60 или выше.

Рабочая область Azure Monitor

Перед настройкой удаленной записи необходимо создать рабочую область Azure Monitor. Это автоматически включает управляемый Прометей. Если у вас еще нет его, см. статью "Управление рабочей областью Azure Monitor".

Создание удостоверения для проверки подлинности

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

Вы не создаете управляемое удостоверение, назначаемое системой, напрямую, а включаете его для виртуальной машины Azure или масштабируемого набора виртуальных машин. Для виртуальной машины Azure вы можете включить идентификацию при создании VM или позже на странице Идентификация на портале Azure. Для VMSS необходимо включить его после создания. Для различных вариантов включения управляемого системой удостоверения см. статьи "Настройка управляемых удостоверений на виртуальных машинах Azure" и "Настройка управляемых удостоверений для ресурсов Azure в масштабируемом наборе виртуальных машин".

Для кластера AKS управляемое удостоверение должно быть назначено масштабируемым наборам виртуальных машин в кластере. AKS создает группу ресурсов, содержащую масштабируемые наборы виртуальных машин. Перейдите к этой группе ресурсов на странице "Свойства " в меню кластера на портале Azure. Щелкните группу ресурсов инфраструктуры , чтобы просмотреть список ресурсов в этой группе ресурсов. Необходимо активировать системную управляемую идентичность для каждого масштабируемого набора виртуальных машин в группе ресурсов.

Создайте управляемое удостоверение, назначаемое пользователем, из меню "Управляемые удостоверения" на портале Azure. Чтобы узнать больше о различных методах создания управляемых удостоверений, назначаемых пользователем, см. статью «Управление управляемыми удостоверениями, назначаемыми пользователем».

Обратите внимание на Client ID назначенного пользователем управляемого удостоверения. Это значение потребуется позже для настройки удаленной записи.

Назначьте управляемое удостоверение виртуальной машине/VMSS или VMSS кластера AKS.

Это важно

Чтобы выполнить действия, описанные в этом разделе, необходимо иметь разрешения владельца или администратора доступа пользователей для виртуальной машины или масштабируемого набора виртуальных машин.

Чтобы включить аутентификацию для удаленной записи с помощью управляемого удостоверения, назначенного пользователем, назначьте это удостоверение ресурсу Azure. Для vm/VMSS назначьте удостоверение, как описано ниже. Для кластера AKS управляемое удостоверение должно быть назначено базовым масштабируемым наборам виртуальных машин. AKS создает группу ресурсов, содержащую масштабируемые наборы виртуальных машин. Имя группы ресурсов находится в формате MC_<resource group name>_<AKS cluster name>_<region>. Для каждого масштабируемого набора виртуальных машин в этой группе ресурсов назначьте управляемое удостоверение в соответствии с приведенными ниже инструкциями.

На портале Azure перейдите на страницу для кластера, виртуальной машины или масштабируемого набора виртуальных машин.
Выберите Идентификатор.
Выберите Назначено пользователем.
Нажмите кнопку "Добавить".
Выберите созданное управляемое удостоверение, назначаемое пользователем, и нажмите кнопку "Добавить".

Процесс настройки удаленной записи Prometheus с использованием аутентификации рабочего идентификатора Microsoft Entra включает выполнение следующих задач (эти задачи описаны в последующих разделах):

Включите OpenID Connect и запишите URL-адрес издателя.
Настройте мутирующий веб-перехватчик записи.
Настройте удостоверение рабочей нагрузки.
Создайте приложение Microsoft Entra или управляемое удостоверение, назначаемое пользователем, и предоставьте разрешения.
Назначьте приложению роль издателя метрик мониторинга в правиле сбора данных для рабочей области.
Создайте или обновите модуль pod учетной записи службы Kubernetes Prometheus.
Установите учетные данные федеративного удостоверения между удостоверением и издателем учетной записи службы и субъектом.
Настройте удаленную запись в Prometheus.

Включите OpenID Connect и выполните запрос к издателю

Чтобы включить OpenID Connect (OIDC) в кластере AKS, следуйте инструкциям в статье "Создание поставщика OpenID Connect в AKS".

После включения запишите SERVICE_ACCOUNT_ISSUER, который по сути является URL-адресом издателя OIDC. Чтобы получить URL-адрес издателя OIDC, выполните команду az aks show . Замените значения по умолчанию для имени кластера и имени группы ресурсов.

az aks show --name myAKScluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv

По умолчанию издатель использует базовый URL-адрес https://{region}.oic.prod-aks.azure.com, где значение для {region} совпадает с расположением, где кластер AKS развернут.

Сведения о других управляемых кластерах (Amazon Elastic Kubernetes Service и Google Kubernetes Engine) см. в разделе "Управляемые кластеры" — Идентификация рабочей нагрузки Microsoft Entra. Сведения о самоуправляемых кластерах см. в разделе "Самоуправляемые кластеры - Идентификатор рабочей нагрузки Microsoft Entra".

Настройка мутирующего вебхука признания

Если включить идентификатор рабочей нагрузки Microsoft Entra в кластере AKS, AKS автоматически установит и управляет мутирующим веб-перехватчиком допуска. Но если вы не используете AKS или если удостоверение рабочей нагрузки не включено в кластере, настройте мутационный перехватчик для обновления федеративных учетных данных. Чтобы настроить веб-перехватчик, см. раздел "Изменение допуска". Идентификация рабочей нагрузки Microsoft Entra.

Настройка идентификации рабочей нагрузки

Чтобы настроить удостоверение рабочей нагрузки, экспортируйте следующие переменные среды:

# [OPTIONAL] Set this if you're using a Microsoft Entra application
export APPLICATION_NAME="<your application name>"
    
# [OPTIONAL] Set this only if you're using a user-assigned managed identity
export USER_ASSIGNED_IDENTITY_NAME="<your user-assigned managed identity name>"
    
# Environment variables for the Kubernetes service account and federated identity credential
export SERVICE_ACCOUNT_NAMESPACE="<namespace where Prometheus pod is running>"
export SERVICE_ACCOUNT_NAME="<name of service account associated with Prometheus pod. See below for more details>"
export SERVICE_ACCOUNT_ISSUER="<your service account (or OIDC) issuer URL>"

Для SERVICE_ACCOUNT_NAME проверьте, связана ли учетная запись службы (отдельно от учетной записи службы по умолчанию) с подом Prometheus. Найдите значение serviceaccountName или serviceAccount (не рекомендуется) в spec модуле pod Prometheus. Используйте это значение, если оно существует. Чтобы найти учетную запись службы, связанную с pod Prometheus, выполните следующую команду kubectl:

kubectl get pods/<Prometheus pod> -o yaml

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

Создание приложения Microsoft Entra или пользовательски назначенного управляемого удостоверения

Создайте приложение Microsoft Entra или управляемое удостоверение, назначаемое пользователем, и запишите идентификатор клиента.

# create a Microsoft Entra application
az ad sp create-for-rbac --name "${APPLICATION_NAME}"

# create a user-assigned managed identity if you use a user-assigned managed identity for this article
az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}"

Назначьте роли

После создания идентификатора необходимо предоставить доступ к правилу сбора данных (DCR), связанному с рабочей областью Azure Monitor, которая получит данные, записанные удалённо. Этот DCR автоматически создается при создании рабочей области. Вы укажете это удостоверение в конфигурации удаленной записи для кластера или виртуальной машины.

На панели обзора рабочей области Azure Monitor выберите ссылку правила сбора данных. Откроется правило сбора данных (DCR), связанное с рабочей областью.
На странице правила сбора данных выберите элемент управления доступом (IAM). Выберите Добавить, а затем Добавить назначение роли.
Выберите роль издателя метрик мониторинга и нажмите кнопку "Далее".
Выберите личность, чтобы назначить роль.
1. Для управляемого удостоверения, назначаемого системой, выберите управляемое удостоверение и выберите участников. В раскрывающемся списке «Управляемое удостоверение» выберите виртуальную машину или виртуальную машину в структуре VMSS, или каждую VMSS в кластере AKS.
1. Для назначаемой пользователем управляемой идентичности выберите раздел назначаемую пользователем управляемую идентичность. Выберите удостоверение, которое вы создали.
1. Для Entra ID выберите "Пользователь", "Группа" или "Служебный принципал", а затем выберите участников. Выберите созданное приложение и нажмите кнопку "Выбрать".
Выберите Select, чтобы подтвердить выбор, а затем Проверить и назначить, чтобы завершить назначение роли.

Настройка удаленной записи в файле конфигурации

Удаленная запись настраивается в файле prometheus.yml конфигурации Prometheus или в операторе Prometheus. Последним шагом является добавление удаленной записи в файл конфигурации для локально управляемого сервера Prometheus. Помимо сведений о созданном удостоверении, вам также потребуется конечная точка для сбора метрик (URL-адрес) для рабочей области Azure Monitor. Получите это значение на странице обзора рабочей области Azure Monitor на портале Azure и запишите его.

Настройка удаленной записи с помощью файла конфигурации Prometheus
Настройка удаленной записи с помощью оператора Prometheus

Чтобы отправить данные в рабочую область Azure Monitor, добавьте следующий раздел в файл конфигурации (prometheus.yml) управляемого экземпляра Prometheus.

Замечание

Для управляемой идентичности, назначаемой системой, оставьте поле идентификатора клиента пустым (client_id: "").

Манажируемая идентичность

prometheus:
  prometheusSpec:
    remote_write:   
    - url: "<metrics ingestion endpoint for your Azure Monitor workspace>"
      azuread:
        cloud: 'AzurePublic'  # Options are 'AzurePublic', 'AzureChina', or 'AzureGovernment'.
        managed_identity:  
          client_id: "<client-id of the managed identity>"

Entra ID

prometheus:
  prometheusSpec:
    remote_write:   
    - url: "<metrics ingestion endpoint for your Azure Monitor workspace>"
      azuread:
        cloud: 'AzurePublic'  # Options are 'AzurePublic', 'AzureChina', or 'AzureGovernment'.
        oauth:  
          client_id: "<client-id from the Entra app>"
          client_secret: "<client secret from the Entra app>"
          tenant_id: "<Azure subscription tenant Id>"

Идентификация рабочей нагрузки

prometheus:
  prometheusSpec:
    podMetadata:
      labels:
        azure.workload.identity/use: "true"
    remote_write:   
    - url: "<metrics ingestion endpoint for your Azure Monitor workspace>"
      azuread:
        cloud: 'AzurePublic'  # Options are 'AzurePublic', 'AzureChina', or 'AzureGovernment'.
        workload_identity:  
          client_id: "<client-id from the Entra app>"
          tenant_id: "<Azure subscription tenant Id>"

Примените обновления файла конфигурации:

Виртуальная машина

Для виртуальной машины файл конфигурации будет prometheus.yml, если только вы не укажете другой файл с помощью prometheus --config.file <path-to-config-file> при запуске сервера Prometheus.

Кластер Kubernetes

Для кластера Kubernetes файл конфигурации обычно хранится в ConfigMap. Ниже приведен пример ConfigMap, который включает конфигурацию удаленной записи с использованием управляемого удостоверения для самостоятельно управляемого сервиса Prometheus, работающего в кластере Kubernetes.

  GNU nano 6.4
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-server-conf # must match what your pod mounts
  namespace: monitoring  # adjust to your namespace
data:
  prometheus.yml: |-
   global:
     scrape_interval: 15s
     evaluation_interval: 15s
     external_labels:
       cluster: "aks11"

   scrape_configs:
     - job_name: "prometheus"
       static_configs:
         - targets: ["localhost:9090"]

   remote_write:
     - url: "https://aks-amw-0mi2.eastus-1.metrics.ingest.monitor.azure.com/dataCollectionRules/dcr-00000000000000000000000000000000/streams/Microsoft-PrometheusMetrics/api/v1/write?api-version=2023-04-24"
       azuread:
         cloud: 'AzurePublic'
         managed_identity:
           client_id: "00001111-aaaa-2222-bbbb-3333cccc4444"

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

kubectl apply -f <configmap-file-name>.yaml

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

kubectl -n monitoring rollout restart deploy <prometheus-deployment-name>

Замечание

После изменения файла конфигурации перезапустите Prometheus, чтобы применить изменения.

Оператор Prometheus

Если вы находитесь в кластере Kubernetes с оператором Prometheus, выполните следующие действия, чтобы отправить данные в рабочую область Azure Monitor:

Если вы используете проверку подлинности идентификатора Microsoft Entra, преобразуйте секрет с помощью кодировки Base64 и примените секрет в кластере Kubernetes. Сохраните следующий код в YAML-файл. Пропустите этот шаг, если используется управляемое удостоверение или удостоверение рабочей нагрузки.
```
apiVersion: v1
kind: Secret
metadata:
  name: remote-write-secret
  namespace: monitoring # Replace with the namespace where Prometheus Operator is deployed.
type: Opaque
data:
  password: <base64-encoded-secret>
```
Примените секрет:
```
# Set context to your cluster 
az aks get-credentials -g <aks-rg-name> -n <aks-cluster-name> 

kubectl apply -f <remote-write-secret.yaml>
```
Обновите значения для раздела удаленной записи в операторе Prometheus. Скопируйте следующий YAML и сохраните его в виде файла. Дополнительные сведения о спецификации рабочей области Azure Monitor для удаленной записи в операторе Prometheus см. в документации по оператору Prometheus. Используйте либо managedIdentity, либо oauth, либо workloadIdentity проверку подлинности в зависимости от вашей настройки. Удалите раздел, который вы не используете.

Замечание

Для управляемого удостоверения, назначаемого системой, оставьте поле идентификатора клиента пустым (clientId: "").

prometheus:
  prometheusSpec:
    podMetadata:
      labels:
        azure.workload.identity/use: "true" # Use this ONLY for workload identity authentication. Skip if using other authentication.
    remoteWrite:
    - url: "<metrics ingestion endpoint for your Azure Monitor workspace>"
      azureAd:
# Microsoft Entra ID configuration.
# The Azure cloud. Options are 'AzurePublic', 'AzureChina', or 'AzureGovernment'.
        cloud: 'AzurePublic'
        managedIdentity:
          clientId: "<clientId of the managed identity>"
        oauth:
          clientId: "<clientId of the Entra app>"
          clientSecret:
            name: remote-write-secret
            key: password
          tenantId: "<Azure subscription tenant Id>"
        workloadIdentity:
          clientId: "<clientId of the user-assigned managed identity or the Entra ID application>"
          tenantId: "<Azure subscription tenant Id>"

Используйте Helm для обновления конфигурации удаленной записи с помощью показанного выше файла YAML.
```
helm upgrade -f <YAML-FILENAME>.yml prometheus prometheus-community/kube-prometheus-stack --namespace <namespace where Prometheus Operator is deployed>
```

Сведения о настройке конфигурации удаленной записи см. в разделе "Удаленная настройка записи".

Troubleshoot

Ошибка HTTP 403 в журнале Prometheus

Для принятия в силу назначения роли требуется около 30 минут. В течение этого времени в журнале Prometheus может появиться ошибка HTTP 403. Убедитесь, что вы правильно настроили управляемое удостоверение или приложение идентификатора Microsoft Entra с ролью издателя метрик мониторинга в DCR рабочей области. Если конфигурация правильна, подождите 30 минут, пока назначение роли вступит в силу.

Сбор данных Kubernetes не выполняется

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

kubectl --namespace <Namespace> describe pod <Prometheus-Pod-Name>

Контейнер повторно перезапускается

Контейнер регулярно перезапускается, скорее всего, из-за неправильной настройки контейнера. Выполните следующую команду, чтобы просмотреть значения конфигурации, заданные для контейнера. Проверьте значения конфигурации, особенно AZURE_CLIENT_ID и IDENTITY_TYPE.

kubectl get pod <Prometheus-Pod-Name> -o json | jq -c  '.spec.containers[] | select( .name | contains("<Azure-Monitor-Side-Car-Container-Name>"))'

Выходные данные этой команды имеют следующий формат:

{"env":[{"name":"INGESTION_URL","value":"https://my-azure-monitor-workspace.eastus2-1.metrics.ingest.monitor.azure.com/dataCollectionRules/dcr-00000000000000000/streams/Microsoft-PrometheusMetrics/api/v1/write?api-version=2021-11-01-preview"},{"name":"LISTENING_PORT","value":"8081"},{"name":"IDENTITY_TYPE","value":"userAssigned"},{"name":"AZURE_CLIENT_ID","value":"00000000-0000-0000-0000-00000000000"}],"image":"mcr.microsoft.com/azuremonitor/prometheus/promdev/prom-remotewrite:prom-remotewrite-20221012.2","imagePullPolicy":"Always","name":"prom-remotewrite","ports":[{"containerPort":8081,"name":"rw-port","protocol":"TCP"}],"resources":{},"terminationMessagePath":"/dev/termination-log","terminationMessagePolicy":"File","volumeMounts":[{"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount","name":"kube-api-access-vbr9d","readOnly":true}]}

Данные теряются в условиях высокой нагрузки

Правило сбора данных (DCR) и конечная точка сбора данных (DCE) для рабочей области Azure Monitor подвергаются ограничениям приема, перечисленным в ограничениях службы Azure Monitor. Вы больше всего подвержены этим ограничениям при настройке удаленной записи для нескольких кластеров, отправляющих данные в одну конечную точку.

Рассмотрите возможность настройки удаленной записи , чтобы настроить параметры конфигурации для повышения производительности. Если вы по-прежнему замечаете пропуски данных, попробуйте создать дополнительные требования к анализу данных (DCR) и средства сбора данных (DCE), чтобы распределить приемную нагрузку между несколькими конечными точками. Этот подход помогает оптимизировать производительность и обеспечивает эффективную обработку данных. См. инструкции по созданию пользовательской конечной точки сбора данных (DCE) и пользовательского правила сбор данных (DCR) для существующей рабочей области Azure Monitor (AMW) с целью приема метрик Prometheus.

Дальнейшие шаги

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-01-28

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

Подключение самостоятельно управляемого Prometheus к управляемой службе Azure Monitor для Prometheus

Architecture

Типы аутентификации

Предпосылки

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

Рабочая область Azure Monitor

Создание удостоверения для проверки подлинности

Назначьте роли

Настройка удаленной записи в файле конфигурации

Манажируемая идентичность

Entra ID

Идентификация рабочей нагрузки

Виртуальная машина

Кластер Kubernetes

Troubleshoot

Дальнейшие шаги

Обратная связь

Дополнительные ресурсы