作为一名 DevOps 工程师或 SRE，经常需要调查复杂的问题，例如，间歇性地发生或仅发生在应用程序流量某些部分的奇怪的应用程序性能问题；这些问题不仅会影响您的最终用户，而且还可能会影响您公司的财务目标。筛选数百甚至数千个事务和跨度可能是一项繁琐、手动和耗时的调查工作。云原生或分布式微服务部署进一步增加了复杂性，因而确定根本原因所需的时间也随之加长。

如果您能快速确定一种共同的模式，帮助解释这样一个看似复杂的问题，从而揭开它的神秘面纱，并为更快地进行根本原因分析和补救铺平道路，岂不是很棒？

Elastic 可观测性中的 APM 关联性魔法

Elastic APM 关联性功能可自动呈现与高延迟或错误事务相关并且对整体服务性能最有显著影响的 APM 数据集属性。

APM 问题的调查工作流通常从 APM 视图的“Transactions”（事务）选项卡中启动。无论您是要调查高延迟事务还是失败事务，都需要先从可视化该特定事务组的延迟分布图中的异常值开始。高延迟事务显示在图表右侧，延迟和失败事务标签表明了影响程度。此外，图表上的第 95 个百分位注释可进一步帮助直观地区分真正的异常值。

下一步是在数据中寻找与这些异常值最相关的属性和因素，并将调查范围缩小到整个数据集中受影响的子组。换句话说，寻找缓慢或错误事务中比例过高地的属性。这些属性包括标签、标记、跟踪属性和元数据（如服务版本）；地理位置；设备类型；基础架构标识符；特定于云的标签（如前端服务的可用区、操作系统、客户端类型）；以及许多其他属性。目的是能够根据这些属性解释异常事务。例如，可以说“几乎所有高延迟事务都发生在 Kubernetes pod x 中”，或者“标签为 shoppingCartVolumeHigh 和服务版本为 a.b 的事务均告失败。”

想象一下，如果您必须手动检查所有这些属性（可能有数百个），以确定哪些特定属性可以帮助解释性能异常值！

Elastic 可观测性会自动将具有高延迟和错误的属性与完整事务集进行比较，并自动识别在次优事务中“特别常见”的标记和元数据。换句话说，就是找出在次优事务中明显比在完整事务集中更常见的元素。然后，Elastic 可观测性不仅可提供关联性，而且还会首先呈现关联性最高的属性。关联值（范围从 0 到 1.00，其中 1.00 表示完全关联）有助于快速表明匹配的程度。单击任何属性，即可查看带有相应属性的事务，这些事务以颜色编码并在分布图中显示，以进一步直观地显示重叠情况。

确定了这些关联因素后，您现在可以将关注范围缩小到这些事务上。单击筛选器“+”或“-”按钮，可仅选择具有此属性值的事务或排除此类事务，并进一步详细研究要调查的事务。对于延迟，下一步通常可能是只查看那些高延迟事务（这些事务也带有已识别的关联属性）的跟踪样例，然后眼前一亮看到罪魁祸首：跟踪中存在一个缓慢的函数调用。

一旦确认了根本原因，即可通过回滚、软件补丁或升级等机制启动补救和恢复过程。

接下来，我们思考一下失败事务的情况。在下面的示例中，“checkoutService”中的“/hipstershop.CheckoutService/PlaceOrder”事务组的失败事务率很高。

失败事务关联功能显示了南美用户的失败事务，如下图所示。

单击筛选器“+”按钮，即可重点查看这个特定的事务子集，并且系统会显示一个有错误的示例事务。

单击“View related error”（查看相关错误），用户将被重定向到相关错误详细信息页面（如下图所示），其中突出显示了与此终端关联的不同类型的错误。此外，还可在此获取显示错误发生位置的堆栈跟踪，了解增强的调试信息。

从上面的示例可以看出，APM 关联性功能在缩小缓慢或错误事务组范围方面为用户完成了大量的工作。因此，平均检测时间和解决问题的时间都显著减少。

辅助关联性所需的输入和数据

对于仅影响一部分群体的问题，APM 关联性功能可以显著加快对问题根本原因分析的速度。用于描述应用、服务、事务、基础架构和客户端的元数据越多，分析就越丰富，找到清晰解释次优事务的属性的概率就越高。该关联性功能会利用数据中存在的所有字段和标签。

使用“Overview”（概述）页面的“Add Integrations”（添加集成）工作流，可为您环境中部署的各种应用程序、基础架构和依赖项添加代理功能和/或数据采集功能。请注意，您还可以原生集成多种技术，包括基于云的 Kubernetes 等云原生环境和 Lambda 等无服务器技术。一旦确定了各种遥测数据源，即可通过 Logstash 或直接通过 APM 代理进一步扩充传入的数据。Elastic 还与 OpenTelemetry 数据无缝集成，并为其提供全面的原生支持（相应地也支持手动检测）。

客户端信息可以通过真实用户监测 (RUM) 数据引入。使用 Elastic RUM 代理时，默认情况下会启用分布式跟踪，而且通过设置 distributedTracingOrigins 配置选项，可以轻松配置跨源请求的跟踪和跟踪状态的传播。通过这种方式与 APM 相结合，RUM 增加了丰富的客户端信息（如浏览器版本、客户端操作系统和用户上下文），而且所有这些数据都会自动包含在关联性测定中。

这些数据流入 Elastic 后，APM 关联性就可以发挥作用，从而提供清晰明了的调查见解，并在许多情况下缩短确定根本原因所需的时间。

APM 关联性可以大幅缩短确定根本原因所需时间的情况

从定义上讲，复杂问题不是一成不变的，无法通过一项功能就能一劳永逸。毕竟，许多 APM 问题都被认为复杂的，正是因为在调查中存在许多未知因素。否则，只有几个已知的问题，我们就会知道要寻找什么，那些问题也就不再复杂了！

然而，对于许多复杂的调查，APM 关联性可以成为调查工具包的重要组成部分，用于快速将关注范围缩小到部署的特定区域，并确定或验证根本原因。一个关键考虑因素是：您的问题是影响整个部署还是只影响一些子群体？例如，您是否看到所有事务都存在高延迟问题？或者，您是否看到一小部分事务显示出高延迟，而其他事务似乎在预期范围内运行？如果您注意到问题并不普遍存在时，则应考虑使用 APM 关联性功能，看一看某个属性子集是否有助于描述所调查的事务。借助这些属性，您可以筛选出更小、更易于管理的事务集，并通过检查其痕迹来发现根本原因，或者查看引发事务性能问题的基础架构依赖项。

以下是我们看到 APM 关联性特别有效的示例情况：

硬件性能问题：特别是在特定负载由特定硬件提供服务的负载均衡情况下，硬件性能下降又会导致某些用户组或应用程序的某些部分出现更高的延迟。APM 关联性可以通过标签和标识符帮助快速隔离这些特定硬件实例。

利用的输入数据：

• 分布式跟踪中收集的 APM 代理的全局标签
• Elastic Agent 或 Metricbeat 的基础架构指标，以便在利用 APM 关联性功能后可继续进行调查

与超大规模业者租户或多云部署相关的问题：超大规模业者为应用程序部署又增加了一层复杂性。多云和混合云部署越来越普遍。当对只影响应用程序某些部分的问题进行故障排查时，超大规模业者标签和标记（例如，云元数据）有助于检测哪些实例、云服务提供商、区域或可用区与该问题相关联。Elastic Java APM 代理允许使用配置变量自动检测云服务提供商。

利用的输入数据（由 APM 代理自动收集）：

• 云可用区
• 云区域

地理位置或用户组特定问题：标识特定地理位置或用户组的标记可以通过 APM 关联性呈现，并且可用于隔离一个用户群并仅研究这些事务。例如，Elastic Java APM 代理支持全局标签，此功能会利用这些标签，因此这些标签可以帮助提供其他上下文并识别群体的子集。Elastic APM 代理（如 Java APM 代理）支持全局标签的配置，可用于向所有事件添加其他元信息。全局标签会被添加到事务、指标和错误。同样，Java APM 代理 API 允许对可用于提取地理位置或用户组信息的事务进行手动检测。这些标签有助于重点关注服务中的重要或新类别/方法，可以加速根本原因分析、假设验证等。

利用的输入数据：

• 云元数据（由 APM 代理自动收集）
• 全局标签，可选择向事件添加元信息
• 通过手动检测添加的任何数据

与金丝雀部署或其他部分部署相关的问题：在企业应用程序部署中，尤其是在 SaaS 提供的应用程序中，同时运行多个版本的软件并不罕见。例如，金丝雀发布或 A/B 测试策略都是并发多版本部署。当应用程序的一个特定版本出现异常行为时，APM 关联性有助于找出错误的版本，缩小问题范围，从而更快地确定根本原因。服务版本可以通过自动检测或使用环境变量进行配置，例如在 Elastic Java APM 代理中。

利用的输入数据：

• 服务版本，通过自动检测或来自 APM 代理

客户端问题：特定浏览器版本或设备类型等客户端指标可立即帮助缩小范围和找到潜在原因，为进一步分析、解决和补救提供有价值的根本原因信息。

利用的输入数据：

• 通过 Elastic RUM 代理自动收集的客户端数据，如浏览器和操作系统版本、设备详细信息、网络类型等

第三方服务提供商的相关问题：在使用第三方提供商（如身份验证服务提供商）的情况下，APM 关联性有助于快速识别与特定提供商有关的问题。这可以通过使用 SDK（Elastic 或 OTel）添加自定义标签来识别身份验证提供商实现。在其他类似场景中，仅靠自动检测不足以提供加快根本原因分析所需的相关上下文，在这种情况下，定制标签可能会非常有用。

利用的输入数据：

• 通过 Elastic 或 OTel SDK 添加的定制标签
• 全局标签

…以及更多用例，您已大致了解。关联性有助于发现对服务的某些部分有影响（服务的其他部分似乎运行顺畅）的复杂问题。

另一方面，在某些情况下，APM 关联性可能无法提供最佳的结果。这方面的示例包括：在整个应用程序服务中出现的普遍问题，而不是只影响特定的较小子群体或用户群。在这种情况下，许多不同的标记、标签或指标可能都与次优事务高度相关，对进一步调查几乎没有价值。最后，如果相关数据不存在或没有足够的描述符和标签，则可能根本无法检测到关联性。请参阅前面关于辅助关联性所需的输入和数据部分。

尽管如此，对于许多 APM 调查，APM 关联性功能都算得上是一个强大的工具，可帮助快速将调查范围缩小到特定的事务组。在许多情况下，这些关联事务会让您快速找到根本原因，从而大大缩短调查时间。

祝您顺利排除故障！

其他资源和信息

APM 关联性功能从 7.15 版开始正式发布。单击此处可查看有关该功能的发行说明。

此处提供了 APM 关联性功能的用户指南和文档。