背景

数字科技创立之初，由于不是所有的业务都完全继承自商城的技术体系，很多业务的部署方式甚至开发框架都有很多不同。那时并没有一套通用的监控系统。大多是各业务线自行搭建开源监控系统，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、业务和组织架构信息定时通过脚本导入到MySQL库中。加上各个机器的告警阈值，一并推送到dt-MQ组件中。dt-MQ不停的从消息队列中抽取监控采集的信息，进行报警判断，同时将原始监控数据存入MongoDB。

4、DT-monitor为用户提供可视化的展示，根据MySQL中记录的组织架构和权限，相关的绘图数据从MongoDB获取。大促前的压测，我们直接使用MongoDB跑MR任务来生成相关统计报表。

基本上最初的几点需求都满足了。整个从开发设计到最终上线，用时大概不到半年。那年的618和双11所有的性能报表，都由谛听产生，这为下一年的大促提供了非常重要的优化依据。

几个问题

但随着使用，我们还是发现了很多问题，有的问题甚至无法忍受，相关的投诉也越来越多。

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

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

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

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

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

V2 - 灵魂的觉醒

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

V2架构特点

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的数据提出进行统一分析。

V2架构部署

整个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的考验。但V2的架构在运行了1年多的时间里，也积累了一些问题。

几个新问题

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

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

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

V3 - 越发精彩

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

1、miicoo组件拆分

拆分成了core和plugin的形式。这样主采集框架就可以不用总是去更新，只更新对应的插件就可以，保证了整体的稳定性。个别插件的采集失败也不会影响其他插件汇报数据。专门分化出一个组件DT-softCenter用来管理每个节点的插件。每个插件也都有自己能够运行的条件限制。这样不同的系统版本，可以共用主框架，配置不同版本的插件就可以完美运行。

2、alarm组件拆分

这样alarm可以进行更为复杂的告警配置。从下图可以看出，我们的告警配置可以针对所有用户，而不是像以前一样，大家公用一套配置。不同的用户设置的不同阈值，也不会影响互相的告警效果。避免了别人配置了一个过于严格的阈值，导致频繁发送告警，自己被动收取。

未来之路

在未来，行业内推行智能化运维，可能阈值都不需要人为来设置，通过测试中积累的数据，就能自动判断。甚至相关问题的出现也都能提前预测。谛听作为一个工具系统，势必会朝着越来越智能的方向发展。

创作场景

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