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

阅读数:1 2020 年 3 月 22 日 21:05

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

背景

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

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

未来之路

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

评论

发布