极牛技术实践分享活动
极牛技术实践分享系列活动是极牛联合顶级VC、技术专家，为企业、技术人提供的一种系统的线上技术分享活动。
每期不同的技术主题，和行业专家深度探讨，专注解决技术实践难点，推动技术创新，每两周的周三20点正式开课。欢迎各个机构、企业、行业专家、技术人报名参加。
主题大纲
浅述APM采样与端到端
1.何为APM
2.何为端到端
3.何为Apdex
采样的做法与弊端
嘉宾介绍
高驰涛(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所关注的几个点：
终端用户体验
应用架构映射
应用事务分析
深度应用诊断
数据分析报告
这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请求的前提下，关注超出响应阈值的请求。
步骤一、全部或部分请求通过hash算法，取得当前URI的hashkey；
步骤二、判断请求是否为首次访问，若是否，则执行；
步骤三、若否是，则执行步骤四；
步骤三、开始追踪本次请求，采集本次请求的哈希值，并将此次采集的哈希值记录在散列图中；步骤四、判断是否允许追踪，若否，则执行步骤五，若是，则执行步骤六；
步骤五、不追踪，并于本次请求结束后，判断是否将本次请求采集的哈希值记录在Trace队列中；
步骤六、判断是否已经实施过追踪，若是，则不追踪，若否，则执行步骤七；
步骤七、启动追踪，并将被追踪的次数记录于Trace队列中。
这样做的优势是什么呢？ 首先，我们没有漏掉任何一个请求，无论快或慢，在出现问题的一刹那，马上开始关注这组请求，当它再次发生，则立刻进行全栈的追踪。其次，天然地将数据请求进行分组，不依据时间分组，而是依据请求事务进行分组； 最后，在不影响全栈追踪的前提下，很好地解决了性能问题。
这个算法默认是关闭的，在用户需要的时候，做细微的参数配置，就可以打开这个算法。也就是说，默认我们连这个算法都没有开启。
没有开启时，其实会是全数据采样，也即样本率为100% 为什么不采样呢？ 因为我们信奉的金典是，基于业务的端到端。 只要想做到端到端的业务追踪，任何形式的采样，都可能直接导致某一个关键请求的缺失。或者换句话说，我们也在采样，只不过样本覆盖率是100%。 这个算法大家可以参考一下，或许会对相类似的场景，有一些借鉴意义。
这其实直接给我们带来了两个极大的挑战：
如何保持性能，包括数据采集性能，和数据处理性能 我们确实为性能付诸了极大的努力，比如数据格式，数据结构，传输协议，数据压缩，等等，自豪地告诉大家，我们基本可以保证对用户低于5%的性能损耗。如果打开了上面所述的算法开关，则可以将性能损耗有效降低到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)基础架构最佳实践
云计算服务（AWS）的介绍
随着从0到千万用户的业务增长，通过aws的不同服务轻松地实现高性能和高可用的基础架构。