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
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 我与微信审核的“相爱相杀”看个人小程序副业
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求