使用Prometheus遇见的一些问题

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

Prometheus + AlertManager + 钉钉/企业微信 + Grafana

但在使用过程当中可能遇见如下问题：

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

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

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

架构

功能

配置告警规则

报警规则: 与Prometheus中的 报警规则 概念相同。

告警历史

这里可以根据历史告警去查看和分析故障时间和恢复时间
也可以根据历史告警去调整我们的告警频率和告警阀值

告警升级

可以设置告警升级机制， 在一定时间范围后未处理直接通知相关leader（可以通过电话，邮件，企业微信等方式通知）

报警时间段：每天发送报警的时段
报警延迟：报警触发多长时间后才开始发送报警，可用于实现报警升级
报警周期：每隔多少分钟发送一次报警
报警用户：报警接收人，可以输入多个报警接收人
值班组：从接口动态获取报警值班人
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表达式。

告警确认

可以在页面上确认告警或者通过连接确认告警
告警确认可以查看那些告警已经处理，哪些没有进行处理

开源地址

https://github.com/Qihoo360/doraemon

中文文档

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

后记

2021年200篇文档第4篇