这是一个创建于 2960 天前的主题，其中的信息可能已经有所发展或是发生改变。
高驰涛 云智慧首席架构师
本文整理自 GOPS2016 全球运维大会 • 上海站 APM 专场 云智慧首席架构师高驰涛的演讲。
高驰涛：今天咱们的专场是 APM 专场，我相信在座的其实对 APM 这个东西肯定是了解的，要不然不会过来， APM 我今天会从几个层面聊一下，因为今天的时间非常有限，也不占用大家太多的时间，我只就 APM 里面的一个小点和大家说一下，这个其实是我们的一些应用的实践，就是我们在 APM 这个行业里面的一些实践，其实像刚才这两位男神和丹姐聊的这个范围没有提到 APM ，其实就是做 APM 的事情。这个二维码是我的微信号，我本人是 PHP 开发组的成员，目前是在云智慧做架构师，说三个东西最后有一个小例子来总结一下。
APM 和大数据，大家既然过来了肯定了解 APM ，在 APM 和大家直接相关的日常工作中其实是有一个非常明显的一个点就是 APM 的数据量太大了，大到我们都想象不到的程度，大家看左侧的这个机房，这里面谁能准确地说出来每天有多少数据流转，这只是几台简单的机柜，如果到了互联网上，我不知道刚才腾讯的同事有没有统计过从客户端采集的数据每天希望采集的客户量有多少，针对业务的数据量比例是多少，我们是做过统计的，在我们很多客户那个地方经过验证我们发现 APM 从客户端采集回来的数据可能是占到你业务数据的 50%以上，就是说如果说采集的数据量非常详细的话，很可能会比你的原始业务量数据还要庞大。意味着很可能业务数据带宽是 2 个 T ，为了支撑 APM 又要上两个 T 的带宽，支撑业务的服务器可能三百台，现在要最少 150 台，这个在数据处理方面是很大的挑战，并不是核心业务，但是用了非常多的资源。
什么是 APM ，简单说一句， APM 就是应用、性能、管理，其实刚才这两位聊的都是 APM 的范畴。最主要的就是 APM 性能，是一个性能不是业务，大家注意不是业务是性能。后面还有一个词是管理，尝试从业务的角度理解这个性能数据，比如说一个崩溃或者说一个卡顿会影响多少用户，具体影响多少用户，影响的用户给我们带来了多少个损失，这就是尝试从业务的角度理解，这是简单的聊一下什么是 APM 。
我们为什么要用 APM ，很明显，其实就是大家看左侧的这张图，比如说刚才丹姐说的，有一个客户在付款或者说打 CF ，老是被人打死，因为他卡顿，后台可能我还买了好枪买了好装备，但是怎么打不过别人，我可能要投诉，投诉之后我们找，找到问题是大家的路由器的问题，如果说最后的解决很有可能是这样。其实我们在整个链路过程当中先问题，如果我们没有这样一个工具，或者说这样一个平台是很难准确发现问题的，使用 APM 不管是用已有的 APM 厂商的还是自己研发的，其实是很有作用的，一个是可以提升我们的工作效率，另外就是准确定位问题，一个比较简单的例子我待会儿会说，就是在客户那个地方，一个生产系统的故障，是要死人的那种故障，停服停了两个小时，造成了好几千万的损失，后台找问题，解决的时候非常简单，把服务切了一下，重新启了一套集群，把业务切过去，就是这样操作的，后来把现场保留下来了，用了一个星期的时间发现其实是内存泄露，他们用了一个星期的时间找到了问题，后来经过我们的帮助，我们重复在系统上重现了这个问题，借用于 APM 的一套工具，可以再不发生这种问题了。
我们为什么说是大数据，讲话说大数据大家应该知道有一个思维特征，非常明确的思维特征第一是数据量特别大，像洪水一样过来了，是正常的数据是很恐怖的，一个是数据量特别大，一个是种类特别繁多，目前我已知的移动端的 APM 指标，就有超过三百多个，最少要超过三百多个，维度可能更多，还有一个是价值链，单条价值非常低，这是大数据的明显特征，还有就是数据产生的速度快，这是思维特征。特别符合左侧的这个，一滴水没有什么，当起来之后特别大量的里面包含着各种泥沙各种什么东西，可能还有一个床什么的，这里 2012 电影里面的截图，一下子全过来了，这是大数据的典型特征， APM 的性能数据恰好符合这个特征。
我们面对那么大的数据量咱们有很多是做运营的，也有很多做研发的，对于大量的数据应该怎么做，我们最直接想到的就是可能我要做采样。
为什么要做采样，这上面列了两个点，一个就是可以有效降低数据量。从数据的价值角度来说我们不希望一条数据漏掉，当那么多的数据量进来以后，一天有一个 PB 的数据量，意味着一天存数据， SD 盘都要用卡车拉，这是一个 PB 的数据量。每天这么多数据量怎么描述，比如说就是响应时间这个事情，我要准确地描述这个网站或者说这个手机应用当前的健康状态是什么，你怎么准确地描述，那么多大数据是描述不出来的，可能为了描述一天的数据量，要花费好几天的时间，意味着永远无法准确描述。
怎么处理呢？最直接的就是马上就能想到的做采样，采样怎么做。大家看左侧这个图，这是我们的一个产品里面很多产品都会有，这个其实是一个散点图。意思是如何在上面标注密密麻麻的点，一个请求一个点位，根据时间的维度不停地在上面点。我可以看到在左侧的这两个比较高的柱上有一个大球，是一个比较密集的地方。那个时候很难看，很难点到每个准确的点，只是一个看上去比较客观的描述一个事情。但是你不能描述整个应用，也不能描述这个应用是什么样子，我们其实利用这种散点图，利用散点图做了一个二维的柱状图。同一个柱状图上又有面积又有高度又有时间，这样好几个维度交叉起来做一个二维图，右侧是大家想要从大量的数据里面描述一个指标，肯定是要用 APDEX ，左侧是变种的种类，右侧是一个 APDEX 的图，我是把这边好几个指标融合成了那边的一个指标。
这是一个 APDEX 的算法， APDEX 的算法是什么东西，大家看一下 APDEX 是什么都是，这个其实是 APM 厂商现在及 APM 这个领域大家都在遵循的一个规范，就是遵循的一个标准， APDEX ，就是应用性能指标这样一个东西，其实不仅限于，这种算法 APDEX 这个名字用于名数一个应用性能的，其实这个算法不仅限于应用性能领域，在很多我们想要的描述同一个指标大量数据的时候都可以用这个做法，我们先说它是什么东西，我们先看左下角，左下角这张图，左下角这张图大家知道高斯分布，正态分布图，我可以从把一个指标，其实就是一个散点图，当我把这些数据让他们符合某一个指标的时候，符合某一个条件的时候，把他们画到这个地方，出来就是这样一个高速分布图，正态分布图。它的波动曲线，波谷越高，说明可能越差，越平缓说明性能越好，这是用正态分布这种方式描述。
但是这种描述方式非常困难，而且还有几个明显的缺点，明显的缺点就是你很容易忽略两此，在这个图两次是什么呢？比如说响应速度非常的快，或者说响应速度非常的慢，这个高斯分布，假设你想用高斯分布描述一个指标，高斯分布这个东西其实是有这样一个假设，假设大量的数据是中庸的，因为它更突出中庸，也就是说另外一个曲线就是说同时假设快的数据就是非中庸的数据都是异常数据，假设非中庸的数据都是异常数据，意味着你描述的时候其实把看起来非常棒和看起来非常差的丢弃了，只剩下中庸数据， APDEX 是对高斯分布的一个改良，他们是怎么做的呢？我们注意看，上面的柱状图。这个柱是一个标识，这个标识最上面 1.00T ， T 就是 APDEX 的一个单位吧，其实 APDEX 是从 0 到 1 这样一个描述的值，比如说我一天平均起来的时间一天内的响应时间，然后每次的相应时间进行一个应用算法计算怎么算 PPT 上没有写，我先定义一个平均响应时间，假设平均响应时间是两秒，大于两秒并且是四倍的时候，两秒到八秒的时候，从零到两秒的时候设为一，如果有四十个，今天一共有四十个请求四十个访问，从零到两秒的时候有十个，从零到两秒是十个，计成一，然后从两秒到八秒有二十个，计成 0.5 ，另外十个大于八秒的，把它计成零。这就是 APDEX 的算法，然后算的时候怎么算，那十个一，一乘十，加上一乘十，加上 0.5 乘以 20 ，然后加上零乘以 10 然后比掉 40 。这是一个 0.75 的值。用这个方法，我可以描述我的应用在一天类的 APDEX 的指标是 0.75 ，我把 0.75 放在这个柱子上看 0.75 什么样，大概还可接受，在 0.7 到 0.85 之间是一个可以接受的状态，不好也不快，如果低于 0.5 是完全不可接受，可能是有故障可能是有问题，这是 APDEX 的算法。
APDEX 有什么问题呢？刚才我们说了 APDEX 有非常好的地方，可以用一个指标去统计出来准确的大概的一些描述我的整个应用或者说某一个指标在一段时间里面大量数据的开拓可以总结出来一个指标。其实存在什么问题？刚才举了一个例子， 40 个请求，以两秒为标杆，我再举一个例子大家就知道这个东西有什么不好。
我以血压为标杆，以血压为例子，比如说我以高压 120 为标杆，有 40 个人，我对 40 个人进行测量，这 40 个人像刚才说的，优秀的十个，中庸的占到 20 个，然后血压偏高已经不行的那些人占了十个，描述四十个人的健康状况他们的血压水平什么样，得出一个还不错的数据， 0.75 ，其实这个时候就有一个非常明确的问题，我去描述这群人是没问题的，我说他可以没问题这群人还不错，但是很可能忽略了一个问题，就是 APDEX 指标最大的问题再在最后大于四倍标量时候的那部分数据被抛弃了，也就是说那十个快要死的人根本没管他，根本没有被关注，这是 APDEX 最大的问题。
另外一个问题是我在进行 APDEX 数据的计算时候，其实原始数据是被丢弃的，因为目前的 APDEX 的计算其实是节省了大量的存储，我可以在数据流动的过程当中直接计算出来指标来。还有就是今天上午的时候友商聊的一点，关于端到端的事情， APDEX 计算的时候端到端被抛弃了，因为那一部分非常差。其实今天上午的时候聊到了端到端，真正做端到端为了实现什么问题？为了实现各个请求从你的手机浏览器端，就是从客户端到客户端客户端后面有自己的网络，有自己的 DB 也自己的物理层有自己其他的外部服务有自己的文件操作等等，整个链路当中你的数据是不是数据孤岛，如果有一个地方是数据孤岛就不是端到端，如果可以通过一个 ID 号或者是时间维度等等可以把它进行串接，这才是有效的端到端，然后就是数据可以有效关联，这是一个真正的现实意义上的端到端，而不是说说就完事了。
这张图今天上午应该也看见了，就是中间一层，很多个位置，现在的做法都是在每个点上这么多服务这么的组建在上面打上，这是我们实现的端到端，端到端有非常大的难度还有采样的问题，我们在使用了 APDEX 的同时，我们还要实现端到端，这个时候其实是一个矛盾，我又要能够准确地描述应用的情况，而且想降低描述的难度，而且一条数据都不丢，这是一个非常大的挑战，这个时候怎么做，有很多做法，这张图上没有，这张图是我们从客户进行真实测试，测试我们解决方案的时候一个真实的数据图，就是机器的负载情况， DPS 降低 4%， CPU 资源使用率在 5%以下。
这是我们具体做到的东西，怎么做呢？是我们再数据传输以及数据采集的地方做了很多大量的工作。比如说真正有问题的，我们假设你的系统有问题，假设你的接口有问题，问题可能在哪里？根据研发经验和运维经验很有可能在进行操作或者是有了网络请求，最有可能这是两种。还有一种可能情况是内存和 CPU 就是你的资源情况，其实逃不出这三个东西，一个是你可能再进行资源操作，或者说你有了网络请求，或者说了 CGU 和内存的使用平静，我知道这些条件之后，就可以针对采集数据，不是说一股脑全都完。还有就是不丢数据，能够准确把你的应用覆盖全，一天又一百万 PV ，一百万 PV 怎么覆盖全了，这也是一个很大的挑战。
我们是怎么做到采样的，这是我们的一个实现的原理图，最初设计的时候一个原理图后来演进之后不是这个样子，大家可以从这个地方看出一些端倪，我们的目标是要全量采集，另外一个目标是我要关注你的响应阈值，各个响应阈值，时间的响应阈值， CPU 和内存响应阈值，还有一个是错误和异常，还有一个是资源操作，为什么说是错误和异常，因为 APDEX 这个东西刚才说了是什么，相应性质时间对吧，通常意义上的 APDEX 是对响应时间这个指标进行计算，做规定的描述。响应时间比如说我在通过一个接口或者通过一个页面访问一个新闻非常简单，发一个请求，获取一篇文章，如果响应时间一百毫秒之内非常棒，其实很有可能响应时间一百毫秒的时候要连接一次，连接一次之后要再写一次缓存或者写一个点击量什么的一个操作，这个时候怎么返回这是一个正常的业务，但是很有可能没有连上，产生了错误或者产生了异常，而响应速度是 90 毫秒，你能说这个 90 毫秒的响应请求比一百毫秒更好吗？
单纯进行相应性质时间这个指标的衡量是有问题的，而且问题非常大。目前我们其实在进行这个的时候大家做的时候也是这么考虑，单纯从客户表现来看，客户并没有感觉，为什么呢？很有可能客户感觉到你的接口确实返回给我东西了，也有可能是接口感觉不到，认为就是这个东西。其实我们应该在关注一个指标的时候要关注异常指标，一个指标正常指标的异常指标比正常指标更重要，在进行 APDEX 衡量的时候一定要进行异常指标的关注。我们这张图其实就是实现这样一个东西，回头大家可以看看这张 PPT 。这是我们端到端的做法，就是在过程当中，或者 RPC 制定协议当中进行自定义操作，每个点都可以拿到数据，然后把数据传上来，就可以实现端到端。
下面有一个事例，云智慧有好几款产品，这个事例是我们监控宝这款产品从使用前和使用后的对比，中间这个是架构，我们监控宝的模块架构是什么样子，右侧右上角有 APDEX ，我们不是一个值，我们还有一个错误的响应，下面有访问时间等等，大家可以看到右上角有一个黄色的条，那个是错误，其实会发现很多问题，怎么应用是不正常的，你能看见满眼是绿色就对了，如果不是绿色就有问题，非常缓慢，缓慢的数量大于了 90%左右。数据库的操作整个面积非常大，面积非常高，产生这是错误和异常的指标，优化后是什么样子，这是真实的数据，如果大家感兴趣可以把帐号数据发给大家仔细看看怎么做的，优化数据满眼都是绿色，查询的响应时间明显降下来了，一下子非常明显，这是响应时间和错误相交叉的一个指标表现。谢谢大家！
刘昕：谢谢高驰涛给我们介绍的关于 APM 的内容，非常好的分享，给我们讲了 APDEX 一下的性能指标还有怎么做端到端的性能优化。
Q ：我想问一下 APDEX 是 APM 行业内的标准还是说根据多年来的经验？
高驰涛：定义是来自于 APM 这个词，这个词是从上市前后才有的，这个词里面的 APDEX 这个东西也是他们一帮专业分析师提出来的标准，刚才说的四倍标量给定义 0.5 大于四倍给零，这个其实没有约定，我们并没有这样的约定，但是大家一直是这么做的。是一个未成文的约定。
刚才我们说了关注几个采样，关注响应时间响应阈值，响应阈值包括访问时间，这是一个关注指标，刚才那个采样没有具体地说，现在我可以简单聊一点关于这个采样的事情，这张图其实采的是 DB 的操作，就是资源操作，我在采的时候首先我可以确定连接我不管有多快，或者多慢，有没有出错，我都必须要采集，因为这是未知的，这是非常关键的操作，关键操作一定要采集，还有对于正常操作，比如说没有发生错误也没有发生异常， CPU 和内存正常，这个时候如果响应时间就会变得非常轻，这个指标。在刚才说的前提下没有产生错误没有产生异常， CPU 和内存响应正常，这个时候响应时间的阈值如果低于一毫秒我们会抛弃掉。我们所有的设计都是不需要用户改一行代码，无任何侵入的，这是我们做的，我所理解的如果说要进行编码是非常不友好的，如果说我相信这个现在有很多厂商是这样做的，就是我要进行编码才能拿取数据这种做法完全没有必要用一个第三方的平台，我觉得这种做法是很 low 的。从无到有是必须要冷部署的，从有到暂停或者说从有到卸载是可以热部署的。
云智慧是业务运维解决方案服务商，旗下产品监控宝（ www.jiankongbao.com ）、透视宝（ www.toushibao.com ）、压测宝（ www.yacebao.com ），已累计为电商、移动互联网、广告传媒、在线游戏、教育医疗、金融证券、政企等行业的几十万用户提供了一站式的应用性能监控、管理及测试服务。
本文整理自 GOPS2016 全球运维大会 • 上海站 APM 专场 云智慧首席架构师高驰涛的演讲。
高驰涛：今天咱们的专场是 APM 专场，我相信在座的其实对 APM 这个东西肯定是了解的，要不然不会过来， APM 我今天会从几个层面聊一下，因为今天的时间非常有限，也不占用大家太多的时间，我只就 APM 里面的一个小点和大家说一下，这个其实是我们的一些应用的实践，就是我们在 APM 这个行业里面的一些实践，其实像刚才这两位男神和丹姐聊的这个范围没有提到 APM ，其实就是做 APM 的事情。这个二维码是我的微信号，我本人是 PHP 开发组的成员，目前是在云智慧做架构师，说三个东西最后有一个小例子来总结一下。
APM 和大数据，大家既然过来了肯定了解 APM ，在 APM 和大家直接相关的日常工作中其实是有一个非常明显的一个点就是 APM 的数据量太大了，大到我们都想象不到的程度，大家看左侧的这个机房，这里面谁能准确地说出来每天有多少数据流转，这只是几台简单的机柜，如果到了互联网上，我不知道刚才腾讯的同事有没有统计过从客户端采集的数据每天希望采集的客户量有多少，针对业务的数据量比例是多少，我们是做过统计的，在我们很多客户那个地方经过验证我们发现 APM 从客户端采集回来的数据可能是占到你业务数据的 50%以上，就是说如果说采集的数据量非常详细的话，很可能会比你的原始业务量数据还要庞大。意味着很可能业务数据带宽是 2 个 T ，为了支撑 APM 又要上两个 T 的带宽，支撑业务的服务器可能三百台，现在要最少 150 台，这个在数据处理方面是很大的挑战，并不是核心业务，但是用了非常多的资源。
什么是 APM ，简单说一句， APM 就是应用、性能、管理，其实刚才这两位聊的都是 APM 的范畴。最主要的就是 APM 性能，是一个性能不是业务，大家注意不是业务是性能。后面还有一个词是管理，尝试从业务的角度理解这个性能数据，比如说一个崩溃或者说一个卡顿会影响多少用户，具体影响多少用户，影响的用户给我们带来了多少个损失，这就是尝试从业务的角度理解，这是简单的聊一下什么是 APM 。
我们为什么要用 APM ，很明显，其实就是大家看左侧的这张图，比如说刚才丹姐说的，有一个客户在付款或者说打 CF ，老是被人打死，因为他卡顿，后台可能我还买了好枪买了好装备，但是怎么打不过别人，我可能要投诉，投诉之后我们找，找到问题是大家的路由器的问题，如果说最后的解决很有可能是这样。其实我们在整个链路过程当中先问题，如果我们没有这样一个工具，或者说这样一个平台是很难准确发现问题的，使用 APM 不管是用已有的 APM 厂商的还是自己研发的，其实是很有作用的，一个是可以提升我们的工作效率，另外就是准确定位问题，一个比较简单的例子我待会儿会说，就是在客户那个地方，一个生产系统的故障，是要死人的那种故障，停服停了两个小时，造成了好几千万的损失，后台找问题，解决的时候非常简单，把服务切了一下，重新启了一套集群，把业务切过去，就是这样操作的，后来把现场保留下来了，用了一个星期的时间发现其实是内存泄露，他们用了一个星期的时间找到了问题，后来经过我们的帮助，我们重复在系统上重现了这个问题，借用于 APM 的一套工具，可以再不发生这种问题了。
我们为什么说是大数据，讲话说大数据大家应该知道有一个思维特征，非常明确的思维特征第一是数据量特别大，像洪水一样过来了，是正常的数据是很恐怖的，一个是数据量特别大，一个是种类特别繁多，目前我已知的移动端的 APM 指标，就有超过三百多个，最少要超过三百多个，维度可能更多，还有一个是价值链，单条价值非常低，这是大数据的明显特征，还有就是数据产生的速度快，这是思维特征。特别符合左侧的这个，一滴水没有什么，当起来之后特别大量的里面包含着各种泥沙各种什么东西，可能还有一个床什么的，这里 2012 电影里面的截图，一下子全过来了，这是大数据的典型特征， APM 的性能数据恰好符合这个特征。
我们面对那么大的数据量咱们有很多是做运营的，也有很多做研发的，对于大量的数据应该怎么做，我们最直接想到的就是可能我要做采样。
为什么要做采样，这上面列了两个点，一个就是可以有效降低数据量。从数据的价值角度来说我们不希望一条数据漏掉，当那么多的数据量进来以后，一天有一个 PB 的数据量，意味着一天存数据， SD 盘都要用卡车拉，这是一个 PB 的数据量。每天这么多数据量怎么描述，比如说就是响应时间这个事情，我要准确地描述这个网站或者说这个手机应用当前的健康状态是什么，你怎么准确地描述，那么多大数据是描述不出来的，可能为了描述一天的数据量，要花费好几天的时间，意味着永远无法准确描述。
怎么处理呢？最直接的就是马上就能想到的做采样，采样怎么做。大家看左侧这个图，这是我们的一个产品里面很多产品都会有，这个其实是一个散点图。意思是如何在上面标注密密麻麻的点，一个请求一个点位，根据时间的维度不停地在上面点。我可以看到在左侧的这两个比较高的柱上有一个大球，是一个比较密集的地方。那个时候很难看，很难点到每个准确的点，只是一个看上去比较客观的描述一个事情。但是你不能描述整个应用，也不能描述这个应用是什么样子，我们其实利用这种散点图，利用散点图做了一个二维的柱状图。同一个柱状图上又有面积又有高度又有时间，这样好几个维度交叉起来做一个二维图，右侧是大家想要从大量的数据里面描述一个指标，肯定是要用 APDEX ，左侧是变种的种类，右侧是一个 APDEX 的图，我是把这边好几个指标融合成了那边的一个指标。
这是一个 APDEX 的算法， APDEX 的算法是什么东西，大家看一下 APDEX 是什么都是，这个其实是 APM 厂商现在及 APM 这个领域大家都在遵循的一个规范，就是遵循的一个标准， APDEX ，就是应用性能指标这样一个东西，其实不仅限于，这种算法 APDEX 这个名字用于名数一个应用性能的，其实这个算法不仅限于应用性能领域，在很多我们想要的描述同一个指标大量数据的时候都可以用这个做法，我们先说它是什么东西，我们先看左下角，左下角这张图，左下角这张图大家知道高斯分布，正态分布图，我可以从把一个指标，其实就是一个散点图，当我把这些数据让他们符合某一个指标的时候，符合某一个条件的时候，把他们画到这个地方，出来就是这样一个高速分布图，正态分布图。它的波动曲线，波谷越高，说明可能越差，越平缓说明性能越好，这是用正态分布这种方式描述。
但是这种描述方式非常困难，而且还有几个明显的缺点，明显的缺点就是你很容易忽略两此，在这个图两次是什么呢？比如说响应速度非常的快，或者说响应速度非常的慢，这个高斯分布，假设你想用高斯分布描述一个指标，高斯分布这个东西其实是有这样一个假设，假设大量的数据是中庸的，因为它更突出中庸，也就是说另外一个曲线就是说同时假设快的数据就是非中庸的数据都是异常数据，假设非中庸的数据都是异常数据，意味着你描述的时候其实把看起来非常棒和看起来非常差的丢弃了，只剩下中庸数据， APDEX 是对高斯分布的一个改良，他们是怎么做的呢？我们注意看，上面的柱状图。这个柱是一个标识，这个标识最上面 1.00T ， T 就是 APDEX 的一个单位吧，其实 APDEX 是从 0 到 1 这样一个描述的值，比如说我一天平均起来的时间一天内的响应时间，然后每次的相应时间进行一个应用算法计算怎么算 PPT 上没有写，我先定义一个平均响应时间，假设平均响应时间是两秒，大于两秒并且是四倍的时候，两秒到八秒的时候，从零到两秒的时候设为一，如果有四十个，今天一共有四十个请求四十个访问，从零到两秒的时候有十个，从零到两秒是十个，计成一，然后从两秒到八秒有二十个，计成 0.5 ，另外十个大于八秒的，把它计成零。这就是 APDEX 的算法，然后算的时候怎么算，那十个一，一乘十，加上一乘十，加上 0.5 乘以 20 ，然后加上零乘以 10 然后比掉 40 。这是一个 0.75 的值。用这个方法，我可以描述我的应用在一天类的 APDEX 的指标是 0.75 ，我把 0.75 放在这个柱子上看 0.75 什么样，大概还可接受，在 0.7 到 0.85 之间是一个可以接受的状态，不好也不快，如果低于 0.5 是完全不可接受，可能是有故障可能是有问题，这是 APDEX 的算法。
APDEX 有什么问题呢？刚才我们说了 APDEX 有非常好的地方，可以用一个指标去统计出来准确的大概的一些描述我的整个应用或者说某一个指标在一段时间里面大量数据的开拓可以总结出来一个指标。其实存在什么问题？刚才举了一个例子， 40 个请求，以两秒为标杆，我再举一个例子大家就知道这个东西有什么不好。
我以血压为标杆，以血压为例子，比如说我以高压 120 为标杆，有 40 个人，我对 40 个人进行测量，这 40 个人像刚才说的，优秀的十个，中庸的占到 20 个，然后血压偏高已经不行的那些人占了十个，描述四十个人的健康状况他们的血压水平什么样，得出一个还不错的数据， 0.75 ，其实这个时候就有一个非常明确的问题，我去描述这群人是没问题的，我说他可以没问题这群人还不错，但是很可能忽略了一个问题，就是 APDEX 指标最大的问题再在最后大于四倍标量时候的那部分数据被抛弃了，也就是说那十个快要死的人根本没管他，根本没有被关注，这是 APDEX 最大的问题。
另外一个问题是我在进行 APDEX 数据的计算时候，其实原始数据是被丢弃的，因为目前的 APDEX 的计算其实是节省了大量的存储，我可以在数据流动的过程当中直接计算出来指标来。还有就是今天上午的时候友商聊的一点，关于端到端的事情， APDEX 计算的时候端到端被抛弃了，因为那一部分非常差。其实今天上午的时候聊到了端到端，真正做端到端为了实现什么问题？为了实现各个请求从你的手机浏览器端，就是从客户端到客户端客户端后面有自己的网络，有自己的 DB 也自己的物理层有自己其他的外部服务有自己的文件操作等等，整个链路当中你的数据是不是数据孤岛，如果有一个地方是数据孤岛就不是端到端，如果可以通过一个 ID 号或者是时间维度等等可以把它进行串接，这才是有效的端到端，然后就是数据可以有效关联，这是一个真正的现实意义上的端到端，而不是说说就完事了。
这张图今天上午应该也看见了，就是中间一层，很多个位置，现在的做法都是在每个点上这么多服务这么的组建在上面打上，这是我们实现的端到端，端到端有非常大的难度还有采样的问题，我们在使用了 APDEX 的同时，我们还要实现端到端，这个时候其实是一个矛盾，我又要能够准确地描述应用的情况，而且想降低描述的难度，而且一条数据都不丢，这是一个非常大的挑战，这个时候怎么做，有很多做法，这张图上没有，这张图是我们从客户进行真实测试，测试我们解决方案的时候一个真实的数据图，就是机器的负载情况， DPS 降低 4%， CPU 资源使用率在 5%以下。
这是我们具体做到的东西，怎么做呢？是我们再数据传输以及数据采集的地方做了很多大量的工作。比如说真正有问题的，我们假设你的系统有问题，假设你的接口有问题，问题可能在哪里？根据研发经验和运维经验很有可能在进行操作或者是有了网络请求，最有可能这是两种。还有一种可能情况是内存和 CPU 就是你的资源情况，其实逃不出这三个东西，一个是你可能再进行资源操作，或者说你有了网络请求，或者说了 CGU 和内存的使用平静，我知道这些条件之后，就可以针对采集数据，不是说一股脑全都完。还有就是不丢数据，能够准确把你的应用覆盖全，一天又一百万 PV ，一百万 PV 怎么覆盖全了，这也是一个很大的挑战。
我们是怎么做到采样的，这是我们的一个实现的原理图，最初设计的时候一个原理图后来演进之后不是这个样子，大家可以从这个地方看出一些端倪，我们的目标是要全量采集，另外一个目标是我要关注你的响应阈值，各个响应阈值，时间的响应阈值， CPU 和内存响应阈值，还有一个是错误和异常，还有一个是资源操作，为什么说是错误和异常，因为 APDEX 这个东西刚才说了是什么，相应性质时间对吧，通常意义上的 APDEX 是对响应时间这个指标进行计算，做规定的描述。响应时间比如说我在通过一个接口或者通过一个页面访问一个新闻非常简单，发一个请求，获取一篇文章，如果响应时间一百毫秒之内非常棒，其实很有可能响应时间一百毫秒的时候要连接一次，连接一次之后要再写一次缓存或者写一个点击量什么的一个操作，这个时候怎么返回这是一个正常的业务，但是很有可能没有连上，产生了错误或者产生了异常，而响应速度是 90 毫秒，你能说这个 90 毫秒的响应请求比一百毫秒更好吗？
单纯进行相应性质时间这个指标的衡量是有问题的，而且问题非常大。目前我们其实在进行这个的时候大家做的时候也是这么考虑，单纯从客户表现来看，客户并没有感觉，为什么呢？很有可能客户感觉到你的接口确实返回给我东西了，也有可能是接口感觉不到，认为就是这个东西。其实我们应该在关注一个指标的时候要关注异常指标，一个指标正常指标的异常指标比正常指标更重要，在进行 APDEX 衡量的时候一定要进行异常指标的关注。我们这张图其实就是实现这样一个东西，回头大家可以看看这张 PPT 。这是我们端到端的做法，就是在过程当中，或者 RPC 制定协议当中进行自定义操作，每个点都可以拿到数据，然后把数据传上来，就可以实现端到端。
下面有一个事例，云智慧有好几款产品，这个事例是我们监控宝这款产品从使用前和使用后的对比，中间这个是架构，我们监控宝的模块架构是什么样子，右侧右上角有 APDEX ，我们不是一个值，我们还有一个错误的响应，下面有访问时间等等，大家可以看到右上角有一个黄色的条，那个是错误，其实会发现很多问题，怎么应用是不正常的，你能看见满眼是绿色就对了，如果不是绿色就有问题，非常缓慢，缓慢的数量大于了 90%左右。数据库的操作整个面积非常大，面积非常高，产生这是错误和异常的指标，优化后是什么样子，这是真实的数据，如果大家感兴趣可以把帐号数据发给大家仔细看看怎么做的，优化数据满眼都是绿色，查询的响应时间明显降下来了，一下子非常明显，这是响应时间和错误相交叉的一个指标表现。谢谢大家！
刘昕：谢谢高驰涛给我们介绍的关于 APM 的内容，非常好的分享，给我们讲了 APDEX 一下的性能指标还有怎么做端到端的性能优化。
Q ：我想问一下 APDEX 是 APM 行业内的标准还是说根据多年来的经验？
高驰涛：定义是来自于 APM 这个词，这个词是从上市前后才有的，这个词里面的 APDEX 这个东西也是他们一帮专业分析师提出来的标准，刚才说的四倍标量给定义 0.5 大于四倍给零，这个其实没有约定，我们并没有这样的约定，但是大家一直是这么做的。是一个未成文的约定。
刚才我们说了关注几个采样，关注响应时间响应阈值，响应阈值包括访问时间，这是一个关注指标，刚才那个采样没有具体地说，现在我可以简单聊一点关于这个采样的事情，这张图其实采的是 DB 的操作，就是资源操作，我在采的时候首先我可以确定连接我不管有多快，或者多慢，有没有出错，我都必须要采集，因为这是未知的，这是非常关键的操作，关键操作一定要采集，还有对于正常操作，比如说没有发生错误也没有发生异常， CPU 和内存正常，这个时候如果响应时间就会变得非常轻，这个指标。在刚才说的前提下没有产生错误没有产生异常， CPU 和内存响应正常，这个时候响应时间的阈值如果低于一毫秒我们会抛弃掉。我们所有的设计都是不需要用户改一行代码，无任何侵入的，这是我们做的，我所理解的如果说要进行编码是非常不友好的，如果说我相信这个现在有很多厂商是这样做的，就是我要进行编码才能拿取数据这种做法完全没有必要用一个第三方的平台，我觉得这种做法是很 low 的。从无到有是必须要冷部署的，从有到暂停或者说从有到卸载是可以热部署的。
云智慧是业务运维解决方案服务商，旗下产品监控宝（ www.jiankongbao.com ）、透视宝（ www.toushibao.com ）、压测宝（ www.yacebao.com ），已累计为电商、移动互联网、广告传媒、在线游戏、教育医疗、金融证券、政企等行业的几十万用户提供了一站式的应用性能监控、管理及测试服务。
目前尚无回复
Select Language