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

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

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

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

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

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

• MongoDB负责存储监控数据。

• MySQL负责存储关系数据。

• DT-monitor是web界面。

1、miicoo放到装机模板里，这样保证每一个终端，都会有监控。之前监控团队的同学需要为每台机器添加监控，现在只要确认每台机器的监控是否运行正常，简化了工作。
2、miicoo和paaraa两个组件，都带有数据缓冲。如果一个机器的网卡IO被打满，一时半会无法发送监控数据到paaraa，它会将发送失败或者超时的数据放入缓冲区，等待下一次成功发送后，再进行补发。同样，如果某个机房的上连线故障，整个区域断网，paaraa也会把所有数据缓存，等网络恢复后，进行统一的上报。这样就解决了数据丢失的问题。
3、业务和组织架构信息定时通过脚本导入到MySQL库中。加上各个机器的告警阈值，一并推送到dt-MQ组件中。dt-MQ不停的从消息队列中抽取监控采集的信息，进行报警判断，同时将原始监控数据存入MongoDB。
4、DT-monitor为用户提供可视化的展示，根据MySQL中记录的组织架构和权限，相关的绘图数据从MongoDB获取。大促前的压测，直接使用MongoDB跑MR任务来生成相关统计报表。
基本上最初的几点需求都满足了。整个从开发设计到最终上线，用时大概不到半年。那年的618和11.11所有的性能报表，都由谛听产生，这为下一年的大促提供了非常重要的优化依据。

但随着使用，还是发现了很多问题。

1、所有组件都采用Python编写，环境是碰到最麻烦的问题。在装机包中，最开始附带了一个pypi的运行环境。但发现整个包要超过200M。后来改用二进制编译miicoo组件，即使这样整个包也要超过100M，而且Python的二进制化兼容性差。

2、所有告警的策略开始都是统一的，如果想做个性化的配置，就需要修改对应miicoo组件的配置文件，同时还要把相关信息推送到dt-MQ。如果有大量机器需要改特殊配置，例如某些大数据相关的业务，就需要做大量的操作，即使使用自动化脚本去做这件事，效率也非常低。每个特殊的应用上线时，又多了修改默认报警配置的工作，这和最早每个机器上线都需要添加监控相比，并没有什么本质的区别，非常不理想。

3、有些演练压测时必然会产生告警，实际上这些告警并不重要。如果需要暂停这些告警，就要针对相关范围的机器，提前修改告警配置。改配置实在是太多太麻烦了，但是不修改可能会使压测时真故障告警被埋没在告警风暴中，没有及时发现，影响其他业务。

4、miicoo的版本更新工作繁琐。有些特殊硬件配置的机器，要用特殊版本的miicoo。而每台机器所部署的miicoo版本，没有组件自动管理，全是人工维护。在数万节点的情况下，这个工作非常反人类。

5、在数万节点的前提下，DT-monitor组件的出图效率非常慢。关注监控的同学，可能每天都要被迫看几十分钟折线图加载过程。

总结之前一年的经验后，有针对性的推出了V2.0架构。

1、强化节点管理，增加了一个dt-mgt组件，用来管理所有的miicoo节点。miicoo也增加了自动升级功能。每次启动时，miicoo需要通过最近的paaraa找到dt-mgt服务，进行注册，获取监控配置，获取最新版本信息。这样可以按照预先设定好的节点属性，进行监控，而不用现场去修改配置。每个节点在dt-mgt中的属性，也是根据相关的资源系统（IAAS）、应用管理系统（SURE）或者某些专用平台，例如数据库管理系统（MEGA）来同步节点属性。得到了正确的配置，就能进行更准确的监控。如果需要对节点进行批量监控策略调整，只要都到dt-mgt修改区域维度或者应用维度的配置，dt-mgt会自动转义成对应的节点配置并下发下去，miicoo得到新的配置后，会自行调整。

2、spark流式计算组件加入，可处理大量的告警计算。

3、Alarm组件，针对更为复杂的告警策略，可专门负责告警。

相关配置可分为三部分。如上图：

• 蓝色部分，是采集配置

• 中间橙色和红色部分是告警判断配置

• 右边绿色的部分是告警发送配置

把配置分开的好处是可以灵活的进行设置。比如某些监控项可以采集，但不报警。而有些监控项要采集，也要进行告警判断，但在允许的时间内才发送特定形式的告警通知。或者有的告警项在极端的情况下会影响服务器性能，要在大部分时间屏蔽掉，而在特定的时间区间才进行采集。

4、双库存储数据，为了提高绘图效率，并且照顾到数据的存储成本，把数据分成了两个库来存储。

• Cassandra库用来存储绘图数据，由spark直接计算后写库，数据只是为了绘图使用，长期数据进行归并处理。

• MongoDB用来存储原始数据，长期数据可以存储到磁带上进行备份。如果想分析每年618的业务数据的区别，就可以单独把每年618的数据提出进行统一分析。

整个2.0部署起来如下图：

为了简化部署，用go重写了miicoo。go语言可以编译成二进制可执行文件，而不需要在每一台机器上部署相同的执行环境，直接传包过去就可以了。所有基础的检查脚本几乎都内置到了单个的可执行文件中。

相应的，也扩充了paaraa层的通信协议。首先采用长连接方式来上报采集的数据。当连接中断，或者一定时间没有上传心跳数据，都会触发paaraa的宕机检测。再加上之前提到的注册逻辑，就组成了一个实时在线的采集关系网。这时又加入了一个创（专）新（利）功能，就是paaraa的动态负载均衡策略。

例如当一个机房有2W台节点，并且有2台paaraa节点的时候，理想的情况下应该是每个paaraa维护1万台miicoo。如果一台paaraa不小心维护了1万6千台，而另一台只维护了4千台时，这就是一种非理想的负载情况。此时设定平均数AVG=1W，偏移百分比为 OFFSET=40%，也就是说当一个节点维护的量大于 AVG * (1 + OFFSET) = 1W4 时，负载高的一台paaraa会强行切断多出来40%的节点，使两台paaraa的压力均衡。如果这时再加入一台新的paaraa节点时，同样也是不需要任何人工干预，一个心跳周期后，会变成每台paaraa维护6666台（或6667）miicoo。

升级架构后的谛听，当年非常顺利的完成了当年618和11.11的考验。但V2的架构在运行了1年多的时间里，也积累了一些问题。

1、miicoo版本太复杂，这是最消耗精力的一个问题。随着机型和操作系统版本不停增多，同样的功能所使用的采集细节也会各有区别，再加上虚机和容器的盛行，导致miicoo版本复杂到了难以维护的程度。而且经常有特殊情况，促使升级特定区域的miicoo。

2、告警的配置过于局限，一个节点，只有一套告警配置。因为是应用负责人和运维，共同使用一套配置，就会出现配置上的冲突。比如有些应用的CPU告警，开发并不关心，就会把阈值调到几乎最大。但运维的SA经常碰到CPU故障导致强制降频，进而促使使用率过高。如果这个机器的CPU告警阈值被开发改大了，很可能SA就收不到相关的告警。以往都是靠通过配置不同的告警接收人来解决，但实际情况过于复杂，导致这样也很难满足需求。

3、第三方编写的监控脚本也变得越来越复杂。一个典型的例子，PE编写的清除磁盘日志的脚本，需要获取磁盘监控的结果。现在的做法是，他们通过订阅我们的消息，然后再远程ssh触发脚本删除日志，整个绕了一大圈，中间还容易出现各种意外情况导致日志清理不及时影响业务。或是DBA针对数据库监控的一些特殊脚本，可能需要特殊的高频率采集，并且又需要报警和绘图，这都是目前支持起来相对麻烦的事情。

通过这段时间的运营总结，针对以上新的问题，设计出了V3的架构。对比前一架构有两点明显变化：