4.5. 为用户工作负载监控配置警报和通知


您可以配置本地或远程 Alertmanager 实例,将警报从 Prometheus 路由到端点接收器。您还可以将自定义标签附加到所有时间序列和警报,以添加有用的元数据信息。

4.5.1. 配置外部 Alertmanager 实例

OpenShift Container Platform 监控堆栈包含一个本地 Alertmanager 实例,用于从 Prometheus 路由警报。

您可以添加外部 Alertmanager 实例来路由用户定义的项目的警报。

如果您为多个集群添加相同的外部 Alertmanager 配置,并且为每个集群禁用本地实例,则可以使用单个外部 Alertmanager 实例管理多个集群的警报路由。

先决条件

  • 您可以使用具有 cluster-admin 集群角色或具有 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. data/config.yaml/<component > 下添加一个带有配置详情的 additionalAlertmanagerConfigs 部分:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        <component>: 1
          additionalAlertmanagerConfigs:
          - <alertmanager_specification> 2
    2
    <alertmanager_specification > 替换为额外的 Alertmanager 实例的身份验证和其他配置详情。目前支持的身份验证方法有 bearer 令牌 (bearerToken) 和客户端 TLS (tlsConfig)。
    1
    <component > 替换为两个支持的外部 Alertmanager 组件之一: prometheusthanosRuler

    以下示例配置映射使用带有客户端 TLS 身份验证的 bearer 令牌为 Thanos Ruler 配置额外的 Alertmanager:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          additionalAlertmanagerConfigs:
          - scheme: https
            pathPrefix: /
            timeout: "30s"
            apiVersion: v1
            bearerToken:
              name: alertmanager-bearer-token
              key: token
            tlsConfig:
              key:
                name: alertmanager-tls
                key: tls.key
              cert:
                name: alertmanager-tls
                key: tls.crt
              ca:
                name: alertmanager-tls
                key: tls.ca
            staticConfigs:
            - external-alertmanager1-remote.com
            - external-alertmanager1-remote2.com
  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

4.5.2. 为 Alertmanager 配置 secret

OpenShift Container Platform 监控堆栈包括 Alertmanager,它将警报从 Prometheus 路由到端点接收器。如果您需要通过接收器进行身份验证以便 Alertmanager 能够向它发送警报,您可以将 Alertmanager 配置为使用包含接收器身份验证凭据的 secret。

例如,您可以将 Alertmanager 配置为使用 secret 与需要由私有证书颁发机构 (CA) 发布的证书的端点接收器进行身份验证。您还可以将 Alertmanager 配置为使用 secret 与需要用于基本 HTTP 身份验证密码文件的接收器进行身份验证。在这两种情况下,身份验证详情都包含在 Secret 对象中,而不是包括在 ConfigMap 对象中。

4.5.2.1. 在 Alertmanager 配置中添加 secret

您可以通过编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射,将 secret 添加到 Alertmanager 配置中。

将 secret 添加到配置映射后,secret 作为一个卷挂载到 Alertmanager Pod 的 alertmanager 容器中的 /etc/alertmanager/secrets/<secret_name 的卷中。

先决条件

  • 您可以使用具有 cluster-admin 集群角色或具有 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 您已创建了要在 openshift-user-workload-monitoring 项目中的 Alertmanager 中配置的 secret。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. 使用以下配置在 data/config.yaml/alertmanager 下添加一个 secrets: 部分:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        alertmanager:
          secrets: 1
          - <secret_name_1> 2
          - <secret_name_2>
    1
    本节包含要挂载到 Alertmanager 中的 secret。secret 必须位于与 Alertmanager 对象相同的命名空间中。
    2
    包含接收器身份验证凭证的 Secret 对象的名称。如果您添加多个 secret,请将每个 secret 放在新行中。

    以下示例配置映射设置将 Alertmanager 配置为使用名为 test-secret-basic-authtest-secret-api-token 的两个 Secret 对象:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        alertmanager:
          secrets:
          - test-secret-basic-auth
          - test-secret-api-token
  3. 保存文件以使改变生效。新的配置会被自动应用。

4.5.3. 在时间序列和警报中附加额外标签

您可以使用 Prometheus 的外部标签功能,将自定义标签附加到离开 Prometheus 的所有时间序列和警报。

先决条件

  • 您可以使用具有 cluster-admin 集群角色或具有 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. data/config.yaml 下定义您要为每个指标添加的标签:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        prometheus:
          externalLabels:
            <key>: <value> 1
    1
    <key>: &lt;value> 替换为键值对,其中 & lt;key > 是新标签的唯一名称,&lt ;value& gt; 是它的值。
    警告
    • 不要使用 prometheus prometheus_replica 作为键的名称,因为它们是保留的并会被覆盖。
    • 不要使用 clustermanaged_cluster 作为密钥名称。使用它们可能会导致您无法在开发人员仪表板中看到数据的问题。
    注意

    openshift-user-workload-monitoring 项目中,Prometheus 负责处理指标,而 Thanos Ruler 负责处理警报和记录规则。在 user-workload-monitoring-config ConfigMap 中为 prometheus 设置 externalLabels 只会为指标配置外部标签,而不会为任何规则配置外部标签。

    例如,要将关于区域和环境的元数据添加到所有时间序列和警报中,请使用以下示例:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        prometheus:
          externalLabels:
            region: eu
            environment: prod
  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

4.5.4. 配置警报通知

在 OpenShift Container Platform 中,管理员可以使用以下方法为用户定义的项目启用警报路由:

  • 使用默认平台 Alertmanager 实例。
  • 仅对用户定义的项目使用单独的 Alertmanager 实例。

具有 alert-routing-edit 集群角色的开发人员和其他用户可以通过配置警报接收器为其用户定义的项目配置自定义警报通知。

注意

查看用户定义的项目的警报路由的以下限制:

  • 用户定义的警报路由的范围为定义资源的命名空间。例如,命名空间 ns1 中的路由配置仅适用于同一命名空间中的 PrometheusRules 资源。
  • 当命名空间不包括在用户定义的监控中时,命名空间中的 AlertmanagerConfig 资源将成为 Alertmanager 配置的一部分。

4.5.4.1. 为用户定义的项目配置警报路由

如果您是一个带有 alert-routing-edit 集群角色的非管理员用户,您可以创建或编辑用户定义的项目的警报路由。

先决条件

  • 集群管理员为用户定义的项目启用了监控。
  • 集群管理员为用户定义的项目启用了警报路由。
  • 您以具有您要为其创建警报路由的项目的 alert-routing-edit 集群角色的用户身份登录。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 创建用于警报路由的 YAML 文件。此流程中的示例使用名为 example-app-alert-routing.yaml 的文件。
  2. 在文件中添加 AlertmanagerConfig YAML 定义。例如:

    apiVersion: monitoring.coreos.com/v1beta1
    kind: AlertmanagerConfig
    metadata:
      name: example-routing
      namespace: ns1
    spec:
      route:
        receiver: default
        groupBy: [job]
      receivers:
      - name: default
        webhookConfigs:
        - url: https://example.org/post
  3. 保存该文件。
  4. 将资源应用到集群:

    $ oc apply -f example-app-alert-routing.yaml

    配置会自动应用到 Alertmanager pod。

4.5.4.2. 使用 Alertmanager secret 为用户定义的项目配置警报路由

如果您启用了专用于用户定义的警报路由的 Alertmanager 实例,您可以通过编辑 openshift-user-workload-monitoring 命名空间中的 alertmanager-user-workload secret 来自定义实例发送通知的位置和方式。

注意

OpenShift Container Platform Alertmanager 配置中也支持支持上游 Alertmanager 的所有功能。要检查受支持的上游 Alertmanager 版本的所有配置选项,请参阅 Alertmanager 配置 (Prometheus 文档)。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 您已为用户定义的警报路由启用了一个单独的 Alertmanager 实例。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 将当前活跃的 Alertmanager 配置输出到 alertmanager.yaml 文件:

    $ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
  2. 编辑 alertmanager.yaml 中的配置:

    route:
      receiver: Default
      group_by:
      - name: Default
      routes:
      - matchers:
        - "service = prometheus-example-monitor" 1
        receiver: <receiver> 2
    receivers:
    - name: Default
    - name: <receiver>
      <receiver_configuration> 3
    1
    指定与警报匹配的标签。这个示例将带有 service="prometheus-example-monitor" 标签的所有警报作为目标。
    2
    指定用于警报组的接收器名称。
    3
    指定接收器配置。
  3. 应用文件中的新配置:

    $ oc -n openshift-user-workload-monitoring create secret generic alertmanager-user-workload --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-user-workload-monitoring replace secret --filename=-

4.5.4.3. 为默认平台警报和用户定义的警报配置不同的警报接收器

您可以为默认平台警报和用户定义的警报配置不同的警报接收器,以确保以下结果:

  • 所有默认平台警报都发送到团队拥有的接收器,以收取这些警报。
  • 所有用户定义的警报都发送到另一个接收器,以便团队只能专注于平台警报。

您可以使用 Cluster Monitoring Operator 添加到所有平台警报的 openshift_io_alert_source="platform" 标签来实现此目的:

  • 使用 openshift_io_alert_source="platform" matcher 来匹配默认平台警报。
  • 使用 openshift_io_alert_source!="platform"'openshift_io_alert_source="" 匹配程序来匹配用户定义的警报。
注意

如果您启用了专用于用户定义的警报的 Alertmanager 实例,则此配置不适用。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.