ARMS作为业务的实时监控系统，可以帮助用户定位从前端到应用的普遍问题，以及利用全系排查解决单点问题定位。本文利用案例演示，更直观的为大家介绍ARMS是怎么帮助用户快速的定界和定位的。让天下没有难定位的问题是ARMS的最终愿景。
演讲嘉宾简介：
徐彤，阿里巴巴中间件技术家
阳其凯，阿里巴巴中间件高级件工程师
以下内容根据演讲嘉宾视频分享以及PPT整理而成。
本次的分享主要围绕以下三个方面：
一、产品概述
二、演示
三、后续功能
一、产品概述
1.ARMS是什么
ARMS是一个业务的实时监控系统，那为何要标红‘业务’两字？日常的运维是不是处于每天早上起来看了一堆花花绿绿的图表，这些图表的曲线高低对我们的业务有什么影响是不知道的，也不知道曲线的高低在以后我们能做什么，这两个问题都没有回答。然后手机上每天都收到很多的短信，CPU超了，memory超了，memory不够了等等短信，尽管短信很多，我们也不知道这些问题出现之后对我们的业务有没有什么影响，也不知道我们能做什么。特别对很多初创公司，他们当前主要主力还在于业务的扩展，一些新需求的开发，这时他们再投入一些宝贵的人力做运维工作的时候，对他们的成本有非常大的影响。所以ARMS正是针对上面的痛点，来帮助用户快速的进行故障的发现，故障的定位，提供问题定位的效率，降低问题定位的时间成本以及人力成本。
2.ARMS的特点
ARMS主要有三个重要特点，一个是前端监控，一个是应用监控，还有一个是自定义监控。
a.前端监控
如果我们的应用是Web类的应用，通常有三个指标是非常重要的。一个是页面的访问速度，第二个是页面运行的稳定性，第三个就是前后端交互的API的调用。下图左上角有个图表，可以看到页面从DNS解析到页面加载的整个时间分成12个指标，我们可以剖析到让你看到页面打开的那一瞬间是哪些环节变慢，这些可以从时间的图表分析出来。同时我们会分析用户访问的PV，UV，有时候页面出现问题时，通过PV，UV能很直观的反映出来，当你的PV，UV出现断崖式的变化，这时就感觉到业务可能出现问题。第二个来看页面运行的稳定性，我们知道很多页面是通过JS写的，在页面加载的时候，以及在前后端进行交互的时候，会有很多JS的报错。我们通过JS的报错数量来知道当前哪些页面是不稳定的。某个页面只要一加载，JS不断的报错，哪些页面报错，我们就会打印出来帮助你分析问题，如下图右上角。第三个很重要的特性就是API的调用，我们知道很多Web类的应用处理数据是前端给后端发AJAX请求，后端把数据包装发送给前端，前端进行一个渲染。这时假如你的页面访问比较慢，前端页面渲染没有什么问题，很有可能就是后端处理数据有问题。我们把前后端的调用的API接口打印出来告诉用户。比如API成功率的排行，也可以知道哪些调用是当前后端的热点调用。我们现在很多企业可以通过知道哪些调用是热点调用，有针对性的提高这块调用使用的效率，很大程度上提高页面的速度，可以用很少的人力做到这些事情。另外我们前端监控的一个很重要的特性就是多维监控。每当我们页面出现问题的时候其实有两个问题是我们需要回答的，第一个就是为什么页面比较卡，打不开。第二个问题，当我的页面打不开时候，是全国都是这样，还是某些浏览器是这样，或者某些网络，某些设备会导致这样子。比如我们的多维监控，第一时间帮你知道故障影响到底是哪些。我们可以按照省市，按照国家，按照浏览器，按照设备，按照操作系统，按照分辨率等等做分类，让你一下子知道你的页面影响范围是多少。
b.应用监控
首先，介绍第一个特性，应用拓扑。文章最开始提到的花花绿绿的图表，不知道曲线高低意味着什么。这是因为我们内心不熟悉业务的整个上下流的关系，不知道谁调了我，也不知道我依赖谁。所以我们通过业务拓扑，每一条线上都标注了你的请求量，你的响应时长，这样可以很清晰的看到谁调了我，这时请求量是多少，我依赖了谁，下流有哪些些数据库等等。很快的帮助你进行故障的定界，是自己有问题还是下流有问题。另外我们做了一个应用概览的图，把几个视图一起给用户看。第一个就是应用提供服务的响应时长和请求量，以及应用依赖服务的响应时长和请求量，还有应用自身的CPU，memory的信息。我们把这三个图放在一起，并且通过时间共轴的方式让你可以看到在这个时间点是我自身有问题，还是我依赖的服务有问题等等。假设是自身有问题，这时候ARMS的手段就很多了。比如我们调用的数据库发现有问题，可以通过一些异常的SQL分析帮你分析出你的哪一条SQL语句出现问题，哪一条SQL语句比较慢，SQL语句什么参数导致有问题。另外当接口出现问题，我们会把异常的信息打印出来，告诉你这时什么样的异常最多，异常里面的参数也打印出来。另外，阿里自己做了一个JVM的内存分析，在遇到内存泄露的问题时，ARMS帮助用户可以用很小的代价分析出到底什么样的内存是大内存，到底什么样的内存常驻在内存中。第三个是链路跟踪，对于单点问题链路跟踪就显得非常有用了。对于单点的链路，我们知道这些用户的id，输入id可以把这个用户所有相关的链路抓出来，其中把异常链路抓出来就可以知道这条链路是调用了哪些分布式的服务，以及这条链路里哪些方法是有问题的，以及方法的参数也都给你一一的抓出来。第四个就是我们可以跟阿里的中间件无缝对接，用户如果使用了阿里的EDAS，我们可以无缝的使用ARMS，一键接入，不需要用户做任何事情。如果用户使用了MQ，DRDS等，我们也是支持对其的监控，也不需要用户做任何的事情。
c.自定义监控
前端监控和应用监控是帮助用户发现前端和应用的问题，假如用户有很灵活的诉求，这时可以使用自定义监控的能力。如下图，上流我们可以对接丰富的数据源，支持ECS，支持MQ，支持EDAS，支持Loghub等。我们收都数据之后，做一些数据的处理，然后把数据输出到你的告警系统，对接到阿里巴巴的高级展示，也可以提供API，供你调用。
上面提到的三个重特性，帮助我们从应用的最前端开始，层层下钻，一直帮你定位到是哪一行代码有问题，哪个SQL语句有问题，哪个接口有问题，通过这样我们打造一个全栈定位的系统，帮助用户快速的发现故障，进行故障的定界和定位。
3.ARMS的优势
ARMS的第一个优势就是零成本监控。上面提到的前端监控如何做呢，就是在你的HDML头里面加上三行JS代码，重启一下应用就OK了。应用监控怎么用呢，也很简单。下载一下代理，修改你的启动参数，重启应用也就OK了。如果你是EDAS的应用，只需要一键点击就可以自动接入ARMS。然后，我们是100%采样的，那有什么意义呢？我们认为调用链是个吉祥物的存在，用到的时候发现被采样了。很多时候我们也很无奈，数据被采样之后很多关键细节信息我们是丢失掉的。所以我们是支持100%采样的，这样不会丢失细节信息。当然如果你不需要100%采样，我们也帮助你动态的调整采样率，秒级生效，不需要你重启应用。另外一个很重要的是我们的价格很低，是同类厂商的10%都不到。我们现在有几种定价方式，一个是按量收费，用多少收多少钱。第二个跟手机套餐一样，有个资源包的形式。最便宜的资源包大概是四块钱一个代理，也就是4块钱就能帮你监控一天。很多初创公司可能是平时只需要一两个人监控，但是在关键的节点，在大促的时用ARMS。这种也是OK的，我们有很灵活的启停，想用的时候打开，不用的时候关闭，关闭阶段不收费。还有我们的应用监控的带宽是零成本的，我们不走公网带宽，而是走内网带宽。另外如果是ARMS的用户会折上加折，可能只需要2块钱的代理。
二、演示
下面利用几个常见的场景，给大家介绍ARMS是怎么帮助用户快速的定界和定位的。
1.普遍问题定位
首先讲一个小故事。一个朋友，他是一个宠物狂，平时比较喜欢撸猫撸狗，所以自己建了一个宠物网站，结合他的这个案例给大家介绍一下如何进行问题的快速定位。进入到这个宠物网站之后，大家可以选择自己喜欢的宠物把它加入到自己的购物车，然后进行购买，这是非常典型的电商场景。
刚刚接到一个告警，是说宠物网站的链路中，一个分类的action发生了API请求成功率低于70%的报警。下面针对这个场景，讲解从前端都应用的详细情况。
首先来看看这个网站整体前端监控的概览，在刚才时间点的满意度，截止错误，PV，UV都正常（绿色块）。但是发现黄颜色那块的API的的请求成功率下降的很明显。
我们可以到API请求中看，直接找到刚才接到报警的核心链路的API，可以看到分类接口的成功率在13：15时是100%的，到13：20时已经跌倒了17%左右。针对这种情况我们来评估一下API的影响范围是多大的，是全网范围，还是某些地区，某些网络。也就是说来看看影响范围是全局的还是局部的。
我们有个多维的监控。首先来看看地理的影响程度，目前在中国有两个省份有访问，第一个浙江省，第二个是湖北省。我们可以看到两个省份API的请求成功率都是呈现下降的趋势，也就是说对全网的用户都是有影响的。
再来看看终端的影响。目前有Google浏览器和Safari。这两个浏览器也是全面的。
再来看看API请求成功率跟我们的网络支持有什么关系。目前我们有三个运营商，阿里巴巴，以及联通和移动，还有3G和4G的，发现也是全局的。
所以可以非常明显的判断我们的影响是全网范围内的，可以判断出是我们后端的应用服务可能出现了问题。我们可以根据刚才接到报警的API的名称到我们对应的应用监控的接口调用里面找。在异常分析里面直接点击可以查看到刚才的时间段内有异常的报警情况。异常类型是double RPC的异常，异常信息是调用了RPC的服务，调不通，然后进行了三次的重试，在刚才的时间段内错误数是八次。点击之后可以看到发生异常的详细链路信息。
随便点击一个trace链路，发现我们的请求进来之后发生了图中的方法调用。红色标注的是发生异常的节点信息，我们根据红色的信息很明显的发现接口的请求成功率下降是由于调用了RPC服务，然后是RPC服务底层出现了问题，而且还可以找到RPC服务的ip地址。也能找到它的端口。我们现在可以很明显的找到刚才报警的接口依赖的哪个应用出现问题，是哪个应用下面哪个ip哪个端口出现了问题。下面到这个应用查看是不是RPC服务挂了，把可能出现的应用的异常恢复好。
检查完之后发现RPC确实挂了，重启之后可以看看前端的满意度，访问速度都是没有异常的，PV，UV也正常，但是发现API的请求成功率已经开始呈现上升的趋势。
那么到刚刚出现问题的API中看看，发现由刚才的百分之十几上升到百分之九十几了。从多个纬度，地理，终端，网络分析发现也已经恢复了。这是从前端进行分析。
从后端看看是否恢复，找到刚刚有问题的分类的接口。最近的时间段异常是没有再次出现的。底层所依赖的RPC也没有异常。也就是说现在前端和后端底层所依赖的服务都是正常的，没有任何问题。
上面演示的是Web类的网站从前端到应用的异常定界，定位的详细情况。假如不是Web类的用户，我们也提供应用总览的界面，如下图。上面是应用提供服务的请求量，时长等，以及应用所依赖服务的请求量，时长，应用自身的负载的CPU，memory。一个很贴心的设计是所有图都是共轴的，鼠标在某个时间点，所有的y轴都是联动的。可以以时间作为剖面，看到我的上游，我自己，我的依赖的健康情况是什么样的。同时在下面会显示出哪些接口是慢调用状态。我们可以通过一个界面快速的定位出哪些地方出现问题。
2.单点问题定位
大家有没有遇到这样的场景，运维中很多曲线其实是看不出来问题的，但是VIP用户出问题了。就所谓黄金指标看起来波澜不惊，但是VIP用户已经很伤心了。那怎么办呢，下面来看第二段演示。
有一个用户在宠物网站上买了一只猫，然后下单，下单失败，重试几次还是不行。针对这种问题，发现前端的指标都正常，那么这就引出了ARMS全新的一个功能，全系排查功能。帮助把业务日志和链路日志进行关联，根据用户的信息找到在出现问题的时间段内链路的信息。下图可以发现有两个红色的点点出现了问题。
点击进去发现这是用户调用了下单支付的接口，这时候报错了。
点击方法栈之后可以看到在调用下单接口时报错，在扩展信息里看到我们的网站是国际的，用户使用了国内的优惠券，这是不支持的，所以导致了用户下单失败。
所以通过全系排查，对于单点的用户我们也可以一下子定位到问题。这样对于普遍出现的问题和单点出现的问题，ARMS都可以很好的定位问题。
3.大内存的解决方案
另外ARMS也发布了一个JVM大内存的解决方案。下图是宠物网站应用的界面，我们在最新版本的ARMS中推出了dump的功能。我们可以新建一个快照，这个快照下面的ip是表征这个应用下面所有应用的节点。随机选择一个ip，进行dump操作。可以看到现在内存中的常驻内存对象，第二个是目前应用里面比较大的对象占用了多少内存，内存的百分比。这对于OOM的问题是非常有用的，从此不再需要繁琐的排查仅需一步，就可以达到目的。
三、后续功能
ARMS后续的一些严演进方向，首先是全面接入OpenTracing，这是业界的标准。C++，python等语言都可以用OpenTracing接入到我们的ARMS系统中。第二个，我们会支持自定义方法的监控，你的任意的方法都可以加入到我们的调用链中，在调用时呈现方法的应用。第三个，我们会做智能的线程分析，当你的线程比较卡的时候自动帮你抓jstack的个数，jstack时间的异常，也可以帮你看出哪些调用是慢调用等等。
我们的愿景是让天下没有难定位的问题，我们希望ARMS可以帮助用户提供问题定位的效率，降低定位问题的时间成本，人力成本。业务在前面开疆踏土，我们在后面为你负重前行！
本文由云栖志愿小组董黎明整理
