【编者按】北京新东方教育科技（集团）有限公司，是大规模的综合性教育集团。在「OneAPM 技术公开课」中，新东方的架构师赵而星从应用监控痛点、了解应用性能、快速定位错误等方面，结合实践案例带来了一场 APM 实践的分享。

讲师简介：赵而星曾在 IBM 工作过 8 年，先后参与过泰康人寿、中信证券、中核集团等多家大型公司的大型系统建设和性能优化，拥有近 10 年的系统实施经验，对于系统架构和性能优化具有丰富的理论和实践经验。目前负责新东方核心系统的升级改造和高并发性能优化工作。

以下为演讲整理：

其实，类似于新东方这样的半传统企业，正面临着强大的互联网技术冲击，开发人员和技术都会面临着新技术的挑战，原本熟悉的一些技术已经被淘汰，而用户的实际业务需求变化得越来越频繁，上线周期也越来越短，这些都给企业带来了巨大的挑战。也正是在这个期间，我们积极地寻求一款可以用于性能监控的工具。

我们调研了一些性能监控厂商，包括国内的 OneAPM 和国外的 New Relic 等。通过对比，发现 OneAPM 应用监控的实用效果相对而言是最好的，因为它可以帮助我们在短期内发布出新应用。比如说有时候需要一个月内上线一个新应用，OneAPM 可以帮我们迅速且稳定的实现，从而能够抵挡用户的冲击。

大家都知道，新东方一年招生的学员在一百万左右，用户量非常大。很多时候市场部或者业务部提出一个需求，比如快速增加一个新功能。由于业务的压力，我们不可能像研发那样制定很合理的时间安排。新功能需要快速地赶出来，甚至来不及很仔细的测试就要上线，这种时候，监控软件对我们的帮助非常显著。所以接下来本人把应用 OneAPM 在解决业务问题时的实际技术问题过程中一些经验分享给大家，希望对大家有所帮助。

以下主要介绍四部分的内容。首先会大概介绍一下应用监控的痛点，其次，会结合痛点介绍我们是如何了解应用的性能，以及如何快速发现错误和准确定位，最后介绍如何利用 OneAPM 的监控工具帮助我们提高效率。

应用监控难以承受之「重」

众所周知，在开发过程中，每个程序员机会都会受到这样的质疑——应用出现问题。「性能慢」是最常见的，甚至比功能 Bug 更为普遍，这映射到的正是性能问题。当别人提出这个问题时，你已经无法确认当时到底是应用问题还是网络问题。所以应用监控最大的痛点就是没有详细数据，无法确认性能到底如何。

另外一种情况，当你的应用出现故障的时候，可能无法判断导致问题的原因。在对内的业务系统中，报错的人可能会及时给你反馈。但是很多时候一些面向互联网用户的应用，一旦出现故障，用户不一定能够反馈。那么，我们如何得知这个地方的错误率是多少，怎么确定这个东西是否出了故障。一旦出现故障，无论是性能故障还是错误故障，又如何完整还原事故的案发现场，能不能再找回来当时的点去解决问题。如果缺乏详细数据，你可能要通过尝试多种组合重现问题，甚至需要花费很多时间，而这是很多开发者每天面临的问题。如何场景重现？如何复现当时的问题？无论在开发产品、系统或者软件，这些问题都不可避免。

最后一个痛点就是对于一些老的应用，我们常常忽略文档的更新。即便提倡敏捷开发或者各种应急项目，很可能在文档还完成的情况下，项目就已经结束。之后项目会交给其他人维护，或者你接手了别人的项目，忘记了该应用的拓朴结构。或者随着版本迭代，你已经完全不了解新加的内容，应用俨然成了一个「黑盒子」。当这个应用再进行迁移或者改造时，你会面临种种的困难。以上四种痛点是开发系统或项目时最为常见的几个问题，接下来我会将解决这些问题过程中的一些实践经验分享给大家。

评估应用性能并快速优化

首要问题是如何评估这个应用性能并快速优化。以前评估应用性能的指标是响应时间，比如接口或者页面的显示时间是多少毫秒或者多少秒。另一个衡量性能的指标是 throughput，即一秒钟能处理多少个请求，在数据库可能是一个事务的 TPS 级别，衡量页面代表的是一秒钟处理多少页面访问，或者需要多少个页面提交。但是这些性能指标并不能真正的反应用户对请求的满意度。

在访问页面时，如果用户能在3秒钟内看到页面会感觉很快。但是对接口而言，现在流行的架构是前后端的接口分离，所以变成了接口为外面提供可复用的服务，接口的响应时间现在普遍的定义是0.5秒。但衡量指标不仅仅代表的是平均响应时间，即便是平均响应时间没问题，但仍然有一部分用户的响应时间很长，对用户而言性能感受是非常差的。

所以目前国际上流行的指标是 Apdex，即 App Performance Index 指标，表示性能指数，计算公式是1乘以满意样本数，加上0.5乘以容忍样本数，除以样本总数。这个指数可以理解为越接近于1，性能反应就越好。假如这个满意样本数的区间是这么定义的，如果响应时间让用户感到很愉快，那么感应时间应该小于T秒钟。之前提到一般接口的 T 响应时间是0.5秒，如果接口能够在0.5秒能够返回给 APP 或其它应用，我们可以认为这个任务是满意的。

那么，容忍区间是什么？对于用户来说，慢一点还能够接受，一般区间在T到4个T，对接口来说是0.5到2秒钟。如果超过这4个 T 的区间，就是超出容忍程度会选择放弃，可能用户会把APP或页面关掉。所以基本上来说，如果所有的请求，你的服务在一秒钟响应了一百次，而这一百次都在满意区间，当接口是0.5秒时，那么 Apdex 指数就为1。因为1乘以满意样本数100，容忍样本数是0，除以样本总数，100除以100等于1。该公式可以计算出应用接口的性能指数。假如 Apdex 指数在0.9以上，基本上能反应出你的应用或接口已经非常好了。所以我们可以利用这个指数进一步衡量应用。以后任何人来质疑接口服务的性能，这个指标足以说明一切。

以上是我们采用 OneAPM 监控软件的架构图。从该图右上角可以看到接口或应用的性能指数，后面方括号显示的是前面提到的 T 值。比如现在监控的是一个接口的后台服务， T值为0.5秒，如果 Apdex 值是0.99或1，说明性能反应已经非常好。中间的部分将响应时间进一步细化到多种类型。如果是一个 Java 应用，绿色代表 GVM 内部处理时间，即 Java 程序的执行时间——纯粹的内部逻辑，既不涉及到数据库访问，也不涉及到第三方接口的调用；黄色代表 Database，即访问数据库的响应时间；蓝色代表外部的 External。假如调用第三方的 rest，通过该图可以形象地了解应用整体的响应时间是在如何波动。

其中每一种类型的处理时间的占比都可以进行直观的比较。当你发现绿色较多时，说明程序代码的内部处理逻辑可能有一些问题，于是可以针对每一个接口去寻找大概问题的位置。蓝色较多意味着可能访问所依赖的第三方服务性能不正常。这个构架图能够比较直观地了解应用或接口大概慢在什么地方。

同时还有一个比较智能的提示，右上角定义了外部事务的时间段，比如可以看到最近30分钟内出现得比较慢的请求，并且给出提示信息。然后我们可以根据这个提示时间进一步分析是哪一次慢了，慢了多少时间以及可能出现什么问题。

以上主要介绍了它能够监控的性能问题，另外一个不可忽略的指标是错误率。因为接口或者页面有可能报错，最典型就是程序接口错误。如果你这个接口找不到了，出现类似404这种错误，它也能够监控得出错误率，当错误率较高时，你需要提高警惕去排查问题。此外，还会提示一些定义的监控事件，因为你可能会定义一些监控的阈值，比如某一个关键接口响应时间超过多少秒就会出现预警，或者哪个接口是不允许报错的，或者错误率的范围。一旦出错，你就可以去查看响应的错误原因。

上图是我们的第一个案例，在快速上线一个 APP 的时候，在优化性能的过程中根本来不及做性能措施，就需要依靠这种监控软件来进行优化。最开始接口刚开始上线时，我们内部试用的 Apdex 指数是比较差的，只有0.73，而且看到大量接口的响应时间都是在秒级，离之前的满意值0.5秒差很多。但通过架构图可以看到发布情况的大概时间花在哪里，再针对每一个慢的时间，看时间到底花费在哪里。

当我们点开其中一个慢的时间时，它可以精准地告诉你，这段时间大概发生了什么，比如查询数据库的请求执行了几次，响应时间是多长，占整个执行时间的比例是多少，以及占用时间比较多的代码段是什么。然后还可以进一步了解 SQL 是什么。为了不泄漏敏感数据，对本图中的 SQL 打了马赛克，该界面可以准确的显示当时执行的 SQL 语句。

如果你不知道程序可能执行的最终结果是什么，还可以查看请求的详细参数，也就是你给 Web App 提供 rest 接口时实际传的参数。它的 Apdex 状态码是200，然后你根据实际的参数值在测试环境或者其它仿真环境中，去尝试模拟复原这个执行过程，进一步准确地还原案发现场。当然这并不一定能百分之百的帮助你解决所有问题，因为可能跟当时其它程序的执行有关系。

经过以上过程，我们找出了执行慢的原因，接下来可以采取优化措施。比如通过 redis 缓存，对内部代码、SQL或数据库方面进行优化。因为我们已经知道性能的确较慢，优化之后达到了0.81，但还是不满意，为什么？我们进一步看会发现，优化之后内部代码执行时间已经很短了。现在反而大部分时间花在黄色的部分，黄色部分是调用了一个第三方的 rest 服务。于是，我们就有足够的证据找到这个 rest 服务的提供者，再通过内部系统给出一个详细数据。因为数据足以证明这个接口有问题，提供者也会很快的采取优化措施，最终我们整个应用的 Apdex 指数提高到0.99。

以上所讲的优化过程，到底花了多长时间？不超过两天。要是在之前，当没有详细的数据帮助你解决性能问题时，光凭感觉说是别人的问题，恐怕沟通协调的时间就远远超过两天。所以 OneAPM 的监控软件帮我们快速稳定好后端接口服务的性能，也是帮助我们快速解决问题的一个典型案例。

快速发现错误

OneAPM 监控软件能够快速发现错误。当时刚上线了我们的应用，同时还发现了很多报错信息，还有很多过期错误。然后我们根据这个具体的错误按照之前的方式一样，看传过来的参数是什么。然后我们发现这是安卓客户端报出来的错误。在客户端应用中，我们区分它的应用请求参数。所以完全可以根据当时错误的详细信息，定位到是安卓客户端发生了错误，而 iOS 端则没有这个问题。于是，我们很快找到安卓端 APP 的开发者去跟进这个参数。由于 iOS 端没有问题，证明了后端接口是正常的。所以这种数据能够帮助我们快速定位问题的 root host，进而分析具体原因。

自动生成拓扑结构

以上两个案例，一个是用于提升性能，另一个是用于解决实际错误。最后，再和大家分享下 OneAPM 可以自动生产网络拓朴结构，帮助解决现有的应用问题。

首先，它在监控接口的时候，能够捕获你对外发出的请求，无论是对数据库，还是对外面的 rest 服务，所以它可以准确的列出来所调用的几个 rest 服务，可以捕捉到有四个 HTTP 在后端的第三方服务。同时，可以记录调用每一个服务的平均响应时间和一段时间内的调用次数。以及它的调用频率，一分钟调用多少次。根据这些数据能看出跟其它的第三方服务接口集成的性能以及健康状态。同时对于数据库来说，可以得知哪些 SQL 比较慢。

因此，你可以不用再去找 DBA 去监控慢 SQL。通过应用端，开发人员自己就可以找到慢 SQL，再根据这些具体数据去解决大部分的问题，所以它可以自动生产网络拓朴结构以及性能问题。尤其是对于一些老应用，我们本来就不知道它的代码，如果想一下子找到问题的根源简直是天方夜谭。但借助于 OneAPM 的监控工具，我们可以高效率定位到问题点所在，进一步提升应用性能。以上内容是本人在使用 APM 监控软件解决系统上线过程中的实际体会和经验。谢谢大家！

本文系 OneAPM 工程师整理，已经得到赵而星老师的发布授权。