Alertmanager告警通知

Alertmanager 告警通知

1.Alertmanager配置文件解析

Alertmanager 本身不产生告警，它只负责”收快递 + 分拣 + 打包 + 派送”。Prometheus 判断规则触发后，把告警（一堆 label + annotation）POST 给 Alertmanager，之后的流程是：

接收告警 → 路由（route）决定交给哪个接收器 → 分组（group）把同类告警打包成一条通知 → 抑制（inhibit）/静默（silence）过滤掉不该发的 → 接收器（receiver）真正发邮件/钉钉/微信。

配置文件的五大块正好对应这个流程：global（全局默认值）、route（分拣规则）、inhibit_rules（抑制规则）、receivers（派送渠道）、templates（通知模板）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
global:  # 全局配置：整个Alertmanager实例的默认参数，如果routes/receivers中没有单独指定，就用这里的默认值
  resolve_timeout: 5m  
  # 【解决超时时间】如果一个告警在5分钟内没有再次收到"仍在触发"的信号，
  # Alertmanager就会自动认为这个告警已经"恢复"（resolved）
  
  http_config:  # 全局HTTP请求的配置（用于调用webhook、发送到第三方API等）
    follow_redirects: true  # 【跟随重定向】如果目标地址返回302/301重定向，是否自动跳转到新地址，true=跟随
    enable_http2: true     # 【启用HTTP2】是否使用HTTP/2协议发送请求，可以提升性能
    
  pagerduty_url: https://events.pagerduty.com/v2/enqueue  
  # 【PagerDuty的API地址】如果使用PagerDuty接收告警，默认调用的接口地址
  
  opsgenie_api_url: https://api.opsgenie.com/  
  # 【Opsgenie的API地址】同上，OpsGenie告警平台的默认接口
  
  wechat_api_url: https://qyapi.weixin.qq.com/cgi-bin/  
  # 【企业微信API地址】发送告警到企业微信时调用的接口地址
  
  victorops_api_url: https://alert.victorops.com/integrations/generic/20131114/alert/  
  # 【VictorOps的API地址】VictorOps告警平台的默认接口
  
  telegram_api_url: https://api.telegram.org  
  # 【Telegram的API地址】发送告警到Telegram机器人时调用的接口
  
  webex_api_url: https://webexapis.com/v1/messages  
  # 【Webex的API地址】发送告警到Webex时调用的接口
  # 👆 以上这些 xxx_api_url 只是"默认值"，如果你在receiver里配置了具体的webhook/key，
  # 就会使用这个默认的API地址来发送数据，一般不需要修改。

route:  # 路由配置：决定"告警"应该发给谁、如何分组、多久发一次
  receiver: Default  # 【默认接收者】如果一个告警没有匹配到任何子路由(routes)，就默认发给"Default"这个接收器
  
  group_by:
  - namespace  
  # 【分组依据】把具有相同"namespace"标签的告警，合并成一组一起发送（避免刷屏）
  
  continue: false  
  # 【是否继续匹配下面的兄弟路由】false表示：如果告警在本层匹配上了（这里指顶层route本身），
  # 就不再继续往下匹配其他同级路由（其实顶层这个字段作用不大，主要用在子路由里）

  routes:  # 【子路由列表】相当于"分支判断"，从上到下依次匹配，命中即处理（除非continue: true）
  - receiver: Watchdog  
    # 子路由1：如果匹配下面的条件，就发给"Watchdog"接收器
    matchers:
    - alertname="Watchdog"  
    # 【匹配条件】告警标签中 alertname 的值等于 "Watchdog"
    # （Watchdog是Prometheus自带的"心跳"告警，用来证明监控系统本身是存活的）
    continue: false  
    # 匹配上之后，不再继续往下比对其他子路由，直接结束路由判断

  - receiver: "null"  
    # 子路由2：如果匹配，发给名为"null"的接收器（相当于啥也不做，丢弃告警）
    matchers:
    - alertname="InfoInhibitor"  
    # 匹配条件：alertname 等于 "InfoInhibitor"
    # （这是一个特殊的"信息抑制"告警，用来配合下面的inhibit_rules抑制info级别告警）
    continue: false  

  - receiver: Critical  
    # 子路由3：如果匹配，发给"Critical"接收器（比如发短信、打电话等紧急通知方式）
    matchers:
    - severity="critical"  
    # 匹配条件：告警标签severity的值为"critical"（严重级别）
    continue: false  

  group_wait: 30s  
  # 【首次等待时间】同一组告警，第一次触发后，先等待30秒，
  # 看看是否还有同组的其他告警一起触发，凑够了再一起发，避免发送太碎的通知
  
  group_interval: 5m  
  # 【同组告警的发送间隔】如果同一组内又有新的告警产生，最快每隔5分钟才发一次新通知
  
  repeat_interval: 12h  
  # 【重复发送间隔】如果一个告警一直没有恢复（Resolved），
  # 那么每隔12小时会重新发一次通知，提醒你"这个问题还没解决"


inhibit_rules:  
# 【抑制规则】用于避免"重复报警"或者"没有意义的低级别告警"刷屏
# 逻辑是：如果满足source条件的告警存在，就会抑制（隐藏）满足target条件的告警

- source_matchers:
  - severity="critical"  
  # 【触发抑制的源头】如果存在一个 severity=critical 的告警
  target_matchers:
  - severity=~"warning|info"  
  # 【被抑制的目标】那么 severity 为 warning 或 info 的告警就会被抑制（不发送）
  equal:
  - namespace
  - alertname  
  # 【匹配条件】必须是相同 namespace 和相同 alertname 的告警才会互相抑制
  # （即：同一个业务、同一种问题，critical出现了，就不用再发warning/info烦你了）

- source_matchers:
  - severity="warning"  
  target_matchers:
  - severity="info"  
  # 同理：如果有 warning 级别的告警，相同namespace+alertname的 info 级别告警就会被抑制
  equal:
  - namespace

- source_matchers:
  - alertname="InfoInhibitor"  
  # 特殊逻辑：如果触发了"InfoInhibitor"这个告警（它是一种控制开关型告警）
  target_matchers:
  - severity="info"  
  # 就会抑制所有 severity=info 的告警
  equal:
  - namespace  
  # 只要namespace相同即可抑制（不需要看alertname是否相同）


receivers:  
# 【接收者定义】上面route里提到的Default、Watchdog、Critical、null，
# 都必须在这里"声明"存在，具体的通知方式（邮件、webhook、钉钉等）也在这里配置

- name: Default  
  # 定义一个名为"Default"的接收者，但是这里没有配置任何具体的发送方式(如email_configs等)
  # 所以实际上它不会真的发送任何通知，只是个"占位符"
  
- name: Watchdog  
  # 同样没有配置具体发送方式，Watchdog告警匹配到这里也不会真正发送通知

- name: Critical  
  # 同样为空，如果想让Critical告警真正发出去，需要在这里加上比如：
  # webhook_configs / email_configs / wechat_configs 等具体配置

- name: "null"  
  # 特殊的"黑洞"接收者，习惯上用来"丢弃"不想要通知的告警（比如InfoInhibitor）


templates: []  
# 【自定义模板文件路径】用于自定义告警通知内容的展示格式（比如邮件正文、webhook的JSON格式等）
# 这里是空数组，表示没有引入任何自定义模板，使用Alertmanager内置的默认模板

上述配置主要分成下面几个部分，接下来对每一部分进行解读:

部分 作用总结
global 全局默认配置，主要是 SMTP 邮件服务器信息和各种通知渠道的默认 URL
route 告警路由树。所有告警从这里开始匹配，决定最终发给哪个接收器
inhibit_rules 抑制规则，用来实现「高级别告警抑制低级别告警」，减少告警轰炸
receivers 实际通知方式的定义。当前全部是空的，真正的邮件/钉钉/企业微信等配置通常写在 AlertmanagerConfig CRD 里，或者后续补充到这里

1.1、global：全局默认值

这一段的作用是”给所有接收器提供默认参数“，这样你在每个 receiver 里就不用重复写 SMTP 地址、API 地址等。receiver 里如果单独写了同名参数，会覆盖 global 的值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
global:
  # 【重要】"告警自动消失"的超时时间。
  # 如果一条告警在这段时间内没有再次被推送过来，Alertmanager 就认为它已恢复(resolved)。
  # 注意：Prometheus 推送告警时会自带 EndsAt 字段，所以这个参数主要作用于
  # 通过 API 手动推送的、没带结束时间的告警。默认 5m。
  resolve_timeout: 5m

  # 全局 HTTP 客户端配置，所有走 HTTP 的通知方式(webhook/钉钉/企业微信/Slack…)都用它。
  # 这里还可以配 proxy_url(代理)、basic_auth、bearer_token、tls_config 等。
  http_config:
    follow_redirects: true   # 遇到 301/302 重定向时自动跟随，默认 true
    enable_http2: true       # 允许使用 HTTP/2 协议，默认 true；对端不支持时会自动降级到 HTTP/1.1

  # ↓↓↓ 以下是各类第三方通知平台的默认 API 地址 ↓↓↓
  # 平时完全不用改，它们的存在意义是：当你用的是私有化部署版本
  # (比如自建 PagerDuty 代理、企业微信专属版)时，可以在这里统一改成内网地址
  pagerduty_url: https://events.pagerduty.com/v2/enqueue                      # PagerDuty 事件接口
  opsgenie_api_url: https://api.opsgenie.com/                                 # Opsgenie 接口
  wechat_api_url: https://qyapi.weixin.qq.com/cgi-bin/                        # 企业微信接口（注意是企业微信，不是个人微信）
  victorops_api_url: https://alert.victorops.com/integrations/generic/20131114/alert/  # VictorOps(Splunk On-Call)接口
  telegram_api_url: https://api.telegram.org                                  # Telegram Bot 接口
  webex_api_url: https://webexapis.com/v1/messages                            # Cisco Webex 接口

1.2、route：路由树（整个配置的核心）

route 是一棵树。根节点（顶层 route）必须存在且必须有 receiver，作为”兜底”；子路由写在 routes 列表里。告警进来后从根开始，按顺序逐个尝试匹配子路由，第一个匹配上的就停下（除非该子路由写了 continue: true）；如果所有子路由都不匹配，就用当前节点的 receiver 处理。

子路由会继承父节点的 group_by、group_wait、group_interval、repeat_interval，除非自己重新定义。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
route:
  # 兜底接收器：所有没被下面子路由匹配到的告警，都发给名为 Default 的接收器
  receiver: Default

  # 【核心概念·分组】按哪些标签把告警聚合成一组，同组的告警合并成一封通知发出。
  # 这里按 namespace 分组：某个 namespace 同时炸了 20 个 Pod，你只会收到 1 封含 20 条的邮件，
  # 而不是 20 封邮件。这是防止"告警风暴"最有效的手段。
  # 常见写法：[alertname, cluster, service]；
  # 特殊值 ['...'] 表示不分组（每条告警单独发）；写 [] 表示所有告警合并成一大组。
  group_by:
  - namespace

  # 匹配成功后是否继续往下匹配兄弟路由。false=匹配到就结束（这是默认值）。
  # 写在根节点上意义不大，它主要用于子路由：比如你想让 critical 告警
  # 既发给值班群、又发给短信网关，就把第一个路由设成 continue: true
  continue: false

  # 子路由列表，自上而下按顺序匹配
  routes:

  # 子路由1：Watchdog（看门狗/心跳告警）
  # Watchdog 是 kube-prometheus-stack 内置的一条"永远处于 firing 状态"的假告警。
  # 它的用途是"死人开关(Dead Man's Switch)"：既然它必须一直响，
  # 那你一旦停止收到它，就说明 Prometheus 或 Alertmanager 本身挂了。
  # 生产环境通常把它转发给外部监控服务(如 healthchecks.io)做反向监控
  - receiver: Watchdog
    matchers:
    - alertname="Watchdog"   # 匹配条件：标签 alertname 的值等于 Watchdog
    continue: false          # 匹配到就不再往下走

  # 子路由2：InfoInhibitor（信息级抑制器）
  # 这也是 kube-prometheus-stack 内置的一条辅助告警：当某个 namespace 里
  # 出现了 warning 及以上级别的告警时，它就会触发，专门用来在下面的
  # inhibit_rules 中"压制"同 namespace 的 info 级告警。
  # 它自己纯粹是工具人，绝不能发出去，所以扔进名为 "null" 的黑洞接收器
  - receiver: "null"         # 引号必须加！YAML 里裸写的 null 会被解析成"空值"而不是字符串
    matchers:
    - alertname="InfoInhibitor"
    continue: false

  # 子路由3：所有 severity=critical 的严重告警走 Critical 接收器
  # 【注意顺序】它排在最后，所以即使 Watchdog 带有 critical 标签，
  # 也会先被上面的规则截胡。路由顺序 = 优先级
  - receiver: Critical
    matchers:
    - severity="critical"
    continue: false

  # ↓↓↓ 三个时间参数（YAML 里位置随意，它们属于根 route，会被所有子路由继承）↓↓↓
  # 【首次等待】一个"新分组"产生后，先憋 30 秒再发第一封通知。
  # 目的是等一等同组的其他告警一起到齐，凑成一封。太小则通知碎片化，太大则响应延迟。
  # 推荐 30s ~ 1m
  group_wait: 30s

  # 【增量等待】某个分组已经发过通知后，如果组内又"新增"了告警，
  # 至少要间隔 5 分钟才会再发一封（包含新增内容）。防止同一组频繁刷屏。
  # 推荐 5m
  group_interval: 5m

  # 【重复提醒】如果一个分组的内容没有任何变化、且一直没恢复，
  # 每隔 12 小时重新提醒你一次（防止你忘了还有故障没处理）。
  # 生产上常设 1h~4h；设太小会被反复轰炸导致"告警疲劳"
  repeat_interval: 3h

matchers 的四种运算符

matchers 是新版语法（旧版是 match 和 match_re，已废弃但仍兼容），支持四种操作：=（等于）、!=（不等于）、=~（正则匹配）、!~（正则不匹配）。正则默认是完全锚定的，也就是 severity=~"warn" 不会匹配 warning，得写 severity=~"warn.*"。值里有空格或特殊字符时用双引号包起来，例如 - team="db ops"。

三个时间参数的直观时间线

假设 12:00:00 某 namespace 第一次爆出告警 A：

12:00:00 告警 A 到达，创建新分组，开始 group_wait 倒计时 → 12:00:20 同组又来了告警 B，一起等着 → 12:00:30 group_wait 到期，发出第 1 封通知（含 A、B）→ 12:01:00 来了告警 C，但要等 group_interval → 12:05:30 发出第 2 封通知（含 A、B、C）→ 之后一直没变化 → 12:05:30 + 12h 发出第 3 封重复提醒。

1.3、inhibit_rules：抑制规则

抑制的作用是”大问题发生时，闭掉由它引起的小问题告警“。逻辑是：如果存在一条匹配 source_matchers 的正在告警的源告警，那么所有匹配 target_matchers 且 equal 列出的标签值都与源告警相同的目标告警，都不会发出通知（它们依然存在，只是被静音）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
inhibit_rules:

# 规则1：critical 压制 warning 和 info
- source_matchers:            # 源（"大哥"）：severity=critical 的告警
  - severity="critical"
  target_matchers:            # 目标（"小弟"）：severity 是 warning 或 info 的告警
  - severity=~"warning|info"  # =~ 表示正则匹配
  equal:                      # 只有当这些标签的值完全一致时才抑制
  - namespace                 # 必须同一个 namespace
  - alertname                 # 且必须是同一条告警规则
  # 效果：同一个 namespace 下同名告警，既有 critical 又有 warning 时，只发 critical 那条

# 规则2：warning 压制 info（同上，只是降了一档）
- source_matchers:
  - severity="warning"
  target_matchers:
  - severity="info"
  equal:
  - namespace
  - alertname

# 规则3：InfoInhibitor 压制所有 info
- source_matchers:
  - alertname="InfoInhibitor"   # 前面提到的那个"工具人"告警
  target_matchers:
  - severity="info"
  equal:
  - namespace                   # 只要同一个 namespace 里有更严重的问题，
                                # 该 namespace 下所有 info 级告警全部闭嘴

这里有个容易忽略的细节：equal 里列的标签如果在源和目标告警上都不存在，Alertmanager 会认为它们”相等”，抑制照样生效。所以 equal 尽量选那些一定存在的标签。另外，源告警自己不会被自己抑制（Alertmanager 有防自锁保护）。

1.4、receivers：接收器

1
2
3
4
5
receivers:
- name: Default    # 只有名字，没有任何 xxx_configs
- name: Watchdog   # 意味着：告警确实被路由到这里了，但不会发送到任何地方
- name: Critical   # 等于"静静地丢掉"
- name: "null"     # 专门作黑洞用的空接收器

这是这份默认配置最需要你动手改的地方：四个接收器全是空壳，所以你配了 SMTP 也一封邮件都收不到。要真正发邮件，得这样写：

1
2
3
4
5
6
7
8
9
10
11
receivers:
- name: Default
  email_configs:                        # 一个 receiver 下可以配多个渠道，会同时发
  - to: ops-team@example.com            # 收件人，多个用逗号分隔
    send_resolved: true                 # 【常用】告警恢复时是否也发一封"已恢复"通知，默认 false
    # from / smarthost / auth_* 这里不写就自动继承 global 的值

- name: Critical
  email_configs:
  - to: oncall@example.com
    send_resolved: true

1.5、templates

用于放置自定义模板的位置；

1
2
3
4
5
6
templates: []
# 自定义通知模板文件的路径列表，支持通配符，例如：
# templates:
#   - '/etc/alertmanager/templates/*.tmpl'
# 空数组表示只用 Alertmanager 内置的默认模板。
# 想让邮件/钉钉消息长得好看、带中文说明，就在这里加自己的 Go template 文件

2.Alertmanager告警通知配置

2.1、配置告警邮箱

邮件通知需要先开启邮箱服务的 IMAP/SMTP 服务，这里以 163邮箱 为例：

登录邮箱-【设置】-【POP3/SMTP/IMAP】-点击【IMAP/SMTP服务】的【开启】按钮


开启后会提供一个授权码【RDunW9PG2CHrcMM2】

接下来通过Alertmanager 的配置文件，添加邮箱服务配置，用 Prometheus Operator 部署的 Alertmanager配置文件实际存放在一个 Secret 资源里

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
# 项目路径kube-prometheus-release-0.14/manifests中的alertmanager-secret.yaml文件中
[root@k8s-master01 manifests]# ll alertmanager-*
-rw-r--r-- 1 root root 1264 Jul 11 15:39 alertmanager-alertmanager.yaml
-rw-r--r-- 1 root root  977 Jul 23  2025 alertmanager-networkPolicy.yaml
-rw-r--r-- 1 root root  561 Jul 23  2025 alertmanager-podDisruptionBudget.yaml
-rw-r--r-- 1 root root 6979 Jul 23  2025 alertmanager-prometheusRule.yaml
-rw-r--r-- 1 root root 1443 Jul 23  2025 alertmanager-secret.yaml
-rw-r--r-- 1 root root  351 Jul 23  2025 alertmanager-serviceAccount.yaml
-rw-r--r-- 1 root root  637 Jul 23  2025 alertmanager-serviceMonitor.yaml
-rw-r--r-- 1 root root  650 Jul 23  2025 alertmanager-service.yaml

# 在 alertmanager-secret.yaml 文件的 global 添加邮箱配置，在receivers的Default添加收件人，如下：
[root@k8s-master01 manifests]# vim alertmanager-secret.yaml
# 添加16-21行，45-47行内容，注意添加区域
1 apiVersion: v1
  2 kind: Secret
  3 metadata:
  4   labels:
  5     app.kubernetes.io/component: alert-router
  6     app.kubernetes.io/instance: main
  7     app.kubernetes.io/name: alertmanager
  8     app.kubernetes.io/part-of: kube-prometheus
  9     app.kubernetes.io/version: 0.27.0
 10   name: alertmanager-main
 11   namespace: monitoring
 12 stringData:
 13   alertmanager.yaml: |-
 14     "global":
 15       "resolve_timeout": "5m"
 16       smtp_from: 'liujunwei0925@163.com'
 17       smtp_smarthost: 'smtp.163.com:465'
 18       smtp_hello: '163.com'
 19       smtp_auth_username: 'liujunwei0925@163.com'
 20       smtp_auth_password: 'RDunW9PG2CHrcMM2'
 21       smtp_require_tls: false
 22     "inhibit_rules":
 23     - "equal":
 24       - "namespace"
 25       - "alertname"
 26       "source_matchers":
 27       - "severity = critical"
 28       "target_matchers":
 29       - "severity =~ warning|info"
 ...
 43     "receivers":
 44     - "name": "Default"
 45       "email_configs":  #这里的收件人邮箱可以不配置，后面在AlertmanagerConfig单独配置
 46         - to: "liujunwei@jiugen.net"
 47           send_resolved: true   #告警如果解决了是否发送通知
 48     - "name": "Watchdog"
 49     - "name": "Critical"
 50     - "name": "null"
 51     "route":
 52       "group_by":
...

将更改好的 Alertmanager 配置加载到 Alertmanager：

1
2
[root@k8s-master01 manifests]# kubectl replace -f  alertmanager-secret.yaml
secret/alertmanager-main replaced

稍等几分钟即可在 Alertmanager 的 Web 界面看到更改的配置（Status）：

同时邮箱会正常收到告警邮件：

2.2、通过AlertmanagerConfig实现邮件告警

如果需要将自定义的告警发送至邮件，可以使用 AlertmanagerConfig 进行单独配置，比如 把 Blackbox 的告警发送到邮箱。

要想实现主 Alertmanager 资源能选中AlertmanagerConfig资源，必须在Alertmanager 资源的 spec.alertmanagerConfigSelector 匹配到AlertmanagerConfig中定义的标签才行，有两种匹配方式，一种是匹配所有AlertmanagerConfig，另一种是根据定义的标签精确匹配

匹配所有AlertmanagerConfig：

1
2
3
4
5
6
7
8
9
10
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
  name: main
  namespace: monitoring
spec:
  alertmanagerConfigSelector: {}   # 空对象，匹配所有 AlertmanagerConfig
  alertmanagerConfigNamespaceSelector: {}     # 同样放开，匹配所有 namespace
  
# 注意，如果 AlertmanagerConfig 分散在多个不同 namespace（不只是和 Alertmanager 资源同一个 namespace），还要一起把命名空间选择器也放开，否则默认只会扫描 Alertmanager 资源自身所在的 namespace

根据标签匹配AlertmanagerConfig：

1
2
3
4
5
6
7
8
9
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
  name: main
  namespace: monitoring
spec:
  alertmanagerConfigSelector:
    matchLabels:
      alertmanagerConfig: email    # 必须和 AlertmanagerConfig 的 label 一致
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: email-alert-config
  namespace: monitoring
  labels:  #重点是AlertmanagerConfig资源定义的标签要和Alertmanager中spec.alertmanagerConfigSelector.matchLabels中的标签匹配
    alertmanagerConfig: email     # 关键：这个标签要能被主 Alertmanager 资源选中
spec:
  route:
    groupBy: ['alertname']        # 分组依据
    groupWait: 30s                # 组内首个告警等待时长
    groupInterval: 5m             # 同组新增告警最短发送间隔
    repeatInterval: 12h           # 未解决告警重复提醒间隔
    receiver: 'email-receiver'    # 该路由默认发给这个接收器
  receivers:
  - name: 'email-receiver'
    emailConfigs:
    - to: 'ops-team@yourcompany.com'
      from: 'alertmanager@yourcompany.com'
      smarthost: 'smtp.example.com:587'   # SMTP服务器:端口
      authUsername: 'alertmanager@yourcompany.com'
      authPassword:
        name: smtp-auth              # 引用第一步创建的 Secret
        key: password
      requireTLS: true
      sendResolved: true             # 告警恢复也发通知
      headers:
      - key: Subject
        value: '[告警] {{ .CommonLabels.alertname }}'

首先确认 Alertmanager 的配置中有没有alertmanagerConfigSelector相关配置，如果没有则添加 AlertmanagerConfig 相关配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
# 可以直接编辑release-0.14/kube-prometheus-release-0.14/manifests/ alertmanager-alertmanager.yaml文件，也可以执行kubectl edit -n monitoring alertmanager main在线编辑alertmanager资源  
[root@k8s-master01 manifests]# vim alertmanager-alertmanager.yaml
# 为了方便我配置的是匹配所有命名空间的所有AlertmanagerConfig
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
  labels:
    app.kubernetes.io/component: alert-router
    app.kubernetes.io/instance: main
    app.kubernetes.io/name: alertmanager
    app.kubernetes.io/part-of: kube-prometheus
    app.kubernetes.io/version: 0.27.0
  name: main
  namespace: monitoring
spec:
  # 主要添加下面两行
  alertmanagerConfigSelector: {}  # 空对象，匹配所有 AlertmanagerConfig
  alertmanagerConfigNamespaceSelector: {}   # 同样放开，匹配所有 namespace
  #image: quay.io/prometheus/alertmanager:v0.27.0
  image: registry.cn-beijing.aliyuncs.com/k8s-liujunwei/alertmanager:v0.27.0
  nodeSelector:
    kubernetes.io/os: linux
  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: cfs-sc
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 2Gi   # alertmanager 数据量很小，几个 G 足够 
  podMetadata:
    labels:
      app.kubernetes.io/component: alert-router
      app.kubernetes.io/instance: main
      app.kubernetes.io/name: alertmanager
      app.kubernetes.io/part-of: kube-prometheus
      app.kubernetes.io/version: 0.27.0
  replicas: 1
  resources:
    limits:
      cpu: 100m
      memory: 100Mi
    requests:
      cpu: 4m
      memory: 100Mi
  secrets: []
  securityContext:
    fsGroup: 2000
    runAsNonRoot: true
    runAsUser: 1000
  serviceAccountName: alertmanager-main
  version: 0.27.0

重新加载配置：

1
2
[root@k8s-master01 manifests]# kubectl replace -f alertmanager-alertmanager.yaml
alertmanager.monitoring.coreos.com/main replaced

接下来创建AlertmanagerConfig资源来实现域名(Blackbox )的告警通知：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
vim blackbox-alertmanagerconfig.yaml
# 在文件添加以下字段
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: blackbox-alerts
  namespace: monitoring  
  #labels:
    # 这个标签非常重要！主 Alertmanager 靠这个标签来发现并加载这个配置文件
    # 具体的标签名和值，取决于你们 Prometheus Operator 的安装配置
    #alertmanagerConfig: main 
spec:
  # 1. 路由分发规则 (Route) - 决定告警去哪儿
  route:
    # 兜底接收器：如果告警没有匹配到下面的任何子路由，就发给它
    receiver: 'default'
    # 分组依据：把同名且同级别的告警打包在一起发出来
    groupBy: ['team', 'job']
    # 分组等待时间：发现新告警后，等 30 秒，看看有没有同类的告警，有的话打包一起发，防止一瞬间发 10 条单条消息
    groupWait: 30s 
    # 分组间隔：如果 30 秒后发出了第一封邮件，过了 5 分钟又出现了同组的新告警，才会发第二封邮件
    groupInterval: 5m 
    # 重复告警间隔：如果一个告警一直没解决，每隔 12 小时重新发一次提醒你
    repeatInterval: 12h 
    # 子路由列表 (这里打破继承，按严重程度分发)
    routes:
      - receiver: 'web-email'
        matchers: # 匹配条件，同时满足：severity = critical，team = web
          - name: severity
            value: critical
            matchType: =  # 注意语法：CRD 里的匹配类型要单独用 matchType 写出来 (=, !=, =~, !~)
          - name: team
            value: web
            matchType: =  # 注意语法：CRD 里的匹配类型要单独用 matchType 写出来 (=, !=, =~, !~)
  # 定义接收器列表 (Receivers)
  receivers:
    # 接收器：发送邮件
    - name: 'web-email'
      emailConfigs:
        - to: 'liujunwei@jiugen.net'
          sendResolved: true  # 发送已解决的告警

     # 默认接收器
    - name: 'default'

创建AlertmanagerConfig资源：

1
2
3
4
5
6
7
# kubectl create -f blackbox-alertmanagerconfig.yaml
alertmanagerconfig.monitoring.coreos.com/blackbox-alerts created

#查看创建的资源
[root@k8s-master01 AlertmanagerConfig]# kubectl get -f blackbox-alertmanagerconfig.yaml
NAME              AGE
blackbox-alerts   2m43s

检查创建的AlertmanagerConfig是否被主配置加载：

通过[Alertmanager的web UI 的Status查看，如果有该配置说明正常：


检查邮箱是否收到通知：

其他案例：结合[四.4]中[基于Grafana面板告警]对节点的cpu告警做邮件通知：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
# 创建AlertmanagerConfig资源
vim node-memory-alertmanager-config.yaml
# 配置如下
# API 组与版本：AlertmanagerConfig 属于 Prometheus Operator 提供的 CRD
# v1alpha1 是较常用的稳定版本（也有 v1beta1）
apiVersion: monitoring.coreos.com/v1alpha1

# 资源类型：AlertmanagerConfig，用于声明式定义 Alertmanager 的路由与接收器
# 注意：不会自动生效，需被 Alertmanager CR 的 alertmanagerConfigSelector 选中
kind: AlertmanagerConfig

metadata:
  # 该 AlertmanagerConfig 资源在集群中的名称
  name: node-memory-alert

  # 资源所在命名空间
  # Prometheus Operator 会自动给该配置注入 namespace="<此值>" 的隐藏 matcher
  # 因此只会处理同命名空间（monitoring）内产生的告警
  namespace: monitoring

spec:
  # ---------- 路由树定义 ----------
  # 定义告警如何匹配、如何分组、以及发送到哪个接收器
  # 该 route 会被 Operator 作为一级子路由挂到 Alertmanager 全局配置中
  route:
    # 匹配成功后，告警发送到的接收器名称
    # 必须在下方 receivers 列表中存在同名项
    receiver: liujunwei

    # 告警分组依据的 label 列表
    # 相同 alertname + type 的告警会被合并成同一组通知，避免刷屏
    groupBy:
      - alertname   # 按告警名称分组（来自 PrometheusRule 中的 alert 字段）
      - type        # 按自定义 label type 分组（来自 PrometheusRule labels.type）

    # 同一组告警首次触发后，等待多久再发出第一封通知
    # 作用：给短时间内的抖动留缓冲，减少瞬时误报
    groupWait: 30s

    # 同一组已发过通知后，若组内告警有新增/变化，间隔多久再发更新通知
    # 作用：控制同一告警组的更新频率
    groupInterval: 10m

    # 同一组告警在状态未变化（仍 firing）时，重复发送通知的最小间隔
    # 作用：防止长时间未恢复的告警过于频繁地骚扰
    repeatInterval: 1h

    # 标签匹配条件列表（AND 关系：全部满足才命中该路由）
    # 对一级 route，Operator 还会额外强制加上 namespace=monitoring
    matchers:
      # 条件 1：告警名称必须等于 NodeMemoryUseTooHigh
      - name: alertname              # 要匹配的 label 名
        value: NodeMemoryUseTooHigh  # 期望的 label 值
        matchType: =                 # 匹配运算符：= 精确相等
                                     # 可选值：= 等于 / != 不等于 / =~ 正则 / !~ 正则不匹配
      # 条件 2：严重级别必须等于 warning
      - name: severity               # 要匹配的 label 名（来自 PrometheusRule labels.severity）
        value: warning
        matchType: =

  # ---------- 接收器列表 ----------
  receivers:
    # 接收器名称，与 route.receiver 对应
    - name: liujunwei
      # 邮件通知配置（可配置多项，会同时发送到多个地址）
      emailConfigs:
        - to: 'liujunwei@jiugen.net'   # 收件人邮箱地址

          # 告警从 firing 恢复为 resolved 时，是否发送“已恢复”通知
          # true  = 发送恢复通知；false = 只在触发时通知（默认）
          sendResolved: true

创建资源：

1
kubectl create -f node-memory-alertmanager-config.yaml

查看资源：

1
2
3
# kubectl get -f node-memory-alertmanager-config.yaml
NAME                AGE
node-memory-alert   50m

web端查看是否加载到主配置：


检查邮箱是否收到邮件通知：

2.3、Alertmanager配置企业微信通知

2.3.1申请企业微信并配置

首先需要在企业微信官网注册企业微信账号：https://work.weixin.qq.com/，如有忽略。 注册完成后进行登录，登录后点击我的企业-拿到【企业ID】信息：

在页面的最下面找到企业 ID并记录，稍后会用到：


创建一个子部门用于接受告警通知：


定义部门名称，点击确定创建即可

之后在 Alertmanager 子部门添加相关的人员即可，在此不演示添加过程，加添好后如下图所示：

查看该部门 ID并记录，后面创建应用会用到该ID：部分ID是2

接下来创建机器人应用，用来接受告警，首先点击应用管理→应用创建：

根据自身情况设置头像，应用名称，应用介绍：

继续选择部门/成员：选择要通知的人员即可

创建完成后，查看 AgentId 和 Secret并记录：

AgentId：1000002

Secret：点击【查看】，会将信息发送到自己的企业微信上

2.3.2配置可信域名和ip

接下来需要在企业微信添加可信域名，并且需要完成网页授权。网页授权的条件如下：

  1. 必须要有一个公网可以访问的域名（需要是已经备案的域名）。

  2. 将授权文件放在域名的根目录下，也就是通过 http(s)://你的域名/xxx.txt 可以直接访问到 该文件

    首先添加可信域名：点击创建的告警应用

    添加可信域名，然后根据提示下载文件，并将下载txt文件上传到域名的站点目录中，点击确定即可：

    要能访问到，如下图：

    接下来配置企业可信IP：

    企业可信IP 填的是：实际发起企业微信 API 调用的那台（或多台）服务器的公网出口 IP。

    在 Prometheus 告警场景下，就是 运行 Alertmanager 的服务器（因为是 Alertmanager 去调用企业微信的接口发消息），而不是 Prometheus 服务器本身。

    情况 应该填的 IP 说明
    只有一台 Alertmanager 这台机器的公网出口 IP 最常见
    多台 Alertmanager（高可用） 所有会发请求的机器的公网出口 IP 用英文分号 ; 隔开，最多 120 个
    通过 NAT / 负载均衡 / 代理出口 NAT 网关 / 代理 / 负载均衡的公网 IP 填真正出去访问公网的那个 IP
    云服务器（阿里云/腾讯云等） 弹性公网 IP（EIP）或绑定的公网 IP 私有 IP（内网）无效
    动态 IP 不推荐，尽量换成固定公网 IP 企业微信要求稳定 IP

    最准确的确认方法（推荐直接做）：最靠谱的方法是从服务器本身去测试，让企业微信告诉你它看到的来源 IP：

    在 Alertmanager 的pod上执行（把企业ID和应用的Secret替换成你的真实值）：

    1
    2
    3
    4
    # curl "https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid=你的企业ID&corpsecret=应用的Secret"

    没有curl命令也可以用wget
    # wget -qO- "https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid=wwca532c53930d132dID&corpsecret=akajDGJqwfCULnJqriRq6tGKJxuG7NR0DITwt9XgwUA"

    如果还没配可信 IP，返回结果里通常会有类似：

    1
    {"errcode":40013,"errmsg":"invalid corpid, hint: [1786514493390121202376757], from ip: 120.245.124.125, more info at https://open.work.weixin.qq.com/devtool/query?e=40013"}

    from ip: 后面的那个 IP，就是你需要添加到「企业可信IP」里的地址。

    也可以直接在服务器上查公网出口：

    1
    2
    3
    curl ifconfig.me
    # 或
    curl ip.sb

    多台服务器

2.3.3Alertmanager 配置

企业微信配置完成后，修改 Alertmanager 配置文件，添加企业微信告警。

首先修改 Global的配置，添加一些通用配置，wechat_api_url 是固定配置，corp_id 为企业 ID：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# 进入到项目Kube-Prometheus目录中release-0.14/kube-prometheus-release-0.14/manifests
[root@k8s-master01 manifests]# vim alertmanager-secret.yaml
# 添加22 23两行内容
  1 apiVersion: v1
  2 kind: Secret
  3 metadata:
  4   labels:
  5     app.kubernetes.io/component: alert-router
  6     app.kubernetes.io/instance: main
  7     app.kubernetes.io/name: alertmanager
  8     app.kubernetes.io/part-of: kube-prometheus
  9     app.kubernetes.io/version: 0.27.0
 10   name: alertmanager-main
 11   namespace: monitoring
 12 stringData:
 13   alertmanager.yaml: |-
 14     "global":
 15       "resolve_timeout": "5m"
 16       smtp_from: 'liujunwei0925@163.com'
 17       smtp_smarthost: 'smtp.163.com:465'
 18       smtp_hello: '163.com'
 19       smtp_auth_username: 'liujunwei0925@163.com'
 20       smtp_auth_password: 'RDunW9PG2CHrcMM2'
 21       smtp_require_tls: false
 22       wechat_api_url: https://qyapi.weixin.qq.com/cgi-bin/  #固定企业微信接口
 23       wechat_api_corp_id: "wwca532c53930d132d"  # 这里是企业ID，2.3.1步骤中的企业ID
 24     "inhibit_rules":
 25     - "equal":
 26       - "namespace"
 27       - "alertname"
 28       "source_matchers":
 29       - "severity = critical"

更新配置：

1
2
[root@k8s-master01 manifests]# kubectl replace -f alertmanager-secret.yaml
secret/alertmanager-main replaced

通过Alertmanager的web UI检查新添加的配置是否被加载：

2.3.4创建AlertmanagerConfig 实现微信告警通知

接下来可以通过创建AlertmanagerConfig将告警推送至企业微信。

首先创建 Secret（存放企业微信密钥），这里的密钥是步骤2.3.1中得到的

1
2
3
4
5
6
7
8
9
# 创建secret保存该密钥
[root@k8s-master01 manifests]# kubectl create secret generic webchat-alert-secret --from-literal=secret=akajDGJqwfCULnJqriRq6tGKJxuG7NR0DITwt9XgwUA -n monitoring

# 参数解释：
webchat-alert-secret 是 Secret 的名字（随便起，都行）。
--from-literal=secret=xxx 表示把这个长字符串（你的应用 Secret）放到 Secret 里，键名叫 secret。
-n monitoring 指定在 monitoring 命名空间。
后续在 AlertmanagerConfig 里会引用这个 Secret。
注意：这个 secret=xxx 就是在企业微信应用管理里复制的那个 Secret（不是 corp_id）。

接下来使用 AlertmanagerConfig 推送告警到企业微信：

案例：将 MySQL 和 Redis 的告警 通知到企业微信：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# 创建 MySQL和 Redis 的AlertmanagerConfig
[root@k8s-master01 AlertmanagerConfig]# vim mysql-redis-alertmanagerconfig.yaml
# 配置如下：
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: mysql-redis-alert  # AlertmanagerConfig资源名称
  namespace: monitoring
spec:
  route:
    receiver: wechat
    groupBy:
    - team
    - severity
    - namespace
    groupWait: 30s
    groupInterval: 10m
    repeatInterval: 1h
    matchers:
      - name: team
        value: dba
        matchType: =
      - name: severity
        value: critical
        matchType: =
  receivers:
  - name: wechat
    wechatConfigs:
      - sendResolved: true  # 发送已解决的告警
        toParty: "2"         # 可改成部门ID（比如你公司部门）
        toUser: 'LiuJunWei'   # 可是具体 USER_ID（比如 LiuJunWei），也可以是@all部门的所有人
        agentID: "1000002"   # 创建的应用 ID
        apiSecret:
          key: "secret"       # 必须和创建 Secret 时指定的 key 一致
          name: "webchat-alert-secret"  # 引用创建的Secret 的名字

参数解读：

toParty: “2” 中的 2 是部门的id

toUser: ‘LiuJunWei’ 中的LiuJunWei是告警通知到组织成员的用户id，用户id就是下图中的账号，也可以用‘@all’ 意思是告警会通知该部门下的所有人

agentID: “1000002”，这里的1000002是创建的应用的id

创建AlertmanagerConfig资源：

1
2
[root@k8s-master01 AlertmanagerConfig]# kubectl create -f mysql-redis-alertmanagerconfig.yaml
alertmanagerconfig.monitoring.coreos.com/mysql-redis-alert created

在Alertmanager的web UI检查新添加的配置是否被加载：


删除MySQL服务的pod，来模拟MySQL宕机，验证是否能收到告警通知：

1
2
3
4
5
6
7
8
9
10
11
12
13
# 服务在default空间下
[root@k8s-master01 AlertmanagerConfig]# kubectl get pod
NAME                    READY   STATUS    RESTARTS        AGE
mysql-965c7bd7f-mrj5f   1/1     Running   3 (4d23h ago)   16d
redis-0                 1/1     Running   3 (4d23h ago)   16d

# 删除pod
[root@k8s-master01 AlertmanagerConfig]# kubectl scale deployment mysql --replicas=0
deployment.apps/mysql scaled
[root@k8s-master01 AlertmanagerConfig]# kubectl get deployments.apps
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
mysql   0/0     0            0           27d  #此时pod的副本数为0

正常会在Alertmanager的web UI产生告警：

查企业微信上是否收到告警信息：

2.3.5自定义告警模板

Alertmanager + 企业微信 + 自定义模板 全流程配置如下：

第一步：修改 alertmanager-secret.yaml（添加自定义模板）
Alertmanager 读取 templates 目录里的文件，把文件内容当作模板引擎。 {{ define "wechat.default.message" }} 就是给这个模板起一个名字，叫 wechat.default.message。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
# 进入项目的部署目录release-0.14/kube-prometheus-release-0.14/manifests
# 在alertmanager-secret.yaml中添加自定义模板
[root@k8s-master01 manifests]# vim alertmanager-secret.yaml
# 在stringData字段下添加模板内容
apiVersion: v1
kind: Secret
metadata:
  labels:
    app.kubernetes.io/component: alert-router
    app.kubernetes.io/instance: main
    app.kubernetes.io/name: alertmanager
    app.kubernetes.io/part-of: kube-prometheus
    app.kubernetes.io/version: 0.27.0
  name: alertmanager-main
  namespace: monitoring
stringData:  #在此配置模板的内容
  wechat.tmpl: |-
      {{ define "wechat.default.message" }}
      {{- if gt (len .Alerts.Firing) 0 -}}
      {{- range $index, $alert := .Alerts -}}
      {{- if eq $index 0 }}
      ==========异常告警==========
      告警类型: {{ $alert.Labels.alertname }}
      告警级别: {{ $alert.Labels.severity }}
      告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description }};{{ $alert.Annotations.summary }}
      故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
      {{- if gt (len $alert.Labels.instance) 0 }}
      实例信息: {{ $alert.Labels.instance }}
      {{- end }}
      {{- if gt (len $alert.Labels.namespace) 0 }}
      命名空间: {{ $alert.Labels.namespace }}
      {{- end }}
      {{- if gt (len $alert.Labels.node) 0 }}
      节点信息: {{ $alert.Labels.node }}
      {{- end }}
      {{- if gt (len $alert.Labels.pod) 0 }}
      实例名称: {{ $alert.Labels.pod }}
      {{- end }}
      ============END============
      {{- end }}
      {{- end }}
      {{- end }}
      {{- if gt (len .Alerts.Resolved) 0 -}}
      {{- range $index, $alert := .Alerts -}}
      {{- if eq $index 0 }}
      ==========异常恢复==========
      告警类型: {{ $alert.Labels.alertname }}
      告警级别: {{ $alert.Labels.severity }}
      告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description }};{{ $alert.Annotations.summary }}
      故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
      恢复时间: {{ ($alert.EndsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
      {{- if gt (len $alert.Labels.instance) 0 }}
      实例信息: {{ $alert.Labels.instance }}
      {{- end }}
      {{- if gt (len $alert.Labels.namespace) 0 }}
      命名空间: {{ $alert.Labels.namespace }}
      {{- end }}
      {{- if gt (len $alert.Labels.node) 0 }}
      节点信息: {{ $alert.Labels.node }}
      {{- end }}
      {{- if gt (len $alert.Labels.pod) 0 }}
      实例名称: {{ $alert.Labels.pod }}
      {{- end }}
      ============END============
      {{- end }}
      {{- end }}
      {{- end }}
      {{- end }}
  alertmanager.yaml: |-
    "global":
      "resolve_timeout": "5m"
      smtp_from: 'liujunwei0925@163.com'
      smtp_smarthost: 'smtp.163.com:465'
      smtp_hello: '163.com'
      smtp_auth_username: 'liujunwei0925@163.com'

添加模板文件位置：还是编辑alertmanager-secret.yaml文件，在alertmanager.yaml下添加templates参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
apiVersion: v1
kind: Secret
metadata:
  labels:
    app.kubernetes.io/component: alert-router
    app.kubernetes.io/instance: main
    app.kubernetes.io/name: alertmanager
    app.kubernetes.io/part-of: kube-prometheus
    app.kubernetes.io/version: 0.27.0
  name: alertmanager-main
  namespace: monitoring
stringData:
  wechat.tmpl: |-
      {{ define "wechat.default.message" }}
      {{- if gt (len .Alerts.Firing) 0 -}}
      {{- range $index, $alert := .Alerts -}}
      {{- if eq $index 0 }}
      ==========异常告警==========
      告警类型: {{ $alert.Labels.alertname }}
      告警级别: {{ $alert.Labels.severity }}
      告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description }};{{ $alert.Annotations.summary }}
      故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
      {{- if gt (len $alert.Labels.instance) 0 }}
      实例信息: {{ $alert.Labels.instance }}
      {{- end }}
      {{- if gt (len $alert.Labels.namespace) 0 }}
      命名空间: {{ $alert.Labels.namespace }}
      {{- end }}
      {{- if gt (len $alert.Labels.node) 0 }}
      节点信息: {{ $alert.Labels.node }}
      {{- end }}
      {{- if gt (len $alert.Labels.pod) 0 }}
      实例名称: {{ $alert.Labels.pod }}
      {{- end }}
      ============END============
      {{- end }}
      {{- end }}
      {{- end }}
      {{- if gt (len .Alerts.Resolved) 0 -}}
      {{- range $index, $alert := .Alerts -}}
      {{- if eq $index 0 }}
      ==========异常恢复==========
      告警类型: {{ $alert.Labels.alertname }}
      告警级别: {{ $alert.Labels.severity }}
      告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description }};{{ $alert.Annotations.summary }}
      故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
      恢复时间: {{ ($alert.EndsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
      {{- if gt (len $alert.Labels.instance) 0 }}
      实例信息: {{ $alert.Labels.instance }}
      {{- end }}
      {{- if gt (len $alert.Labels.namespace) 0 }}
      命名空间: {{ $alert.Labels.namespace }}
      {{- end }}
      {{- if gt (len $alert.Labels.node) 0 }}
      节点信息: {{ $alert.Labels.node }}
      {{- end }}
      {{- if gt (len $alert.Labels.pod) 0 }}
      实例名称: {{ $alert.Labels.pod }}
      {{- end }}
      ============END============
      {{- end }}
      {{- end }}
      {{- end }}
      {{- end }}
  alertmanager.yaml: |-
    "global":
      "resolve_timeout": "5m"
      smtp_from: 'liujunwei0925@163.com'
      smtp_smarthost: 'smtp.163.com:465'
      smtp_hello: '163.com'
      smtp_auth_username: 'liujunwei0925@163.com'
      smtp_auth_password: 'RDunW9PG2CHrcMM2'
      smtp_require_tls: false
      wechat_api_url: https://qyapi.weixin.qq.com/cgi-bin/
      wechat_api_corp_id: "wwca532c53930d132d"
    templates:  # 添加该参数指定模板位置，注意templates和global同级
    - "/etc/alertmanager/config/*.tmpl"
    "inhibit_rules":
    - "equal":
      - "namespace"
      - "alertname"
      "source_matchers":
      - "severity = critical"

更新应用，加载新配置：

1
2
[root@k8s-master01 manifests]# kubectl replace -f alertmanager-secret.yaml
secret/alertmanager-main replaced

检查配置是否被加载：

1
2
3
4
5
6
7
# 进入alertmanager的pod的/etc/alertmanager/config路径有wechat.tmpl文件表示配置正确
[root@k8s-master01 manifests]# kubectl exec -ti -n monitoring alertmanager-main-0 -- sh
/alertmanager $ cd /etc/alertmanager/config
/etc/alertmanager/config $ ls -l
total 0
lrwxrwxrwx    1 root     2000            27 Aug  9 08:23 alertmanager.yaml.gz -> ..data/alertmanager.yaml.gz
lrwxrwxrwx    1 root     2000            18 Aug 12 15:48 wechat.tmpl -> ..data/wechat.tmpl

Alertmanager的web UI看到templates配置的参数表示正确：

第二步：修改AlertmanagerConfig

在AlertmanagerConfig资源中引用定义的自定义模板,以【2.3.4】中创建的mysql-redis-alertmanagerconfig.yaml为例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
[root@k8s-master01 AlertmanagerConfig]# vim mysql-redis-alertmanagerconfig.yaml
# 在spec.receivers.name.wechatConfigs下添加message参数
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: mysql-redis-alert  # AlertmanagerConfig资源名称
  namespace: monitoring
spec:
  route:
    receiver: wechat
    groupBy:
    - team
    - severity
    - namespace
    groupWait: 30s
    groupInterval: 10m
    repeatInterval: 1h
    matchers:
      - name: team
        value: dba
        matchType: =
      - name: severity
        value: critical
        matchType: =
  receivers:
  - name: wechat
    wechatConfigs:
      - sendResolved: true  # 发送已解决的告警
        toParty: "2"         # 可改成部门ID（比如你公司部门）
        toUser: 'LiuJunWei'   # 可是具体 USER_ID（比如 LiuJunWei），也可以是@all部门的所有人
        agentID: "1000002"   # 创建的应用 ID
        apiSecret:
          key: "secret"       # 必须和创建 Secret 时指定的 key 一致
          name: "webchat-alert-secret"  # 引用创建的Secret 的名字
        message: '{{ template "wechat.default.message" . }}'   # 添加此配置

注意：{{ template "wechat.default.message" . }} 配置的 wechat.default.message 是模板文件 define 定义的名称：{{ define "wechat.default.message" }}，不要配置文件名称(wechat.tmpl)。

更新AlertmanagerConfig配置：

1
2
[root@k8s-master01 AlertmanagerConfig]# kubectl replace -f mysql-redis-alertmanagerconfig.yaml
alertmanagerconfig.monitoring.coreos.com/mysql-redis-alert replaced

模拟MySQL宕机故障，并查看企业微信收到的告警通知：

1
kubectl scale deployment mysql --replicas=0

异常告警通知：

告警恢复通知：

2.4Alertmanager 实现钉钉告警通知

2.4.1配置钉钉机器人

Alertmanager 默认不支持钉钉告警，需要通过webhook的方式发送告警信息到钉钉；

使用钉钉告警，需要先创建一个群聊，群要至少有三个人，然后添加一个机器人：

打开【群设置】-【机器人】-【添加机器人】-选择【自定义】-【添加】

给机器人定义一个名字；

添加到群组默认即可(选择的是告警通知的群组)

安全设置中勾选加签(相当于创建了一个密钥，记住后面会用到)；

同意条款后点击【完成】即可创建


点击完成后会有如下图提示，记住Webhook的地址：https://oapi.dingtalk.com/robot/send?access_token=dbeefffbffdb41423c97f9a12bfa71c29886190a34bb7ce42615d39ea0ee70eb

2.4.2部署钉钉Webhook服务

下载钉钉 Webhook 服务部署文件：

项目在GitHub上：timonwong/prometheus-webhook-dingtalk

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
[root@k8s-master01 30-Prometheus]# git clone https://github.com/timonwong/prometheus-webhook-dingtalk.git
Cloning into 'prometheus-webhook-dingtalk'...
remote: Enumerating objects: 6397, done.
remote: Counting objects: 100% (294/294), done.
remote: Compressing objects: 100% (148/148), done.
remote: Total 6397 (delta 216), reused 146 (delta 146), pack-reused 6103 (from 2)
Receiving objects: 100% (6397/6397), 16.52 MiB | 314.00 KiB/s, done.
Resolving deltas: 100% (2104/2104), done.

[root@k8s-master01 30-Prometheus]# ll prometheus-webhook-dingtalk
total 104
-rw-r--r-- 1 root root  3168 Aug 13 16:53 CHANGELOG.md
drwxr-xr-x 3 root root    41 Aug 13 16:53 cmd
drwxr-xr-x 2 root root    62 Aug 13 16:53 config
-rw-r--r-- 1 root root  1299 Aug 13 16:53 config.example.yml
drwxr-xr-x 4 root root    34 Aug 13 16:53 contrib
-rw-r--r-- 1 root root  1188 Aug 13 16:53 Dockerfile
drwxr-xr-x 3 root root    37 Aug 13 16:53 docs
drwxr-xr-x 2 root root    28 Aug 13 16:53 examples
-rw-r--r-- 1 root root  1621 Aug 13 16:53 go.mod
-rw-r--r-- 1 root root 52207 Aug 13 16:53 go.sum
-rw-r--r-- 1 root root 11358 Aug 13 16:53 LICENSE
-rw-r--r-- 1 root root  2085 Aug 13 16:53 Makefile
-rw-r--r-- 1 root root 10536 Aug 13 16:53 Makefile.common
drwxr-xr-x 2 root root    29 Aug 13 16:53 notifier
drwxr-xr-x 4 root root    34 Aug 13 16:53 pkg
-rw-r--r-- 1 root root  3771 Aug 13 16:53 README.md
drwxr-xr-x 2 root root    61 Aug 13 16:53 scripts
drwxr-xr-x 2 root root   101 Aug 13 16:53 template
-rw-r--r-- 1 root root     6 Aug 13 16:53 VERSION
drwxr-xr-x 5 root root    59 Aug 13 16:53 web

# 进入prometheus-webhook-dingtalk/contrib/k8s/config目录
[root@k8s-master01 30-Prometheus]# cd prometheus-webhook-dingtalk/contrib/k8s/config

# 修改config.yaml，将webhook的url地址和secret改成在2.4.1中配置
[root@k8s-master01 k8s]# vim config.yaml
  8 ## Customizable templates path
  9 templates:
 10   - /config/template.tmpl
 11
 12 ## You can also override default template using `default_message`
 13 ## The following example to use the 'legacy' template from v0.3.0
 14 # default_message:
 15 #   title: '{{ template "legacy.title" . }}'
 16 #   text: '{{ template "legacy.content" . }}'
 17 targets:
 18   webhook1:
        # 这里的url是2.4.1中创建机器人时的webhook的地址
 19     url: https://oapi.dingtalk.com/robot/send?access_token=dbeefffbffdb41423c97f9a12bfa71c29886190a34bbe42615d39ea0ee70eb
 20     # secret for signature
        # 这里的secret是2.4.1中创建机器人时勾选加签时生成的
 21     secret: SECbd2d9a6b71fa24362b1a601c4ed7ea6ce5387fa3923622964aa4d9456e4e
 22   webhook2:
 23     url: https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxx
 24   webhook_legacy:
 25     url: https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxx
 26     # Customize template content

修改服务的镜像：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# 文件默认使用的镜像在dockerhub，网络原因可能无法拉取，改用自己仓库的镜像registry.cn-beijing.aliyuncs.com/k8s-liujunwei/prometheus-webhook-dingtalk:latest
# 文件路径：prometheus-webhook-dingtalk/contrib/k8s/deployment.yaml
[root@k8s-master01 k8s]# vim  deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: alertmanager-webhook-dingtalk
spec:
  template:
    spec:
      volumes:
        - name: config
          configMap:
            name: alertmanager-webhook-dingtalk
      containers:
        - name: alertmanager-webhook-dingtalk
          # 这是修改后的镜像地址
          image: registry.cn-beijing.aliyuncs.com/k8s-liujunwei/prometheus-webhook-dingtalk:latest
          args:
            - --web.listen-address=:8060
            - --config.file=/config/config.yaml
          volumeMounts:
            - name: config
              mountPath: /config
          resources:
            limits:
              cpu: 100m
              memory: 100Mi
          ports:
            - name: http
              containerPort: 8060

安装部署应用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 注意：该命令要在包含 kustomization.yaml 的目录里执行
[root@k8s-master01 k8s]# ll
total 12
drwxr-xr-x 2 root root  46 Aug 13 17:02 config
-rw-r--r-- 1 root root 741 Aug 13 17:11 deployment.yaml
-rw-r--r-- 1 root root 456 Aug 13 16:53 kustomization.yaml
-rw-r--r-- 1 root root 147 Aug 13 16:53 service.yaml


[root@k8s-master01 k8s]# kubectl kustomize . | kubectl apply -f - -n monitoring
# Warning: 'commonLabels' is deprecated. Please use 'labels' instead. Run 'kustomize edit fix' to update your Kustomization automatically.
configmap/alertmanager-webhook-dingtalk-489685mdt8 created
service/alertmanager-webhook-dingtalk created
deployment.apps/alertmanager-webhook-dingtalk created

# 查看服务部署情况
[root@k8s-master01 k8s]# kubectl get po -n monitoring |grep webhook-dingtalk
alertmanager-webhook-dingtalk-589fd78b4f-wms2s   1/1     Running   0                 78s

服务部署完成。

2.4.3创建AlertmanagerConfig实现钉钉告警通知

接下来创建AlertmanagerConfig资源将告警推送钉钉，还是用MySQL服务模拟宕机产生告警发送至钉钉

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
[root@k8s-master01 AlertmanagerConfig]# vim  dingding-mysql-alertmanagerconfig.yaml
# 配置如下：
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: mysql-redis-alert-dingding  # AlertmanagerConfig资源名称
  namespace: monitoring
spec:
  route:
    receiver: dingding-webhook
    groupBy:
    - team
    - severity
    - namespace
    groupWait: 30s
    groupInterval: 10m
    repeatInterval: 1h
    matchers:
      - name: team
        value: dba
        matchType: =
      - name: severity
        value: critical
        matchType: =
  receivers:
  - name: dingding-webhook  #这里定义的receiver名称可以自定义，但是要和spec.route中的receiver名称一致
    webhookConfigs:
      - sendResolved: true  # 发送已解决的告警
        # 这里url定义的是部署的alertmanager-webhookdingtalk服务，结构是http://<服务名>.<命名空间>/dingtalk/<target名称>/send
        url: http://alertmanager-webhook-dingtalk.monitoring/dingtalk/webhook1/send

参数解读：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1.spec.receivers.name中定义的dingding-webhook要和spec.route.receiver定义的值(dingding-webhook)保持一致
2.url: http://alertmanager-webhookdingtalk.monitoring/dingtalk/webhook1/send的结构是http://<服务名>.<命名空间>/dingtalk/<target名称>/send  
# alertmanager-webhookdingtalk是2.4.2步骤中部署服务的service名字
[root@k8s-master01 k8s]# kubectl get svc -n monitoring
NAME                            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                         AGE
alertmanager-webhook-dingtalk   ClusterIP   10.96.143.13    <none>        80/TCP                          15m

# monitoring 是service所在的命名空间
# dingtalk/webhook1/send中的dingtalk和send是固定值，webhook1必须与适配服务配置文件里的 targets 下定义的名称对应，也就是2.4.2中config.yaml文件中的webhook1，只配置了这一个地址，配置大致如下：
targets:
  webhook1:          # ← 这里的名字必须和 URL 路径中的 webhook1 一致
    url: https://oapi.dingtalk.com/robot/send?access_token=dbeefffbffdb41423c97f9a12bfa71c29886190a34bb7ce42615d39ea0ee70eb
    secret: SECbd2d9a6b71fa24362b1a601c4ed7ea6ce45387fa3fdc923622964aa4d9456e4e   # 可选，加签时用
  webhook2:          # 可以定义多个
    url: https://oapi.dingtalk.com/robot/send?access_token=另一个token

创建这个AlertmanagerConfig资源：

1
2
[root@k8s-master01 AlertmanagerConfig]# kubectl create -f dingding-mysql-alertmanagerconfig.yaml
alertmanagerconfig.monitoring.coreos.com/mysql-redis-alert-dingding created

通过web UI检查配置是否被加载：

接下来模拟MySQL宕机，验证钉钉是否能收到告警通知：

1
2
[root@k8s-master01 AlertmanagerConfig]# kubectl scale deployment mysql --replicas=0
deployment.apps/mysql scaled

告警产生，如下图所示：

钉钉的群组中也收到告警通知：

恢复通知就不记录了，参考其他章节即可。

3.维护时暂停告警

应用场景：当集群中某个服务需要维护时，不触发告警通知，因为这是人为的有计划的停止服务进行维护，所以此时不应该发送告警通知

Silences（静默）： 用来临时屏蔽某些告警，让它们在指定时间内不发送通知（告警本身还在，只是不通知）

通过Alertmanager的web UI选择Silences-New Silences

字段 说明 示例
Matchers 匹配哪些告警（最重要） alertname="HighCPU" 或 severity="prod" 或 instance=~"10.0.*"
Starts at 静默开始时间 默认现在
Ends at 静默结束时间 选一个未来时间，或填持续时间
Duration 持续多久（可选） 2h、1d 等
Creator 创建人 你的名字
Comment 原因说明（建议写） “维护窗口，暂时屏蔽CPU告警”

三种状态

  • Active：正在生效的静默
  • Pending：还没到开始时间
  • Expired：已经过期

常见使用场景

  • 计划维护：屏蔽某个服务/节点一段时间
  • 已知问题：暂时不让某条告警一直弹
  • 测试：临时关掉某个告警