将自托管 Prometheus 连接到适用于 Prometheus 的 Azure Monitor 托管服务

Prometheus 的 Azure Monitor 托管服务 旨在替代自管理 Prometheus，因此无需在 Kubernetes 群集中管理 Prometheus 服务器。 在某些情况下，你可能希望在 Kubernetes 群集中继续使用自管理 Prometheus，同时将数据发送到托管 Prometheus 进行长期数据保留，并跨群集创建集中式视图。 这可能是你在迁移到托管 Prometheus 时的临时解决方案，也可能是你在对自管理 Prometheus 有特定要求时的长期解决方案。

Architecture

Remote_write 是 Prometheus 中的一项功能，可用于将指标从本地 Prometheus 实例发送到远程存储或其他 Prometheus 实例。 通过使用此功能，可以将指标从您的 Kubernetes 群集或虚拟机中运行的自管理 Prometheus 发送到托管 Prometheus 使用的 Azure Monitor 工作区。

下图演示了此配置。 Azure Monitor 中的 数据收集规则（DCR） 为自管理 Prometheus 实例提供终结点，用于发送指标并定义要在其中发送数据的 Azure Monitor 工作区 。

身份验证类型

远程写入的配置要求取决于用于连接到 Azure Monitor 工作区的身份验证类型。 下表描述了支持的身份验证类型。 以下各节介绍了每个配置的详细信息。

Azure Monitor 工作区

必须先创建 Azure Monitor 工作区，然后才能配置远程写入。 这会自动启用托管 Prometheus。 如果还没有 Azure Monitor 工作区，请参阅“管理 Azure Monitor 工作区”。

创建用于身份验证的身份

在配置远程写入之前，必须创建用于向 Azure Monitor 工作区进行身份验证的标识。 以下部分介绍如何创建每种类型的标识（如果不重用现有标识）。

分配角色

创建要使用的标识后，需要向其授予对与 Azure Monitor 工作区关联的数据收集规则（DCR）的访问权限，该规则将接收远程写入数据。 创建工作区时会自动创建此 DCR。 将在群集或 VM 的远程写入配置中指定此标识。

1. 在 Azure Monitor 工作区的概述窗格中，选择“数据收集规则”链接。 这会打开与工作区关联的数据收集规则（DCR）。

   

2. 在数据收集规则的页面上，选择“访问控制”（IAM）。 选择 “添加 ”，然后选择 “添加角色分配”。

   

3. 选择监控指标发布者角色，然后选择下一步。

   

4. 选择要分配角色的身份。

   1. 对于系统分配的托管标识，请选择 “托管标识 ”，然后选择 “成员”。 在 “托管标识 ”下拉列表中，选择 VM/VMSS 或 AKS 群集中的每个 VMSS。

   

   2. 对于用户分配的托管标识，请选择 “用户分配的托管标识 ”部分。 请选择您创建的身份。

   

   3. 对于 Entra ID，请选择 “用户”、“组”或服务主体，然后选择 “成员”。 选择你创建的应用程序，然后选择“选择”。

   

5. 选择 “选择 ”以确认你的选择，然后选择 “查看 + 分配 ”以完成角色分配。

在配置文件中配置远程写入

最后一步是向自管理 Prometheus 服务器的 配置文件 添加远程写入。 除了您所创建的标识详情之外，您还需要 Azure Monitor 工作区的指标采集终结点。 从 Azure 门户中 Azure Monitor 工作区的 “概述 ”页获取此值。

remote-write Prometheus 配置文件的部分将如下所示，具体根据您所使用的身份验证类型而定。

托管标识

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

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>"

应用配置文件更新

虚拟机

对于虚拟机，配置文件将会是 promtheus.yml ，除非在启动 Prometheus 服务器时指定了其他配置文件 prometheus --config.file <path-to-config-file> 。

Kubernetes 群集

对于 Kubernetes 群集，配置文件通常存储在 ConfigMap 中。 下面是一个示例 ConfigMap，其中包含使用托管标识的远程写入配置，用于在 Kubernetes 群集中运行的自托管 Prometheus。

  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.chinanorth-1.metrics.ingest.monitor.azure.cn/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 以选取新配置。 如果您使用部署，可以通过运行以下命令来重启 pods。

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

发行说明

有关远程写入端汽车映像的详细发行说明，请参阅远程写入发行说明。

疑难解答

Prometheus 日志中的 HTTP 403 错误

角色的分配需要大约 30 分钟才能生效。 在此期间，Prometheus 日志中可能会出现 HTTP 403 错误。 检查是否已在工作区 DCR 上使用“监视指标发布者”角色正确配置托管标识或 Microsoft Entra ID 应用程序。 如果配置正确，请等待 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.chinanorth2-1.metrics.ingest.monitor.azure.cn/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}]}

由于高容量环境中的数据丢失

Azure Monitor 工作区的数据收集规则（DCR）和数据收集终结点（DCE）受 Azure Monitor 服务限制中列出的引入限制。 为向同一终结点发送数据的多个群集配置远程写入时，你最受这些限制的约束。

请考虑 进行远程写入优化 ，以调整配置设置以提高性能。 如果仍然观察到数据丢失，请考虑创建其他 DCR 和 DCE，以将摄取负载分配到多个终结点。 此方法有助于优化性能并确保高效的数据处理。 请参阅 有关如何为现有 Azure Monitor 工作区（AMW）创建自定义数据收集终结点（DCE）和自定义数据收集规则（DCR）以引入 Prometheus 指标的说明。

后续步骤

• 详细了解适用于 Prometheus 的 Azure Monitor 托管服务。
• 从 AKS 群集收集 Prometheus 指标