本系列文章涵盖许多基础性内容：它给出了应用程序性能管理（APM）的总体概述；指明了实现一个 APM 策略的主要挑战；提出了衡量，评估一个企业级 Node.js 应用程序运行状况的最重要的 5 条指标；并提出了通过 AppDynamics 方式构建一个 APM 解决方案。在文章的最后部分，还提出了一些提示和技巧类以帮助您实现最佳的 APM 策略。具体地说，本文讨论了以下主题：

1.业务交易优化

本文章系列里，我会不断重复强调的就是监控方案里的业务交易优化一环。要最有效地利用业务交易监控，您需要做到以下几项：

AppDynamics 可以为您自动识别业务交易，并且尽可能给出最优的命名。不过这样取决于您的应用是如何编写的，应用名可能可以如实反映业务交易，也可能不可以。例如，您可能有一个业务交易叫做“POST/payment”，对应着检验流程。那么如果将其命名为“Checkout”的话，就更能如实反映业务功能，这将更利于操作人员操作，也便与生成报表与执行人员查看。

下面，如果您有多个业务交易，却只有一个入口的话，你需要花一些时间将其分割为独立的业务单元。以下几个可能发生的例子，包含如下特点：

如果一个入口却对应着多个业务功能，那么就需要根据不同的指标配置业务交易。例如，如果 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 个。这会显著地减少持续的消耗，但代价是可能会导致捕捉不到有代表性的快照。

?

?

AppDynamics 设计了一套通用的监控解决方案，并且对于比正常情况慢两个标准差的业务事务提供警告。这在大多数情况下是有效的，但是你需要知道你的应用程序响应时间有多不稳定，以便确定这对你的业务需求来说是否为最佳配置。

?

根据业务事务对比基准线的估算值，AppDynamics 定义了三种阈值：

?

?

?

如果您的应用程序的响应时间不稳定,那么默认的两个标准差临界值可能导致太多的错误警报。在这种情况下，您可能希望增加更多的标准差或换一种方式来处理。如果您的应用程序的响应时间比较稳定，你就会想减少你的临界值提前发出警告。此外，如果你有提供给特殊协定用户的服务或 API（应用程序接口），你应该为此业务设置一个稳定的协定值。AppDynamics（应用性能管理）会提供给你个人或企业业务定义警报规则的灵活性。

?

你需要分析你的应用程序的行为，并相应地配置报警引擎。

在前面我已经提到过，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，让你自己定义系统的服务层次。

但性能问题发生的时候，有时候问题只发生在某个浏览器或者移动设备上，有时候只发生在客户端发送了特定的请求内容。在这种情况下，由于问题并不总是能够重现，那么我们怎么来定位这些问题呢？