热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

prometheus结合Alertmanager实现告警通知

  Alertmanager   prometheus-server触发一条告警的过程:   prometheus---触发阈值---超出持续时间---alertmanage

  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: 'ptiizujqboiydejf'
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: 'yytlspogrrutbbdj'
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: '15105211792@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

 

 

   未完待续....

 

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



推荐阅读
  • 本文详细介绍了在Linux操作系统上安装和部署MySQL数据库的过程,包括必要的环境准备、安装步骤、配置优化及安全设置等内容。 ... [详细]
  • Docker安全策略与管理
    本文探讨了Docker的安全挑战、核心安全特性及其管理策略,旨在帮助读者深入理解Docker安全机制,并提供实用的安全管理建议。 ... [详细]
  • 本文详细介绍了Oracle 11g中的创建表空间的方法,以及如何设置客户端和服务端的基本配置,包括用户管理、环境变量配置等。 ... [详细]
  • 本文详细介绍了如何在Oracle VM VirtualBox中实现主机与虚拟机之间的数据交换,包括安装Guest Additions增强功能,以及如何利用这些功能进行文件传输、屏幕调整等操作。 ... [详细]
  • 函子(Functor)是函数式编程中的一个重要概念,它不仅是一个特殊的容器,还提供了一种优雅的方式来处理值和函数。本文将详细介绍函子的基本概念及其在函数式编程中的应用,包括如何通过函子控制副作用、处理异常以及进行异步操作。 ... [详细]
  • 调试利器SSH隧道
    在开发微信公众号或小程序的时候,由于微信平台规则的限制,部分接口需要通过线上域名才能正常访问。但我们一般都会在本地开发,因为这能快速的看到 ... [详细]
  • CentOS下ProFTPD的安装与配置指南
    本文详细介绍在CentOS操作系统上安装和配置ProFTPD服务的方法,包括基本配置、安全设置及高级功能的启用。 ... [详细]
  • Web动态服务器Python基本实现
    Web动态服务器Python基本实现 ... [详细]
  • 本文详细介绍了如何搭建一个高可用的MongoDB集群,包括环境准备、用户配置、目录创建、MongoDB安装、配置文件设置、集群组件部署等步骤。特别关注分片、读写分离及负载均衡的实现。 ... [详细]
  • 深入理解:AJAX学习指南
    本文详细探讨了AJAX的基本概念、工作原理及其在现代Web开发中的应用,旨在为初学者提供全面的学习资料。 ... [详细]
  • 本文通过分析一个具体的案例,探讨了64位Linux系统对32位应用程序的兼容性问题。案例涉及OpenVPN客户端在64位系统上的异常行为,通过逐步排查和代码测试,最终定位到了与TUN/TAP设备相关的系统调用兼容性问题。 ... [详细]
  • 本文详细介绍了如何在ARM架构的目标设备上部署SSH服务端,包括必要的软件包下载、交叉编译过程以及最终的服务配置与测试。适合嵌入式开发人员和系统集成工程师参考。 ... [详细]
  • 在尝试使用 Android 发送 SOAP 请求时遇到错误,服务器返回 '无法处理请求' 的信息,并指出某个值不能为 null。本文探讨了可能的原因及解决方案。 ... [详细]
  • 本文介绍了如何在两个Oracle数据库(假设为数据库A和数据库B)之间设置DBLink,以便能够从数据库A中直接访问和操作数据库B中的数据。文章详细描述了创建DBLink前的必要准备步骤以及具体的创建方法。 ... [详细]
  • 本文档介绍了如何使用ESP32开发板在STA模式下实现与TCP服务器的通信,包括环境搭建、代码解析及实验步骤。 ... [详细]
author-avatar
2d15064efa_556
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有