老实说，刚接到监控平台这项工作内容的时候，只是过了一下产品的设计，产品的设计大部分借鉴的腾讯某监控平台，然后说是要做一套监控平台，以替代现有的Zabbix监控平台，那其实公司的现状是，公司有自己的机房，生产业务大部分都部署在物理机/虚拟机，现在向容器化迈进（听说做了两年），也有接入腾讯云、华为云等云厂商，目前监控用的是Zabbix, 因为在推容器化，k8s平台的监控首选Prometheus了，正因如此，所以要将再有的监控（只是主机监控）全面转向Prometheus，这个理由，不可谓不充分。
事情已经摆在眼前了，就是要基于Prometheus做一套监控平台，平台的作用是让监控可配置，在公司推广，让其它人能用起来。于是乎，开始折腾起Prometheus起来了，先来认识一下：
Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。
先盗一张官网的架构图
image.png
监控报警就是Prometheus Server
- 收集目标exporter的数据
- 判断阈值
- 触发报警
- Alertmanager推送消息
整体构架还是清晰明了的，从产品的核心需求来看，平台提供的能力要满足以下几点：
- 自定义监控规则
- 自定义报警规则
- 自定义报警通知
- 自定义报警频率
由于产品目标用户的特殊性，服务部署在物理机/虚拟机/云主机上，单台主机会存在部署多个服务的情况，本质上是在做主机监控，但是要开放给业务开发使用，也就是业务要跟主机监控绑定。好了，拿到需求，要马上做吗？老司机都不急于动手，先想清楚一些问题：
- 业务开发是否真实关心主机状况，例如cpu过载/内存过载等问题？
- 主机监控及报警配置是否在存在大量差异化需求，如：a机器cpu利用率超过80%报警，b机器cpu利用率超过60报警？
- 主机与服务是多对多的关系，这就会存在监控告的是别人的警，跟自己没关系的情况？
[图片上传失败...(image-86c7d9-1605083016207)]
经过了解，问题1并非由开发提出，但你要说不存在这样的需求也的确欠妥，毕竟目前主机监控是由运维在负责，现在运维希望将主机监控将由开发去负责；问题2，本来差异是比较小的，不过由于需求1的存在，的确存在这种可能；问题3，基本无解，由于问题1的存在，3也不算问题。
无论如何，还是要实际使用一下Prometheus的，好在容器做强部署还是非常方便快捷的，不过又发现一些问题？
- prometheus规则配置目前只直接配置文件的形式，这对于业务平台来说并不太友好，如果支持关系型数据库也好呀
- 主机与服务间的关系由内部第三方服务管理，主机目标配置目前还是以文件存ip的形式，这对于报警查询及配置来说，都不友好
- 主机监控要考虑到不同环境，不同机房的统一管理，Prometheus该如何使用？
针对以上问题，在一番斟酌后，我拿出了自己的设计：
image.png
红框部分即是需要参与编码服务或模块。
- alert-service: 跟前端交互的服务
- alert-engine: RESTful API服务
- alert-webhook: 用于接收alertmanager的webhook
- minio: 用于报警规则配置
- consul: Prometheus的服务发现
首先，Prometheus需要联邦部署，这是一个树形结构，所有子Prometheus数据都上送到根Prometheus，这样，外部只需要与根Prometheus打交道即可，这解决了不同Prometheus集群统一管理的问题；
引入consul是为了解决Prometheus的服务发现问题，所谓服务发现是为了让Prometheus发现自己需要从哪些目标抓数据，同时也可以很方便地给目标打上自己想要的标签，如机房，应用名等信息，如果不用consul，也可以使用文件配置，使用文件配置的问题在于需要人为处理，不容易与外部系统对接，不够灵活。
引入minio是为了解决规则配置的问题，再有规则配置使用文件配置，也需要人手工操作，如果不使用minio这类文件系统，就需要ssh远程登录到配置所在主机，然后修改规则配置，不过在程序中使用ssh并不友好（也考虑过用git来管理规则配置，由于时间关系，这个方案并没有施行)
alert那三个服务本可以合三为一的，为什么要拆成三个呢？
alert-webhook只是接收alertmanager报警然后将期扔到kafka中，如果只有一个服务的话，那么在需求迭代服务重启时，就可能会丢掉报警。
alert-engine单纯提供RESTful API服务，比较稳定，这样的好处是上层如何变，下层不用有较大改变或者只需要关注自身业务即可，如此，如些，告警的接收、发送、配置也就彻底解耦了。
至于表的设计，由于依托于Prometheus，可以参照报警规则的结构体来建表，通知渠道根据自己的需求进行一些设计，最终需要与Prometheus保持一致，保证报警消息最终能发给目标用户。
这套系统对于业务方而言，可能作用不大，因为主机报警这类信息对于业务方开发而言，他们即使收到消息，并不能解决问题，如果能有阈值触发时，保存现场，比如火焰图，对开发者而言应该是有帮助的。
主机监控跟应用监控还是有很大区别的，目标用户在根本上是不一样的，当然，这两者也有结合的可能，比如日志聚合系统Loki，师承Prometheus，如果跟运维监控相结合，有很大的想像空间，比如，可以统一监控的入口，信息聚合等。
监控报警的意义最终是要能解决问题，从这个角度讲，我的这个设计目前只能暴露问题，解决问题需要接外部系统，比如，自动扩缩容、服务降级、问题跟踪等，最终能形成闭环，让问题能够真正得到处理以及最终解决，还有不少事情需要做。
网友评论