代管式收集使用入门

本文档介绍了如何使用代管式收集设置 Google Cloud Managed Service per Prometheus。此设置是工作注入的最小示例，它使用 Prometheus 部署来监控示例应用并将收集的指标存储在 Monarch 中。

本页面介绍如何完成以下任务：

• 设置环境和命令行工具。
• 为集群设置托管式收集。
• 配置用于目标爬取和指标注入的资源。
• 迁移现有的 prometheus-operator 自定义资源。

我们建议您使用代管式收集；它降低了部署、扩缩、分片、配置和维护收集器的复杂性。GKE 和所有其他 Kubernetes 环境均支持代管式收集。

代管式收集将基于 Prometheus 的收集器作为 Daemonset 运行，并通过仅抓取共置节点上的目标来确保可扩缩性。您可以将收集器配置为轻量级自定义资源，以使用拉取收集来抓取导出工具，然后，收集器将抓取的数据推送到中央数据存储区 Monarch。Google Cloud 绝不会直接访问您的集群以拉取或抓取指标数据；您的收集器将数据推送到 Google Cloud。如需详细了解代管式和自部署数据收集，请参阅使用 Managed Service for Prometheus 收集数据和使用代管式和自部署收集进行提取和查询。

准备工作

本部分介绍本文档中描述的任务所需的配置。

设置项目和工具

要使用 Google Cloud Managed Service per Prometheus，您需要以下资源：

• 启用了 Cloud Monitoring API 的 Google Cloud 项目。

  • 如果您没有 Google Cloud 项目，请执行以下操作：

    1. 在 Google Cloud 控制台中，转到新建项目：

       创建新项目

    2. 在项目名称字段中，为您的项目输入一个名称，然后点击创建。

    3. 转到结算：

       转到“结算”

    4. 在页面顶部选择您刚刚创建的项目（如果尚未选择）。

    5. 系统会提示您选择现有付款资料或创建新的付款资料。

    默认情况下，新项目会启用 Monitoring API。

  • 如果您已有 Google Cloud 项目，请确保已启用 Monitoring API：

    1. 转到 API 和服务：

       转到 API 和服务

    2. 选择您的项目。

    3. 点击启用 API 和服务。

    4. 搜索“Monitoring”。

    5. 在搜索结果中，点击“Cloud Monitoring API”。

    6. 如果未显示“API 已启用”，请点击启用按钮。

• Kubernetes 集群。如果您没有 Kubernetes 集群，请按照 GKE 快速入门中的说明进行操作。

您还需要以下命令行工具：

• gcloud
• kubectl

gcloud 和 kubectl 工具是 Google Cloud CLI 的一部分。如需了解如何安装这些工具，请参阅管理 Google Cloud CLI 组件。如需查看已安装的 gcloud CLI 组件，请运行以下命令：

gcloud components list

配置您的环境

为避免重复输入您的项目 ID 或集群名称，请执行以下配置：

• 按如下方式配置命令行工具：

  • 配置 gcloud CLI 以引用您的 Google Cloud 项目的 ID：

    gcloud config set project PROJECT_ID
    

  • 配置 kubectl CLI 以使用集群：

    kubectl config set-cluster CLUSTER_NAME
    

  如需详细了解这些工具，请参阅以下内容：

  • gcloud CLI 概览
  • kubectl 命令

设置命名空间

为您在示例应用中创建的资源创建 NAMESPACE_NAME Kubernetes 命名空间：

kubectl create ns NAMESPACE_NAME

设置代管式收集

您可以在 GKE 集群和非 GKE Kubernetes 集群上使用代管式收集。

启用代管式收集后，集群内组件将运行，但不会生成任何指标。这些组件需要 PodMonitoring 或 ClusterPodMonitoring 资源才能正确抓取指标端点。您必须使用有效的指标端点部署这些资源，或者启用某个代管式指标数据包，例如 GKE 中内置的 Kube 状态指标。如需了解问题排查信息，请参阅注入端问题。

启用代管式收集会在集群中安装以下组件：

• gmp-operator Deployment，用于为 Managed Service for Prometheus 部署 Kubernetes Operator。
• rule-evaluator Deployment，用于配置并运行提醒和记录规则。
• collector DaemonSet，可通过仅从与每个收集器所在节点上运行的 Pod 爬取指标来横向扩缩收集。
• alertmanager StatefulSet，配置为向您的首选通知渠道发送触发的提醒。

如需了解 Managed Service for Prometheus Operator，请参阅清单页面。

启用代管式收集：GKE

默认情况下，系统会为以下各项启动代管式收集：

• 运行 GKE 1.25 或更高版本的 GKE Autopilot 集群。

• 运行 GKE 1.27 版或更高版本的 GKE Standard 集群。您可以在创建集群时替换此默认值；请参阅停用代管式收集。

如果您在默认不启用代管式收集的 GKE 环境中运行，请参阅手动启用代管式收集。

新的集群内组件版本发布后，GKE 上的代管式收集会自动升级。

GKE 上的“受管理的集合”使用授予默认 Compute Engine 服务账号的权限。如果您的政策修改了默认节点服务账号的标准权限，您可能需要添加 Monitoring Metric Writer 角色以继续。

手动启用托管式集合

如果您在默认不启用托管式收集的 GKE 环境中运行，则可以使用以下项启用托管式收集：

• Cloud Monitoring 中的 GKE 集群信息中心。
• Google Cloud 控制台中的 Kubernetes Engine 页面。
• Google Cloud CLI。如需使用 gcloud CLI，您必须运行 GKE 1.21.4-gke.300 版或更高版本。

• 适用于 Google Kubernetes Engine 的 Terraform。如需使用 Terraform 启用 Managed Service for Prometheus，您必须运行 GKE 1.21.4-gke.300 或更高版本。

GKE 集群信息中心

您可以使用 Cloud Monitoring 中的 GKE 集群信息中心执行以下操作。

• 确定集群是否已启用 Managed Service for Prometheus，以及您使用的是托管式收集还是自部署收集。
• 在项目中的集群上启用托管式收集。
• 查看有关集群的其他信息。

如需查看 GKE 集群信息中心，请执行以下操作：

1. 在 Google Cloud 控制台中，转到 信息中心页面：

   前往信息中心

   如果您使用搜索栏查找此页面，请选择子标题为监控的结果。

2. 选择 GCP 信息中心类别，然后选择 GKE 集群。

如需使用“GKE 集群”信息中心在一个或多个 GKE 集群上启用代管式收集，请执行以下操作：

1. 选中要为其启用代管式收集的每个 GKE 集群对应的复选框。

2. 选择启用所选项。

注意：此信息中心仅显示当前项目中的 GKE 集群，即使项目的指标范围内有多个项目也是如此。如需了解详情，请参阅查看多个项目的指标概览。

Kubernetes Engine 界面

您可以使用 Google Cloud 控制台执行以下操作：

• 在现有 GKE 集群上启用托管式收集。
• 创建启用了代管式收集的新 GKE 集群。

如需更新现有集群，请执行以下命令：

1. 在 Google Cloud 控制台中，转到 Kubernetes 集群页面：

   转到 Kubernetes 集群

   如果您使用搜索栏查找此页面，请选择子标题为 Kubernetes Engine 的结果。

2. 点击集群的名称。

3. 在功能列表中，找到 Managed Service for Prometheus 选项。如果该选项被列为已停用，请点击 修改，然后选择启用 Managed Service for Prometheus。

4. 点击保存更改。

如需创建启用了代管式收集的集群，请执行以下命令：

1. 在 Google Cloud 控制台中，转到 Kubernetes 集群页面：

   转到 Kubernetes 集群

   如果您使用搜索栏查找此页面，请选择子标题为 Kubernetes Engine 的结果。

2. 点击创建。

3. 针对标准选项点击配置。

4. 在导航面板中，点击功能。

5. 在操作部分中，选择启用 Managed Service for Prometheus。

6. 点击保存。

gcloud CLI

您可以使用 gcloud CLI 执行以下操作：

• 在现有 GKE 集群上启用托管式收集。
• 创建启用了代管式收集的新 GKE 集群。

这些命令最长可能需要 5 分钟才能完成。

首先，设置您的项目：

gcloud config set project PROJECT_ID

如需更新现有集群，请根据您的集群是可用区级还是区域级来运行以下 update 命令之一：

• gcloud container clusters update CLUSTER_NAME --enable-managed-prometheus --zone ZONE
  

• gcloud container clusters update CLUSTER_NAME --enable-managed-prometheus --region REGION
  

如需创建启用了代管式收集的集群，请运行以下命令：

gcloud container clusters create CLUSTER_NAME --zone ZONE --enable-managed-prometheus

GKE Autopilot

默认情况下，运行 GKE 1.25 或更高版本的 GKE Autopilot 集群支持代管式收集。您无法关闭代管式收集。

如果您的集群在升级到 1.25 时未能自动启用托管式收集，您可以通过运行 gcloud CLI 部分中的更新命令来手动启用它。

Terraform

如需了解如何使用 Terraform 配置代管式收集，请参阅 google_container_cluster 的 Terraform 注册表。

如需了解有关将 Google Cloud 与 Terraform 搭配使用的一般信息，请参阅将 Terraform 与 Google Cloud 搭配使用。

停用托管式集合

如果要在集群上停用托管式收集，您可以使用以下方法之一：

Kubernetes Engine 界面

您可以使用 Google Cloud 控制台执行以下操作：

• 在现有 GKE 集群上停用代管式收集。
• 在创建运行 GKE 1.27 版或更高版本的新 GKE Standard 集群时替换自动启用代管式收集。

如需更新现有集群，请执行以下命令：

1. 在 Google Cloud 控制台中，转到 Kubernetes 集群页面：

   转到 Kubernetes 集群

   如果您使用搜索栏查找此页面，请选择子标题为 Kubernetes Engine 的结果。

2. 点击集群的名称。

3. 在功能部分中，找到 Managed Service for Prometheus 选项。点击  修改，然后清除启用 Managed Service for Prometheus。

4. 点击保存更改。

如需在创建新的 GKE Standard 集群（1.27 版或更高版本）时替换自动启用代管式收集的功能，请执行以下操作：

1. 在 Google Cloud 控制台中，转到 Kubernetes 集群页面：

   转到 Kubernetes 集群

   如果您使用搜索栏查找此页面，请选择子标题为 Kubernetes Engine 的结果。

2. 点击创建。

3. 针对标准选项点击配置。

4. 在导航面板中，点击功能。

5. 在操作部分中，清除启用 Managed Service for Prometheus。

6. 点击保存。

gcloud CLI

您可以使用 gcloud CLI 执行以下操作：

• 在现有 GKE 集群上停用代管式收集。
• 在创建运行 GKE 1.27 版或更高版本的新 GKE Standard 集群时替换自动启用代管式收集。

这些命令最长可能需要 5 分钟才能完成。

首先，设置您的项目：

gcloud config set project PROJECT_ID

如需在现有集群上停用“管理的集合”，请根据您的集群是可用区级还是区域级来运行以下 update 命令之一：

• gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus --zone ZONE
  

• gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus --region REGION
  

如需在创建新的 GKE Standard 集群（1.27 版或更高版本）时替换自动启用托管式收集的功能，请运行以下命令：

gcloud container clusters create CLUSTER_NAME --zone ZONE --no-enable-managed-prometheus

GKE Autopilot

您无法在运行 GKE 1.25 或更高版本的 GKE Autopilot 集群中停用托管式收集。

Terraform

如需停用托管式收集，请将 managed_prometheus 配置块中的 enabled 属性设置为 false。如需详细了解此配置块，请参阅 google_container_cluster 的 Terraform 注册表。

如需了解有关将 Google Cloud 与 Terraform 搭配使用的一般信息，请参阅将 Terraform 与 Google Cloud 搭配使用。

启用代管式收集：非 GKE Kubernetes

如果您正在非 GKE 环境中运行，那么可以使用以下命令启用代管式收集：

• kubectl CLI。

• 运行 1.12 版或更高版本的 GKE Enterprise 部署中包含的捆绑解决方案。

kubectl CLI

如需在使用非 GKE Kubernetes 集群时安装代管式收集器，请运行以下命令来安装设置和 Operator 清单：

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/setup.yaml

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml

GKE Enterprise

如需了解如何为 GKE Enterprise 集群配置代管式收集，请参阅您的发行版的文档：

• Anthos clusters on VMware (v1.12+)
• Anthos clusters on Bare Metal (v1.12+)

部署示例应用

示例应用在其 metrics 端口上发出 example_requests_total 计数器指标和 example_random_numbers 直方图指标（以及其他指标）。应用的清单定义了三个副本。

要部署示例应用，请运行以下命令：

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/example-app.yaml

配置 PodMonitoring 资源

为了注入示例应用发出的指标数据，Managed Service for Prometheus 使用目标爬取。目标爬取和指标注入使用 Kubernetes 自定义资源进行配置。托管式服务使用 PodMonitoring 自定义资源 (CR)。

PodMonitoring CR 仅在部署了 CR 的命名空间中抓取目标。如需抓取多个命名空间中的目标，请在每个命名空间中部署同一 PodMonitoring CR。 您可以通过运行 kubectl get podmonitoring -A 来验证 PodMonitoring 资源是否已安装在预期的命名空间中。

如需查看所有 Managed Service for Prometheus CR 的参考文档，请参阅 prometheus-engine/doc/api 参考文档。

以下清单在 NAMESPACE_NAME 命名空间中定义了 PodMonitoring 资源 prom-example。该资源使用 Kubernetes 标签选择器查找命名空间中值为 prom-example 的 app.kubernetes.io/name 标签的所有 pod。在 /metrics HTTP 路径上，每 30 秒在名为 metrics 的端口上抓取匹配的 Pod。

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s

要应用此资源，请运行以下命令：

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/pod-monitoring.yaml

您的代管式收集器现在正在爬取匹配的 pod。 您可以通过启用目标状态功能来查看爬取目标的状态。

要配置应用于所有命名空间中的一系列 pod 的横向收集，请使用 ClusterPodMonitoring 资源。ClusterPodMonitoring 资源提供与 PodMonitoring 资源相同的接口，但不会将发现的 pod 限制为给定命名空间。

注意：targetLabels 字段提供简化的 Prometheus 样式重新添加标签的配置。您可以使用重新添加标签为提取的时间序列添加 pod 标签。您无法覆盖强制目标标签；如需查看这些标签的列表，请参阅 prometheus_target 资源。

如果您在 GKE 上运行，则可以执行以下操作：

• 如需在 Cloud Monitoring 中使用 PromQL 查询示例应用注入的指标，请参阅使用 Cloud Monitoring 进行查询。
• 如需使用 Grafana 查询示例应用注入的指标，请参阅使用 Grafana 或任何 Prometheus API 使用方进行查询。
• 如需了解如何过滤导出的指标以及调整 prom-operator 资源，请参阅代管式收集的其他主题。

如果您在 GKE 之外运行，则需要创建服务账号并授权其写入指标数据，如以下部分所述。

明确提供凭据

在 GKE 上运行时，收集 Prometheus 服务器会根据节点的服务账号自动从环境中检索凭据。在非 GKE Kubernetes 集群中，必须通过 gmp-public 命名空间中的 OperatorConfig 资源明确提供凭据。

1. 将上下文设置为目标项目：

   gcloud config set project PROJECT_ID
   

2. 创建服务账号：

   gcloud iam service-accounts create gmp-test-sa
   

3. 向服务账号授予所需权限：

   gcloud projects add-iam-policy-binding PROJECT_ID\
     --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/monitoring.metricWriter
   

4. 创建并下载服务账号的密钥：

   gcloud iam service-accounts keys create gmp-test-sa-key.json \
     --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
   

5. 将密钥文件作为 Secret 添加到非 GKE 集群：

   kubectl -n gmp-public create secret generic gmp-test-sa \
     --from-file=key.json=gmp-test-sa-key.json
   

6. 打开 OperatorConfig 资源以进行修改：

   kubectl -n gmp-public edit operatorconfig config
   

   1. 将粗体显示的文本添加到资源：

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      collection:
        credentials:
          name: gmp-test-sa
          key: key.json
      

      此外，请确保将这些凭据添加到 rules 部分，以便托管式规则评估正常工作。

   2. 保存该文件并关闭编辑器。应用更改后，系统会重新创建 pod 并使用给定服务账号向指标后端进行身份验证。

   代管式收集的其他主题

   本部分介绍了如何执行以下操作：

   • 启用目标状态功能可简化调试。
   • 使用 Terraform 配置目标抓取。
   • 过滤您导出到托管式服务的数据。
   • 抓取 Kubelet 和 cAdvisor 指标。
   • 转换现有 prom-operator 资源以用于代管式服务。
   • 在 GKE 之外运行代管式收集。

   启用目标状态功能

   您可以通过在 OperatorConfig 资源中将 features.targetStatus.enabled 值设置为 true 来检查 PodMonitoring 或 ClusterPodMonitoring 资源中的目标状态，如下所示：

       apiVersion: monitoring.googleapis.com/v1
       kind: OperatorConfig
       metadata:
         namespace: gmp-public
         name: config
       features:
         targetStatus:
           enabled: true
   

   配置后，Status.Endpoint Statuses 字段会在几秒钟后显示在每个有效的 PodMonitoring 或 ClusterPodMonitoring 资源上。

   如果您在 NAMESPACE_NAME 命名空间中有名为 prom-example 的 PodMonitoring 资源，则可以运行以下命令来检查状态：

   kubectl -n NAMESPACE_NAME describe podmonitorings/prom-example
   

   输出如下所示：

   API Version:  monitoring.googleapis.com/v1
   Kind:         PodMonitoring
   ...
   Status:
     Conditions:
       ...
       Status:                True
       Type:                  ConfigurationCreateSuccess
     Endpoint Statuses:
       Active Targets:       3
       Collectors Fraction:  1
       Last Update Time:     2023-08-02T12:24:26Z
       Name:                 PodMonitoring/custom/prom-example/metrics
       Sample Groups:
         Count:  3
         Sample Targets:
           Health:  up
           Labels:
             Cluster:                     CLUSTER_NAME
             Container:                   prom-example
             Instance:                    prom-example-589ddf7f7f-hcnpt:metrics
             Job:                         prom-example
             Location:                    REGION
             Namespace:                   NAMESPACE_NAME
             Pod:                         prom-example-589ddf7f7f-hcnpt
             project_id:                  PROJECT_ID
           Last Scrape Duration Seconds:  0.020206416
           Health:                        up
           Labels:
             ...
           Last Scrape Duration Seconds:  0.054189485
           Health:                        up
           Labels:
             ...
           Last Scrape Duration Seconds:  0.006224887
   

   输出包括以下状态字段：

   • 当 Managed Service for Prometheus 确认和处理 PodMonitoring 或 ClusterPodMonitoring 时，Status.Conditions.Status 为 true。
   • Status.Endpoint Statuses.Active Targets 显示 Managed Service for Prometheus 在所有收集器上计算的此 PodMonitoring 资源的爬取目标数。在示例应用中，prom-example 部署有三个副本，且具有单个指标目标，因此值为 3。如果有健康状况不佳的目标，则会显示 Status.Endpoint Statuses.Unhealthy Targets 字段。
   • 如果 Managed Service for Prometheus 可以访问所有代管式收集器，则 Status.Endpoint Statuses.Collectors Fraction 显示的值为 1（表示 100%）。
   • Status.Endpoint Statuses.Last Update Time 显示上次更新时间。如果上次更新时间显著长于您所需的爬取间隔时间，则差异可能表示目标或集群存在问题。
   • Status.Endpoint Statuses.Sample Groups 字段显示按收集器注入的通用目标标签分组的示例目标。此值有助于调试未发现目标的情况。如果所有目标健康状况良好且正在收集，则 Health 字段的预期值为 up，Last Scrape Duration Seconds 字段的值是典型目标的常规时长值。

   如需详细了解这些字段，请参阅 Managed Service for Prometheus API 文档。

   以下各项均表示配置可能存在问题：

   • PodMonitoring 资源中没有 Status.Endpoint Statuses 字段。
   • Last Scrape Duration Seconds 字段的值太早。
   • 您看到的目标太少。
   • Health 字段的值表示目标是 down。

   如需详细了解如何调试目标发现问题，请参阅问题排查文档中的注入端问题。

   配置授权的爬取端点

   如果您的爬取目标需要授权，您可以将收集器设置为使用正确的授权类型并提供相关 Secret。

   Google Cloud Managed Service for Prometheus 支持以下授权类型：

   • mTLS
   • BasicAuth
   • HTTP 授权标头
   • OAuth 2

   mTLS

   mTLS 通常在零信任环境（例如 Istio 服务网格或 Cloud Service Mesh）中配置。

   如需爬取使用 mTLS 保护的端点，请将 PodMonitoring 资源中的 Spec.Endpoints[].Scheme 字段设置为 https。您也可以将 PodMonitoring 资源中的 Spec.Endpoints[].insecureSkipVerify 字段设置为 true，以跳过证书授权机构验证步骤，但我们不建议这样做。或者，您也可以配置 Managed Service for Prometheus，从 Secret 资源加载证书和密钥。

   例如，以下 Secret 资源包含客户端 (cert)、私钥 (key) 和证书授权机构 (ca) 证书的密钥：

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     cert: ********
     key: ********
     ca: ********
   

   向 Managed Service for Prometheus 收集器授予访问该 Secret 资源的权限：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   在 GKE Autopilot 集群上，如下所示：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   如需配置使用先前的 Secret 资源的 PodMonitoring 资源，请修改资源以添加 scheme 和 tls 部分：

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       scheme: https
       tls:
         ca:
           secret:
             name: secret-example
             key: ca
         cert:
           secret:
             name: secret-example
             key: cert
         key:
           secret:
             name: secret-example
             key: key
   

   如需查看所有 Managed Service for Prometheus mTLS 选项的参考文档，请参阅 API 参考文档。

   BasicAuth

   如需爬取使用 BasicAuth 保护的端点，请使用您的用户名和密码设置 PodMonitoring 资源中的 Spec.Endpoints[].BasicAuth 字段。如需了解其他 HTTP 授权标头类型，请参阅 HTTP 授权标头。

   例如，以下 Secret 资源包含用于存储密码的密钥：

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     password: ********
   

   向 Managed Service for Prometheus 收集器授予访问该 Secret 资源的权限：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   在 GKE Autopilot 集群上，如下所示：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   如需配置使用先前的 Secret 资源和用户名 foo 的 PodMonitoring 资源，请修改资源以添加 basicAuth 部分：

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       basicAuth:
         username: foo
         password:
           secret:
             name: secret-example
             key: password
   

   如需查看所有 Managed Service for Prometheus BasicAuth 选项的参考文档，请参阅 API 参考文档。

   HTTP 授权标头

   如需爬取使用 HTTP 授权标头保护的端点，请使用类型和凭据设置 PodMonitoring 资源中的 Spec.Endpoints[].Authorization 字段。对于 BasicAuth 端点，请改用 BasicAuth 配置。

   例如，以下 Secret 资源包含用于存储凭据的密钥：

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     credentials: ********
   

   向 Managed Service for Prometheus 收集器授予访问该 Secret 资源的权限：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   在 GKE Autopilot 集群上，如下所示：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   如需配置使用先前的 Secret 资源和 Bearer 类型的 PodMonitoring 资源，请修改资源以添加 authorization 部分：

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       authorization:
         type: Bearer
         credentials:
           secret:
             name: secret-example
             key: credentials
   

   如需查看所有 Managed Service for Prometheus HTTP 授权标头选项的参考文档，请参阅 API 参考文档。

   OAuth 2

   如需爬取使用 OAuth 2 保护的端点，您必须在 PodMonitoring 资源中设置 Spec.Endpoints[].OAuth2 字段。

   例如，以下 Secret 资源包含用于存储客户端 Secret 的密钥：

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     clientSecret: ********
   

   向 Managed Service for Prometheus 收集器授予访问该 Secret 资源的权限：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   在 GKE Autopilot 集群上，如下所示：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   如需配置使用先前的客户端 ID 为 foo 且令牌网址为 example.com/token 的 Secret 资源的 PodMonitoring 资源，请修改资源以添加 oauth2 部分：

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       oauth2:
         clientID: foo
         clientSecret:
           secret:
             name: secret-example
             key: password
         tokenURL: example.com/token
   

   如需查看所有 Managed Service for Prometheus OAuth 2 选项的参考文档，请参阅 API 参考文档。

   使用 Terraform 配置目标抓取

   如需自动创建和管理 PodMonitoring 和 ClusterPodMonitoring 资源，您可以使用 kubernetes_manifest Terraform 资源类型或 kubectl_manifest Terraform 资源类型，其中任何一个都可让您指定任意的自定义资源。

   如需了解有关将 Google Cloud 与 Terraform 搭配使用的一般信息，请参阅将 Terraform 与 Google Cloud 搭配使用。

   过滤导出的指标

   如果您收集大量数据，则可能需要防止将一些时序发送到 Managed Service for Prometheus，以降低费用。为此，您可以使用包含 keep 操作的 Prometheus 重新添加标签规则作为许可名单，或使用包含 drop 操作的 Prometheus 重新添加标签规则作为拒绝名单。对于托管式收集，此规则位于 PodMonitoring 或 ClusterPodMonitoring 资源的 metricRelabeling 部分。

   例如，以下指标重新添加标签规则将过滤掉以 foo_bar_、foo_baz_ 或 foo_qux_ 开头的所有指标：

     metricRelabeling:
     - action: drop
       regex: foo_(bar|baz|qux)_.+
       sourceLabels: [__name__]
   

   Cloud Monitoring 指标管理页面提供的信息可帮助您控制在收费指标上支出的金额，而不会影响可观测性。指标管理页面报告以下信息：

   • 针对指标网域中基于字节和基于样本的结算以及各个指标的注入量。
   • 有关标签和指标基数的数据。
   • 每个指标的读取次数。
   • 指标在提醒政策和自定义信息中心内的使用。
   • 指标写入错误率。

   您还可以使用指标管理来排除不需要的指标，从而降低提取这些指标的费用。 如需详细了解指标管理页面，请参阅查看和管理指标使用情况。

   如需了解降低费用的其他建议，请参阅费用控制和归因。

   抓取 Kubelet 和 cAdvisor 指标

   Kubelet 会公开有关其自身的指标以及有关在其节点上运行的容器的 cAdvisor 指标。您可以通过修改 OperatorConfig 资源，将代管式收集功能配置为抓取 Kubelet 和 cAdvisor 指标。如需查看相关说明，请参阅有关 Kubelet 和 cAdvisor 的导出器文档。

   转换现有的 prometheus-operator 资源

   您通常可以将现有的 prometheus-operator 资源转换为 Managed Service for Prometheus 代管式收集 PodMonitoring 和 ClusterPodMonitoring 资源。

   例如，ServiceMonitor 资源定义了对一组服务的监控。PodMonitoring 资源提供 ServiceMonitor 资源提供的部分字段。您可以通过映射下表中介绍的字段来将 ServiceMonitor CR 转换为 PodMonitoring CR：

   monitoring.coreos.com/v1 ServiceMonitor	兼容性	monitoring.googleapis.com/v1 PodMonitoring
   .ServiceMonitorSpec.Selector	完全相同	.PodMonitoringSpec.Selector
   .ServiceMonitorSpec.Endpoints[]	.TargetPort 映射到 .Port .Path: compatible .Interval: compatible .Timeout: compatible	.PodMonitoringSpec.Endpoints[]
   .ServiceMonitorSpec.TargetLabels	PodMonitor 必须指定： .FromPod[].From pod 标签 .FromPod[].To 目标标签	.PodMonitoringSpec.TargetLabels

   以下是 ServiceMonitor CR 示例；转换操作会替换粗体内容，而斜体内容则直接映射：

   apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     name: example-app
   spec:
     selector:
       matchLabels:
         app: example-app
     endpoints:
     - targetPort: web
       path: /stats
       interval: 30s
     targetLabels:
     - foo
   

   以下是类似的 PodMonitoring CR，假设您的服务及其 pod 带有 app=example-app 标签。如果此假设不适用，则您需要使用底层 Service 资源的标签选择器。

   转换操作已替换粗体内容：

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: example-app
   spec:
     selector:
       matchLabels:
         app: example-app
     endpoints:
     - port: web
       path: /stats
       interval: 30s
     targetLabels:
       fromPod:
       - from: foo # pod label from example-app Service pods.
         to: foo
   

   注意：您可以按相同方式将 prometheus-operator PodMonitor CR 转换为托管式服务的 PodMonitoring CR；标签选择器始终可复制。

   您始终可以通过自行部署的收集器（而不是代管式收集器）继续使用现有的 prometheus-operator 资源和部署配置。您可以查询从这两种收集器类型发送的指标，因此您可以为现有 Prometheus 部署使用自行部署的收集器，同时为新的 Prometheus 部署使用代管式收集器。

   预留标签

   Managed Service for Prometheus 会自动将以下标签添加到收集的所有指标。以下标签用于在 Monarch 中唯一标识资源：

   • project_id：与指标关联的 Google Cloud 项目的标识符。
   • location：存储数据的物理位置（Google Cloud 区域）。此值通常是 GKE 集群所在的区域。如果从 AWS 或本地部署收集数据，则值可能是最接近的 Google Cloud 区域。
   • cluster：与指标关联的 Kubernetes 集群的名称。
   • namespace：与指标关联的 Kubernetes 命名空间的名称。
   • job：Prometheus 目标的作业标签（如果已知）；对于规则评估结果，可能为空。
   • instance：Prometheus 目标的实例标签（如果已知）；对于规则评估结果，可能为空。

   您可以将 project_id、location 和 cluster 标签添加为 operator.yaml 中的 Deployment 资源的 args，从而替换这些标签。但在 Google Kubernetes Engine 上运行时，这不是推荐的方法。如果您使用任何预留标签作为指标标签，则 Prometheus 托管式服务会自动添加前缀 exported_ 以为它们重新添加标签。此行为与上游 Prometheus 处理与预留标签的冲突的方式相匹配。

   压缩配置

   如果您有许多 PodMonitoring 资源，则可能会耗尽 ConfigMap 空间。如需解决此问题，请在 OperatorConfig 资源中启用 gzip 压缩：

     apiVersion: monitoring.googleapis.com/v1
     kind: OperatorConfig
     metadata:
       namespace: gmp-public
       name: config
     features:
       config:
         compression: gzip
   

   为托管集合启用 Pod 纵向自动扩缩 (VPA)

   如果您在集群中遇到收集器 Pod 内存不足 (OOM) 错误，或者收集器的默认资源请求和限制无法满足您的需求，那么您可以使用 Pod 纵向自动扩缩功能动态分配资源。

   当您在 OperatorConfig 资源上设置 scaling.vpa.enabled: true 字段时，该运算符会在集群中部署 VerticalPodAutoscaling 清单，以便根据使用情况自动设置收集器 Pod 的资源请求和限制。

   如需在 Managed Service for Prometheus 中为收集器 Pod 启用 VPA，请运行以下命令：

   kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge
   

   如果命令成功完成，则该运算符会为收集器 Pod 设置垂直 Pod 自动缩放。内存不足错误会导致资源限制立即增加。如果没有 OOM 错误，则收集器 Pod 的资源请求和限制的首次调整通常会在 24 小时内完成。

   在尝试启用 VPA 时，您可能会收到以下错误消息：

   vertical pod autoscaling is not available - install vpa support and restart the operator

   如需解决此错误，您需要先在集群级别启用垂直 Pod 自动扩缩：

   1. 前往 Google Cloud 控制台中的 Kubernetes Engine - 集群页面。

      在 Google Cloud 控制台中，转到 Kubernetes 集群页面：

      转到 Kubernetes 集群

      如果您使用搜索栏查找此页面，请选择子标题为 Kubernetes Engine 的结果。

   2. 选择要修改的集群。

   3. 在自动化部分中，修改Pod 纵向自动扩缩选项的值。

   4. 选中启用 Pod 纵向自动扩缩复选框，然后点击保存更改。此更改会重启您的集群。在此过程中，该运算符会重新启动。

   5. 重试以下命令：kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge 为 Managed Service for Prometheus 启用 VPA。

   如需确认 OperatorConfig 资源已成功修改，请使用命令 kubectl -n gmp-public edit operatorconfig config 打开该资源。如果成功，您的 OperatorConfig 将包含以下加粗部分：

   apiVersion: monitoring.googleapis.com/v1
   kind: OperatorConfig
   metadata:
     namespace: gmp-public
     name: config
   scaling:
     vpa:
       enabled: true
   

   在注入稳定数量的样本（平均分配到各个节点）时，Pod 纵向自动扩缩功能效果最佳。如果指标负载不规则或呈尖峰状，或者如果各个节点之间的指标负载差异很大，则 VPA 可能不是高效的解决方案。

   如需了解详情，请参阅 GKE 中的 Pod 纵向自动扩缩。

   删除

   如需停用通过 gcloud 或 GKE 界面部署的代管式收集，您可以执行以下任一操作：

   • 运行以下命令：

     gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus
     

   • 使用 GKE 界面：

     1. 在 Google Cloud 控制台中选择 Kubernetes Engine，然后选择集群。

     2. 找到要停用代管式收集功能的集群，然后点击其名称。

     3. 在详细信息标签页上，向下滚动到功能，然后使用修改按钮将状态切换至已停用。

   如需停用通过 Terraform 部署的代管式收集，请在 google_container_cluster 资源的 managed_prometheus 部分中指定 enabled = false。

   如需停用通过 kubectl 部署的代管式收集，请运行以下命令：

   kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml
   

   停用代管式收集会导致您的集群停止向 Managed Service for Prometheus 发送新数据。执行此操作不会删除已存储在系统中的任何现有指标数据。

   停用代管式收集还会删除 gmp-public 命名空间及其中的所有资源，包括该命名空间中所有已安装的导出器。

   在 GKE 之外运行代管式收集

   在 GKE 环境中，您无需进一步配置，即可运行代管式收集。但是，在其他 Kubernetes 环境中，您需要明确提供凭据、用于包含指标的 project-id 值、用于存储指标的 location 值（Google Cloud 区域）以及用于保存收集器运行所在集群的名称的 cluster 值。

   由于 gcloud 在 Google Cloud 环境之外不起作用，因此您需要使用 kubectl 进行部署。与 gcloud 不同，如果使用 kubectl 部署代管式收集，系统不会在有新版本可用时自动升级集群。请务必检查版本页面是否有新版本，并通过使用新版本重新运行 kubectl 命令来手动升级。

   您可以按照明确提供凭据中的说明修改 operator.yaml 中的 OperatorConfig 资源，以提供服务账号密钥。如需提供 project-id、location 和 cluster 值，您可以将其作为 args 添加到 operator.yaml 中的 Deployment 资源中。

   我们建议您根据计划的读取租用模型选择 project-id。根据您以后计划通过指标范围组织读取的方式，选择用于存储指标的项目。如果您不介意，可以将所有内容放到一个项目中。

   对于 location，我们建议您选择最靠近您的部署的 Google Cloud 区域。您选择的 Google Cloud 区域距离您的部署越远，写入延迟时间就越长，您受到潜在网络问题的影响就越大。建议您参阅跨多个云环境的区域列表。如果您不在意，则可以将所有内容放入一个 Google Cloud 区域中。 您不能使用 global 作为自己的位置。

   对于 cluster，我们建议您选择在其中部署了运算符的集群的名称。

   正确配置后，您的 OperatorConfig 应如下所示：

       apiVersion: monitoring.googleapis.com/v1
       kind: OperatorConfig
       metadata:
         namespace: gmp-public
         name: config
       collection:
         credentials:
           name: gmp-test-sa
           key: key.json
       rules:
         credentials:
           name: gmp-test-sa
           key: key.json
   

   此外，您的 Deployment 资源应如下所示：

   apiVersion: apps/v1
   kind: Deployment
   ...
   spec:
     ...
     template:
       ...
       spec:
         ...
         containers:
         - name: operator
           ...
           args:
           - ...
           - "--project-id=PROJECT_ID"
           - "--cluster=CLUSTER_NAME"
           - "--location=REGION"
   

   此示例假定您已将 REGION 变量设置为 us-central1 之类的值。

   在 Google Cloud 之外运行 Managed Service for Prometheus 会产生数据传输费用。将数据转移到 Google Cloud 中会产生费用，而从另一个云转移出数据也可能会产生费用。您可以通过 OperatorConfig 启用在线 gzip 压缩，从而最大限度地降低这些费用。将粗体显示的文本添加到资源：

       apiVersion: monitoring.googleapis.com/v1
       kind: OperatorConfig
       metadata:
         namespace: gmp-public
         name: config
       collection:
         compression: gzip
         ...
   

   关于代管式收集自定义资源的更多内容

   如需了解所有 Managed Service for Prometheus 自定义资源的参考文档，请参阅 prometheus-engine/doc/api 参考文档。

   后续步骤

   • 在 Cloud Monitoring 中使用 PromQL 查询 Prometheus 指标。
   • 使用 Grafana 查询 Prometheus 指标。
   • 使用 Cloud Monitoring 中的 PromQL 提醒。
   • 设置代管式规则评估。
   • 设置常用的导出工具。