背景

数字科技创立之初，由于不是所有的业务都完全继承自商城的技术体系，很多业务的部署方式甚至开发框架都有很多不同。那时并没有一套通用的监控系统。大多是各业务线自行搭建开源监控系统，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 可以进行更为复杂的告警配置。从下图可以看出，我们的告警配置可以针对所有用户，而不是像以前一样，大家公用一套配置。不同的用户设置的不同阈值，也不会影响互相的告警效果。避免了别人配置了一个过于严格的阈值，导致频繁发送告警，自己被动收取。

未来之路

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