一、概述
Prometheus 包含一个报警模块,就是 AlertManager,Alertmanager 主要用于接收 Prometheus 发送的告警信息,它支持丰富的告警通知渠道,而且很容易做到告警信息进行去重、降噪、分组等,是一款前卫的告警通知系统。 Prometheus 的学习资料:
关于 Prometheus 整体介绍,请参考:Prometheus 原理详解
Prometheus 和 Pushgetway 的安装,请参考:Prometheus Pushgetway 讲解与实战操作
二、AlertManager 架构
Alertmanager 由以下 6 部分组成:
API 组件——用于接收 Prometheus Server 的 http 请求,主要是告警相关的内容;
Alert Provider 组件——API 层将来自 Prometheus Server 的告警信息存储到 Alert Provider 上;
Dispatcher 组件——不断的通过订阅的方式从 Alert Provider 获取新的告警,并根据 yaml 配置的 routing tree 将告警通过 label 路由到不同的分组中,以实现告警信息的分组处理;
Notification Pipeline 组件——这是一个责任链模式的组件,它通过一系列的逻辑(抑制、静默、去重)来优化告警质量;
Silence Provider 组件——API 层将来自 prometheus server 的告警信息存储到 silence provider 上,然后由这个组件实现去重逻辑处理;
Notify Provider 组件——是 Silence Provider 组件的下游,会在本地记录日志,并通过 peers 的方式将日志广播给集群中的其他节点,判断当前节点自身或者集群中其他节点是否已经发送过,避免告警信息在集群中重复出现。
三、AlertManager 部署
① 下载
wget https: / / github. com/ prometheus/ alertmanager/ releases/ download/ v0.24 . 0 / alertmanager- 0.24 . 0 . linux- amd64. tar. gz
tar - xf alertmanager- 0.24 . 0 . linux- amd64. tar. gz
② 配置
global:
resolve_timeout: 5m
route:
group_by: [ 'alertname ']
group_wait: 30s
group_interval: 5m
repeat_interval: 1h
receiver: 'web . hook'
receivers:
- name: 'web . hook'
webhook_configs:
- url: 'http : / / 127.0 . 0.1 : 5001 / '
inhibit_rules:
- source_match:
severity: 'critical '
target_match:
severity: 'warning '
equal: [ 'alertname ', 'dev ', 'instance ']
Alertmanager 配置中一般会包含以下几个主要部分:
全局配置(global):用于定义一些全局的公共参数,如全局的 SMTP 配置,Slack 配置等内容;
模板(templates):用于定义告警通知时的模板,如 HTML 模板,邮件模板等;
告警路由(route):根据标签匹配,确定当前告警应该如何处理;
接收人(receivers):接收人是一个抽象的概念,它可以是一个邮箱也可以是微信,Slack 或者 Webhook 等,接收人一般配合告警路由使用;
抑制规则(inhibit_rules):合理设置抑制规则可以减少垃圾告警的产生。 具体字段解释:
resolve_timeout 当告警的状态有 firing 变为 resolve 的以后还要呆多长时间,才宣布告警解除,这个主要是解决某些监控指标在阀值边缘上波动,一会儿好一会儿不好;
route 是个重点,告警内容从这里进入,寻找自己应该用那种策略发送出去;
receiver 一级的 receiver,也就是默认的 receiver,当告警进来后没有找到任何子节点和自己匹配,就用这个 receiver;
group_wait 同一组的告警发出前要等待多少秒,这个是为了把更多的告警一个批次发出去;
group_interval 同一组的多批次告警间隔多少秒后,才能发出;
repeat_interval 重复的告警要等待多久后才能再次发出去;
routes 也就是子节点了,配置项和上面一样,告警会一层层的找,如果匹配到一层,并且这层的 continue 选项为 true,那么它会再往下找,如果下层节点不能匹配那么它就用区配的这一层的配置发送告警,如果匹配到一层,并且这层的 continue 选项为 false,那么它会直接用这一层的配置发送告警,就不往下找了。
match_re 用于匹配 label,此处列出的所有 label 都匹配到才算匹配;
inhibit_rules这个叫做抑制项,通过匹配源告警来抑制目的告警,比如说当主机挂了,可能引起主机上的服务、数据库、中间件等一些告警,假如说后续的这些告警相对来说没有意义,可以用抑制项这个功能,让 Prometheus 只发出主机挂了的告警;
source_match 根据 label 匹配源告警;
target_match 根据 label 匹配目的告警;
equal 此处的集合的 label,在源和目的里的值必须相等。如果该集合的内的值再源和目的里都没有,那么目的告警也会被抑制。
③ 启动服务
# 查看帮助
. / alertmanager - h
# 可以直接启动,但是不提倡,最好配置alertmanager. service
. / alertmanager
配置 alertmanager.service 启动脚本:
# 默认端口9093
cat > / usr/ lib/ systemd/ system/ alertmanager. service<< EOF
[ Unit ]
Description = alertmanager
[ Service ]
WorkingDirectory = / opt/ prometheus/ alertmanager/ alertmanager- 0.24 . 0 . linux- amd64
ExecStart = / opt/ prometheus/ alertmanager/ alertmanager- 0.24 . 0 . linux- amd64/ alertmanager - - config. file= / opt/ prometheus/ alertmanager/ alertmanager- 0.24 . 0 . linux- amd64/ alertmanager. yml - - storage. path= / opt/ prometheus/ alertmanager/ alertmanager- 0.24 . 0 . linux- amd64/ data - - web. listen- address= : 9093 - - data. retention= 120h
Restart = on- failure
[ Install ]
WantedBy = multi- user. target
EOF
# 执行 systemctl daemon- reload 命令重新加载systemd
systemctl daemon- reload
# 启动
systemctl start alertmanager
# 检查
systemctl status alertmanager
netstat - tnlp| grep : 9093
ps - ef| grep alertmanager
④ 与 Prometheus 集成
修改 Prometheus 的配置文件,修改配置如下:
systemctl restart prometheus
四、在 Prometheus 中设置告警规则
在 Prometheus 配置中添加报警规则配置,配置文件中 rule_files 就是用来指定报警规则文件的,如下配置即指定存放报警规则的目录为 /etc/prometheus,规则文件为 rules.yml:
rule_files:
- / etc/ prometheus/ rules. yml
警报规则允许基于 Prometheus 表达式语言的表达式来定义报警报条件的,并在触发警报时发送通知给外部的接收者(Alertmanager),一条警报规则主要由以下几部分组成:
expr——是用于进行报警规则 PromQL 查询语句;
for——评估告警的等待时间(Pending Duration);
labels——自定义标签,允许用户指定额外的标签列表,把它们附加在告警上;
annotations——用于存储一些额外的信息,用于报警信息的展示之类的。 rules.yml 如下所示:
groups:
- name: example
rules:
- alert: high_memory
# 当内存占有率超过10 % ,持续1min, 则触发告警
expr: 100 - ( ( node_memory_MemAvailable_bytes{ instance= "192.168.182.110:9100" , job= "node_exporter" } * 100 ) / node_memory_MemTotal_bytes{ instance= "192.168.182.110:9100" , job= "node_exporter" } ) > 90
for : 1m
labels:
severity: page
annotations:
summary: spike memeory
五、 AlertManager 告警通道配置
## Alertmanager 配置文件
global:
resolve_timeout: 5m
# smtp配置
smtp_from: "xxx@qq.com"
smtp_smarthost: 'smtp . qq. com: 465 '
smtp_auth_username: "xxx@qq.com"
smtp_auth_password: "auth_pass"
smtp_require_tls: true
# email、企业微信的模板配置存放位置,钉钉的模板会单独讲如果配置。
templates:
- '/ data/ alertmanager/ templates/ * . tmpl'
# 路由分组
route:
receiver: ops
group_wait: 30s # 在组内等待所配置的时间,如果同组内,30 秒内出现相同报警,在一个组内出现。
group_interval: 5m # 如果组内内容不变化,合并为一条警报信息,5m后发送。
repeat_interval: 24h # 发送报警间隔,如果指定时间内没有修复,则重新发送报警。
group_by: [ alertname] # 报警分组
routes:
- match :
team: operations
group_by: [ env, dc]
receiver: 'ops '
- match_re:
service: nginx| apache
receiver: 'web '
- match_re:
service: hbase| spark
receiver: 'hadoop '
- match_re:
service: mysql| mongodb
receiver: 'db '
# 接收器
# 抑制测试配置
- receiver: ops
group_wait: 10s
match :
status: 'High '
# ops
- receiver: ops # 路由和标签,根据match 来指定发送目标,如果 rule的lable 包含 alertname, 使用 ops 来发送
group_wait: 10s
match :
team: operations
# web
- receiver: db # 路由和标签,根据match 来指定发送目标,如果 rule的lable 包含 alertname, 使用 db 来发送
group_wait: 10s
match :
team: db
# 接收器指定发送人以及发送渠道
receivers:
# ops分组的定义
- name: ops
email_configs:
- to: '9935226 @ qq. com, 10000 @ qq. com'
send_resolved: true
headers:
subject: "[operations] 报警邮件"
from: "警报中心"
to: "小煜狼皇"
# 钉钉配置
webhook_configs:
- url: http: / / localhost: 8070 / dingtalk/ ops/ send
# 企业微信配置
wechat_configs:
- corp_id: 'ww5421dksajhdasjkhj '
api_url: 'https : / / qyapi. weixin. qq. com/ cgi- bin/ '
send_resolved: true
to_party: '2'
agent_id: '1000002 '
api_secret: 'Tm1kkEE3RGqVhv5hO - khdakjsdkjsahjkdksahjkdsahkj'
# web
- name: web
email_configs:
- to: '9935226 @ qq. com'
send_resolved: true
headers: { Subject : "[web] 报警邮件" } # 接收邮件的标题
webhook_configs:
- url: http: / / localhost: 8070 / dingtalk/ web/ send
- url: http: / / localhost: 8070 / dingtalk/ ops/ send
# db
- name: db
email_configs:
- to: '9935226 @ qq. com'
send_resolved: true
headers: { Subject : "[db] 报警邮件" } # 接收邮件的标题
webhook_configs:
- url: http: / / localhost: 8070 / dingtalk/ db/ send
- url: http: / / localhost: 8070 / dingtalk/ ops/ send
# hadoop
- name: hadoop
email_configs:
- to: '9935226 @ qq. com'
send_resolved: true
headers: { Subject : "[hadoop] 报警邮件" } # 接收邮件的标题
webhook_configs:
- url: http: / / localhost: 8070 / dingtalk/ hadoop/ send
- url: http: / / localhost: 8070 / dingtalk/ ops/ send
# 抑制器配置
inhibit_rules: # 抑制规则
- source_match: # 源标签警报触发时抑制含有目标标签的警报,在当前警报匹配 status: 'High '
status: 'High ' # 此处的抑制匹配一定在最上面的route中配置不然,会提示找不key。
target_match:
status: 'Warning ' # 目标标签值正则匹配,可以是正则表达式如: ".*MySQL.*"
equal: [ 'alertname ',' operations', 'instance '] # 确保这个配置下的标签内容相同才会抑制,也就是说警报中必须有这三个标签值才会被抑制。
一般企业钉钉、邮件、webhook 告警通道比较常用,尤其是 webhook,一般都会通过 webhook 对接公司内部的统一告警平台。