剑客
关注科技互联网

APM 数据采样与端到端详解

据云智慧统计,APM从客户端采集的性能数据可能占到业务数据的50%,而企业要做到从Request到Response整个链路中涉及到的所有数据的准确采集,并进行有效串接,进而实现真正的端到端,绝非一件易事。

那么云智慧是如何进行APM数据采样的,又是如何在“端到端”应用性能管理中满足用户对业务数据的高性能分析的呢?在全球运维大会的APM专场上,云智慧首席架构师高驰涛先生为你揭晓APM背后的大数据奥秘。

今天是APM专场,相信大家对APM都有一定了解,我就从APM的数据采样与端到端的几个层面进行分享,这也是云智慧近几年在服务和解决客户需求过程中的实践结果。

APM和大数据

APM 数据采样与端到端详解 在APM使用过程中有一个非常明显的特征,就是可采集的数据量非常大,大到不可想象,看看上面这个机房,谁能准确说出里面每天有多少数据流转,而这只是几台简单的机柜。我们对客户的数据做过统计,在互联网上,APM从客户端采集回来的数据能够占到企业业务数据的50%以上,这就意味着如果采集数据非常详细,很可能会比原始业务数据量还要庞大。假设业务数据带宽是2T,为了支撑APM又要上2T的带宽,支撑业务的服务器可能要三百台,现在要最少再额外增加150台支撑APM,这在数据处理方面是个很大的挑战,而APM并不是企业的核心业务,却要消耗这么多的计算与存储资源,这是数据未作采样时的现状。

什么是APM,从字面上看就是“应用+性能+管理”,前面两位嘉宾聊的都是APM的范畴,他们聊的核心就是应用性能,注意不是业务而是性能。APM后面还有一个词是管理,就是从业务的角度理解这个性能数据,比如说一个崩溃或者说一个卡顿会影响多少用户,影响的用户会给企业造成多少损失,这就是APM对业务价值方面的体现,也是我们正在努力和实践的方向。

我们为什么要用APM,今天有腾讯的嘉宾举个在手机上玩CF游戏的例子,一个玩家在玩CF,最近常常因为应用运行卡顿被人打死,即便买了好枪、好装备还是打不过别人,用户必然会投诉,投诉之后客服会根据系统的知识库问一大堆有的没的问题,然后承诺玩家马上安排运维检查系统,最后往往不了了之。在企业业务人员在服务用户的过程中往往缺少一个工具或者一个平台,及时、准确的发现用户问题,甚至定位到具体用户、某一条SQL和某一段关键代码。

APM有两大好处,一个是可以提升工作效率,减少和用户无效沟通的时间;另一个就是及时发现和准确定位问题。 因为运行在互联网上的业务系统,往往是用户最先感知到系统故障,如果能在接到用户反馈的第一时间及时发现和解决问题,就会大大降低故障带来的业务损失。

举个简单的例子,云智慧有个客户的生产系统故障导致停服两个小时,造成了好几千万的损失,后台运维的解决办法非常简单,把服务切了一下,重新启了一套集群,把业务切过去,现场保留下来了,之后用了一个星期的时间发现原来是内存泄露。后来在云智慧透视宝的帮助下,直接在测试系统上重现了这个问题,并且在10分钟内准确地定位到了内存泄露的位置,使用APM可以有效地缩短问题的发现时间,并有效解决,避免再次发生类似问题。

为什么说APM是大数据呢?我们知道大数据有着非常明确的4V特征:

✔ 数据量大(Volume),我们的一个典型用户,每天在APM系统中产生的数据存储量超过了500G;

✔  种类繁多(Variety),例如目前我们已知的移动端APM指标超过三百多个,维度更多;

✔ 高速(Velocity),数据产生的速度和消费的速度都是非常恐怖的;

✔  数据价值(Value),单条数据价低,需要综合大量数据进行多纬度综合分析,以得出数据现状和趋势;

这是大数据的典型特征,而APM数据恰好符合这些特征。

Apdex的得失

面对这么大的数据量应该怎么做,最直接有效的方式就是采样。为什么要做采样,一个是可以有效降低数据量,从数据价值角度来说我们不希望一条数据漏掉,但当大量数据进来以后,如果为了描述一天的数据量需要花费几天的时间,这就意味着永远无法准确描述。

APM 数据采样与端到端详解 怎么处理呢?大家看这个Jmeter的请求散点图,在上面标注密密麻麻的点,一个请求一个点位,根据时间维度和响应时间不停地在画布上面点。这时候很难点到每个准确的点,只是比较客观的描述一个事情,就像是一篇流水账,但是不能描述整个应用,也不能描述这个应用是什么样子。

APM 数据采样与端到端详解 利用这个散点图可以做出这样的一个二维的柱状图,同一个柱状图上又有面积又有高度又有时间,这样好几个维度交叉起来做一个二维图,右侧是从大量不同维度的数据里把几个指标通过APDEX算法融合成一个Apdex指标。

APM 数据采样与端到端详解 APDEX就是应用性能指标,是APM领域共同遵循的一个规范标准,这个算法不仅限于应用性能领域,在很多我们想要用同一个指标描述大量数据的时候都可以用。我们先看看为什么要用APDEX,这张图是高斯分布,也就是正态分布图,可以把一个指标的散点图画到这个地方,形成一张高斯分布图,它的波动曲线上波峰越高说明性能越差,越平缓说明性能越好。

但这种描述方式有个明显的缺点,很容易忽略两极,这个图两极是响应速度最快或者最慢的情况,而高斯分布更关注中庸状态,假设非中庸的数据都是异常数据,这就意味着描述的时候其实把看起来非常棒和非常差的状态丢弃了,只留下中庸数据。

APM 数据采样与端到端详解 APDEX是对高斯分布的一个改良,这个柱是一个标尺,这个标尺最上面1.00T,T是APDEX的一个单位,APDEX是从0到1描述一项指标,比如计算应用在某一天的平均响应时间,假设一共有四十个请求,平均响应时间是两秒,低于两秒的时候设为一,从零到两秒是十个请求计成一,从两秒到八秒有二十个计成0.5,另外十个大于八秒的计成零,得到APDEX的计算结果是(1×10+0.5×20+0×10)÷40=0.75。用这个方法可以描述应用在一天内的响应时间指标是0.75,把0.75放在这个柱子上看还可接受,如果低于0.5是完全不可接受,可能是有故障。这就是APDEX算法,可以用一个值去描述应用在一段时间内大量采样数据的整体状况。

APDEX有什么问题呢?以血压为例子,比如说高压120是标杆,有40个人进行测量,这40个人像刚才说的,优秀的10个,中庸的20个,血压偏高已经不行的人占了10个,描述40个人的健康状况得出一个还不错的数据0.75。这个时候就有一个非常可怕的问题,用0.75去描述这个人群是没问题的,但是忽略了最后大于四倍标量时候的那部分数据,也就是说那10个快要死的人根本没管他,这是APDEX最大的问题。

APDEX的另一个问题是原始数据和端到端的缺失,因为APDEX是通过数据流动过程中直接计算出指标来节省大量存储的,不但原始数据没了,端到端数据也被抛弃了。举一个更直接的例子,如果应用系统的数据库连接池出现了问题,此时整个应用接受到的请求在判断连接池出现问题后,可能会快速地抛出一个异常并响应前端一个静态页,此时整个应用响应非常快速,APDEX值也会非常的理想,而整个应用的性能其实是非常非常差的,因为正常的业务全部被中断了。

真正的端到端APM采样

真正的端到端是能够串联各个请求从客户端到后面的网络、DB、物理层、外部服务、文件操作的整个链路的数据,数据是不能存在数据孤岛的,如果可以通过一个ID号或者是时间维度把数据进行串接,这才是真正的端到端。

APM 数据采样与端到端详解

这张图的中间一层就是端到端链路,端到端的实现就是在每个点上的这么多服务、组件上采集数据,同时由一个惟一标识在各个服务组件上采集的数据中作出传递; 在分析客户端用户行为的同时,还可以通过一个客户端的API调用,直接追踪到API对应后端执行的SQL和执行的代码栈,以及同时刻服务器的CPU/内存/网络/IO等系统状态。

其中最大的难题是采样,在使用了APDEX的同时还要实现端到端,这其实就是一个矛盾,既要准确地描述应用的情况,又想降低描述的难度,而且一条数据都不丢,这是一个非常大的挑战。

APM 数据采样与端到端详解

这个时候有很多做法,这张图是为客户测试时的真实机器负载数据图,TPS降低4%,CPU资源使用率在5%以下。这是怎么做到的呢?我们在数据传输以及数据采集的地方做了大量的工作。比如说系统或接口有问题,问题可能在哪里?根据研发和运维经验很有可能是在进行操作或者有了网络请求,还有一种可能情况是内存和CPU的资源情况,知道这些条件之后,就可以有针对的采集数据,而不是一股脑全部采集。还有就是在不丢数据的前提下,要把一款日PV达到百万级的应用覆盖全,也是一个很大的挑战。

APM 数据采样与端到端详解

这是云智慧的端到端数据采集原理图,我们的目标是全量采集,同时要关注各个响应阈值,时间的响应阈值、CPU和内存响应阈值,还有错误和异常。为什么说是错误和异常?因为通常意义上的APDEX是对响应时间这个指标进行计算,做规定的描述。

APM 数据采样与端到端详解

比如说通过一个接口或者通过一个页面访问一条新闻,发一个请求,获取一篇文章,如果响应时间一百毫秒之内非常棒,但很有可能响应时间一百毫秒的时候要连接一次,连接一次之后要再写一次缓存或者写一个点击量什么的操作,这个时候返回这是一个正常的业务,但是很有可能没有连上,产生了错误或者异常,而响应时间是90毫秒,我们能说这个90毫秒的响应请求比一百毫秒更好吗?所以单纯用响应时间这个指标去衡量性能是有问题的,我们应该在关注响应时间指标的同时关注异常指标,而异常指标比正常指标更重要,在进行APDEX衡量的时候一定要进行异常指标的关注。

APM 数据采样与端到端详解

APM 数据采样与端到端详解

最后举个APM应用实例,这是监控宝在使用前和使用后的对比,右上角是响应时间占比,下面有访问时间等等,大家可以看到右上角黄色部分就是缓慢响应,其实会发现应用有很多问题,缓慢数量大于了90%左右,这是错误和异常的指标,优化数据满眼都是绿色,查询的响应时间明显降下来了,这就是响应时间和错误相交叉的一个指标表现。通过事务快照还可以查看每个具体请求的代码运行栈/SQL/API请求/请求参数等指标,如果有错误或异常还可以快速地查看错误或异常的详情。

Q:APDEX是APM行业内的标准,还是云智慧多年来的经验总结?

高驰涛:APDEX定义是来自于APM这个词,这个词是从APM出现以后才有的,而APDEX也是许多专业分析师提出来的标准。刚才说的四倍标量给定义0.5,大于四倍给零,这个其实没有约定,但是大家一直是这么做的,算一个未成文的约定。

刚才说了关注几个采样,关注响应时间、响应阈值,响应阈值包括访问时间,这是一个关注指标,在采集的时候首先可以确定连接,不管连接有多快、多慢、有没有出错,都必须要采集,因为这是未知的非常关键的操作,关键操作一定要采集。还有对于正常操作,比如说没有发生错误也没有发生异常,CPU和内存正常,这个时候如果响应时间的阈值低于一毫秒的方法我们会抛弃掉。

云智慧所有的设计都要求不让用户改一行代码,无工程侵入;如果要进行编码才能获取数据的话,是完全没有必要使用第三方平台的,开发者自己就可以轻松地实现。云智慧从无到有是必须要冷部署的,从有到暂停或者说从有到卸载是可以热部署的。

高驰涛(Neeke Gao),云智慧首席架构师,PHP/PECL开发组成员,同时也是PECL/SeasLog,PECL/JsonNet,GoCrab等多项开源软件的作者。10年+研发管理经验,早期从事大规模企业信息化架构研发,09年涉足互联网数字营销领域并深入研究架构与性能优化。2014年加入云智慧,致力于 APM 产品的架构研发,崇尚敏捷,高效,GettingReal。

APM 数据采样与端到端详解

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址