Draemon 360开源的基于Promtheus的升级版本告警系统

使用Prometheus遇见的一些问题

现在很多公司主要采用以下的方式监控:

Prometheus + AlertManager + 钉钉/企业微信 + Grafana
Draemon 360开源的基于Promtheus的升级版本告警系统_第1张图片
但在使用过程当中可能遇见如下问题:

  1. 告警不能像zabbix一样设置告警升级
  2. 不能像zabbix一样设置维护周期
  3. 分组告警,在变更或者项目过多导致维护成本增加
  4. 无法动态加载监控规则,需要修改配置文件
  5. 需要在后台配置当中设置altermanager

Draemon 对于Promentheus的提供优化方案:

  • 用户可以通过 Web-UI 动态配置报警规则
  • 支持灵活的报警策略,比如报警延迟(可以实现报警升级),创建报警接收组以及值班组。用户还能通过 HOOK 的方式来发送报警,由用户自己来决定如何处理报警。
  • 用户可以通过 prometheus 的标签来实现批量确认报警。
  • 支持创建维护组。维护组中的机器在维护时间段内产生的报警将不会发送给用户。
  • 为了减少报警发送数量,所有报警都在报警规则的维度做了报警聚合(根据该报警规则对应的报警策略每个周期聚合一次并发送)。报警恢复信息也从报警规则的维度每分钟聚合发送一次。
  • 支持多种登录方式:企业版支持 LDAP/OAuth 2.0/本地登录。

架构

Draemon 360开源的基于Promtheus的升级版本告警系统_第2张图片

功能

配置告警规则

Draemon 360开源的基于Promtheus的升级版本告警系统_第3张图片
报警规则: 与Prometheus中的 报警规则 概念相同。

告警历史

Draemon 360开源的基于Promtheus的升级版本告警系统_第4张图片
这里可以根据历史告警去查看和分析故障时间和恢复时间
也可以根据历史告警去调整我们的告警频率和告警阀值

告警升级

可以设置告警升级机制, 在一定时间范围后未处理直接通知相关leader(可以通过电话,邮件,企业微信等方式通知)
Draemon 360开源的基于Promtheus的升级版本告警系统_第5张图片
报警时间段:每天发送报警的时段
报警延迟:报警触发多长时间后才开始发送报警,可用于实现报警升级
报警周期:每隔多少分钟发送一次报警
报警用户:报警接收人,可以输入多个报警接收人
值班组:从接口动态获取报警值班人
Filter表达式:
Filter表达式用于根据标签来过滤报警,例如某个规则的报警信息中有idc这样一个标签,表示该报警来自哪个机房,如果某个运维人员只负责接收和处理北京机房的报警,他就可以使用idc=beijing这样一个Filter表达式(见上图),Filter表达式支持如下符号:
"="表示等于,例如:idc=beijing
"!="表示不等于,例如:idc!=beijing
"&"表示逻辑与,例如:idc=beijing&app=online
"|“表示逻辑或,例如:idc=beijing|app=online
“(”,”)"括号表示优先级,例如:(idc=beijing|app=online)&env=product
需要注意的是标签的key和value中不能包含空格、Tab、=、!、&、|这几种特殊符号,并且当前版本只支持完全匹配。此外,如果某个报警的标签中不包含Filter表达式中的某个标签,则直接判定为匹配失败,不会发送报警。如果希望接收某条规则的全部报警,则不需要填写Filter表达式。

告警确认

可以在页面上确认告警或者通过连接确认告警
告警确认可以查看那些告警已经处理,哪些没有进行处理
Draemon 360开源的基于Promtheus的升级版本告警系统_第6张图片

开源地址

https://github.com/Qihoo360/doraemon

中文文档

https://github.com/Qihoo360/doraemon/blob/master/docs/readme-CN.md

后记

2021年200篇文档第4篇

你可能感兴趣的:(运维GO-开源推荐,运维GO-devops,运维GO-云原生,devops,监控类)