本系列文章涵盖了很多基础工作：它给出了应用程序性能管理(APM)的总体概述；确定实施APM策略的主要挑战；，评估企业级Node.js应用运行状态最重要的五个指标；并提议通过AppDynamics构建APM解决方案。在本文的最后一部分，还介绍了一些提示和技巧，以帮助您实现最佳的APM策略。具体来说，本文讨论了以下主题：业务事务优化快照调优阈值调优分层管理上下文信息捕获1.业务事务优化在本系列文章中，我会反复强调监控解决方案中的业务事务优化部分。为了充分利用业务交易监控，您需要执行以下操作：适当地命名您的业务交易以匹配您的业务功能正确识别您的业务交易通过排除您不关心的业务交易来减少噪音AppDynamics可以做到为您自动识别和命名尽可能最好的商业交易。但取决于您的应用程序的编写方式，应用程序名称可能反映也可能不反映业务交易。例如，您可能有一个名为“POST/payment”的业务交易对应于一个验证过程。那么，如果命名为“Checkout”，则更能如实反映业务功能，更方便操作人员操作，也方便生成报表和执行人员查看。接下来，如果您有多个业务交易但只有一个条目，则需要花一些时间将它们分解为单独的业务单元。下面是几个可能的示例，包括以下特征：多个URL被路由到同一个MVC控制器和操作基于负载的业务交易功能的制定基于GET参数的业务交易功能的制定复杂的URL路径，如果一个条目对应于如果有是多个业务功能，那么业务交易需要根据不同的指标进行配置。比如body中有一个“operation”元素对应“operation”操作，那么这个事务就需要按照“operaiton”进行划分。而如果有一个接受“命令”URL参数的“执行”动作，那么交易就需要根据“命令”字段进行拆分。***，URL模式可能因应用程序而异，因此您需要最适合您的应用程序的模式。例如，AppDynamics会根据两段格式自动为您的URL定义业务交易，例如一/二。大多数Node.jsMVC框架会自动路由到相应的应用程序控制器和操作。如果您的应用程序使用单段或四段，那么您需要根据命名规则定义业务事务。命名和识别业务交易单元可确保您捕获正确的业务功能，但尽可能减少噪音同样重要。您是否有不关心的业务交易？比如有没有每隔几秒查一次高分的网页游戏？或者，如果你有一个每晚运行的Node.jsCLI作业，每次都需要很长时间，但因为它是离线运行的，所以它不会影响最终用户，你不在乎吗？如果是这样，请排除这些交易以减少分析噪音。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类中的保存方法执行得非常慢。相反，你希望能够看到更具体的信息，比如save方法在数据库中存储数据花费了多少时间，以及执行其他任务花费了多少时间。如果在你的系统中，所有的服务调用都使用一个通用的协议栈（比如HTTP协议），那么AppDynamics会非常准确的分析出你系统的服务级别，但是如果你的系统使用一个非通用的协议栈与后端通信系统，而AppDynamics是无能为力的。例如，我目前在一家使用AS/400机器进行RFQ服务的保险公司工作。在我们的系统中，我们使用专有库与AS/400通信，它使用专有的基于套接字的通信协议链接到AS/400。在这种情况下，很明显AppDynamics无法知道系统使用了基于套接字的通信协议，也不可能知道套接字通信协议是如何工作的。因此，我们需要告诉AppDynamics哪个方法实现了与AS/400的通信，并将这个方法标记为自定义后端资源。这样，AppDynamics就会将这个方法识别为一个新的服务级别，然后AppDynamics可以统计对这个新服务级别的调用并计算它的平均响应时间。在大多数情况下，您可以使用AppDynamics的内置函数来分析系统的服务级别，但是如果您有特定的要求，AppDynamics也提供了Node.jsAPI，允许您自己定义系统的服务级别。5、获取上下文信息但出现性能问题时，有时问题只出现在某个浏览器或移动设备上，有时只出现在客户端发送特定请求内容时。在这种情况下，由于问题并不总是可重现的，我们如何解决它们？答案是在创建快照的同时获取上下文信息。您可以通过查看上下文信息来了解一些共性。需要捕获的上下文信息可能包括以下内容：HTTP请求头信息，例如浏览器类型（user-agent）、cookies和referrerHTTPGET请求发送的参数被调用方法的参数应用程序中定义的变量和变量的值我们将在下面描述给出一些示例，说明您将如何应用上述上下文信息来查找和发现性能不佳的Node.js事务的问题。比如抓取User-AgentHTTP请求头信息，就可以知道用户是在哪个浏览器上进行业务交易的。如果您提供的HTTP服务支持GET方法，那么您可能想通过检查QueryString中一个或多个变量的值来了解用户想要查询什么。更进一步，如果您知道应用程序代码的工作原理，您可能想知道特定参数的值。您可以配置AppDynamics以获取上下文信息并将其添加到快照中。上一节已经详细描述了可以捕获的上下文信息。下面简单介绍一下AppDynamics获取上下文信息的过程：AppDynamics发现一个业务事务运行缓慢，于是AppDynamics开始创建快照。在创建快照的过程中，AppDynamics获取相应的上下文信息并将其放入快照中的结果是，当您找到反映您要解决的问题的快照时，您可以查看其中是否有任何有用的内容AppDynamics为您捕获的上下文。当你使用上下文信息捕获功能时，由于AppDynamics使用侵入式代码来获取方法的参数值，这会导致原始代码运行效率较低。因此，请仅在真正需要的地方使用此功能。结语应用性能管理的难点在于需要让开发者在获取尽可能少的数据的同时分析出性能瓶颈的真正原因。对于一个APM工具来说，它应该能够提供一系列的配置选项，让开发者在应用程序执行过程中能够以最小的成本获得足够的性能分析数据。本文主要介绍实施APM策略需要考虑的核心点。这些核心点包括：业务事务优化快照调优阈值调优服务级别管理获取上下文信息APM系统的实现非常困难。但是像AppDynamics这样的系统大大简化了APM的实施。通过使用AppDynamics，开发者可以很容易地在应用程序中实现APM，而不会对应用程序本身造成太大的影响（APM代码的引入也会造成一定的性能下降）。
