一、概述
Prometheus 包括一个报警模块,便是咱们的
AlertManager
,Alertmanager 主要用于接纳 Prometheus 发送的告警信息,它支撑丰富的告警告诉途径,而且很简单做到告警信息进行去重,降噪,分组等,是一款前卫的告警告诉体系。
- GitHub地址:github.com/prometheus/…
- 官方文档:prometheus.io/docs/alerti…
- 关于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 布置
下载地址:prometheus.io/download/
1)下载
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
2)装备
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
):合理设置按捺规矩能够削减废物告警的发生。
详细字段解释:
-
global
这个是大局设置 -
resolve_timeout
当告警的状态有firing变为resolve的以后还要呆多长时间,才宣布告警免除。这个主要是解决某些监控方针在阀值边际上动摇,一会儿好一会儿欠好。 -
route
是个要点,告警内容从这儿进入,寻觅自己应该用那种策略发送出去。 -
receiver
一级的receiver,也便是默许的receiver,当告警进来后没有找到任何子节点和自己匹配,就用这个receiver。 -
group_by
告警应该依据那些标签进行分组。 -
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,在源和意图里的值有必要相等。假如该调集的内的值再源和意图里都没有,那么意图告警也会被按捺。
3)发动服务
# 查看帮助
./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
web拜访:http://ip:9093
4)与Prometheus集成
修改Prometheus的装备文件,修改装备如下: 重启Prometheus
systemctl restart prometheus
四、在Prometheus中设置告警规矩
在Prometheus 装备中增加报警规矩装备,装备文件中 rule_files
便是用来指定报警规矩文件的,如下装备即指定寄存报警规矩的目录为/etc/prometheus,规矩文件为rules.yml
:
rule_files:
- /etc/prometheus/rules.yml
设置报警规矩:
警报规矩允许依据 Prometheus 表达式语言的表达式来界说报警报条件的,并在触发警报时发送告诉给外部的接纳者(Alertmanager),一条警报规矩主要由以下几部分组成:
-
alert
——告警规矩的称号。 -
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对接公司内部的统一告警平台。
Prometheus AlertManager解说就先到这儿了,有任何疑问欢迎给我留言,后续会继续更新【云原生+大数据】相关的文章,请小伙伴耐性等候~