本系列文章涵盖许多基础性内容：它给出了应用程序性能管理（APM）的总体概述；指明了实现一个 APM 策略的主要挑战；提出了衡量，评估一个企业级 Node.js 应用程序运行状况的最重要的 5 条指标；并提出了通过 AppDynamics 方式构建一个 APM 解决方案。在文章的最后部分，还提出了一些提示和技巧类以帮助您实现最佳的 APM 策略。具体地说，本文讨论了以下主题：
业务交易优化
快照调优
阈值调优
层级管理
上下文信息捕获
1 . 业务交易优化
本文章系列里，我会不断重复强调的就是监控方案里的业务交易优化一环。要最有效地利用业务交易监控，您需要做到以下几项：
恰当地命名业务交易以配合您的业务功能
正确识别您的业务交易
通过排除您并不关心的业务交易来降低噪音
AppDynamics 可以为您自动识别业务交易，并且尽可能给出最优的命名。不过这样取决于您的应用是如何编写的，应用名可能可以如实反映业务交易，也可能不可以。例如，您可能有一个业务交易叫做“POST/payment”，对应着检验流程。那么如果将其命名为“Checkout”的话，就更能如实反映业务功能，这将更利于操作人员操作，也便与生成报表与执行人员查看。
下面，如果您有多个业务交易，却只有一个入口的话，你需要花一些时间将其分割为独立的业务单元。以下几个可能发生的例子，包含如下特点：
多个 URL 都路由到相同的 MVC 控制器和动作
根据有效负载的制定业务交易功能
根据 GET 参数制定业务交易功能
复杂的 URL 路径
如果一个入口却对应着多个业务功能，那么就需要根据不同的指标配置业务交易。例如，如果 body 里有一个”operation“元素对应着”operation“操作的话，那么就需要根据”operaiton“对交易进行分割。又如果有一个”execute“动作接受一个”command“URL 参数，那么就需要根据”command“字段对交易进行分割。最后，URL 模式可能会因应用不同而不同，所以您需要与您的应用最匹配的形式。例如，AppDynamics 会根据两段式自动为您的 URL 定义业务交易，例如 one/two。大多数 Node.js MVC 框架都会自动路由到对应的应用控制器和动作。如果您的应用使用的是一段式，或者四段式，那么您需要根据命名规则来定义业务交易。
命名和识别业务交易单元可以确保您捕捉到了正确的业务功能，但是尽可能多的减噪也同样重要。您是否有些并不关心的业务交易呢？比如，会不会有一个网页游戏会每隔几秒就检查对高分呢？又或者如果有一个每晚都执行的 Node.js 的 CLI 作业，每次都执行很长时间，但是由于脱机运行，它并不影响终端用户，您不关心么？ 如果是的话，排除这些交易，以便减少分析噪音。
2 . 快照调优
正如在前面文章提到的，AppDynamics 每隔一段时间就会智能捕获性能快照，并可以逐渐缩小每次性能会话里快照的个数。由于这两个值都是可以调整的，所以有利于调优。
AppDynamics 直接捕获整个进程的调用关系图，同时去掉配置阈值以下的记录。如果你只对“大的”性能问题感兴趣，那么你可能不需要精确到 10 毫秒以下。如果你把间隔时间增加到 50 毫秒，你会丢失粒度。如果你想微调应用程序，你可能需要 10 毫秒的粒度，但是如果你不打算让方法在 50 毫秒内执行完毕，为什么需要那种级别的粒度呢？问题在于你应该分析需求然后做相应的调整。
接下来，观察你的产品故障排除模式，然后判断 AppDynamics 捕获的进程快照数在你当前状况下是否合适。如果你发现每分钟捕获 2 个快照太多了，那么你可以配置 AppDynamics 来调整快照间隔。尝试配置 AppDynamics 让其每分钟最多捕获一个快照。另外如果你只对系统性问题感兴趣，你可以把最大快照数降低至 5 个。这会显著地减少持续的消耗，但代价是可能会导致捕捉不到有代表性的快照。
3 . 阈值调优
AppDynamics 设计了一套通用的监控解决方案，并且对于比正常情况慢两个标准差的业务事务提供警告。这在大多数情况下是有效的，但是你需要知道你的应用程序响应时间有多不稳定，以便确定这对你的业务需求来说是否为最佳配置。
根据业务事务对比基准线的估算值，AppDynamics 定义了三种阈值：
标准差: 比较业务事务的响应时间与基准线的几个标准差
百分比: 比较业务事务的响应时间与基准线的差值百分比
静态 SLA: 比较业务事务的响应时间和静态值，比如2秒
如果您的应用程序的响应时间不稳定,那么默认的两个标准差临界值可能导致太多的错误警报。在这种情况下，您可能希望增加更多的标准差或换一种方式来处理。如果您的应用程序的响应时间比较稳定，你就会想减少你的临界值提前发出警告。此外，如果你有提供给特殊协定用户的服务或 API（应用程序接口），你应该为此业务设置一个稳定的协定值。AppDynamics（应用性能管理）会提供给你个人或企业业务定义警报规则的灵活性。
你需要分析你的应用程序的行为，并相应地配置报警引擎。
4 . 分层调优
在前面我已经提到过，AppDynamics 不仅能够捕获业务事务性能的基准，同时它也能捕获一个业务事务在不同服务层上的性能基准。打个比方，如果你的业务事务调用了一个规则引擎提供的服务，那么AppDynamics将正确捕获你的业务事务对规则引擎部分的调用数以及规则引擎的平均响应时间，并且将会把这些数据正确反映到业务事务的性能基准中。正是因为 AppDynamics 的这个特性，因此在你的整个系统中最好能够清晰定义所有的服务层，这样你可以得到一个非常清晰而且优秀的业务事务性能基准。
如果你没有明确指定系统的服务层次，那么AppDynamics将根据一定的规则（不同的协议栈）自动分析你的应用的服务层次。比如，它将自动把你的应用分解成 HTTP 服务层，JMS 服务层，JDBC 服务层。举一个具体的例子，如果 AppDynamics 发现你的代码中有一个对 Database 的操作，那么它就会假设你的整个业务逻辑中存在一个数据库访问层，因此它就会自动计算你的业务逻辑用在数据库访问上的时间。这个对于调优你的业务逻辑是非常重要的，因为你不希望在性能基准中只是看到一个信息说你的 ORM class 中的 save 方法执行的非常慢，相反的你希望能够看到更具体的信息，比如说 save 方法花了多少时间把数据存储到数据库中，又花了多少时间执行其他的任务。
如果在你的系统中，所有的 service 调用都使用的是通用协议栈（比如 HTTP 协议）， 那么 AppDynamics 将非常完美的分析出你的系统的服务层次，但是如果你的系统使用了一个非通用协议栈和后端系统进行通信，AppDynamics 就无能为力了。举例来说，目前我在一个保险公司工作，这个保险公司使用一个 AS/400 机器提供询价服务。在我们的系统中，我们使用了一个私有库来和 AS/400 通讯，这个库使用了一个私有的基于 socket 的通讯协议链接到 AS/400 上。在这种情况下，很明显 AppDynamics 不可能知道系统使用了基于 socket 的通讯协议，也不可能知道这 个socket 通讯协议是如何工作的。因此，我们需要告诉 AppDynamics 是哪个方法实现了和 AS/400 之间的通讯，并且标记这个方法为定制化的后端资源。这样一来，AppDynamics 就会将这个方法识别成一个新的服务层次，接下来 AppDynamics 就可以对这个新的服务层次进行调用计数，并计算它的平均响应时间了。
在大部分情况下，你可以使用 AppDynamics 的内置功能来分析系统的服务层次，但是如果你有特定的要求，AppDynamics 也提供了 Node.js API，让你自己定义系统的服务层次。
5 . 获取上下文信息
但性能问题发生的时候，有时候问题只发生在某个浏览器或者移动设备上，有时候只发生在客户端发送了特定的请求内容。在这种情况下，由于问题并不总是能够重现，那么我们怎么来定位这些问题呢？
答案就是在创建快照的时候，同时获得上下文信息。你可以通过查看上下文信息，看来发现一些共性。需要捕获上下文信息可能有以下这些：
HTTP 请求头信息，比如浏览器类型（user-agent ），cookies 和 referrer
HTTP GET 请求发送的参数
被调用方法的参数
应用中定义的变量以及变量的值
我们下面就举一些例子来说明对于一个性能不好的 Node.js 事务，你将如何应用上面说的这些上下文信息来查找和发现问题。比如，如果你捕获了 User-Agent HTTP 请求头信息，那么你就可以知道用户是在哪个浏览器上执行商业事务。如果你提供的 HTTP 服务支持 GET 方法，那么你可能想通过检查Query String 里面某个或者多个变量的值来知道用户想查询什么内容。再进一步，如果你知道应用的代码是如何工作，你可能就想知道一个具体参数的值。
你可以通过配置让 AppDynamics 获取上下文信息并且加入到快照中，可以被捕获的上下文信息在上一节中已经详细介绍了。下面我们简单的介绍一下 AppDynamics 获取上下文信息的过程：
- AppDynamics 发现了一个运行缓慢的业务事务
- 于是 AppDynamics 开始创建一个快照
- 在创建快照的过程中，AppDynamics 根据你配置的信息，获取相应的上下文信息并放入快照中
结果就是当你找到一个可以反映你试图解决的问题的快照的时候，你可以在 AppDynamics 为你捕获的上下文信息中查看是否有有用的信息。
当你使用上下文信息捕获功能的时候，因为 AppDynamics 使用侵入式代码来获取方法的参数值，这将造成原始代码运行效率有一些下降。因此，只在确实需要的地方使用这个功能。
结束语
应用性能管理的难处在于它需要在获取尽量少的数据的情况下，能够让开发人员分析出导致性能瓶颈的真正原因。 对于一个 APM 工具，都应该能够提供一系列的配置选项，以便开发人员可以在应用程序执行过程中，以尽量小的代价获得足够的性能分析数据。 这篇文章主要介绍了一下这些在实现 APM 策略的时候需要思考的核心点，这些核心点包括：
业务事务优化
快照调优
阀值调优
服务层次管理
获取上下文信息
实现一个 APM 系统是非常困难的，但是象 AppDynamics 这样的系统就极大的简化了 APM 的实现。通过使用 AppDynamics， 开发人员可以很方便的在应用中实现 APM，而不会对应用本身造成很大的影响（ APM 代码的引入也是会造成一定的性能下降的）。
文章转载自 开源中国社区[https://www.oschina.net]
