谛听｜大规模主机监控告警平台的架构演变

点击「京东数科技术说」可快速关注

「摘要」谛听是京东数科自行研发的一套主机监控系统。整套系统对所有业务进行主机性能采集和相应的告警。目前谛听覆盖10个地区、4个国家，每天产生800多G数据量，平均每天发送告警1万余次，已成为公司平时，特别是大促前夕压测模拟必不可少的重要平台之一。

本文从谛听最初的开发目标，到后续所碰到的一些重要困难，从架构设计角度出发，讲述这过程中的演变历程。希望我们走过的弯路，能够警示大家尽可能避开。没有一套监控系统是完全理想的，有自己见解的同学也欢迎一起共同探讨。

 

背  景 

 

数字科技创立之初，由于不是所有的业务都完全继承自商城的技术体系，很多业务的部署方式甚至开发框架都有很多不同。那时并没有一套通用的监控系统。大多是各业务线自行搭建开源监控系统，nagios、cacti、zabbix都有人使用过。互相之间的告警也不统一，甚至看个监控图都要去好几个平台，出个故障，事件处理小组要去多个地方截图，再拼接到一起来做故障分析报告。

 

几个需求和痛点

• 覆盖率问题。以前多个平台，责任不明确，有些机器没有监控，或装的监控版本不统一，监控项不具备可比性，无法分析问题。

• 不能丢数据。相关业务经常进行压测，一台机器被临时压死后再恢复过来，这期间的数据要保存下来；或者网络出现问题后，到底业务之间会有怎样的影响不是很明确。

• 性能要好，不能几千个节点部分功能就失效或不好用了，至少要支持数万个节点而不出现任何问题。

• 要能结合公司自身的业务信息、组织架构。

• 能按需求出性能报表。

 V1 诞 生 - 混 沌 的 开 始 

 

按照最开始的5点需求，设计了V1的版本：

• miicoo是agent端，部署在每台服务器上。自行采集数据后，主动发送给paaraa组件。
  

• paaraa是每个机房的代理节点。汇总数据后，异步的投递给消息队列。

• 中间有个统一的消息队列。

• dt-MQ负责提取消息，并做报警处理。

• MongoDB负责存储监控数据。

• MySQL负责存储关系数据。

• DT-monitor是web界面。

  V1架构特点

1、miicoo放到装机模板里，这样保证每一个终端，都会有我们的监控。之前监控团队的同学需要为每台机器添加监控，现在只要确认每台机器的监控是否运行正常，简化了工作。

2、miicoo和paaraa两个组件，都带有数据缓冲。如果一个机器的网卡IO被打满，一时半会无法发送监控数据到paaraa，它会将发送失败或者超时的数据放入缓冲区，等待下一次成功发送后，再进行补发。同样，如果某个机房的上连线故障，整个区域断网，paaraa也会把所有数据缓存，等网络恢复后，进行统一的上报。这样就解决了数据丢失的问题。

3、业务和组织架构信息定时通过脚本导入到MyS