共计 5160 个字符，预计需要花费 13 分钟才能阅读完成。
一、Alertanager 的装置
1、下载
2、装置
# 不同的平台下载不同的安装包
wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.darwin-amd64.tar.gz
# 解压
tar zxvf alertmanager-0.21.0.darwin-amd64.tar.gz
# 重命名
mv alertmanager-0.21.0.darwin-amd64.tar.gz alertmanager3、启动
# 启动的时候指定配置文件的门路和启动端口
./alertmanager --config.file=alertmanager.yml --web.listen-address=":9093"
# 显示帮忙信息
./alertmanager --help4、alertmanager 和 prometheus 的整合
批改 prometheus.yml 配置文件
alerting:
alertmanagers:
- static_configs:
- targets:
- 127.0.0.1:9082 # 告警管理器的地址整合参考链接 https://prometheus.io/docs/prometheus/latest/configuration/configuration/#alertmanager_config
二、告警分组
分组机制能够将某一类型的告警信息合并成一个大的告警信息，防止发送太多的告警邮件。
比方：咱们有 3 台服务器都染指了 Prometheus，这 3 台服务器同时宕机了，那么如果不分组可能会发送 3 个告警信息，如果分组了，那么会合并成一个大的告警信息。
1、告警规定
监控服务器宕机的工夫超过 1 分钟就发送告警邮件。
groups:
- name: Test-Group-001 # 组的名字，在这个文件中必须要惟一
rules:
- alert: InstanceDown # 告警的名字，在组中须要惟一
expr: up == 0 # 表达式, 执行后果为 true: 示意须要告警
for: 1m # 超过多少工夫才认为须要告警(即 up== 0 须要继续的工夫)
labels:
severity: warning # 定义标签
annotations:
summary: "服务 {{$labels.instance}} 下线了"
description: "{{$labels.instance}} of job {{$labels.job}} has been down for more than 1 minutes."2、alertmanager.yml 配置
global:
resolve_timeout: 5m
# 整合 qq 邮件
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: '1451578387@qq.com'
smtp_auth_username: '1451578387@qq.com'
smtp_auth_identity: 'xxxxxx'
smtp_auth_password: 'xxxxxx'
smtp_require_tls: false
# 路由
route:
group_by: ['alertname'] # 依据什么分组，此处配置的是依据告警的名字分组, 没有指定 group_by 貌似是依据规定文件的 groups[n].name 来分组的。group_wait: 10s # 当产生一个新分组时，告警信息须要等到 group_wait 才能够发送进来。group_interval: 10s # 如果上次告警信息发送胜利，此时又来了一个新的告警数据，则须要期待 group_interval 才能够发送进来
repeat_interval: 120s # 如果上次告警信息发送胜利，且问题没有解决，则期待 repeat_interval 再次发送告警数据
receiver: 'email' # 告警的接收者，须要和 receivers[n].name 的值统一。receivers:
- name: 'email'
email_configs:
- to: '1451578387@qq.com'3、分组相干的 alertmanager 的配置
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 120s group_wait、group_interval和 repeat_interval 的解释参考上方的正文。和此链接 https://www.robustperception….
4、邮件发送后果
三、告警克制
指的是当某类告警产生的时候，于此相干的别的告警就不必发送告警信息了。
比方：咱们对某台机器的 CPU 的使用率进行了监控，比方 应用到 80% 和 90% 都进行了监控，那么咱们可能想如果 CPU 使用率达到了 90% 就不要发送 80% 的邮件了。
1、告警规定
如果 cpu 在 5 分钟的使用率超过 80% 则产生告警信息。
如果 cpu 在 5 分钟的使用率超过 90% 则产生告警信息。
groups:
- name: Cpu
rules:
- alert: Cpu01
expr: "(1 - avg(irate(node_cpu_seconds_total{mode='idle'}[5m])) by (instance,job)) * 100 > 80"
for: 1m
labels:
severity: info # 自定一个一个标签 info 级别
annotations:
summary: "服务 {{$labels.instance}} cpu 使用率过高"
description: "{{$labels.instance}} of job {{$labels.job}} 的 cpu 在过来 5 分钟内应用过高，cpu 使用率 {{humanize $value}}."
- alert: Cpu02
expr: "(1 - avg(irate(node_cpu_seconds_total{mode='idle'}[5m])) by (instance,job)) * 100 > 90"
for: 1m
labels:
severity: warning # 自定一个一个标签 warning 级别
annotations:
summary: "服务 {{$labels.instance}} cpu 使用率过高"
description: "{{$labels.instance}} of job {{$labels.job}} 的 cpu 在过来 5 分钟内应用过高，cpu 使用率 {{humanize $value}}."2、alertmanager.yml 配置克制规定
克制规定：
如果 告警的名称 alertname = Cpu02 并且 告警级别 severity = warning，那么克制住 新的告警信息中 标签为 severity = info 的告警数据。并且源告警和指标告警数据的 instance 标签的值必须相等。
# 克制规定，缩小告警数据
inhibit_rules:
- source_match: # 匹配以后告警规定后，克制住 target_match 的告警规定
alertname: Cpu02 # 标签的告警名称是 Cpu02
severity: warning # 自定义的告警级别是 warning
target_match: # 被克制的告警规定
severity: info # 克制住的告警级别
equal:
- instance # source 和 target 告警数据中，instance 的标签对应的值须要相等。克制规定配置
3、邮件发送后果
能够看到 只发送了 warning级别的告警，没有发送 info 级别的告警。
四、告警静默
指的是处于静默期，不发送告警信息。
比方：咱们零碎某段时间进行停机保护，由此可能会产生一堆的告警信息，然而这个时候的告警信息是没有意义的，就能够配置静默规定过滤掉。
1、配置静默规定
须要在 alertmanager 的控制台，或通过 amtool 来操作。
通过上述的配置，就收不到告警信息了。
五、告警路由
1、altermanager.yml 配置文件的编写
global:
resolve_timeout: 5m
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: '145xxx8387@qq.com'
smtp_auth_username: '1451578387@qq.com'
smtp_auth_identity: 'xxxxx'
smtp_auth_password: 'xxxxx'
smtp_require_tls: false
# 根路由，不能存在 match 和 match_re，任何告警数据没有匹配到路由时，将会由此根路由进行解决。route:
group_by: ['job']
group_wait: 10s
group_interval: 10s
repeat_interval: 120s
receiver: 'default-receiver'
routes:
- match_re:
alertname: 'Cpu.*' # 如果告警的名字是以 Cpu 结尾的发给 receiver-01
receiver: 'receiver-01'
- match:
alertname: 'InstanceDown' # 如果告警的名字是 InstanceDown 则发送给 receiver-02
receiver: 'receiver-02'
group_by: ['instance'] # 依据 instance 标签分组
contine: true # 为 true 则还须要去匹配子路由。routes:
- match:
alertname: 'InstanceDown' # 如果告警的名字是 InstanceDown 则还是须要发送给 receiver-03
receiver: 'receiver-03'
# 定义 4 个接管人（接管组等等）receivers:
- name: 'default-receiver'
email_configs:
- to: '145xxx8387@qq.com'
send_resolved: true
- name: 'receiver-01'
email_configs:
- to: '2469xxx193@qq.com'
send_resolved: true
- name: 'receiver-02'
email_configs:
- to: 'weixin145xxx8387@163.com'
send_resolved: true
- name: 'receiver-03'
email_configs:
- to: 'it_xxx_software@163.com'
send_resolved: true
inhibit_rules:
- source_match:
alertname: Cpu02
severity: warning
target_match:
severity: info
equal:
- instance告警后果：
1、告警名称中存在 Cpu 的发送给 receiver-01(2469xxx193@qq.com)
2、告警名称是 InstanceDown 的须要发送给 receiver-02 和 receiver-03(weixin145xxx8387@163.com 和 it_xxx_software@163.com)
3、须要留神一下路由中的 continue参数，为 true, 则须要在持续匹配子路由, 为false: 不在匹配它下方的子路由了。
当告警信息没有匹配到工作路由时，则由根路由 (route) 进行解决。
拜访 url https://www.prometheus.io/webtools/alerting/routing-tree-editor/ 查看告警树。
2、路由匹配
告警数据 从 最顶级的 route进入路由树，根路由须要匹配所有的告警数据，不能够设置 match 和match_re
每个路由下，有本人的子路由。比方：某个告警，如果级别一般，则告诉给用户 A，如果过段时间还未复原，变 y 重大了，则须要告诉给张三和李四，那么能够通过子路由实现。
默认状况下，告警从 根路由 进入之后，会遍历它下方的所有的子路由，
如果 route 中的 continue = false，那么在匹配到第一个合乎的路由之后就进行匹配了。
如果 continue = true那么会持续进行匹配。
如果所有的都没有匹配到，那么走 根路由。
六、参考链接
1、下载 alertmanager
2、alertmanager 的官网文档
3、alertmanager 和 prometheus 整合参考链接
4、分组告警中 group_wait、group_interval 和 repeat_interval 的解释
5、克制规定配置
6、告警解决后蕴含旧的值
7、https://aleiwu.com/post/prometheus-alert-why/
8、查看告警树