Prometheus-Operator：告警路由配置
上篇内容我们主要是针对告警以及如何自定义告警规则做了演示，但是我们会发现告警不够清晰，例如如何根据不同的主机、业务艾特人员。本篇文章讲解如何设置告警路由。
Altermanager默认配置文件
通过控制台查看Alertmanager配置：
global:
resolve_timeout: 5m # 该参数定义了当Alertmanager持续多长时间未接收到告警后标记告警状态为resolved
http_config: {} # HTTP 配置，此处为空对象，表示没有特定的配置
smtp_hello: localhost # SMTP 邮件发送时使用的 HELO 消息
smtp_require_tls: true # SMTP 邮件发送是否需要使用 TLS
pagerduty_url: https://events.pagerduty.com/v2/enqueue # PagerDuty API URL
opsgenie_api_url: https://api.opsgenie.com/ # Opsgenie API URL
wechat_api_url: https://qyapi.weixin.qq.com/cgi-bin/ # 微信企业号 API URL
victorops_api_url: https://alert.victorops.com/integrations/generic/20131114/alert/ # VictorOps API URL
route:
receiver: Default # 默认的接收器名称
group_by: # 分组字段，用于将警报按照指定字段进行分组
- namespace # 按照命名空间分组
routes: # 路由规则列表
- receiver: Watchdog # 接收器名称为 Watchdog 的路由规则
match: # 匹配条件
alertname: Watchdog # 匹配警报名称为 Watchdog 的警报
- receiver: Critical # 接收器名称为 Critical 的路由规则
match: # 匹配条件
severity: critical # 匹配严重程度为 critical 的警报
group_wait: 30s # 在组内等待所配置的时间，如果同组内，30秒内出现相同报警，在一个组内发送报警。
group_interval: 5m # 如果组内内容不变化，合并为一条警报信息，5m后发送。
repeat_interval: 12h # 发送报警间隔，如果指定时间内没有修复，则重新发送报警。
inhibit_rules: # 抑制规则列表，用于控制警报传播的行为
- source_match: # 源警报匹配条件
severity: critical # 源警报的严重程度为 critical
target_match_re: # 目标警报匹配条件（使用正则表达式进行匹配）
severity: warning|info # 目标警报的严重程度为 warning 或 info
equal: # 需要匹配相等的字段
- namespace # 命名空间字段需要相等
- alertname # 警报名称字段需要相等
- source_match: # 源警报匹配条件
severity: warning # 源警报的严重程度为 warning
target_match_re: # 目标警报匹配条件（使用正则表达式进行匹配）
severity: info # 目标警报的严重程度为 info
equal: # 需要匹配相等的字段
- namespace # 命名空间字段需要相等
- alertname # 警报名称字段需要相等
receivers: # 接收器列表
- name: Default # 默认接收器
- name: Watchdog # Watchdog 接收器
- name: Critical # Critical 接收器
templates: [] # 模板列表，此处为空列表，表示没有定义任何模板
案例介绍
基于自定义路由告警，我们依旧使用prometheusAlert作为告警渠道，为了方便区分来自不同路由的告警，我们这里使用艾特不同的人员进行区分
环境概述
# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master-50.57 Ready control-plane,master 96d v1.20.5
k8s-node-50.58 Ready <none> 96d v1.20.5
k8s-node-50.59 Ready <none> 96d v1.20.5
# kubectl get pod -n monitoring
NAME READY STATUS RESTARTS AGE
alertmanager-main-0 2/2 Running 0 8d
alertmanager-main-1 2/2 Running 0 8d
alertmanager-main-2 2/2 Running 0 8d
blackbox-exporter-55c457d5fb-5m7ql 3/3 Running 0 8d
grafana-9df57cdc4-gpzsq 1/1 Running 0 8d
kube-state-metrics-56dbb74497-gpkn9 3/3 Running 0 8d
node-exporter-4wl6d 2/2 Running 0 8d
node-exporter-b4595 2/2 Running 0 8d
node-exporter-g4l99 2/2 Running 0 8d
prometheus-adapter-59df95d9f5-tnt4w 1/1 Running 0 8d
prometheus-adapter-59df95d9f5-xhz5v 1/1 Running 0 8d
prometheus-k8s-0 2/2 Running 1 8d
prometheus-k8s-1 2/2 Running 1 10m
prometheus-operator-c46b8b7c9-mg9cv 2/2 Running 0 8d
快速开始
创建Altermanager配置文件
## Alertmanager 配置文件
global:
resolve_timeout: 1m # 该参数定义了当Alertmanager持续多长时间未接收到告警后标记告警状态为resolved（已解决）
# 路由分组
route:
receiver: devops # 默认的接收器名称
group_wait: 30s # 在组内等待所配置的时间，如果同组内，30秒内出现相同报警，在一个组内发送报警。
group_interval: 1m # 如果组内内容不变化，合并为一条警报信息，5m后发送。
repeat_interval: 1m # 发送报警间隔，如果指定时间内没有修复，则重新发送报警。
group_by: [alertname,instance] # 报警分组
routes: # 子路由的匹配设置
- match: # 匹配
severity: critical
receiver: 'ops-critical'
continue: true
- match_re: # 正则匹配
severity: error|info
receiver: 'ops-err'
continue: true
# 接收器指定发送人以及发送渠道
receivers:
- name: devops
webhook_configs:
- url: http://prometheusalert.monitoring.svc:8080/prometheusalert?type=dd&tpl=prometheus-dd&ddurl=https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxx&at=18438613802
send_resolved: true
- name: ops-critical
webhook_configs:
- url: http://prometheusalert.monitoring.svc:8080/prometheusalert?type=dd&tpl=prometheus-dd&ddurl=https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxxxxxxxxxxxxx&at=18538702120
- name: ops-err
webhook_configs:
- url: http://prometheusalert.monitoring.svc:8080/prometheusalert?type=dd&tpl=prometheus-dd&ddurl=https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxxxxxxxxxxxxxxx&at=18438613801
修改Alertmanager配置文件
# cat alertmanager-secret.yaml
apiVersion: v1
kind: Secret
metadata:
labels:
alertmanager: main
app.kubernetes.io/component: alert-router
app.kubernetes.io/name: alertmanager
app.kubernetes.io/part-of: kube-prometheus
app.kubernetes.io/version: 0.21.0
name: alertmanager-main
namespace: monitoring
stringData:
alertmanager.yaml: |-
## Alertmanager 配置文件
global:
resolve_timeout: 1m # 该参数定义了当Alertmanager持续多长时间未接收到告警后标记告警状态为resolved（已解决）
# 路由分组
route:
receiver: devops # 默认的接收器名称
group_wait: 30s # 在组内等待所配置的时间，如果同组内，30秒内出现相同报警，在一个组内发送报警。
group_interval: 1m # 如果组内内容不变化，合并为一条警报信息，5m后发送。
repeat_interval: 1m # 发送报警间隔，如果指定时间内没有修复，则重新发送报警。
group_by: [alertname,instance] # 报警分组
routes: # 子路由的匹配设置
- match: # 匹配
severity: critical
receiver: 'ops-critical'
continue: true
- match_re: # 正则匹配
severity: error|info
receiver: 'ops-err'
continue: true
# 接收器指定发送人以及发送渠道
receivers:
- name: devops
webhook_configs:
- url: http://prometheusalert.monitoring.svc:8080/prometheusalert?type=dd&tpl=prometheus-dd&ddurl=https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxx&at=18438613802
send_resolved: true
- name: ops-critical
webhook_configs:
- url: http://prometheusalert.monitoring.svc:8080/prometheusalert?type=dd&tpl=prometheus-dd&ddurl=https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxxxxxxxxxxxxx&at=18538702120
- name: ops-err
webhook_configs:
- url: http://prometheusalert.monitoring.svc:8080/prometheusalert?type=dd&tpl=prometheus-dd&ddurl=https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxxxxxxxxxxxxxxx&at=18438613801
type: Opaque
# kubectl apply -f alertmanager-secret.yaml
该yaml中的
alertmanager.yaml中的内容使用的正是我们创建的内容，别忘记altermanager重新加载一下哦
匹配告警路由
这里我们通过 可视化路由 树来进行手动匹配规则验证
经过我们路由的匹配，发现当标签匹配不到时，会使用默认的路由。
查看钉钉告警
告警级别为critical，使用ops-critical路由进行告警，艾特人员为18538xxxx
注：忽略该告警内容中的@没有名字，应为不存在该用户
告警级别为warning，使用devops默认路由进行告警，艾特人员为张行雷手机号为：18538xxxx
告警级别为info，使用ops-err路由进行告警，艾特人员手机号为：18538xxxx
注：忽略该告警内容中的@没有名字，应为不存在该用户
总结
本篇文章主要讲解了如何配置告警路由进行提醒不同人员，当然这种情况也是有瑕疵的。下期内容：告警认领
本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。
原始发表：2023-08-25，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读
腾讯云开发者
