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
)。
流程
编辑
openshift-user-workload-monitoring
项目中的user-workload-monitoring-config
配置映射:$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
在
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
以下示例配置映射使用带有客户端 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
- 保存文件以使改变生效。受新配置影响的 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
)。
流程
编辑
openshift-user-workload-monitoring
项目中的user-workload-monitoring-config
配置映射:$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
使用以下配置在
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>
以下示例配置映射设置将 Alertmanager 配置为使用名为
test-secret-basic-auth
和test-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
- 保存文件以使改变生效。新的配置会被自动应用。
4.5.3. 在时间序列和警报中附加额外标签
您可以使用 Prometheus 的外部标签功能,将自定义标签附加到离开 Prometheus 的所有时间序列和警报。
先决条件
-
您可以使用具有
cluster-admin
集群角色或具有openshift-user-workload-monitoring
项目中的user-workload-monitoring-config-edit
角色的用户访问集群。 - 集群管理员为用户定义的项目启用了监控。
-
已安装 OpenShift CLI(
oc
)。
流程
编辑
openshift-user-workload-monitoring
项目中的user-workload-monitoring-config
配置映射:$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
在
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>: <
;value> 替换为键值对,其中 <key
> 是新标签的唯一名称,<value&
gt; 是它的值。
警告-
不要使用
prometheus
或prometheus_replica
作为键的名称,因为它们是保留的并会被覆盖。 -
不要使用
cluster
或managed_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
- 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。
其他资源
4.5.4. 配置警报通知
在 OpenShift Container Platform 中,管理员可以使用以下方法为用户定义的项目启用警报路由:
- 使用默认平台 Alertmanager 实例。
- 仅对用户定义的项目使用单独的 Alertmanager 实例。
具有 alert-routing-edit
集群角色的开发人员和其他用户可以通过配置警报接收器为其用户定义的项目配置自定义警报通知。
查看用户定义的项目的警报路由的以下限制:
-
用户定义的警报路由的范围为定义资源的命名空间。例如,命名空间
ns1
中的路由配置仅适用于同一命名空间中的PrometheusRules
资源。 -
当命名空间不包括在用户定义的监控中时,命名空间中的
AlertmanagerConfig
资源将成为 Alertmanager 配置的一部分。
其他资源
- 了解用户定义的项目的警报路由
- 将通知发送到外部系统
- PagerDuty (PagerDuty 官方站点)
- Prometheus Integration Guide (PagerDuty 官方站点)
- 监控组件的支持版本列表
- 为用户定义的项目启用警报路由
4.5.4.1. 为用户定义的项目配置警报路由
如果您是一个带有 alert-routing-edit
集群角色的非管理员用户,您可以创建或编辑用户定义的项目的警报路由。
先决条件
- 集群管理员为用户定义的项目启用了监控。
- 集群管理员为用户定义的项目启用了警报路由。
-
您以具有您要为其创建警报路由的项目的
alert-routing-edit
集群角色的用户身份登录。 -
已安装 OpenShift CLI(
oc
)。
流程
-
创建用于警报路由的 YAML 文件。此流程中的示例使用名为
example-app-alert-routing.yaml
的文件。 在文件中添加
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
- 保存该文件。
将资源应用到集群:
$ 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
)。
流程
将当前活跃的 Alertmanager 配置输出到
alertmanager.yaml
文件:$ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
编辑
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
应用文件中的新配置:
$ 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 实例,则此配置不适用。