监控大盘 #

设计方案 #

市面上监控系统虽多，但功能太多且碎片化，查找问题需要大量沟通，定位问题繁琐。

自定义监控系统实现方案

• 通过Agent进行监控数据采集，Agent是一个独立服务。
• Agent定时（3s）采集后将数据同步到Monitor。
• Monitor保存监测数据。
• Dashboard展示数据，通过红黄绿颜色表示节点状态为不健康、未知/警告、健康，同时显示出错信息。
• Dashboard界面应该可以定制化。
• 各节点的配置信息可以保存在单独的注册中心，也可以直接保存在Monitor中，由Agent定期获取最新配置。

数据建模 #

表结构

• 系统信息表：系统名称，页面布局方式。
• 节点信息表：节点名称、节点类型、节点机器、节点账号、节点所属系统、节点所属应用、告警邮箱、告警收集。
• 节点监控状态表：节点名称、节点类型、错误信息、上报时间、调用数、错误数、平均响应时间。

Agent设计方案 #

• Redis
  • Agent通过Jedis尝试对Redis进行读写操作，操作正常则表明Redis是健康的。
• MQ
  • Agent通过MQ API检测 MQ 是否有活跃的消费者在连接，同时检测队列积压的消息数量。如果没有活跃的消费者，或者未消费的消息超过阀值，就表明当前的 MQ 节点是不健康的。
• Database
  • Agent通过JDBC连接数据，尝试读写操作，正常返回则表明Redis是健康的。
• Web Server
  • 每个服务集成SDK，统计采集窗口内（3s）的接口调用次数、出错次数、RT等额外信息。
  • Agent通过网络请求调用服务中集成的SDK，获取健康信息和额外信息。

不少中间件在空间不足或网络分区等情况下仍然可以接受读取操作，但这种情况并不表示节点是健康的，所以对于写操作的监测是必不可少的。

Web Server SDK设计方案 #

• 每个时间窗口一个HashMap，key=接口名，value=调用详情，包含调用次数、出错次数、RT等。
• Agent调用SDK时，SDK统计健康状态。如果没有错误产生，则节点健康；错误次数小于一定阀值则为警告；错误次数大于一定阀值则为错误。
• SDK统计RT健康状态时，不能采用预先设定的RT阀值，而应该根据节点运行轨迹动态计算出正常请求的AVG RT。
• 一个应用内通常包含多个接口，SDK反应的节点健康状态是所有接口中最差的。