搭建一个通用监控告警平台，架构上需要有哪些设计

大家好，又见面了。

说到监控告警平台，大家应该都不会陌生，对于线上系统而言可以说是个标配，各个公司或项目也都会有搭建自己的监控告警平台的实际诉求。

当前比较主流的监控告警平台实现方案，很多都是基于Prometheus + Grafana + AlertManager来实现的。但是实际使用的时候会发现不易实施：

• 在运维部署对接方面存在一些不便，接入新的被监控节点时需要到平台部署机器上去修改配置文件、甚至重启服务来生效

• 配置告警规则等也是基于xml配置，必须要到平台服务器上去添加文件，对于一个各项目通用的平台而言，显然不可能将后端服务地址暴露让各业务负责人员去自行修改服务器上的配置文件

• Grafana界面相对单一、可以用于看板或者大屏展示，但是一些公司内高度定制化的页面能力实现起来会比较麻烦（当然也可以基于Grafana二次开发定制），或者想在公司已有的运维平台中深度集成，实现难度较大。

前段时间研究了下基于Prometheus构建监控系统相关的概念，并以此为基准设计了一个企业级通用的监控告警平台的方案。这里分享一下架构的分析过程以及上述问题的解决思路。

平台与业务职责规划

既然是构建通用平台，就会涉及到平台与业务的职责划分的问题，这条线究竟按照什么尺度去画，究竟将平台做厚还是做薄，将直接决定了平台的整体定位：

• 平台做的太厚重，势必导致业务使用的约束增加、且定制化能力减弱，适用范围受限；
• 平台做的太轻薄，业务虽然有更多的主导权与定制灵活度，但也导致各个业务需要重复构建相关能力，平台将失去意义。

从构建通用平台的角度而言，很明显厚平台方案更具优势，可以统一整个公司各个业务的监控水平、可以持续的汇聚能力、积累沉淀。

所以，最终选择采用厚平台模式来构建：

• 集成数据存储、统计、告警策略、告警推送等能力，业务仅负责埋点数据上报即可。
• 告警能力扩展性强，全业务无差别共享
• 业务接入简单，但平台实现工作量较大
• 业务可以有限定制，但是需要基于管理界面上去配置规则，受平台规则支持度限制