浅述APM采样与端到端

极牛技术实践分享活动

极牛技术实践分享系列活动是极牛联合顶级VC、技术专家，为企业、技术人提供的一种系统的线上技术分享活动。

每期不一样的技术主题，和行业专家深度探讨，专一解决技术实践难点，推进技术创新，每两周的周三20点正式开课。欢迎各个机构、企业、行业专家、技术人报名参加。

主题大纲

浅述APM采样与端到端

1.何为APM

2.何为端到端

3.何为Apdex

1. 采样的作法与弊端

嘉宾介绍

高驰涛(Neeke)，PHP官方PECL开发组成员，SeasLog做者，云智慧高级架构师。9年研发管理经验，早期从事大规模企业信息化研发架构，09年涉足互联网数字营销领域并深刻研究架构与性能优化。2014年加入云智慧，致力于APM产品的架构与研发。热衷开源。崇尚敏捷，高效，GettingReal。

图片描述

首先，“何为APM”。

相信你们最近几年应该已经逐步地在了解APM这个行业

APM ＝ ApplicationPerformance Management.

也即：应用性能管理

这里有一段较正式地解释说明： APM is the monitoring and management of performance andavailability of software applications.

http://en.wikipedia.org/wiki/...

APM关注的是应用和软件的性能和可用性的监控以及管理。

随着软件和应用的发展，应用性能已经愈来愈受到传统IT和互联网企业的关注。

咱们来看一幅图，聊一下为何须要APM。这是一个普通网站或应用的架构模型。

从箭头的指向，咱们能够看到，用户的请求穿透了不少个节点，最终从服务器取得资源，并呈现到用户的面前。这其中任何一个节点出现了问题，均可能直接或间接致使用户直观感受的“应用不可响应”。

而要最终确认是哪个节点的问题，正是全部互联网运维和研发人员，天天面临的问题。

云智慧通过抽象，得出了一个更简单的模型

上面的模型归纳了一个应用的架构，以及APM所关注的几个点：

1. 终端用户体验

2. 应用架构映射

3. 应用事务分析

4. 深度应用诊断

5. 数据分析报告

这5个层次，贯穿了上面的模型中的几个抽象层：User，CDN，Server，Code，Data Store，Physical.

而APM所解决的，正是一个应用管理过程当中因为性能而产生的问题和损失的监控，定位，解决和管理。

咱们引出今天的第二个问题，“何为端到端”。咱们继续把视点放在这个抽象图上：

抛出一个问题： 若是用户报告说，网站或应用，不能登陆，可能会是这个抽象图中的哪层的缘由呢？

咱们对着几个层来思考：

User： 会不会是用户本身的网络不稳定？

CDN： 会不会是CDN厂商节点故障？

Firewall：（这个不便多说。。）

Server： 会不会是WebServer负载太高？

Code:会不会是今天有一个上线，致使了登陆业务bug？

DataStore： 会不会是DB故障，或者有慢SQL？

Physical： 这个最直接，会不会是服务器磁盘或CPU坏掉了？

再抛出一个问题：有没有一个办法，能够把这个报告问题的用户，遇到的问题现象完整地呈现出来，即：用一条数据，把用户的浏览器表现，CDN的表现，Server的表现，Code的执行，SQL的执行，物理层的监控数据，串接起来呈现呢？

这就是云智慧所理解的"End to End"，即“端到端”。

第二个问题的答案是确定的，咱们正在就此努力，前几天咱们刚刚开过一个全栈性能监控的发布会。

云智慧全栈应用性能管理解决方案是一套面向企业实际业务的端到端总体解决方案，其中IT数据的端到端采集和展示是云智慧领先于国内其余APM产品的重要特性之一，那么咱们是如何进行数据采样的，又是如何在“端到端”应用性能管理中知足用户对业务数据性能衡量呢？

端到端有不少种理解，咱们的理解是：从终端用户出发，将从Request到Response整个链路中涉及到的全部数据，有效地串接起来，这样的数据才是真正的端到端，而不是将数据按照时间序列进行简单地罗列展示。

何为Apdex

首先，须要确认一点，Apdex，是一个采样算法的表现，也是一个被其余APM厂商奉为衡量应用性能核心指标的量化标准。采样这个事提及来是最有意思的，有数学基础或作过计算机研发的都会很是熟悉。基本上，全部有关数据统计或分析的场景，都离不开采样。

采样最直接的目的有两个：减小计算量和下降描述难度。

采样方法有很是多种，最简单的，不管哪种语言，确定有一个random函数，对其施以随机种子，而后综合时间 / CPU即时频率 / 内存地址等等信息，那么出来的便是一个采样值。像一些profile工具，开始执行的开关就是用这种方式，好比facebook开源的xhprof就很是典型。

采样还能够人为指定样本，这也是一种常见的作法。好比，直接指定某一个特定标识，如时间，ip，或进程id，等有很是明确特指意义的属性。如程序猿们在开发过程当中，对一次具体请求的debug过程，也很是典型。

在APM厂商中，广泛采用这样一种采样算法来计算Apdex（Application Performance Index）.

之后提到Apdex，你们用这个图来解释：Apdex值是0 －1的区间值，每一个区间对应一个评价：1~0.94是优秀，0.94~0.85是良好，0.85~0.70是尚可，0.70~0.50是差评，低于0.50的Apdex值是用户没法接受的。

这个值，怎么计算呢？ Apdex算法起源于对一个传统数据方法的质疑，这个传统方法就是正态分布，也叫高斯分布。 正态分布的定义：

正态分布应用很是普遍，好比用来对比班级之间的成绩，或用来对比某两组数据的属性差别时，会用它来做为衡量标准。

正态分布很是的标准和简单，但它有三个明显的问题：

衡量时，使用的是平均值，所以，它假定了“占主导地位的值是最重要的”。

计算时，进一步取向平均的值是不重要的，由于，它假定了那些值 “偏离了规范”。

计算时，它过度夸大了曲线两端的极限值，由于，它假定了“分布在两端的数据会被平均，而影响其余值”。

这三个问题是正态分布在数据统计时存在的明显缺陷。而Apdex的算法针对以上三个问题，做了一个演进。Apdex ＝ ( 1 x 满意 ＋0.5 x 容忍 ＋ 0 x 失望 ) / 样本数

Apdex的计算首先定义一个标准量T，进而将待计算的样本以T为标准量划为三个区间。分别是： 小于等于 1T， 为 Satisfactory （满意） 大于1T，小于4T，为 Tolerating （ 容忍 ） 大于等于4T，为 Frustrated （ 失望 ）

有没有注意到一点，失望样本被忽略了。而满意样本，即钟曲线最左侧的极限值，也未被绝对平均。从计算公式中咱们能够看到，Apdex假定你的样本就是属于标准正态分布的，而且减轻曲线两端对衡量值的影响。 首先声明标量T ＝ 2s

咱们套一下上面的公式： 假定样本为：小于2s的请求次数为10次，满意； 大于2s，小于8s的请求次数为20次，容忍；大于等于8s的请求次数为10次，失望。 那么获得 Apdex = ( 1 x 10 + 0.5 x 20 + 0 x 10 ) / 40 = 0.5

拿这个标尺看一下0.5在哪里，已经接近“没法接受”了。因此，若是用Apdex来衡量刚才这组样本，则认为，这个应用已经要挂了。

可是，我这里有一个问题： 这个被广大APM厂商奉为金典的标准，合理吗？

我再举一个例子以说明是否合理。假如上面计算的不是响应时间，而是一群人的血压。

若是样本数据是同样的，即：血压满意的为10, 血压可容忍的为20, 血压超高使人失望的为10。那么得出的这个0.5的结果，则意味着：这群人已经接近了“没法接受”状态，快挂了，须要集体用药。

是的，这个值只能说明一个概况，而并不能反映真实的现状。由于它作到了简单的总体衡量，而忽略了病患。不能说Apdex不合理，只是在具象的衡量上，标准并不能表明真实状态。

接下来看看云智慧APM产品透视宝对数据采样的方案，你们能够对比一下其优劣。 首先能够肯定的是，云智慧的数据采样算法并不是统计方法。

这个方法的设计思路是：充分覆盖全部的URI请求的前提下，关注超出响应阈值的请求。

步骤1、所有或部分请求经过hash算法，取得当前URI的hashkey；

步骤2、判断请求是否为首次访问，如果否，则执行；

步骤3、若否是，则执行步骤四；

步骤3、开始追踪本次请求，采集本次请求的哈希值，并将这次采集的哈希值记录在散列图中；步骤4、判断是否容许追踪，若否，则执行步骤五，如果，则执行步骤六；

步骤5、不追踪，并于本次请求结束后，判断是否将本次请求采集的哈希值记录在Trace队列中；

步骤6、判断是否已经实施过追踪，如果，则不追踪，若否，则执行步骤七；

步骤7、启动追踪，并将被追踪的次数记录于Trace队列中。

这样作的优点是什么呢？ 首先，咱们没有漏掉任何一个请求，不管快或慢，在出现问题的一刹那，立刻开始关注这组请求，当它再次发生，则马上进行全栈的追踪。其次，自然地将数据请求进行分组，不依据时间分组，而是依据请求事务进行分组； 最后，在不影响全栈追踪的前提下，很好地解决了性能问题。

这个算法默认是关闭的，在用户须要的时候，作细微的参数配置，就能够打开这个算法。也就是说，默认咱们连这个算法都没有开启。

没有开启时，其实会是全数据采样，也即样本率为100% 为何不采样呢？ 由于咱们信奉的金典是，基于业务的端到端。 只要想作到端到端的业务追踪，任何形式的采样，均可能直接致使某一个关键请求的缺失。或者换句话说，咱们也在采样，只不过样本覆盖率是100%。 这个算法你们能够参考一下，或许会对相相似的场景，有一些借鉴意义。

这其实直接给咱们带来了两个极大的挑战：

1. 如何保持性能，包括数据采集性能，和数据处理性能 咱们确实为性能付诸了极大的努力，好比数据格式，数据结构，传输协议，数据压缩，等等，自豪地告诉你们，咱们基本能够保证对用户低于5%的性能损耗。若是打开了上面所述的算法开关，则能够将性能损耗有效下降到1%如下。

1. 取得了大量的数据，如何对这海量数据进行分析

举个例子：如何对海量请求的事务数据进行响应时间的分析。请求的事务数据：一个应用中的事务基本是不可枚举的，由于有各类参数的存在；那么在各类参数存在的前提上，怎么对响应时间进行分析？ 这方面各厂商的作法是对这段时间内请求时间最慢的事务进行排序，列出TOP10，这是至关不负责任的作法。

为何不负责任，客户的原话是这样的：我知道这就是个人TOP10，而后呢？每天说这个TOP10，周周说，月月说，这并不能反映个人应用健康状态。咱们须要关注的是，某段时间内，请求次数又多，响应时间又相对较慢的这些事务。

因而咱们提出了三个维度的交叉：单位时间，请求次数，响应时间。首先构思这样一幅矩阵图，X轴是时间，左Y轴是请求次数，右Y轴是平均响应时间。 这些事务以向量散落在这个象限内，那么咱们能够得出，距离XY的左原点，距离最远的，便是咱们所关注的。演化以后，咱们获得了这个柱状的散点图。

由每次请求向下深钻，则能够获得每一个请求的“端到端”数据呈现：

Q&A

Q1：如何经过APM定位到线上服务瓶颈在哪里？

A1：APM所要求的几个点中，有比较重要的一个点，便是应用架构映射。几乎全部的APM产品，都会知足这样的需求：自动映射服务中的架构结构和性能表现。 这里展现一下云智慧的应用架构映射：

注意右上角：

咱们能够观察到这个应用，有27%的请求很是慢。 这些请求以及相对应的sql都在对应的视图中有表现：咱们点选第一个表的操做统计。

Q2：若是服务器压力增长，咱们能不能经过简单的加机器来解决，须要加多少台机器，这个场景下，怎么使用APM？

A2：对负载的解决，最直接的方式确实是增长机器，分担负载。此时，APM带来的应用是，准确地评估现有集群中机器的负载状况和对应的请求。咱们能够从APM产品中“主机”与“应用”交叉的维度来分析这个问题。以透视宝为例：一眼能够看到，目前集群中，主机的负载能力和所承担的应用服务状况。此时，须要对哪一个应用添加机器，添加多少机器，能够缓解多少负载压力，均可以有数据进行佐证。

Q3：APM经过探针侵入式方式来收集诊断数据，对企业而言敏感和隐私数据担忧泄露，这个问题APM厂商怎么来处理？

A3：众所周知，APM的技术门槛相对较高，探针的研发目前仍然是一个入门瓶颈，而这同时，也意味着，企业所选择的服务厂商相对比较少，不会像普通建站业务那样处处都是，APM厂商的服务相对质量也是更高的；

基本上全部厂商在进行数据采集和数据传输的过程当中都会采用压缩，或二进制传输的方式，来下降数据泄露风险；

云智慧在带来高质量服务和高私密传输的处理作法上，同时提供私有化部署，即将saas服务转化为私有云，来解决企业更高的数据安全需求。同时咱们拥有专业的实施团队，能够充分地保证更高质量的私有云服务。

Q4：请问性能达5%是靠算法实现吗？监控宝是怎样采集不一样语法的性能?

A4：性能5%的影响，不是靠算法实现的。而是靠更快的数据序列化方法和更精准的类hook完成。若是采用算法，能够承诺在1%如下的性能影响；

不一样语法，应该是指不一样语言吧； 咱们经过不一样语言的容器hook或字节码修改，来进行准确的数据拦截和采集， 目前提供的语言Agent包含PHP,Java,DotNet,Python，基本能够覆盖95%以上的IT企业和互联网企业需求。

Q5：对于内部代码监控是采用aop方式进行切面采集吗，是用开源组件仍是所有自研？在这一过程当中有哪些坑，已经trouble_shooting了?

A5：首先确认一点，咱们在Java语言层面，并不是使用aop进行切面采集；

而是经过在语言启动时，动态修改字节码来完成，其实交给jvm执行的，已是被咱们Agent Hook以后的代码了；

Hook内容包括类方法的执行开始和执行结束； 拦截到的是类和方法的执行顺序和执行参数，执行时间；Hook内容包括类方法的执行开始和执行结束； 拦截到的是类和方法的执行顺序和执行参数，执行时间；

这一过程当中有很多坑，咱们目前发现的坑已经填得差很少了，同时在客户使用过程当中也可能会有坑存在，但因为是自研，因此处理速度很是及时有效；

举一个坑的例子，因为修改字节码交给jvm，在大量代码的项目中，启动时间会比较长，咱们采起的作法是，默认关注一些类和资源driver，以减小这部分的启动时间消耗，剩余的类“白名单”和“黑名单”能够由用户进行配置便可。

＊此分享由PHP官方PECL高驰涛(Neeke)开发组成员在极牛线上技术分享群里所分享，有意加入的技术朋友，请在极牛公众号(ji-niu)里回复“技术分享”。

下期预告

分享时间

2016年11月9日 晚8:00

分享形式

线上微信群图文直播

嘉宾介绍

方坤、9年服务器开发和云计算领域解决方案经验.曾任Intel亚太研发公司软件开发工程师和UCloud云计算高级解决方案架构师，熟悉互联网领域多种应用场景，有丰富的初创企业IT解决方案项目设计经验。目前在AWS中国负责推广针对初创企业的最佳云计算架构实践。

主题大纲：

从零到千万用户的云端(AWS)基础架构最佳实践

1. 云计算服务（AWS）的介绍

2. 随着从0到千万用户的业务增加，经过aws的不一样服务轻松地实现高性能和高可用的基础架构。