说到监控告警平台，大家应该都不陌生了。可以说是线上系统的标配，每个公司或者项目也会有。搭建自己的监控告警平台的实际需求。目前主流的监控告警平台很多实现都是基于Prometheus+Grafana+AlertManager。但是在实际使用中，你会发现实现起来并不容易：在运维部署的对接上存在一些不便。当连接到新的被监控节点时，需要到平台部署机上修改配置文件，甚至重启服务才能生效。配置告警规则等也是基于xml配置，需要在平台服务器添加文件。对于一个所有项目通用的平台，暴露后端服务地址，让业务负责人自行修改服务器上的配置文件，显然是不可能的。.Grafana接口比较简单，可以做看板或者大屏展示，但是在一些公司实现高度定制化的页面能力会比较麻烦（当然也可以基于Grafana二次开发定制），或者如果想在公司现有的运维平台中深度融合，很难实现。前段时间研究了基于Prometheus搭建监控系统的相关概念，并以此为基础设计了一个企业级通用监控告警平台的解决方案。在此分享一下架构的分析过程以及针对上述问题的解决方法。1.平台和业务责任规划既然是搭建一个通用平台，就会涉及到平台和业务之间的责任划分。这条线应该用什么比例尺画，平台厚还是薄，将直接决定平台的整体定位：如果平台太重，势必会增加对业务使用的限制，以及定制能力将减弱，应用范围将受到限制；这样一来，每个业务都需要反复构建相关能力，平台也就失去了存在的意义。从搭建通用平台的角度，显然厚平台方案更有优势，可以统一整个公司各个业务的监控层面，实现持续聚合能力，积累沉淀。因此，最终我们选择采用厚平台模型来构建：集成数据存储、统计、告警策略、告警推送等能力，业务只负责上报埋点数据。告警能力高度可扩展，所有业务可以无差别共享。服务接入简单，但平台实现工作量较大。业务可以进行一定程度的自定义，但是规则需要基于管理接口进行配置，受限于平台规则的支持。2、用户场景需求分析首先分析对监控平台的总体需求，以及监控平台需要支持的一些核心业务场景。站在用户的角度，收集不同角色人员的诉求：1.管理者掌控全局，可以从不同的维度看（如按部门、项目、负责人等看）2.开发者知道什么他们负责如果项目状态异常，您可以在第一时间收到报警通知。您可以自定义自己项目的告警规则和告警接收者。3、运维人员可以查看所有负责机器的状态。附加部署、安装、运行监控平台本身的稳定性和可靠性是可以总结的。在用户层面，系统的诉求主要有：易用性：可查看全局，可划分权限控制，可接收告警易用性：业务接入简单方便自定义规则3.选型及总体设计作为一个监控平台，目前主流的方案之一是Prometheus+Grafana+AlertManager的封装。此解决方案也使用此常规包。设计要点：由于prometheus使用配置文件管理数据采集、告警规则等，为了方便使用，设计构建了配置接口和配套服务，负责web端修改配置，编写服务器端prometheus配置文件中的逻辑和中间件Probes自动启动部署等能力。考虑到prometheus的告警推送通道有限，设计了一个消息推送服务，提供一个rest接口接收prometheus的告警推送，然后转发到已有的微信推送通道，实现微信接收告警。通常Prometheus探针部署在被监控进程所在的机器上，比较分散，不易维护。对于各种中间件通用的数据采集探针，采用服务器集中部署的方案，通过web命令部署对应中间件的探针服务。最终整体搭建的整体图如上图。橙色部分使用开源组件实现，绿色部分为自建。作为辅助能力，打通平台的辅助控制能力，降低用户使用门槛。四、重点设计1、以监控平台管理界面方案为门面，处理用户层面。管理接口端的实现不仅需要承载用户维度的基础诉求，同时也是解决前面提到的Prometheus+Grafana+AlertManager使用配置和规则定制高门槛的关键部分。很多基于Prometheus的监控平台都搭载了Grafana作为界面展示。但是Grafana作为一个通用的开源组件，主要侧重于仪表盘的展示能力，而其他的管理能力相对薄弱。因此在界面规划上，采用的策略是继续围绕现有运维平台界面，设计整合grafana的dashboard展示能力。也就是说，对于用户来说，门户就是运维平台Poral，一些规则的配置和部署操作都是由运维平台门户提供的。当你点击查看某个项目的数据时，会跳转到Grafana展示。2、分层分组告警实现机制作为一个监控告警平台，告警能力自然是最关键的部分。这部分有使用Prometheus的能力。具体实现中，为实现告警的按需、精准推送，计划在Prometheus配置采集探针数据时为每个探针配置相应的标签数据，如项目组、系统、模块、环境类型等。.这样就可以根据项目组或系统维度进一步推送给相关人员。这里的方案是在prometheus拉取探测服务的地方配置添加固定的组标签信息，而不是从每个探测的索引项上报，主要是考虑到平台统一的控制维度。3、对接告警通道的设计Prometheus实现告警有两种选择：对接PrometheusAlarmManager组件，通过修改服务器本地配置文件设置告警规则。连接Grafana，使用Grafana报警功能，直接在Grafana界面指标项配置即可。其实无论是PrometheusAlertManager还是Grafana，其配置都需要遵循一定的规则。您必须登录到部署服务器才能添加或修改配置文件——这作为一个平台显然是不能接受的。因此，从功能和方便的角度考虑，我们选择使用AlertManager来实现告警能力。作为对其缺点的补偿，计划搭建管理配置服务，在平台统一入口提供简单易用的配置能力，如下：用户通过接口配置后，将更改的配置文件传输通过管理配置服务而自动写入。输入AlertManager对应的配置文件，从而避免人为修改AlertManager服务端的配置文件可能带来的问题。AlarmManage预设的告警渠道主要有email、钉钉、微信或webhook。自由定制和后续自由定制，这里选择webhook的方式：开发一个新的webhook报警接收服务，提供rest接口接收报警信息；对接收到的告警信息进行处理后，调用当前监控平台提供的微信告警推送接口，推送给用户。4、部署运维管理策略基于Prometheus机制。数据上报使用探针暴露相关接口，然后Prometheus定时轮询拉取。对于探针的部署，可以考虑可选的常规模式和集中模式。1）常规模式下，每个业务和每个中间件节点自己部署自己的探测服务。2）集中式模式，将各个中间件的探测服务集中部署，打通web端的配置逻辑，根据需求自动部署探测服务。评估实施工作量，最终确定混合使用两种模式：中间件监控、集中部署、集中监管作为平台能力的一部分。各业务监控采用常规模式，各业务定制提供探针服务并部署。中间探针集中部署：在服务器上安装各个常用中间件的exporter包，根据web传来的监控中间件类型执行命令，z启动对应的探针，方便后续维护，将启动命令写到脚本中file中，设置开机相关的配置信息，每个exporter绑定的端口信息，以及监听的中间件信息，保存在DB中，方便维护。5、高可用设计作为一个用来监控其他服务是否正常的告警平台，其自身的高可用显然是必须要考虑的。一旦监控平台宕机，业务问题可能没有第一时间通知负责人，很容易导致线上事故。针对整个平台的高可用设计，子模块采用了不同的策略：1）Prometheus高可用：冗余方案。部署2套prometheus进程，两套prometheus采集相同的探测节点，配置数据完全相同。可扩展：分片策略。当监控对象过多时，会将监控对象分片，在每个分片上部署一组（2个进程）prometheus服务，实现无限水平扩展。2）AlarmManager高可用、可扩展：集群部署。多个prometheus进程向AlarmManagerCluster重复发送告警信息，最终只会发出一个告警。3）配置部署服务高可用、可扩展：集群部署。部署多个流程节点，对外提供统一的访问地址。4）探针服务不是监控平台的主体，不保证高可用。有停机时会有报警，符合要求。5.整体回顾回顾整个方案的分析和设计过程。其实整体逻辑很简单。确定选人后，根据选人结果以及选人与目标诉求的差异，考虑如何拉平两者之间的差距。不同之处。正所谓“不忘初心，从头做起”。按照上述策略搭建完成后，监控平台整体功能如下：
