本系列文章涵盖了很多领域：它概述了应用程序性能管理 (APM)，它确定了实施 APM 策略的挑战，它提出了用于衡量评估应用程序运行状况的前 5 个重要指标列表企业 PHP 应用程序，它介绍了 AppDynamics 构建 APM 解决方案的方法。在这最后一期中，本文提供了一些提示和技巧来帮助您实施最佳的 APM 策略。具体而言，本文涉及以下主题：
- 业务交易优化
- 快照调整
- 阈值调整
- 层级管理
- 捕获上下文信息
业务交易优化
在本系列文章中，我一再强调业务交易对您的监控解决方案的重要性。然而，要充分利用您的业务交易监控，您需要做几次：
- 正确命名您的业务交易以匹配您的业务功能
- 正确识别您的业务交易
- 通过排除您不关心的业务交易来减少噪音
AppDynamics 将自动为您识别业务交易，并尝试为其命名，但根据您的应用程序的编写方式，这些名称可能反映也可能不反映业务交易本身。例如，您可能有一个标识为“POST /payment”的业务交易，这等同于您的结账流程。在这种情况下，如果业务交易名称反映了它们的业务功能，那么对于您的运营人员以及生成您可能与高管共享的报告时都会更容易。因此考虑将此业务交易重命名为“Checkout”。
接下来，如果您有多个由单个入口点标识的业务交易，请花时间将它们分解为单独的业务交易。有几个可能会发生这种情况的示例，其中包括：
- 路由到相同 MVC 控制器和操作的 URL
- 根据有效载荷确定其功能的业务事务
- 根据 GET 参数确定其功能的业务事务
- 复杂的 URI 路径
如果单个入口点对应于多个业务功能，则根据区分标准配置业务交易。例如，如果 HTTP POST 的正文有一个“操作”元素，用于标识要执行的操作，则根据该操作中断事务。或者，如果有接受“命令”URI 参数的“执行”操作，则根据“命令”段中断事务。最后，URI 模式可能因应用程序而异，因此选择最适合您的应用程序的模式对您来说很重要。例如，AppDynamics 自动为基于两个段的 URI 定义业务事务，例如 /one/two。对于大多数 PHP MVC 框架，这会自动路由到应用程序控制器和操作。如果您的应用程序使用一个段或四个段，那么您需要根据您的命名约定来定义您的业务交易。
命名和识别业务交易对于确保您捕获正确的业务功能很重要，但尽可能多地排除噪音也同样重要。您是否有任何您真的不关心的业务交易？例如，是否有每隔几分钟检查一次高分的网页游戏？或者是否有一个每晚运行的 PHP CLI cron 作业，需要很长时间，但因为它处于离线状态并且不会影响最终用户，所以您不在乎？如果是这样，则排除这些交易，以免它们给您的分析增加噪音。
快照调整
如上一篇文章所述，AppDynamics 通过在指定时间间隔分析 PHP 代码执行而不是对所有快照元素利用代码检测，以及通过限制在性能会话中捕获的快照数量来智能地捕获性能快照。因为这两个值都可以调整，所以调整它们可以使您受益。
开箱即用，AppDynamics 捕获整个堆栈跟踪，同时修剪任何低于配置阈值的粒度。如果您只对“大”性能问题感兴趣，那么您可能不需要 10 毫秒那么细的粒度。您可以将此间隔增加到 50 毫秒，但会失去粒度。如果您正在微调您的应用程序，那么您可能需要 10 毫秒的粒度，但如果您无意调整执行时间低于 50 毫秒的方法，那么您为什么需要该级别的粒度？关键是您应该分析您的需求并相应地进行调整。
接下来，观察您的生产故障排除模式并确定 AppDynamics 捕获的快照数量是否适合您的情况。如果你发现，虽然每分钟最多捕获 5 个快照，持续 5 分钟会产生 20 个或更多快照，但你只查看其中的 2 个快照，然后就不必费心捕获 20 个。尝试配置 AppDynamics 以捕获最多 1 个快照分钟 5 分钟。如果您只对系统问题感兴趣，那么您可以将最大尝试次数降低到 5 次。这将显着减少持续的开销，但代价是可能无法捕获具有代表性的快照。
阈值调整
AppDynamics 设计了一个通用的监控解决方案，因此，它默认对慢于正常两个标准偏差的业务交易发出警报。这在大多数情况下都适用，但您需要确定您的应用程序响应时间的波动性，以确定这是否是满足您业务需求的最佳配置。
AppDynamics 定义了三种类型的阈值，根据这些阈值评估业务交易及其基线：
- 标准偏差：将业务事务的响应时间与其基线的许多标准偏差进行比较
- 百分比：将业务事务的响应时间与基线的差异百分比进行比较
- 静态 SLA：将业务事务的响应时间与静态值（例如 2 秒）进行比较
如果您的应用程序响应时间不稳定，则两个标准差的默认阈值可能会导致过多的错误警报。在这种情况下，您可能希望将其增加到更多标准偏差，甚至切换到另一种策略。如果您的应用程序响应时间具有低波动性，那么您可能希望降低阈值以更快地提醒您注意问题。此外，如果您向具有特定 SLA 的用户提供服务或 API，那么您应该为该业务交易设置一个静态 SLA 值。 AppDynamics 为您提供了一般定义警报规则或针对单个业务交易的灵活性。
您需要分析您的应用程序行为并相应地配置警报引擎。
层级管理
我已经描述了 AppDynamics 如何捕获业务交易的基线，但它也捕获跨层业务交易的基线。例如，如果您的业务交易调用规则引擎服务层，那么 AppDynamics 将捕获该层的调用次数和平均响应时间，作为业务交易基线的贡献者。因此，您要确保清楚地标识所有层级。
开箱即用，AppDynamics 识别跨通用协议的层，例如 HTTP、PHP CLI、PHP MVC 等。例如，如果它看到您进行了数据库调用，那么它会假定存在数据库并将方法调用所花费的时间分配给数据库。这很重要，因为您不想认为 ORM 类中的“保存”方法非常慢，而是想知道将对象持久保存到数据库并将该时间归因于数据库需要多长时间。
AppDynamics 在识别遵循通用协议的层方面做得很好，但有时您与后端系统的通信不使用通用协议。例如，我在一家使用 AS/400 进行报价的保险公司工作。我们利用了一个使用专有套接字协议的库来建立与服务器的连接。显然，AppDynamics 对套接字连接及其使用方式一无所知，因此我们问题的答案是识别与 AS/400 建立连接的方法调用，并将其识别为自定义后端资源。当您这样做时，AppDynamics 将该方法调用视为一个层并计算调用次数并捕获该方法执行的平均响应时间。
您可能能够使用开箱即用的功能，但如果您有特殊要求，那么 AppDynamics 提供了一种机制，允许您使用 PHP API 函数手动定义应用程序层，以进一步定制您的应用程序。
捕获上下文信息
当出现性能问题时，它们有时仅限于特定的浏览器或移动设备，或者它们可能仅基于与请求相关的输入而发生。如果问题不是系统性的（跨所有服务器），那么您如何识别导致问题的请求子集？
答案是您需要在快照中捕获特定于上下文的信息，以便您可以寻找共性。这些可能包括：
- HTTP 标头，例如浏览器类型（用户代理）、cookie 或引荐来源网址
- HTTP GET 参数值
- 方法参数值
- 应用程序变量及其值
想一想您可能需要排除故障并隔离性能不佳的 PHP 事务子集的所有信息。例如，如果您捕获 User-Agent HTTP 标头，那么您就可以知道用户用来执行您的业务交易的浏览器。如果您的 HTTP 请求接受 GET 参数，例如搜索字符串，那么您可能希望查看其中一个或多个参数的值，例如，用户在搜索什么？此外，如果您对应用程序的工作方式有代码级的了解，您可能希望查看特定方法参数的值。
AppDynamics 可以配置为捕获上下文信息并将其添加到快照中，快照可以包括上述所有类型的值。该过程可以概括如下：
- AppDynamics 观察到业务交易运行缓慢
- 它触发快照会话的捕获
- 在每个快照上，它会捕获您请求的上下文信息并将其与快照相关联
结果是，当您找到说明问题的快照时，您可以查看此上下文信息以查看它是否为您提供了更多诊断信息。
唯一的警告是这是一个很小的代价：AppDynamics 使用代码检测来捕获方法参数的值。换句话说，在需要的地方使用此功能，但要谨慎使用。
结论
应用程序性能管理 (APM) 是一项挑战，它平衡了数据的丰富性和诊断 PHP 性能问题根本原因的能力，同时捕获该数据所需的开销最少。您可以使用配置选项和调整功能来为您提供所需的信息，同时最大限度地减少应用程序的开销。本文回顾了任何实施 APM 策略的人都应该考虑的一些核心提示和技巧。具体而言，它提出了以下建议：
- 业务交易优化
- 快照调整
- 阈值调整
- 层级管理
- 捕获上下文信息
APM 并不容易，但像 AppDynamics 这样的工具可以让您轻松捕获所需的信息，同时减少对生产应用程序的影响。