15 | 高可用架构案例（三）：如何打造一体化的监控系统？

上一讲，介绍了整体化监控系统的设计方案，今天就深入它的内部设计，了解它具体是如何落地的。

这个监控系统主要分为 4 大部分：节点信息采集、节点接入、数据上报和前端展示。下面，就来具体展开介绍。

节点信息采集

在上一讲中提到过，Agent 负责采集节点的健康数据，每隔 3s，主动访问一次；然后，Agent 会根据这些数据，结合相应的规则，来判断节点的健康状态。最终的健康状态有三种，分别是错误、警告和正常，这三种状态也对应了 Dashboard 中节点的红黄绿三种颜色。

节点分为 4 类：Web 应用、Redis、MQ 和数据库。下面我就来具体讲一下，系统是如何对它们进行监控的。

对于 Redis 节点，Agent 通过 Jredis API，尝试连接 Redis 实例并进行简单的读写。如果这个操作没有问题，就表明 Redis 当前的健康状态是正常的，否则就是错误的。

对于 MQ 节点，Agent 是通过 MQ API，来检测 MQ 节点是否有活跃的消费者在连接，同时检测队列积压的消息数量。如果没有活跃的消费者，或者未消费的消息超过了预设的值，就表明当前的 MQ 节点的健康状态是错误的，否则它就是正常的。

对于数据库节点，Agent 是通过 JDBC 去连接数据库，并对表进行简单的读写。如果操作成功，表明数据库的健康状态是正常的，否则就是错误的。

对于这三类节点，它们的健康状态只有正常和错误两种，没有警告状态。如果节点有问题，Agent 会同时给出具体的出错信息，比如节点连接错误、积压消息过多等等。

对于 Web 应用来说，Agent 采集的方式则稍微复杂一些，它会同时采集应用的功能和性能数据，具体包括最近 3s 的接口调用次数、接口平均响应时间、接口出错次数、节点的健康状态和错误消息。

这里举一个 Web 节点请求和响应的例子，来帮助直观地了解 Agent 是如何采集数据的。

请求：http://10.10.1.1/agent/check
返回信息：
 "status":“warning",  
 "avg_time":“583.0",  
 "call_count":"10",   
 "error_count":"0",   
 "error_info":" orderListGet: current average time= 583.0, total average time =109.84, 调用次数= 10"

Web 节点会预先提供一个 HTTP 接口，Agent 通过调用这个接口，返回当前 Web 实例最近 3s 的健康状态。

这里最主要的就是 status 字段，它表明了 Web 节点最近 3s 是否健康，如果是“error”或者“warning”，返回的结果还会包含 error_info 字段，它负责给出具体的错误信息。

Agent 在获取了这 4 类节点的健康状态后，会调用 Monitor Service 进行数据上报，如果节点有问题&#x