阿里业务全链路智能监控探索 [ 站在巨人的肩膀上 ]

阿里监控的发展与挑战

我把整个阿里巴巴监控发展分成四个阶段：

第一个是在2011年以前，这是一个草莽阶段，在这个阶段大家的监控系统参差不齐，各种自研的，开源系统都上，能够抓到老鼠的都是好猫，当然这种模式随着规模大了以后变的难以维护。

第二个就是监控平台化的阶段，在这个阶段其实解决的更多是监控的技术问题，就是怎么做监控的采集、存储、报警等等这些技术上面的问题，主要代表就Alimonnitor系统，它能帮助用户把采集、计算、报警这些问题都处理掉，当时主要的用户是我们运维的同学PE，他们只关心我要采什么数据，然后在上面写脚本，直接在我们的监控系统里面配置，最后就能监控起来。Alimonitor开始大家用的非常爽，到后面也暴露出很多问题：

第一个就是自定义的东西就很多，标准化的程度低，那你这些监控的运维管控就很困难，进一步的数据分析挖掘就更难做了。举个例子，我一个磁盘容量监控，就有二十几个各种不同的监控项，这些监控项的指标命名、格式、单位都是不一样的。

第二个就是它对用户的要求比苛刻，复杂程度比较高，比较适合像PE这样一些专业的运维同学。

第三个阶段是标准化的阶段，在这个阶段我们主推的就是我们现在的Sunfire监控平台。

我们把基础的监控都已经标准化掉，只要一个应用上线这些基础的监控数据全部都有了，你只需对一些报警规则做一些设置就可以了，这样对于不是很专业的人用起来会更加的方便，同时在这个阶段有很多的自动化的诊断工具应运而生的，在这个阶段是一个诊断排查工具大爆发的一个阶段。

第四个阶段就是智能化的阶段，智能化阶段要就是要实现无人化，整个监控运维的一体化。

下面说一下整个集团监控平台的规模，平台是以租户的形式来进行划分的，一个租户差不多相当于一个事业部的规模，比如说是天猫、淘宝、优酷等等，现在我们基本上已经覆盖全集团80%以上的事业部。

我们整个平台的监控服务器有4000多个台，这里不是说监控了多少服务器，而是现在用了这么多机器在做监控，这里不包括我们的存储服务，主要是计算以及采集计算等等这部分的服务。

整个对监控的应用大概是在一万个以上，平台主要是通过分析日志的方式做数据采集的，现在每秒钟平均的日志处理量大概是在2T左右。

接下来讲一下阿里监控一些挑战，主要围绕业务监控来说：

近年来，随着集团新业务、新技术的快速发展，传统的业务总量的“监控大盘”已经越来越不能满足监控需求，主要表现在以下几个方面：

缺乏全局视角

“监控大盘”主要反映的是单个业务或应用的运行状态，缺少全局的业务视角能反应整个“业务域”的上下游整体的运行情况，比如交易系统成功率下跌，想看看是不是优惠出问题了，但是不知道“优惠”的业务监控在哪里，只能依赖”优惠”的同学去排查，钉钉电话沟通，大家来拼凑信息，上下游协调成本很高。

监控标准不统一

一直以来“业务监控”都是自定义的，依赖开发人员的个人经验，往往系统、业务监控混在一起，没有标准，业务之间不能比较；各系统监控能力参差不齐，很容易出现业务链路中的监控断层；业务监控缺少一套行之有效的方法论，新人或者新业务对于业务要怎么监控，不知道如何下手、不知道自己配的监控是否覆盖全面，只有等到故障发生以后才去补监控

缺少业务视图

随着阿里业务飞速发展，特别是“大中台”的建设，使得传统的“总量”监控已经不能满足需求，比如一个“交易”中台业务就会有数十个“业务方”调用，单纯的总量监控会把小调用量的业务淹没，必须按每个业务方的“业务身份”进行监控。

对于像“盒马”、“淘鲜达”这样的新零售业务，这样的问题更加突出，一家门店出现交易异常对于“交易总量”来说是微不足道的，但是对这件门店的客户体验来说是灾难性的?

监控配置成本高

“业务监控”一直都是由“开发人员”纯手工打造，需要经过日志埋点、监控配置、报警阈值设置，整个过程费时费力，缺乏自动化、智能化监控的手段，这也是造成各系统监控能力参差不齐的重要原因，一些新业务因为无力投入大量精力配置监控，导致业务监控能力缺失。

业务全链路监控的思考和建设

第二部分重点讲一下业务全链路监控是怎么做的，怎么解决我们的痛点。

一开始我们的监控系统都是针对单个应用的，比如说交易的开发只关心交易指标是是否正常，优惠的同学只关心自己系统的健康状况，他们各自配置数据大盘，报警等等。

一旦出现问题怎么办？大家只能在群里面问，或者电话会议，互相讨论，定位到底是谁出了问题。

同时上层的领导更加着急，因为他看不到整体情况，就只能挨个问情况。所以单系统监控的问题就是看不到全景，上下游协同成本非常之高；系统的监控能力是依赖于开发人员自己的素养，能力高一点的，监控完善一些，技能不足或者意识不够的可能就是空白。

后来有很多trace的监控出来，比如说阿里的鹰眼系统，它主要解决的是如何做系统间链路排查，这样从原来完全看不到全景，发展到可以看一部分系统调用链路上面的情况。

同时trace监控也存在一些不足，什么问题呢？首先，那它是没有业务含义的，就比如说我们中台交易的业务，其实服务于很多业务方，每个业务方调用都是调用同一个API，在系统链路里只能看到总量，比如我们拿盒马来说，系统链路就看不出问题，因为盒马在整个交易里面量会占的比较小，总量的波动也很小。

其次，系统链路的细节太多，缺乏对强弱依赖的梳理，导致整个链路形如蛛网，反而看不清全局。

业务全链路监控就是要从业务的视角出发，监控整个业务流程的健康状况，无需多个系统切换，直观看到全局和上下游，方便快速发现、定位问题。

建立了完整的“业务监控模型”，为业务建立起一个从“宏观”到“微观”的全景式业务监控体系，结束了业务监控没有标准，只能纯手工打造的历史。业务监控模型主要包括3部分：

业务域：一个完整的业务或产品称为“业务域”，如电商的“交易域”、“营销域”、“支付域”等。

业务活动：业务域中的的核心业务用例叫做“业务活动”，如交易域的“下单确认”、“创建订单”等，业务活动是整个监控模型的核心，每个业务活动都会有标准的【黄金指标】来反应自身的健康状况，业务活动之间建立上下游关系就形成了业务链路。

系统服务：业务活动中的依赖的关键方法称作“系统服务”，如“下单确认”包含：查询会员、查询商品、查询优惠等关键方法，每个系统服务也通过【黄金指标】来表示其健康状况。

这是我们整个平台的产品大图，最底层是数据采集，所有的数据都会在这里被处理，上面是各个服务层，包括我们的元数据中心，以及对外提供数据的服务，事件中心包括报警事件查询，通知规则定义等等，最后一个是我们的整个监控指标库，所有监控指标都要落到这里统一管理。

业务层主要分成两块业务：一块是应用监控，应用监控里面主要是一些基础的标准化的监控，第二块是业务监控，原来主要是靠用户自定义，缺少标准和对数据有效组织，以后更多的会以业务全链路作为一个入口，把所有的业务指标以及后面的应用监控来串联起来。

以“业务模型”为基础，我们总结出了一套如何做“业务全链路监控”的方法论，并将其沉底到产品中。

梳理关键业务：业务方需要梳理出自己的核心业务是什么（业务活动），以及这些核心业务的关键依赖有哪些（系统服务）。

监控数据埋点：提供了无侵入的配置化监控SDK，只要将‘业务活动’和‘系统服务’对应的方法填写到配置文件中即可，系统会自动收集，计算，上报监控数据。

监控链路：系统根据收集的数据自动生成业务链路，每个‘业务活动’和‘系统服务’节点都自动生成流量、耗时、成功率的黄金指标，同时每个‘节点’都可以通过钻取查看详细的监控数据，包括：不同机房、单元、分组的数据对比，每个业务身份的明细调用情况等。

异常检测：业务链路涉及节点众多，必须要有完善的异常检测机制来帮助用户自动发现问题，我们提供了“智能基线预警”和“专家规则预警”相结合的异常检测机制，无需用户逐个配置报警规则，自动发现异常节点，实时将这些节点‘标红’，异常的详细信息也会同步显示，方便用户快速发现和定位问题。

通过业务全链路监控，可以做到对业务域的监控标准化和全覆盖，避免了自定义监控覆盖不全面、不标准、配置工作量大的问题，使得老板、PD、运营、监控值班等用户都可以快速了解业务是否有问题。

这里引入Google的黄金指标概念，改变了业务监控完全依赖自定义的现状，为业务监控树立了标准。

流量：业务在单位时间内的调用量，如：服务的QPS、每秒订单笔数等。

耗时：业务的具体处理时长，需区分成功耗时和失败耗时。

错误：调用出错数量、成功率、错误码。

饱和度：应用已使用资源的占比。由于饱和度更多反应的是应用的层面情况，所以业务监控使用流量、耗时、错误这三个指标就能很好的回答“业务”是否健康的问题，在“业务全链路监控”中每个业务活动和系统服务都会标配这三个监控指标。

除了黄金指标以外，还可以根据各自业务的不同特点，定义各种分维度的辅助指标，比如：按不同的业务身份，按商家、按门店分，不同的错误码等等，用于进一步细化和定位问题。

前面我们已经确定了“业务域”、“业务活动”和“系统服务”三层业务模型，再通过“黄金指标”来描述这些业务模型的监控状况，这样我们就能‘量化’清楚一件事情：业务是否健康。

能量化“业务健康”这件事情价值很大，是很多AIOps的基础，比如我们在做无人职守发布或者智能调度的时候，就需要明确我在调度前后或者发布的前后，业务到底健不健康，是否正常，否则智能化运维就是一句空话，无法大规模推广。

横向业务维度：传统的‘总量’指标已经不能满足中台、盒马这样的业务监控需求了，通过可扩展的业务维度实现对业务身份、商家、门店的精细化监控。

像“交易”这样的中台业务会被几十个业务方调用，总量没有异常并不代表具体的业务方没有问题，而是需要监控每一个业务方各自的调用情况，只要有一个出现异常就要预警。

业务全链路监控提供了“横向业务维度”功能，能够方便的配置‘业务身份’、‘商家’、‘门店’等特定的业务维度，可以对一个业务域中所有的“业务活动”和“系统服务”按一个维度过滤，比如可以对交易链路按“盒马”这个业务身份过滤，从而在链路上看到的是盒马的交易调用情况。

监控SDK使用AOP切面技术实现了配置化埋点能力，业务系统引入监控SDK后，通过简单的一个配置文件即可完成监控埋点，自动完成数据的拦截、计算、上报，与业务代码完全解耦。

自动生成核心链路、黄金指标、下钻的业务维度大盘，无需用户配置，用户还可以通过可视化编辑页面对链路进行调整。

业务码：用来表示这行日志是属于哪个一个业务域，哪个业务活动或者系统服务。

错误码：错误信息里面最重要的是错误码，产生了一次错误以后到底是什么样的错误就全靠错误码进行区分，这样你在做定位的时候才能有的放矢。

错误类型：错误一定要分类型，大致分为这么两类。一类是用户级的错误，一类是系统级的错误。对于用户级的错误，比如用户登录的时候密码输入出错了，这些错误是已知道的，对整个系统是不会产生影响的，它是属于业务日常错误里的一部分，你需要在做监控的时候把这些错误排除掉，要不然你整个成功率指标就失准了。

扩展信息：扩展信息里输出的是每个业务特有的维度，也就是前面提到的“横向业务维度”，比如“业务方”，“商家名称”等，比较通用的是一个压测标识，记录这条数据是真实流量还是压测请求。

接下来讲一下监控存储，我们所有的数据格式化以后，就会存储到监控数据库里，今年我们监控平台在存储上最主要做的一件事情就是把监控数据全部标准化，数据从原来的HBASE迁移到HiTSDB里面。HiTSDB是一个高性能的时序数据库，已经在阿里云上发布了，现在已经在上面存储了几十亿条时间线。

在HiTSDB的上层实现了一套监控数据查询语言（MQL），通过MQL我们实现了监控数据查询的标准化，上层的图形展示和报警都会通过这种方式去查询，会大大简化操作。

业务链路监控发现异常以后，就需要对异常做更加精确的定位，最主要的是两大平台。

一个是我们前面提到过的鹰眼系统，原理和Dapper类似，主要做系统Trace链路排查。

第二个我们叫A3系统，它是一个日志的异常诊断的一个工具，我们的日志里边肯定会很多的错误堆栈，各种错误信息，A3通过一种比较智能化的手段对错误进行分析和归类，统计每种错误的出现时间、次数、类型和原始样本等信息，帮你找出应用里面有哪些错误是比较高危，哪些错误是最近新产生的，这样能快速帮助你定位问题。

在业务链路监控中，跨部门或者跨BU的链路监控一直是个难题，业务全链路路监控通过“黄金指标”+“业务维度”来解决这个难题。

首先每个部门把直接对外提供服务的核心业务梳理出来，并设定它的“黄金指标”，我们设定这样的黄金指标为这个部门的SLA指标，其它部门的系统调用这个业务时，就看这些SLA的指标是否正常，而不再关心这个业务的内部调用细节。

一般这样的业务调用方很多，我们通过一个“业务身份”的维度来对这些SLA指标进行细分，每个业务身份会有独立的SLA指标数据，调用方只看自己的业务身份对应的监控数据即可判断对方业务是否正常。

每个部门都定义自己的对外核心业务和SLA指标，相互之间通过数据说话，形成一种标准化的服务能力评价体系，随着这个体系的不断推进，业务全链路可以把各个部门的业务节点串联起来，组成一个更大的大网，在这个里面每个部门都对外暴露的自己的关键业务，每个关键业务通过“黄金指标”量化服务能力，这样就可以快速定位到底是谁的问题，建立起一个正在的全景式监控。

接下来，我们通过一个交易链路实例来看一下效果，链路中列出交易域的关键业务，也就是交易对其它部门提供的核心服务，省略了每个业务的‘系统服务’等细节，整个链路可以通过“业务身份”来过滤不同调用方的调用情况，通过智能检测程序实现对每个调用方的SLA监控，一旦出现异常会通过短信等消息通知用户，并将节点标记为异常。

每个业务节点都可以钻取查看更详细的业务活动大盘，它是业务异常排查的一个总的入口，整合了这个业务活动的所有业务指标，关联应用的系统指标，以及系统调用的链路等等信息。