本文档介绍了如何使用代管式收集设置 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 项目,请执行以下操作:
在 Google Cloud 控制台中,转到新建项目:
在项目名称字段中,为您的项目输入一个名称,然后点击创建。
转到结算:
在页面顶部选择您刚刚创建的项目(如果尚未选择)。
系统会提示您选择现有付款资料或创建新的付款资料。
默认情况下,新项目会启用 Monitoring API。
如果您已有 Google Cloud 项目,请确保已启用 Monitoring API:
转到 API 和服务:
选择您的项目。
点击启用 API 和服务。
搜索“Monitoring”。
在搜索结果中,点击“Cloud Monitoring API”。
如果未显示“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
如需详细了解这些工具,请参阅以下内容:
设置命名空间
为您在示例应用中创建的资源创建 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 集群信息中心,请执行以下操作:
-
在 Google Cloud 控制台中,转到 信息中心页面:
如果您使用搜索栏查找此页面,请选择子标题为监控的结果。
选择 GCP 信息中心类别,然后选择 GKE 集群。
如需使用“GKE 集群”信息中心在一个或多个 GKE 集群上启用代管式收集,请执行以下操作:
选中要为其启用代管式收集的每个 GKE 集群对应的复选框。
选择启用所选项。
Kubernetes Engine 界面
您可以使用 Google Cloud 控制台执行以下操作:
- 在现有 GKE 集群上启用托管式收集。
- 创建启用了代管式收集的新 GKE 集群。
如需更新现有集群,请执行以下命令:
-
在 Google Cloud 控制台中,转到 Kubernetes 集群页面:
如果您使用搜索栏查找此页面,请选择子标题为 Kubernetes Engine 的结果。
点击集群的名称。
在功能列表中,找到 Managed Service for Prometheus 选项。如果该选项被列为已停用,请点击 edit 修改,然后选择启用 Managed Service for Prometheus。
点击保存更改。
如需创建启用了代管式收集的集群,请执行以下命令:
-
在 Google Cloud 控制台中,转到 Kubernetes 集群页面:
如果您使用搜索栏查找此页面,请选择子标题为 Kubernetes Engine 的结果。
点击创建。
针对标准选项点击配置。
在导航面板中,点击功能。
在操作部分中,选择启用 Managed Service for Prometheus。
点击保存。
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 集群时替换自动启用代管式收集。
如需更新现有集群,请执行以下命令:
-
在 Google Cloud 控制台中,转到 Kubernetes 集群页面:
如果您使用搜索栏查找此页面,请选择子标题为 Kubernetes Engine 的结果。
点击集群的名称。
在功能部分中,找到 Managed Service for Prometheus 选项。点击 edit 修改,然后清除启用 Managed Service for Prometheus。
点击保存更改。
如需在创建新的 GKE Standard 集群(1.27 版或更高版本)时替换自动启用代管式收集的功能,请执行以下操作:
-
在 Google Cloud 控制台中,转到 Kubernetes 集群页面:
如果您使用搜索栏查找此页面,请选择子标题为 Kubernetes Engine 的结果。
点击创建。
针对标准选项点击配置。
在导航面板中,点击功能。
在操作部分中,清除启用 Managed Service for Prometheus。
点击保存。
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.12.0/manifests/setup.yaml kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.12.0/manifests/operator.yaml
GKE Enterprise
如需了解如何为 GKE Enterprise 集群配置代管式收集,请参阅您的发行版的文档:
部署示例应用
示例应用在其 metrics
端口上发出 example_requests_total
计数器指标和 example_random_numbers
直方图指标(以及其他指标)。应用的清单定义了三个副本。
要部署示例应用,请运行以下命令:
kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.12.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.12.0/examples/pod-monitoring.yaml
您的代管式收集器现在正在爬取匹配的 pod。 您可以通过启用目标状态功能来查看爬取目标的状态。
要配置应用于所有命名空间中的一系列 pod 的横向收集,请使用 ClusterPodMonitoring 资源。ClusterPodMonitoring 资源提供与 PodMonitoring 资源相同的接口,但不会将发现的 pod 限制为给定命名空间。
如果您在 GKE 上运行,则可以执行以下操作:
- 如需在 Cloud Monitoring 中使用 PromQL 查询示例应用注入的指标,请参阅使用 Cloud Monitoring 进行查询。
- 如需使用 Grafana 查询示例应用注入的指标,请参阅使用 Grafana 或任何 Prometheus API 使用方进行查询。
- 如需了解如何过滤导出的指标以及调整 prom-operator 资源,请参阅代管式收集的其他主题。
如果您在 GKE 之外运行,则需要创建服务账号并授权其写入指标数据,如以下部分所述。
明确提供凭据
在 GKE 上运行时,收集 Prometheus 服务器会根据节点的服务账号自动从环境中检索凭据。在非 GKE Kubernetes 集群中,必须通过 gmp-public 命名空间中的 OperatorConfig 资源明确提供凭据。
将上下文设置为目标项目:
gcloud config set project PROJECT_ID
创建服务账号:
gcloud iam service-accounts create gmp-test-sa
向服务账号授予所需权限:
gcloud projects add-iam-policy-binding PROJECT_ID\ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.metricWriter
创建并下载服务账号的密钥:
gcloud iam service-accounts keys create gmp-test-sa-key.json \ --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
将密钥文件作为 Secret 添加到非 GKE 集群:
kubectl -n gmp-public create secret generic gmp-test-sa \ --from-file=key.json=gmp-test-sa-key.json
打开 OperatorConfig 资源以进行修改:
kubectl -n gmp-public edit operatorconfig config
将粗体显示的文本添加到资源:
此外,请确保将这些凭据添加到apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config collection: credentials: name: gmp-test-sa key: key.json
rules
部分,以便托管式规则评估正常工作。保存该文件并关闭编辑器。应用更改后,系统会重新创建 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
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 资源和部署配置。您可以查询从这两种收集器类型发送的指标,因此您可以为现有 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
删除
如需停用通过
gcloud
或 GKE 界面部署的代管式收集,您可以执行以下任一操作:运行以下命令:
gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus
使用 GKE 界面:
在 Google Cloud 控制台中选择 Kubernetes Engine,然后选择集群。
找到要停用代管式收集功能的集群,然后点击其名称。
在详细信息标签页上,向下滚动到功能,然后使用修改按钮将状态切换至已停用。
如需停用通过 Terraform 部署的代管式收集,请在
google_container_cluster
资源的managed_prometheus
部分中指定enabled = false
。如需停用通过
kubectl
部署的代管式收集,请运行以下命令:kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.12.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 参考文档。
后续步骤