本系列文章涵盖许多基础性内容：它给出了应用程序性能管理（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秒