大型系统如何做一体化监控?

目前系统监控的手段比较多,大致可以分为三类:业务监控,应用监控和系统监控。

业务监控监测业务指标,比如下单量,用户注册数等,从业务数据来评估当前系统是否正常。

应用监控针对具体的应用,一般从接口调用的角度检测应用状态,比如调用数量/响应时间/错误数等,有很多APM工具可以做到这点。

系统监控针对物理机器资源,比如CPU/内存/磁盘使用情况等,Zabbix是典型的工具。

这些监控针对不同维度,监控结果在不同的系统里输出,比较分散;而且由不同的人负责,比如运维负责Zabbix,开发负责应用监控。在系统真正出问题的时候,从发现问题到定位问题,再到解决问题,协作困难,造成事故时间长,业务影响大。

本人基于实际的监控痛点,通过一体化地监控手段,比较高效地解决大型系统的监控问题,这里抛砖引玉,和大家探讨一下。

本文的内容包括:

  1. 监控痛点
  2. 解决思路
  3. 架构方案
  4. 监控效果
  5. 总结

1.监控痛点

大型的互联网平台,特别是面向C端的交易类系统,当线上发生问题,通常要求分钟级的处理速度。比如美团/饿了吗外卖平台,停摆10分钟,相信无数的商家/骑手/消费者会大规模投诉,这不仅是经济损失,平台商誉也会受严重影响。

这些平台背后都是大规模的分布式系统,有各种应用,还有基础组件(数据库/缓存/MQ等),共同组成复杂的依赖网络,任何节点都可能出问题,导致系统不可用。这样对系统的监控就非常重要,通过监控,及时干预,避免事故或缩短事故时间。

大型交易类平台监控还是相对完善的,一般由很多块屏幕组成一个屏幕墙,包括业务曲线监控(业务监控),关键应用的接口调用和出错情况(应用监控),网络和数据库监控(系统监控),但是事故发生时,还是一大堆人手忙脚乱,无所适从。

这里举一个典型的线上事故处理例子:

Monitor发现订单曲线突然跌停,快速拉起电话会议或群里@大堆的人排查。

运维检查网络和机器,开发检查错误日志,DBA检查数据库。然后负责APP服务端的开发在ELK发现大量的调用下单服务超时,询问下单服务怎么回事,并给出调用例子;下单服务根据调用例子检索错误日志,发现调用会员服务大量超时,问会员服务怎么回事;会员服务检索错误日志,发现访问会员数据库连接超时,问DBA怎么回事;DBA拉上网络同事一起看,发现网络没问题,而是会员数据库有慢查询把DB 挂住;最后DBA把慢查询杀掉,系统暂时恢复正常,大家都松了一口气。这个时候距离问题发生已经过去很长时间。在此期间,技术总监被CTO催了N次,CTO被CEO催了2N次,CEO被客户催了NN次,客户被消费者投诉了NN*N次。

可以看到,虽然有很多监控手段或者大屏监控,但真正出事故时,能发挥的用处还是比较有限,那这里面具体有哪些问题呢?

第一发现问题慢,业务曲线一般1分钟更新一次,有时候因为正常的业务抖动,还需把这种情况确认排除掉,带来很大的滞后性。

第二定位问题慢,系统庞大,大量的人需要介入排查,而且由于依赖复杂,需要反复沟通才能串起来。一方面无关的人卷入进来,人员浪费,另一方面沟通效率低,定位问题时间长。

第三解决问题慢,当定位到问题,对系统进行调整后,验证问题是否解决也不是容易的事。更新大量机器需要时间,然后需要各个研发确认系统有没问题,还要通过滞后的业务曲线看业务是否恢复。有时病急乱投医,往往会发生二次事故,这里的问题是缺乏实时直观的反馈途径。

2.解决思路

如何有效解决监控上的这些痛点,快速处理线上事故呢?

我们可以借鉴道路交通监控的例子,在交通监控图上,每条道路通过上下左右方位有机地关联在一起,形成整体的交通网络,同时通过红黄绿三种状态实时反映拥堵情况。司机可以非常直观地获取信息,及时避开拥堵路段,如下图所示:

这里有几个关键词:实时,整体,直观。

首先要实时,马上知道系统当前是否有问题。

然后要针对系统做整体监控,把各个部分放一起,能够迅速识别哪些部分是好的,哪些部分不好。有问题的部分,又有可能是它依赖的部分引起的,因此依赖关系也要直观展示,便于定位真正的问题源。

最后要直观,发生紧急事故时,人脑处于错乱状态,这时候,不能借助专业的头脑或严密的分析才能判断。哪些部分有问题,问题严重程度,以及出问题的原因必须一目了然,不能连累他人。谁家的娃有问题,各找各妈,各回各家。

如果我们能按照道路交通监控的思路,对我们的系统提供类似的监控,那就非常理想,每个系统节点对应一条道路,应用的健康状况对应道路拥堵情况,应用的上下游依赖关系对应道路的方位关系,这样我们就能构建一个实时直观的一体化监控体系。

回到刚才的例子,我们的系统交通图监控如此设计,首先聚合层应用,各种服务(下单服务,会员服务,商品服务,库存服务,促销服务等),各个服务对应的Redis,MQ和数据库,这些节点按照相互调用关系放在一张图里。出上述问题时,聚合层应用->下单服务->会员服务->会员数据库这4个节点都会爆红,其他节点保持绿色。前3个节点有错误消息提示接口调用超时,会员数据库节点提示数据库连接超时。这样首先其他节点可以不用排查,然后观察爆红的节点,通过直观的上下游依赖关系,知道最终问题很可能出在会员数据库上,DBA重点检查这个就可以。数据库问题解决后,可以看到爆红的节点马上变绿,整个系统恢复正常。

3.架构方案

整个系统架构如上图所示,每个被监控节点,均有对应的agent负责采集健康数据,不同的节点类型,采集的方式不一样,web节点提供http接口,agent定时访问,Redis和MQ 通过对应的api,db则采用标准的jdbc。除了web应用有少量改造(提供一个接口),其他节点都无需改造,系统的侵入性很低。

Agent每5s采集节点数据,由monitor service确定节点当前状态并存储,Dashboard每3s拉取节点状态并以红黄绿三色展示,同时显示具体出错信息。

4.落地效果

看下实际监控效果,下图是某个业务系统的实际监控效果图,左边是系统部署架构,最上面是两个前端应用,分别有自己的Web服务器(Docker部署,所以只显示一个节点实例),以及MQ和Redis中间件(有多个节点实例),这两个应用同时依赖后端3个服务,实际节点部署情况和依赖关系一目了然。

图中有一个节点是黄色状态,原因是采样时间内接口平均调用时间超过正常数倍。其他节点均正常,具体出错信息在右边列表有说明。点击某个节点,会显示该节点历史出错信息,可供进一步排查,这里就不贴截图了。

这是单个系统的监控,用一个单独的页面表示,如果一个公司有多达数十套系统,对应数十个页面,monitor肯定看不过来,屏幕墙物理空间也有限。这里可以进一步做所有系统的大盘监控,每个系统在大盘上用一个方块表示,同样有红黄绿三种状态,这个状态是根据该系统内所有节点状态加权算出。

此外,如果具体节点实例有问题,会在大盘左侧区域按照类别汇总显示,出错信息在大盘下方展示。这张图兼顾宏观和微观,一方面直观展示各个系统总体状况,另一方面展示所有问题节点的出错情况。Monitor只要观察这个大盘页面就可以,如果发现某个系统有问题,可以点击进去,看该系统详细出错情况。

下图有一个系统处于红色高危状态,两个系统是黄色警告状态,引起这3个系统出问题的是3个web节点,在左边显示,具体出错信息在最下面的错误列表。这里系统状态,节点状态,错误消息均以红黄绿表示,可以非常直观地对应起来。

通过一体化地交通图监控,可以快速定位到哪些节点有问题,通过依赖关系进一步确定问题源,并且有具体的出错信息可以帮助定位原因,配合在一起,大大减少问题解决的时间。

5.总结

交通图监控有以下特点: 1). 包含节点->应用->系统->大盘监控,层次鲜明,依赖清晰,实现一体化监控。 2). 直观地以红黄绿展示节点状态,每个人都能判断哪里有问题,以及问题原因。 3). 本质上这是一个活的部署图,实时反映系统状态,并和实际部署一模一样。

常规的监控工具,比如Zabbix和APM,强调微观,适合程序员排查具体问题。

交通图监控强调更宏观一些,自上而下地把监控对象组织在一起,把所有人拉到同一个信息层面,并提供直观的手段标识问题,非常适合解决线上重大事故。

当然两者完全可以结合起来,交通图监控作为监控大屏入口,常规监控作为细节补充。在我们的节点详情页里,也是有链接指向该节点的Zabbix和CAT监控页面,可以帮助获取错误详细信息。

交通图监控的更多内容,后续会进一步介绍,敬请期待。

作者介绍

王庆友,大型电商平台负责人兼首席架构师,先后就职于ebay、腾讯、1号店、非码科技,精通大型电商平台和门店零售及O2O交易系统,有丰富的高并发/高可靠系统建设经验,非常接地气,微信Brucetwins,头条号架构大道,目前正在寻找合适的工作机会,欢迎关注,一起聊架构,一起做事。

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/pUlZJ6TjDbLeXcfEhAWS

扫码关注云+社区

领取腾讯云代金券