“端到端”应用性能管理的不一样采样方法

云智慧全栈应用性能管理解决方案是一套面向企业实际业务的端到端总体解决方案，其中IT数据的端到端采集和展示是云智慧领先于国内其余APM产品的重要特性之一，那么咱们是如何进行数据采样的，又是如何在“端到端”应用性能管理中知足用户对业务数据性能衡量呢？本文将为您一一道来。
首先理解一下咱们对“端到端”的定义，“端到端”就是不少年前业内就在提的End2End，如今业内几个APM厂商在云智慧提出端到端概念以后，也在这么吆喝。端到端有不少种理解，咱们的理解是：从终端用户出发，将从Request到Response整个链路中涉及到的全部数据，有效地串接起来，这样的数据才是真正的端到端，而不是将数据按照时间序列进行简单地罗列展示。

咱们从上面的软硬件模型中能够看到，一个用户请求从前到后，通过了N多的节点才最终返回数据并展示在用户面前，相信不少有经验的开发和运维都曾经想，怎样有效地将从用户请求开始，将请求链路中的数据都采集到，而且有效地关联起来。
下面就为您剖析一下“采样”对于“端到端”应用性能管理的意义和实现。

为何要采样？

采样这个事提及来是最有意思的，有数学基础或作过计算机研发的都会很是熟悉。基本上，全部有关数据统计或分析的场景，都离开采样。
采样最直接的目的有两个：减小计算量和下降描述难度。
采样方法有很是多种，最简单的，不管哪种语言，确定有一个random函数，对其施以随机种子，而后综合时间 / CPU即时频率 / 内存地址等等信息，那么出来的便是一个采样值。像一些profile工具，开始执行的开关就是用这种方式，好比facebook开源的xhprof就很是典型。
采样还能够人为指定样本，这也是一种常见的作法。好比，直接指定某一个特定标识，如时间，ip，或进程id，等有很是明确特指意义的属性。如程序猿们在开发过程当中，对一次具体请求的debug过程，很是典型。
在APM厂商中，广泛采用这样一种采样算法来计算Apdex。（注：云智慧并未采用这个采样算法，后文会解释缘由。）先看看什么是Apdex，它是Application Performance Index 应用性能指数的缩写，这个指数被其余的APM厂商奉为衡量应用性能的核心指标。它为用户对应用性能满意度进行量化，提供了一个测量标准。

之后提到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的计算首先定义一个标准量T，进而将待计算的样本以T为标准量划为三个区间。分别是：
 小于等于 1T， 为 Satisfactory （满意）
 大于1T，小于4T，为 Tolerating （ 容忍 ）
 大于等于4T，为 Frustrated （ 失望 ）
此时，Apdex ＝ ( 1 x 满意 ＋ 0.5 x 容忍 ＋ 0 x 失望 ) / 样本数
有没有注意到一点，失望样本被忽略了。而满意样本，即钟曲线最左侧的极限值，也未被绝对平均。从计算公式中咱们能够看到，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的hash key；
步骤2、判断请求是否为首次访问，如果否，则执行步骤三，若否是，则执行步骤四；
步骤3、开始追踪本次请求，采集本次请求的哈希值，并将这次采集的哈希值记录在散列图中；
步骤4、判断是否容许追踪，若否，则执行步骤五，如果，则执行步骤六；
步骤5、不追踪，并于本次请求结束后，判断是否将本次请求采集的哈希值记录在Trace队列中；
步骤6、判断是否已经实施过追踪，如果，则不追踪，若否，则执行步骤七；
步骤7、启动追踪，并将被追踪的次数记录于Trace队列中。

这样作的优点是什么呢？

首先，咱们没有漏掉任何一个请求，不管快或慢，在出现问题的一刹那，立刻开始关注这组请求，当它再次发生，则马上进行全栈的追踪。
其次，自然地将数据请求进行分组，不依据时间分组，而是依据请求事务进行分组；
最后，在不影响全栈追踪的前提下，很好地解决了性能问题。
这个算法默认是关闭的，在用户须要的时候，作细微的参数配置，就能够打开这个算法。也就是说，默认咱们连这个算法都没有开启。

为何不采样呢？

由于咱们信奉的金典是，基于业务的端到端。只要想作到端到端的业务追踪，任何形式的采样，均可能直接致使某一个关键请求的缺失。或者换句话说，咱们也在采样，只不过样本覆盖率是100%。这其实直接给咱们带来了两个极大的挑战：

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

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

为何不负责任，客户的原话是这样的：我知道这就是个人TOP10，而后呢？每天说这个TOP10，周周说，月月说，这并不能反映个人应用健康状态。咱们须要关注的是，某段时间内，请求次数又多，响应时间又相对较慢的这些事务。
因而咱们提出了三个维度的交叉：单位时间，请求次数，响应时间。首先构思这样一幅矩阵图，X轴是时间，左Y轴是请求次数，右Y轴是平均响应时间。这些事务以向量散落在这个象限内，那么咱们能够得出，距离XY的左原点，距离最远的，便是咱们所关注的。
演化以后，咱们获得了这个柱状的散点图。

咱们的产品和技术还在不停地演进中，相信会愈来愈趋合最根本最真实的需求。

原文连接：https://mp.weixin.qq.com/s?__biz=MzAwNzA0NTMzMQ==&mid=404008341&idx=1&sn=e6f85d5f65c1907b8f8bc603cb2221f6&scene=1&srcid=0308494B6co4CmtYwnUqhta3&pass_ticket=RYds8wv0BtoOPcvXL3pvNIo1R%2BGx1RkNTkl1s7iqLNUIbf9uRHCVs6aJ%2FHsiTpKN#rd