prometheus 结合 Alertmanager 实现告警通知
Alertmanager
prometheus-server 触发一条告警的过程:
prometheus--->触发阈值--->超出持续时间--->alertmanager--->分组|抑制|静默--->媒体类型--->邮件|钉钉|微信等。

分组(group): 将类似性质的警报合并为单个通知,比如网络通知、主机通知、服务通知。
静默(silences): 是一种简单的特定时间静音的机制,例如:服务器要升级维护可以先设置这个时间段告警静默。
抑制(inhibition): 当警报发出后,停止重复发送由此警报引发的其他警报即合并一个故障引起的多个报警事件,可以消除冗余告警
安装 alertermanager:
prometheus官网:https://prometheus.io/download/#alertmanager
Github地址:https://github.com/prometheus/alertmanager
root@haproxyB:/usr/local# tar xf alertmanager-0.24.0.linux-amd64.tar.gz
root@haproxyB:/usr/local# ln -s alertmanager-0.24.0.linux-amd64 alertmanager
创建service启动文件
root@haproxyB:/usr/local/alertmanager\# vim /etc/systemd/system/alertmanager.service
[Unit]
Description=Prometheus alertmanager
After=network.target
[Service]
ExecStart=/usr/local/alertmanager/alertmanager --config.file="/usr/local/alertmanager/alertmanager.yml"
[Install]
WantedBy=multi-user.target
启动alertmanager
systemctl daemon-reload && systemctl enable alertmanager.service && systemctl start alertmanager.service
alertermanager.yaml 配置文件解析:
global:
smtp_from: #发件人邮箱地址
smtp_smarthost: #邮箱 smtp 地址。
smtp_auth_username: #发件人的登陆用户名,默认和发件人地址一致。
smtp_auth_password: #发件人的登陆密码,有时候是授权码。
smtp_require_tls: #是否需要 tls 协议。默认是 true。
wechart_api_url: #企业微信 API 地址。
wechart_api_secret: #企业微信 API secret
wechat_api_corp_id: #企业微信 corp id 信息。
resolve_timeout: 60s #当一个告警在 Alertmanager 持续多长时间未接收到新告警后就标记告警状态为resolved(已解决/已恢复)。
具体配置详解:
vim /usr/local/alertmanager/alertmanager.yml
global:
resolve_timeout: 1m
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: '1015693563@qq.com'
smtp_auth_username: '1015693563@qq.com'
smtp_auth_password: '邮箱授权码'
smtp_hello: '@qq.com'
smtp_require_tls: false
route:
group_by: [alertname] #通过 alertname 的值对告警进行分类,- alert: 物理节点 cpu 使用率
group_wait: 10s #一组告警第一次发送之前等待的延迟时间,即产生告警后延迟 10 秒钟将组内新产生的消息一起合并发送(一般设置为 0 秒 ~ 几分钟)。
group_interval: 2m #一组已发送过初始通知的告警接收到新告警后,下次发送通知前等待的延迟时间(一般设置为 5 分钟或更多)。
repeat_interval: 2m #一条成功发送的告警,在最终发送通知之前等待的时间(通常设置为 3 小时或更长时间)。
#间隔示例:
#group_wait: 10s #第一次产生告警,等待 10s,组内有告警就一起发出,没有其它告警就单独发出。
#group_interval: 2m #第二次产生告警,先等待 2 分钟,2 分钟后还没有恢复就进入 repeat_interval。
#repeat_interval: 5m #在最终发送消息前再等待 5 分钟,5 分钟后还没有恢复就发送第二次告警。
receiver: default-receiver #其它的告警发送给 default-receiver
routes: #将 critical 的报警发送给 myalertname
- receiver: myalertname
group_wait: 10s
match_re:
severity: critical
receivers: #定义多接收者
- name: 'default-receiver'
email_configs:
- to: 'rooroot@aliyun.com'
send_resolved: true #通知已经恢复的告警
- name: myalertname
webhook_configs:
- url: 'http://172.30.7.101:8060/dingtalk/alertname/send'
send_resolved: true #通知已经恢复的告警
配置 prometheus-server 报警规则
说明:
“description: 容器 {{ $labels.name }} CPU 资源利用率大于 10% , (current value is {{ $value }})”,中$labels.name指的是promql查询结果的label标签名称key,$value为promql查询结果的value
root@prometheus:~# cd /usr/local/prometheus
root@prometheus:/usr/local/prometheus# mkdir rules
root@prometheus:/usr/local/prometheus# vim rules/rule1.yaml
groups:
- name: alertmanager_pod.rules
rules:
- alert: Pod_all_cpu_usage
expr: (sum by(container_label_io_kubernetes_pod_name)(rate(container_cpu_usage_seconds_total{image!=""}[5m]))*100) > 10
for: 2m
labels:
severity: critical
service: pods
annotations:
description: 容器 {{ $labels.container_label_io_kubernetes_pod_name }} CPU 资源利用率大于 10% , (current value is {{ $value }})
summary: Dev CPU 负载告警
- alert: Pod_all_memory_usage
#expr: sort_desc(avg by(name)(irate(container_memory_usage_bytes{name!=""}[5m]))*100) > 10
#内存大于 10%
expr: sort_desc(avg by(name)(irate(node_memory_MemFree_bytes {name!=""}[5m]))) > 2*1024*1024*1024 #内存大于 2G
for: 2m
labels:
severity: critical
annotations:
description: 容 器 {{ $labels.name }} Memory 资 源 利 用 率 大 于 2G , (current value is {{ $value }})
summary: Dev Memory 负载告警
- alert: Pod_all_network_receive_usage
expr: sum by (name)(irate(container_network_receive_bytes_total{container_name="POD"}[1m])) > 50*1024*1024
for: 2m
labels:
severity: critical
annotations:
description: 容器 {{ $labels.name }} network_receive 资源利用率大于 50M , (current value is {{ $value }})
- alert: pod 内存可用大小
expr: node_memory_MemFree_bytes > 1 #故意写错的
#expr: node_memory_MemFree_bytes < 512*1024*1024 (512 *1024兆*1024字节) 小于500兆
for: 2m
labels:
severity: critical
annotations:
description: 容器可用内存小于 100k
prometheus-server配置添加告警规则配置
alerting:
alertmanagers:
- static_configs:
- targets:
- 192.168.100.21:9093 #填写alertmanager服务地址
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
- "/usr/local/prometheus/rules/rule1.yaml" #填写告警规则文件
访问prometheus-server告警界面

邮箱接受告警邮件


邮件通知
官方配置文档:https://prometheus.io/docs/alerting/configuration/
配置并重启alertmanager
root@haproxyB:/usr/local/alertmanager# cat alertmanager.yml
global:
resolve_timeout: 1m
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: '1015693563@qq.com'
smtp_auth_username: '1015693563@qq.com'
smtp_auth_password: '邮箱授权码'
smtp_hello: '@qq.com'
smtp_require_tls: false
route: #route 用来设置报警的分发策略
group_by: [alertname] #通过 alertname 的值对告警进行分类,- alert: 物理节点 cpu 使用率
group_wait: 10s #一组告警第一次发送之前等待的延迟时间,即产生告警后延迟 10 秒钟将组内新产生的消息一起合并发送(一般设置为 0 秒 ~ 几分钟)。
group_interval: 2m #一组已发送过初始通知的告警接收到新告警后,下次发送通知前等待的延迟时间(一般设置为 5 分钟或更多)。
repeat_interval: 2m #一条成功发送的告警,在最终发送通知之前等待的时间(通常设置为 3 小时或更长时间)。
receiver: "qqmail" #设置接收人
receivers: #定义接收者
- name: 'qqmail'
email_configs:
- to: '1510*****92@163.com'
send_resolved: true #通知已经恢复的告警
inhibit_rules: #抑制的规则
- source_match: #源匹配级别,当匹配成功发出通知,但是其它'alertname', 'dev', 'instance'产生的warning 级别的告警通知将被抑制
severity: 'critical' #报警的事件级别
target_match:
severity: 'warning' #调用 source_match 的 severity 即如果已经有'critical' 级别的报警,那么将匹配目标为新产生的告警级别为'warning' 的将被抑制
equal: ['alertname', 'dev', 'instance'] #匹配哪些对象的告警
systemctl restart alertmanager
访问alertmanager dashboard


钉钉通知
告警推送流程图

创建钉钉群聊和机器人
创建钉钉群聊,添加智能群助手,选择自定义webhook

添加机器人设置中,在安全设置勾选“自定义关键词”,输入alertmanager 中定义的标签label名称 “alertname”, label名称例如:


添加后,会生成一个webhook access token,一定要保留不要泄露。


创建告警脚本
钉钉认证-关键字-shell 脚本:
root@haproxyB:/usr/local/alertmanager# cat dingding-keywords.sh
#!/bin/bash
source /etc/profile
#PHONE=$1
#SUBJECT=$2
MESSAGE=$1
/usr/bin/curl -X "POST" 'https://oapi.dingtalk.com/robot/send?access_token=6755dc6d17a9a5b5597f60628d65e2c4d454be1325ea3bb68673ec508161a373' \
-H 'Content-Type: application/json' \
-d '{"msgtype": "text",
"text": {
"content": "'${MESSAGE}'"
}
}'
执行脚本,验证钉钉告警,message传参不允许有空格,shell中
root@haproxyB:/usr/local/alertmanager# ./dingding-keywords.sh "alertname=test,node=192.168.100.21"
{"errcode":0,"errmsg":"ok"}

创建python 钉钉告警脚本
解决shell脚本中,message信息无法传递空格解析json
root@haproxyB:/usr/local/alertmanager# cat dingding-keywords.py
#!/usr/bin/python3
import sys
import requests
import json
#钉钉告警:
def info(msg):
url = 'https://oapi.dingtalk.com/robot/send?access_token=6755dc6d17a9a5b5597f60628d65e2c4d454be1325ea3bb68673ec508161a373'
headers = {
'Content-Type': 'application/json;charset=utf-8'
}
formdata = {
"msgtype": "text",
"text": {"content":str(msg)}
}
#print(formdata)
requests.post(url=url, data=json.dumps(formdata),headers=headers)
info(sys.argv[1])
执行python脚本,验证钉钉告警:
root@haproxyB:/usr/local/alertmanager# python3 dingding-keywords.py "alertname=Pythontest, node=192.168.100.21:9100"

部署webhook-dingtalk
github地址:https://github.com/timonwong/prometheus-webhook-dingtalk,使用1.4.0版本
解压部署
root@haproxyB:/usr/local# tar xf prometheus-webhook-dingtalk-1.4.0.linux-amd64.tar.gz
root@haproxyB:/usr/local# mv prometheus-webhook-dingtalk-1.4.0.linux-amd64 prometheus-webhook-dingtalk
创建启动脚本
--ding.profile= 要指定alertmanager和钉钉webhook创建的机器人中的标签关键字要一致,以及钉钉webhook的accesskey
#!/bin/bash
nohup /usr/local/prometheus-webhook-dingtalk/prometheus-webhook-dingtalk --web.listen-address="0.0.0.0:8060" --ding.profile="altername=https://oapi.dingtalk.com/robot/send?access_token=6755dc6d17a9a5b5597f60628d65e2c4d454be1325ea3bb68673ec508161a373" &
编辑 alertermanager服务配置 调用钉钉告警
https://prometheus.io/docs/alerting/configuration/ #官方配置文档
root@haproxyB:/usr/local# cat alertmanager/alertmanager.yml
global:
resolve_timeout: 1m
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: '1015693563@qq.com'
smtp_auth_username: '1015693563@qq.com'
smtp_auth_password: '邮箱授权码'
smtp_hello: '@qq.com'
smtp_require_tls: false
route:
group_by: [alertname] #通过 alertname 的值对告警进行分类,- alert: 物理节点 cpu 使用率
group_wait: 10s #一组告警第一次发送之前等待的延迟时间,即产生告警后延迟 10 秒钟将组内新产生的消息一起合并发送(一般设置为 0 秒 ~ 几分钟)。
group_interval: 2m #一组已发送过初始通知的告警接收到新告警后,下次发送通知前等待的延迟时间(一般设置为 5 分钟或更多)。
repeat_interval: 2m #一条成功发送的告警,在最终发送通知之前等待的时间(通常设置为 3 小时或更长时间)。
receiver: "dingding" #指定接收人为dingding
receivers: #定义接收者
- name: 'qqmail'
email_configs:
- to: '15105***2@163.com'
send_resolved: true #通知已经恢复的告警
- name: 'dingding'
webhook_configs:
- url: 'http://192.168.100.21:8060/dingtalk/altername/send' #指定prometheus-webhook-dingtalk服务地址
send_resolved: true
inhibit_rules: #抑制的规则
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
prometheus-server配置告警规则
root@prometheus:/usr/local/prometheus# cat rules/rule1.yaml
groups:
- name: alertmanager_pod.rules
rules:
- alert: Pod_all_cpu_usage
expr: (sum by(container_label_io_kubernetes_pod_name)(rate(container_cpu_usage_seconds_total{image!=""}[5m]))*100) > 10
for: 2m
labels:
severity: critical
service: pods
annotations:
description: 容器 {{ $labels.container_label_io_kubernetes_pod_name }} CPU 资源利用率大于 10% , (current value is {{ $value }})
summary: Dev CPU 负载告警
- alert: Pod_all_memory_usage
#expr: sort_desc(avg by(name)(irate(container_memory_usage_bytes{name!=""}[5m]))*100) > 10
#内存大于 10%
expr: sort_desc(avg by(name)(irate(node_memory_MemFree_bytes {name!=""}[5m]))) > 2*1024*1024*1024 #内存大于 2G
for: 2m
labels:
severity: critical
annotations:
description: 容 器 {{ $labels.name }} Memory 资 源 利 用 率 大 于 2G , (current value is {{ $value }})
summary: Dev Memory 负载告警
- alert: Pod_all_network_receive_usage
expr: sum by (name)(irate(container_network_receive_bytes_total{container_name="POD"}[1m])) > 50*1024*1024
for: 2m
labels:
severity: critical
annotations:
description: 容器 {{ $labels.name }} network_receive 资源利用率大于 50M , (current value is {{ $value }})
#- alert: pod 内存可用大小
# expr: node_memory_MemFree_bytes > 1 #故意写错的
# for: 2m
# labels:
# severity: critical
# annotations:
# description: 容器可用内存小于 100k
验证告警
查看prometheus-server告警

验证钉钉告警

企业微信通知
企业微信配置
登录企业微信后台,创建应用

输入创建应用名称

发送secret,针对可见范围的用户可以查看到

登录企业微信查看

测试发送信息



alertmanager配置,增加微信报警规则wechat_configs
获取应用agentid

获取api_secret

获取企业ID,corp_id

配置alertmanager
root@haproxyB:/usr/local/alertmanager# cat alertmanager.yml
global:
resolve_timeout: 1m
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: '1015693563@qq.com'
smtp_auth_username: '1015693563@qq.com'
smtp_auth_password: '邮箱授权码'
smtp_hello: '@qq.com'
smtp_require_tls: false
route:
group_by: ['alertname'] #通过 alertname 的值对告警进行分类,- alert: 物理节点 cpu 使用率
group_wait: 1s #一组告警第一次发送之前等待的延迟时间,即产生告警后延迟 10 秒钟将组内新产生的消息一起合并发送(一般设置为 0 秒 ~ 几分钟)。
group_interval: 1s #一组已发送过初始通知的告警接收到新告警后,下次发送通知前等待的延迟时间(一般设置为 5 分钟或更多)。
repeat_interval: 15s #一条成功发送的告警,在最终发送通知之前等待的时间(通常设置为 3 小时或更长时间)。
receiver: wechat
receivers: #定义接收者
- name: 'wechat'
wechat_configs:
- corp_id: ww1ea393212b62d1cd
#to_user: '@all' #定义发送给公司组织架构下所有人
to_party: 2 #定义发送给组织架构下组ID为2的所有用户
agent_id: 1000002 #定义微信应用机器人的agent_id
api_secret: T4Pvc4aq9uuvAX7Mtx3OSEP0X0FqdkUonmWr6n5n_fA #定义
send_resolved: true
inhibit_rules: #抑制的规则
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
prometheus-server的配置与 配置 prometheus-server 报警规则一致
消息分类发送:
根据消息中的属性信息设置规则,将消息分类发送,如以下为将 severity 级别为critical 的通知消息发送到dingding,宿主机告警project 为 node 通过邮箱送给监控组,其它的则发送到微信
prometheus rules 配置
在prometheus规则文件中,针对某一个rule规则,设置特定的标签。如:
labels:
severity: critical
service: pods
完整规则如下
root@prometheus:/usr/local/prometheus# cat rules/rule1.yaml
groups:
- name: alertmanager_pod.rules
rules:
- alert: Pod_all_cpu_usage
expr: (sum by(container_label_io_kubernetes_pod_name)(rate(container_cpu_usage_seconds_total{image!=""}[5m]))*100) > 10
for: 2m
labels:
severity: critical
service: pods
project: myserver
annotations:
description: 容器 {{ $labels.container_label_io_kubernetes_pod_name }} CPU 资源利用率大于 10% , (current value is {{ $value }})
summary: Dev CPU 负载告警
- alert: Pod_all_memory_usage
#expr: sort_desc(avg by(name)(irate(container_memory_usage_bytes{name!=""}[5m]))*100) > 10
#内存大于 10%
expr: sort_desc(avg by(name)(irate(node_memory_MemFree_bytes {name!=""}[5m]))) > 2*1024*1024*1024 #内存大于 2G
for: 2m
labels:
severity: critical
project: myserver
annotations:
description: 容 器 {{ $labels.name }} Memory 资 源 利 用 率 大 于 2G , (current value is {{ $value }})
summary: Dev Memory 负载告警
- alert: Pod_all_network_receive_usage
expr: sum by (name)(irate(container_network_receive_bytes_total{container_name="POD"}[1m])) > 50*1024*1024
for: 2m
labels:
severity: critical
project: myserver
annotations:
description: 容器 {{ $labels.name }} network_receive 资源利用率大于 50M , (current value is {{ $value }})
- alert: pod 内存可用大小
expr: node_memory_MemFree_bytes > 1 #故意写错的
#expr: node_memory_MemFree_bytes < 512*1024*1024 (512 *1024兆*1024字节) 小于500兆
for: 2m
labels:
severity: warning
project: node
annotations:
description: 容器可用内存小于 100k
重启prometheus-server
root@prometheus:/usr/local/prometheus# systemctl restart prometheus
配置alertmanager
root@haproxy:/usr/local/alertmanager# cat alertmanager.yml
global:
resolve_timeout: 1m
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: '1015693563@qq.com'
smtp_auth_username: '1015693563@qq.com'
smtp_auth_password: '邮箱授权码'
smtp_hello: '@qq.com'
smtp_require_tls: false
route:
group_by: ['alertname']
group_wait: 1s
group_interval: 1s
repeat_interval: 15s
receiver: 'wechat' #默认告警方式为钉钉
#添加消息路由
routes:
- receiver: 'dingding' #critical 级别的通过邮件发送给 leader
group_wait: 10s
match_re:
severity: critical #标签匹配严重等级告警
- receiver: 'qqmail' #宿主机告警通过企业微信发送给监控组
group_wait: 10s
match_re:
project: node
receivers: #定义接收者
- name: 'wechat'
wechat_configs:
- corp_id: 'ww1ea393212b62d1cd'
#to_user: '@all'
to_party: 2
agent_id: '1000002'
api_secret: 'T4Pvc4aq9uuvAX7Mtx3OSEP0X0FqdkUonmWr6n5n_fA'
send_resolved: true
- name: 'dingding'
webhook_configs:
- url: 'http://192.168.0.31:8060/dingtalk/altername/send' #指定prometheus-webhook-dingtalk服务地址
send_resolved: true
- name: 'qqmail'
email_configs:
- to: '15105211792@163.com'
send_resolved: true #通知已经恢复的告警
inhibit_rules: #抑制的规则
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
告警结果:
钉钉告警推送


自定义消息模板
默认的消息内容需要调整、而且消息是连接在一起的。
root@haproxy:/usr/local/alertmanager# touch message_template.tmpl
root@haproxy:/usr/local/alertmanager# vim message_template.tmpl
{{ define "wechat.default.message" }}
{{ range $i, $alert :=.Alerts }}
===alertmanager监控报警===
告警状态: {{ .Status }}
告警级别: {{ $alert.Labels.severity }}
告警类型: {{ $alert.Labels.alertname }}
告警应用: {{ $alert.Annotations.summary }}
故障主机: {{ $alert.Labels.instance }}
告警主题: {{ $alert.Annotations.summary }}
触发阀值: {{ $alert.Annotations.value }}
告警详情: {{ $alert.Annotations.description }}
触发时间: {{ $alert.StartsAt.Format "2006-01-02 15:04:05" }}
===========end============
{{ end }}
{{ end }}
配置alertmanager
添加模板配置
templates:
- '/usr/local/alertmanager/template/message_template.tmpl'

重启alertmanager
root@haproxy:/usr/local/alertmanager# systemctl restart alertmanager.service

告警抑制与静默
告警抑制
基于告警规则,超过80%就不在发60%的告警,即由 60%的表达式触发的告警被抑制了。
配置prometheus-server规则
groups:
- name: alertmanager_pod.rules
rules:
- alert: 磁盘容量
expr: 100-(node_filesystem_free_bytes{fstype=~"ext4|xfs"}/node_filesystem_size_bytes{fstype=~"ext4|xfs"}*100) > 80 #磁盘容量利用率大于 80%
for: 2s
labels:
severity: critical
annotations:
summary: "{{$labels.mountpoint}} 磁盘分区使用率过高!"
description: "{{$labels.mountpoint }} 磁盘分区使用大于 80%(目前使用:{{$value}}%)"
- alert: 磁盘容量
expr: 100-(node_filesystem_free_bytes{fstype=~"ext4|xfs"}/node_filesystem_size_bytes{fstype=~"ext4|xfs"}*100) > 60 #磁盘容量利用率大于 60%
for: 2s
labels:
severity: warning
annotations:
summary: "{{$labels.mountpoint}} 磁盘分区使用率过高!"
description: "{{$labels.mountpoint }} 磁盘分区使用大于 80%(目前使用:{{$value}}%)"
手动静默
先找到要静默的告警事件,然后手动静默指定的事件:

定义静默时长,默认2小时,可以修改,creator为修改者,comment为修改备注内容

本文来自博客园,作者:PunchLinux,转载请注明原文链接:https://www.cnblogs.com/punchlinux/p/17035742.html

浙公网安备 33010602011771号