代管式规则评估和提醒

Google Cloud Managed Service for Prometheus 支持与 Prometheus 兼容的规则评估和提醒。本文档介绍如何设置代管式规则评估。

规则评估

Managed Service for Prometheus 提供了一个规则评估器组件，可让您在全局 Prometheus 后端环境中安全地编写规则，从而防止在较大的组织中干扰其他用户的数据。在 Kubernetes 集群上运行时，该组件会作为代管式收集的一部分自动部署。

您可以编写适用于 Managed Service for Prometheus 指标和 Cloud Monitoring 指标的规则和提醒。在编写 Cloud Monitoring 指标的规则时，您需要使用 GlobalRules 资源。

规则

代管式规则评估器使用 Rules 资源配置记录和提醒规则。以下是 Rules 资源的示例：

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: NAMESPACE_NAME
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

.spec.groups 元素的格式与上游 Prometheus rule_group 数组相同。在 Rules 中定义的提醒和记录规则的范围限定为资源的 project_id、cluster 和 namespace。例如，上述资源中的 job:up:sum 规则会有效地查询 sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"})。这可确保提醒或记录规则不会意外评估您甚至可能不了解的应用中的指标。

如需将示例规则应用于您的集群，请运行以下命令：

kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.8.2/examples/rules.yaml

几分钟后，指标 job:up:sum 将变为可用。提醒 AlwaysFiring 也将开始触发。如需了解如何将提醒发送到 Alertmanager，请参阅 Alertmanager 配置。

ClusterRule 和 GlobalRule 资源提供与 Rules 资源相同的接口，但它们会将规则应用于更广泛的范围。ClusterRule 使用 project_id 和 cluster 标签选择数据，GlobalRule 选择查询指标范围内的所有数据，而不限制标签。

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

从 Prometheus 规则转换为 Rules

Rules 资源为 Prometheus 规则提供了兼容的接口，以提供将现有规则整合到代管式规则评估中的无缝迁移路径。您可以在 Rules 资源中添加现有规则。例如，下面是一条 Prometheus 规则：

groups:
- name: example
  interval: 30s
  rules:
  - record: job:up:sum
    expr: sum without(instance) (up)
  - alert: AlwaysFiring
    expr: vector(1)

对应的 Rules 资源（粗体字为原始 Prometheus 规则）如下所示：

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: NAMESPACE_NAME
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

ClusterRules

您可以使用 ClusterRules 资源配置记录和提醒规则，以评估从特定集群的所有命名空间发送到 Managed Service for Prometheus 的所有时间序列。该规范与 Rules 的规范相同。先前的示例 Prometheus 规则将成为以下 ClusterRules 资源：

apiVersion: monitoring.googleapis.com/v1
kind: ClusterRules
metadata:
  name: example-clusterrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

我们建议您仅在水平指标（例如由服务网格生成的指标）上使用 ClusterRules 资源。对于各个部署的指标，请使用 Rules 资源来确保评估不包含意外数据。

GlobalRules

您可以使用 GlobalRules 资源配置记录和提醒规则，这些规则可以评估某个指标范围内所有项目发送到 Managed Service for Prometheus 的所有时序。该规范与 Rules 的规范相同。先前的示例 Prometheus 规则将成为以下 GlobalRules 资源：

apiVersion: monitoring.googleapis.com/v1
kind: GlobalRules
metadata:
  name: example-globalrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

由于 Cloud Monitoring 指标的范围未限定至特定命名空间或集群，因此在为 Cloud Monitoring 指标编写规则或提醒时，您必须使用 GlobalRules 资源。在针对 Google Kubernetes Engine 系统指标发出提醒时，也需要使用 GlobalRules。

如果您的规则不保留 project_id 或 location 标签，则默认采用集群的值。

对于 Managed Service for Prometheus 指标，我们建议您仅在有提醒可能需要一次性获取所有集群的数据时使用 GlobalRules，但这种情况非常罕见。对于单个部署的指标，请使用 Rules 或 ClusterRules 资源以提高可靠性并确保评估不包含意外数据。我们强烈建议您在规则评估结果中保留 cluster 和 namespace 标签（除非规则的目的是汇总这些标签），否则查询性能可能会下降，并且您可能会遇到基数限制问题。强烈建议不要移除这两个标签。

多项目和全局规则评估

部署在 Google Kubernetes Engine 上时，规则评估器会使用其自动检测的与集群关联的 Google Cloud 项目。如需评估跨项目的规则，您必须配置执行 GlobalRules 资源的规则评估器，以使用具有多项目指标范围的项目。可以通过以下两种方法实现此目的：

  • 将 GlobalRules 资源放在具有多项目指标范围的项目中。
  • 设置 OperatorConfig 中的 queryProjectID 字段以使用具有多项目指标范围的项目。

您还必须更新规则评估器使用的服务账号的权限（通常是节点上的默认服务账号），以便服务账号可以从范围限定项目中读取数据，以及写入指标范围内所有受监控的项目。

如果您的指标范围包含所有项目，则您的规则进行全局评估。如需了解详情，请参阅指标范围。

使用 Cloud Monitoring 指标进行提醒

您可以通过 GlobalRules 资源使用 PromQL 针对 Google Cloud 系统指标发出提醒。有关如何创建有效查询的说明，请参阅 PromQL for Cloud Monitoring 指标。

使用 Terraform 配置规则和提醒

要自动创建和管理 Rules、ClusterRules 和 GlobalRules 资源，您可以使用 kubernetes_manifest Terraform 资源类型或 kubectl_manifest Terraform 资源类型，其中任何一个都可让您指定任意自定义资源。

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

明确提供凭据

在 GKE 上运行时，规则评估器会根据节点的服务账号自动从环境中检索凭据。在非 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.viewer \
&& \
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
rules:
  credentials:
    name: gmp-test-sa
    key: key.json
      请务必将这些凭据添加到 collection 部分，使得代管式集合能够正常工作。

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

    Alertmanager 配置

    您可以使用 OperatorConfig 资源配置代管式规则评估器以向 Prometheus Alertmanager 发送提醒。除了任何自行部署的 Alertmanager 之外，您还可以将提醒发送到自动部署的代管式 Alertmanager。

    代管式 Alertmanager

    Managed Service for Prometheus 会部署 Alertmanager 的代管式实例，规则评估程序会自动配置为将提醒转发到该实例。默认情况下，此配置使用包含 Alertmanager 配置文件的明确命名的 Kubernetes Secret 进行设置。

    如需启用并配置已部署的 Alertmanager 实例的报告，请执行以下操作：

    1. 创建一个包含 Alertmanager 设置的本地配置文件（请参阅示例配置模板）：

      touch alertmanager.yaml

    2. 使用所需的 Alertmanager 设置更新该文件，然后在 gmp-public 命名空间中创建名为 alertmanager 的 Secret：

      kubectl create secret generic alertmanager \
  -n gmp-public \
  --from-file=alertmanager.yaml

    片刻之后，Managed Service for Prometheus 会选取新的配置 Secret 并使用您的设置启用代管式 Alertmanager。

    自定义配置 Secret 名称

    代管式 Alertmanager 还支持使用自定义 Secret 名称加载配置。如果您有多个配置 Secret 并且希望 Alertmanager 实例在相应的配置之间切换，则此功能会非常有用。例如，您可能希望根据轮替的轮值班次更改提醒通知渠道，或者可能希望替换实验性 Alertmanager 配置以测试新的提醒路由。

    如需使用 OperatorConfig 资源指定非默认 Secret 名称，请执行以下操作：

    1. 从本地 Alertmanager 配置文件创建 Secret：

      kubectl create secret generic SECRET_NAME \
  -n gmp-public \
  --from-file=FILE_NAME

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

      kubectl -n gmp-public edit operatorconfig config

    3. 如需启用代管式 Alertmanager 报告，请通过修改 managedAlertmanager 部分来修改资源，如以下粗体文本所示：

      apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
managedAlertmanager:
  configSecret:
    name: SECRET_NAME
    key: FILE_NAME

    如果您需要对 Alertmanager 配置进行任何更改，则可以通过更新先前创建的 Secret 来修改此 Alertmanager 的配置。

    自行部署的 Alertmanager

    如需为自行部署的 Alertmanager 配置规则评估器，请执行以下操作：

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

      kubectl -n gmp-public edit operatorconfig config

    2. 配置资源以将提醒发送到您的 Alertmanager 服务：

      apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
rules:
  alerting:
    alertmanagers:
    - name: SERVICE_NAME
      namespace: SERVICE_NAMESPACE
      port: PORT_NAME

    如果您的 Alertmanager 与规则评估器位于不同的集群中，您可能需要设置 Endpoints 资源。例如，如果您的 OperatorConfig 提示可以在 Endpoints 对象 ns=alertmanager/name=alertmanager 中找到 Alertmanager 端点，则可以手动或以编程方式创建此对象，并使用其他集群中的可访问 IP 填充此对象。AlertmanagerEndpoints 配置部分在必要时提供授权配置选项。