Prometheus AlertManager 企业微信告警系统

技术选型Prometheus AlertManager Go 中间件Prometheus本身不具备发送通知的能力其实是具有生成告警规则的能力的。可以说它更加专注于状态判定基于时间序列数据的逻辑运算而将状态管理分发、静默、抑制、去重解耦给了 AlertManager。在 Prometheus 生态之中 AlertManager 承担的这一角色除了简单的告警定义之外还有额外的层来添加告警摘要、通知速率限制、静默和告警依赖关系等功能。Prometheus 可以配置为定期向 AlertManager 实例发送告警状态信息然后由 AlertManager 实例负责分发相应的通知。 Prometheus 通过配置服务发现集成来配置为自动发现可用的 AlertManager 实例。我们先假设应用程序全部都正常运行在服务器上了。这里我们先来聊一下针对告警系统的配置部分。配置部分Prometheus 配置官方的prometheus配置文档中有基础的针对警报规则的配置。最核心的主要是两个模块# Alertmanager configuration alerting: alertmanagers: - static_configs: - targets: [IP_ADDRESS:PORT] # Load rules once and periodically evaluate them according to the global evaluation_interval. rule_files: # - first_rules.yml # - second_rules.yml - rule_file_pathalerting: 的配置告诉 prometheus server 具体的警报该向哪里推送AlertingManager 具体的位置在什么地方。而 rule_files: 则配置了具体的警报产生规则。也就是说 prometheus server 根据规则和逻辑判断生成了这些告警随后会根据配置的地址将生成的这些告警推送给AlertingManager。一个示例的 example_rule.yaml 如下groups: - name: system-alerts interval: 30s rules: # 测试 - alert: Test Test expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 0 for: 3s labels: severity: critical annotations: summary: 测试主机 {{ $labels.instance }} CPU 测试 description: 测试信息CPU 使用率已持续 5 分钟达到 {{ $value | printf \%.2f\ }}%请立即检查在这个示例配置文件中发生了如下的行为interval: prometheus 每隔 30s 执行一次查询语句expr。for: 待定状态Pending。如果CPU使用率超过了阈值必须持续满足 3s prometheus 才会正式把这个告警发送给 Alertmanager。一旦告警进入 Firing 状态 Prometheus 会在接下来的每个计算周期也就是 interval 30s都向 AlertingManager 推送一次告警的状态。具体的配置可以在官方文档中获取https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/AlertManager 配置AlertingManager处理由客户端应用程序也就是prometheus server发送的警报。它负责对警报进行去重、分组并将其路由到正确的接收集成非常强大的中间件功能这也是为什么我们会需要它。否则要进行路由我们就只能自己手搓代码了。此外它还负责警报的静默和抑制。我们主要会用到的几个模块如下route: // 路由策略 group_by: [alertname] // 具有相同alertname的告警会被打包成同一个通知发送 group_wait: 10s // 初次发送前的等待时间。当第一个告警触发时AlertManager会等待10s看看后续有没有同组的告警。如果有就会合并发送。 group_interval: 20s // 距离上一次发送之后如果又收到了新的告警加入该组等待多久再次发送 repeat_interval: 1m // 重复频率。如果某个告警一直没解决在发送时隔1分钟重新发送一次告警 receiver: web.hook // 默认的接收者 receivers: // 对接收者的配置。 - name: web.hook // 接收者的唯一标识哪个接收者 webhook_configs: // 使用webhook的方式进行推送通知给接收者 - url: http://127.0.0.1:6666/webhook // 推送到这个位置接口。我们会在这个位置部署一个中间件。 inhibit_rules: // 抑制规则 - source_matchers: [severitycritical] // 源警告 已存在的警告 target_matchers: [severitywarning] // 目标警告 待发送的警告 equal: [alertname, dev, instance] // 匹配条件 // 这一条警告的意思是如果存在了一个级别为critical的告警如果它的alertname\dev\instance与warning级别的告警完全一致那么这个warning告警就会被静音抑制不再发送。这一个示例的行为如下假设告警a,b,c在一个分组初次收到告警等待10s进行发送告警阶段收到组内新增告警等待20s进行发送持续未解决的旧告警每隔1m发送一次AlertManager 可以在运行时重新加载其配置。如果新配置格式不正确则更改将不会生效并且会记录错误。可以通过向SIGHUP进程发送消息或向/-/reload端点发送 HTTP POST 请求来触发配置重新加载。——Prometheus官方文档https://prometheus.io/docs/alerting/latest/configuration/数据周转流程目前可以得知情形如下。比如说有一台主机的CPU处理器持续高于80%的使用率prometheus server 每隔 30s 检查一次所有的告警配置一旦发现某条符合并满足观察的时间阈值以上随后prometheus 向 AlertManager 发送告警。AlertManager 收到了这条告警随后随后根据配置进行判断我是第一次收到这条告警吗还有别的告警吗这条告警一直在来吗种种条件判断之下随后 AlertManager 向 接收者 以json的数据格式发送可能合并后的告警信息。Go 中间件中间件主要负责获取从 AlertManager 处的告警数据也就是位于 PORT:/文件位置/注册该位置的路由进行数据上的获取随后进行数据结构上的处理渲染成 wecom 中可读取的数据最终将数据源源不断地转发到HOOK_KEY的资源链接上。权限管理你要写风就不能只写风。你要写柳条摆动写纸鸢翻飞写行人缩脖写湖面泛起涟漪。新增系统用户 Prometheussudo useradd \ --system \ --shell /bin/false \ --no-create-home \ prometheus sudo usermod -aG adm prometheus将解压出来的 node_exporter 的二进制可执行文件放在 /usr/local/bin/下方并修改权限 保证其他用户只可执行。当看到这个即说明部署成功指标都在 /metrics 中距离 prometheus 部署 全部成功只差临门一脚。