站内搜索

您当前位置:首页 >> 安监站动态

大规模主机监控告警平台的架构演变
文章来源: 发布者: 发布时间:2019-05-19 02:00 阅读:1

Tech

"

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

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

"

背景

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

1

几个需求和痛点

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

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

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

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

能按需求出性能报表。

V1 诞生 - 混沌的开始

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

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

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

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

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

MongoDB负责存储监控数据。

MySQL负责存储关系数据。

DT-monitor是web界面。

1

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.11所有的性能报表,都由谛听产生,这为下一年的大促提供了非常重要的优化依据。

2

几个问题

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

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

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

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

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

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

V2 - 灵魂的觉醒

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

1

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

2

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

3

几个问题

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

未来之路

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


[字体:  ]【打印本页】 【关闭本页
【上一篇】:发布游戏主机?谷歌放出GDC 2019宣传预告
【下一篇】:UCloud新一代云主机将搭载英特尔新一代至强可扩展处理器!
版权所有:邯郸县安全质量监督局 2012 All Rights Reserved 查询电话:0310-1234567 安全事故电话:0310-1234567
网站维护:邯郸县委宣传部 电子信箱:hdx@163.com 技术支持:Powered by SiteServer CMS