AI时代的全链路监控，阿里工程师怎么做？

摘要：背景近年来，随着阿里新业务新技术的快速发展，传统的业务总量监控大盘已经越来越不能满足监控需求，主要表现在以下几个方面缺乏全局视角监控大盘主要反映的是单个业务或应用的运行状态，缺少全局的业务视角能反应整个业务域的上下游整体的运行情况。

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

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

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

缺少业务视角：随着阿里业务飞速发展，特别是“大中台”的建设，使得传统的“总量”监控已经不能满足需求，比如一个“交易”中台业务就会有数十个“业务方”调用，单纯的总量监控会把小调用量的业务淹没，必须按每个业务方的“业务身份”进行监控。对于像“盒马”、“淘鲜达”这样的新零售业务，这样的问题更加突出，一家门店出现交易异常对于“交易总量”来说是微不足道的，但是对这件门店的客户体验来说是灾难性的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

● 饱和度 ：应用已使用资源的占比。

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

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

传统的“总量”指标已经不能满足中台、盒马这样的业务监控需求了，通过可扩展的业务维度实现对业务身份、商家、门店的精细化监控。像“交易”这样的中台业务会被几十个业务方调用，总量没有异常并不代表具体的业务方没有问题，而是需要监控每一个业务方各自的调用情况，只要有一个出现异常就要预警。

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

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

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

通过机器学习快速预测指标的合理范围，一旦超出边界就会自动触发报警，无需配置阈值。

智能基线预警已经在业务自定义监控中得到了验证（已经有超过1200指标接入），准确率和召回率相对于人工配置都有大幅提高，现在我们将该技术引入“业务全链路监控”，实现对业务活动的智能异常检测，全程无人参与。

实战1-交易全局链路

交易域的全局业务链路，链路中列出交易的关键“业务活动”，省略了每个业务活动的“系统服务”等细节，主要用于全链路压测，大促投屏等需要关注全局状态的业务场景，已在6.18大促中得到实际应用。

实战2-交易核心链路

交易是整个电商的核心，我们通过“链路自动生成”能力生成了核心业务链路，其中绿色节点为“业务活动”，黄色节点为“业务活动”依赖的“系统服务”。

通过业务链路可以很方便了解交易活动的运行状况，一旦业务活动出现问题也可以更加直观的发现与下游依赖的关系。

实战3-POS服务端链路

POS是整个新零售场景线下支付场景的交易核心，下线支付场景对交易系统提出更加严格的可靠性要求，通过POS业务链路可以很好的监控POS交易各环节的运行情况，及时发现交易异常。

同时POS链路添加了“商家”、“门店”的业务维度，可以实时切换“盒马”，“大润发”等不同商家的POS交易情况，实现针对每个商家精细化监控。

本文作者：劲节

阅读原文

本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。