« APM 故障排除 APM Server 或 Elasticsearch 宕机时会发生什么？ »
Elastic 文档 ›Elastic 可观测性 [8.16] ›应用程序和服务监控 ›应用性能监控 (APM) ›APM 故障排除

常见问题

编辑

常见问题

编辑

本节介绍在使用 APM Server 和 Kibana 中的应用程序 UI 时可能遇到的常见问题。

APM Server:

应用程序 UI:

未索引数据
编辑

如果 Elasticsearch 中没有显示任何数据，首先请确保您的 APM 组件已正确连接。

Elastic Agent 是否健康？

在 Kibana 中打开 Fleet 并找到运行 APM 集成的主机；确认其状态为 健康。如果不是，请检查 Elastic Agent 日志以诊断潜在原因。请参阅 监控 Elastic Agent 以了解更多信息。

APM Server 是否正常？

在 Kibana 中，打开 Fleet 并选择运行 APM 集成的主机。打开 日志 选项卡并选择 elastic_agent.apm_server 数据集。查找可能有助于诊断问题的任何 APM Server 错误。

APM Agent 是否可以连接到 APM Server

要确定 APM Agent 是否可以连接到 APM Server，请向已检测的服务发送请求，并在 APM Server 日志中查找包含 [request] 的行。

如果未记录任何请求，请确认

  1. SSL 未 错误配置。
  2. 主机是否正确。例如，如果您使用的是 Docker，请确保绑定到正确的接口（例如，设置 apm-server.host = 0.0.0.0:8200 以匹配任何 IP）并在 APM Agent 中相应地设置 SERVER_URL 设置。

如果您看到请求通过 APM Server 但未被接受（响应代码不是 202），请参阅 APM Server 响应代码 以缩小可能原因的范围。

检测差距

APM Agent 为许多流行的框架和库提供自动检测。如果 APM Agent 未自动检测您期望的内容，则不会将数据发送到 Elastic Stack。参考相关的 APM Agent 文档 以了解自动检测的内容的详细信息。

常见的 SSL 相关问题
编辑
SSL 客户端连接失败编辑

目标主机可能无法访问或证书可能无效。要解决此问题

  1. 确保目标主机上的 APM Server 进程正在运行并且您可以连接到它。尝试 ping 目标主机以验证您是否可以从运行 APM Server 的主机访问它。然后使用 nc 或 telnet 确保端口可用。例如

    ping <hostname or IP>
telnet <hostname or IP> 5044
  2. 验证证书是否有效以及主机名和 IP 是否匹配。
  3. 使用 OpenSSL 测试与目标服务器的连接并诊断问题。有关更多信息，请参阅 OpenSSL 文档。
x509：无法验证 <IP 地址> 的证书，因为它不包含任何 IP SAN编辑

发生这种情况是因为您的证书仅对主题字段中存在的主机名有效。要解决此问题，请尝试以下解决方案之一

  • 为主机名创建 DNS 条目，将其映射到服务器的 IP。
  • 在 /etc/hosts 中为主机名创建条目。或者，在 Windows 上，在 C:\Windows\System32\drivers\etc\hosts 中添加一个条目。
  • 重新创建服务器证书并为服务器的 IP 地址添加主题备用名称 (SAN)。这使得服务器的证书对主机名和 IP 地址都有效。
getsockopt：没有路由到主机编辑

这不是 SSL 问题。这是一个网络问题。确保这两个主机可以通信。

getsockopt：连接被拒绝编辑

这不是 SSL 问题。确保 Logstash 正在运行并且没有防火墙阻止流量。

无法建立连接，因为目标计算机主动拒绝了它编辑

防火墙拒绝连接。检查客户端、网络或目标主机上的防火墙是否阻止了流量。

I/O 超时
编辑

当您在整个堆栈中的超时设置配置不正确时，可能会发生 I/O 超时，尤其是在使用负载均衡器时。

您可能会在 APM Agent 日志中看到如下错误，或者在 APM Server 端看到类似的错误

[ElasticAPM] APM Server responded with an error:
"read tcp 123.34.22.313:8200->123.34.22.40:41602: i/o timeout"

要解决此问题，请确保超时从 APM Agent、通过您的负载均衡器到 APM Server 递增。

默认情况下，代理超时设置为 10 秒，服务器超时设置为 3600 秒。您的负载均衡器应设置在这两个数字之间。

例如

APM agent --> Load Balancer  --> APM Server
   10s            15s               3600s

可以通过更新 读取整个请求的最大持续时间 来配置 APM Server 超时。

字段限制超出
编辑

在事务或跨度上添加太多不同的标签键时，您有风险导致 映射爆炸。

例如，您应该避免将用户指定的数据（如 URL 参数）用作标签键。同样，使用当前时间戳或用户 ID 作为标签键也不是一个好主意。但是，具有高基数的标签 值 不会有问题。只需尝试将唯一标签键的数量保持在最低限度。

映射爆炸的症状是事务和跨度在一段时间后不再被索引。通常，在第二天，跨度和事务将再次被索引，因为每天都会创建一个新的索引。但是，一旦达到字段限制，索引就会再次停止。

在代理日志中，您不会看到任何故障迹象，因为 APM 服务器会异步地将从代理接收到的数据发送到 Elasticsearch。但是，APM 服务器和 Elasticsearch 会记录如下警告

{\"type\":\"illegal_argument_exception\",\"reason\":\"Limit of total fields [1000] in [INDEX_NAME] has been exceeded\"}
基于尾部的采样导致系统内存使用率高和磁盘 IO 高
编辑

基于尾部的采样需要最少的内存来运行，并且 RSS 内存使用量不应有明显的增加。但是，由于基于尾部的采样将数据写入磁盘，因此由于磁盘 IO，可能会看到 OS 页面缓存内存使用量显着增加。如果您在启用基于尾部的采样后看到吞吐量下降和过多的磁盘活动，请确保系统中有足够的内存空间供 OS 页面缓存有效执行磁盘 IO。

唯一事务名称过多
编辑

事务名称在每个 APM Agent 中定义；当 APM Agent 支持某个框架时，它会包含用于命名该框架创建的事务的逻辑。但在某些情况下，例如当使用 APM Agent 的 API 创建自定义事务时，用户需要定义事务命名的模式。当事务命名不正确时，每个唯一的 URL 都可以与唯一的交易组关联，从而导致每个服务的交易组数量激增，并导致应用程序 UI 中出现不准确。

要解决大量唯一事务名称的问题，您需要更改使用 APM Agent API 命名事务的方式。为此，请确保您 没有 基于可能更改的参数进行命名。例如，用户 ID、产品 ID、订单编号、查询参数等应被删除，并且应该在唯一的 URL 之间找到共性。

让我们看看 RUM Agent 文档中的一个示例。以下是在 Elastic.co 上可能找到的一些 URL

// Blog Posts
https://elastic.ac.cn/blog/reflections-on-three-years-in-the-elastic-public-sector
https://elastic.ac.cn/blog/say-heya-to-the-elastic-search-awards
https://elastic.ac.cn/blog/and-the-winner-of-the-elasticon-2018-training-subscription-drawing-is

// Documentation
https://elastic.ac.cn/guide/en/elastic-stack/current/index.html
https://elastic.ac.cn/guide/en/apm/get-started/current/index.html
https://elastic.ac.cn/guide/en/infrastructure/guide/current/index.html

这些 URL 与大多数 URL 一样，包含唯一的名称。如果我们根据每个唯一的 URL 命名事务，我们将遇到上面描述的问题——大量不同的事务名称。相反，我们应该删除唯一信息，并根据通用信息对事务进行分组。在本例中，这意味着将所有博客事务命名为 /blog，并将所有文档事务命名为 /guide。

如果您觉得遵循此命名约定会丢失有价值的信息，请不要担心！您可以始终使用 标签（已索引）或 自定义上下文（未索引）将其他元数据添加到您的事务中。

确保您已正确命名事务后，您可能仍会在应用程序 UI 中看到与已达交易组限制相关的错误

已达到交易组数量。当前 APM 服务器处理唯一交易组的能力已达到上限。此列表中至少缺少 X 个事务。请减少服务中的交易组数量或增加分配给 APM 服务器的内存。

如果代理创建了过多的事务组，您将看到此警告。这可能表示检测不正确，需要在您的应用程序中修复。或者，您可以增加APM服务器的内存。

事务组数量超过显示的允许最大值 (1,000)。Kibana 中显示的事务组数量已达到最大值。请尝试使用查询栏缩小结果范围。

如果您的结果包含超过 1000 个唯一事务组，您将看到此警告。或者，您可以使用查询栏减少结果中唯一事务组的数量。

更多信息

虽然这可能发生在任何APM代理中，但通常发生在RUM代理中。有关如何在RUM代理中正确设置 transaction.name 的更多信息，请参阅 自定义初始页面加载事务名称。

RUM代理还可以在观察事务事件时设置 transaction.name。有关更多信息，请参阅 apm.observe()。

如果您的问题发生在其他APM代理中，以上提示仍然适用。请参阅相关的 代理API文档 以调整命名事务的方式。

未知路由
编辑

只有当服务中的事务被正确命名时，事务概述 才会显示有用的信息。如果您在应用程序UI中看到“GET未知路由”或“未知路由”，这可能表示某些内容未按预期工作。

Elastic APM代理开箱即用地支持流行的框架。这意味着，除其他事项外，APM代理将尝试自动命名HTTP请求。例如，Node.js代理使用处理请求的路由，而Java代理使用Servlet名称。

“未知路由”表示APM代理无法确定请求的名称，可能是因为您使用的技术不受支持、代理安装不正确，或者请求发生了代理无法理解的情况。

要解决此问题，您需要转到相关的 APM代理文档。具体来说，查看代理的支持的技术页面。您还可以使用代理的公共API手动设置事务的名称。

字段不可搜索
编辑

在Elasticsearch中，索引模板用于定义设置和映射，这些设置和映射确定如何分析字段。APM的推荐索引模板来自内置的Elasticsearch apm-data插件。默认情况下，这些模板会在某些字段上启用和禁用索引。

例如，某些APM代理将cookie值存储在 http.request.cookies 中。由于 http.request 禁用了动态索引，并且 http.request.cookies 未在自定义映射中声明，因此 http.request.cookies 中的值未被索引，因此无法搜索。

确保存在APM数据视图 作为第一步，您应该确保存在正确的数据视图。在Kibana中，转到堆栈管理 > 数据视图。您应该看到APM数据视图——默认值为 traces-apm*,apm-*,logs-apm*,apm-*,metrics-apm*,apm-*。如果看不到，则数据视图不存在。要修复此问题，请导航到Kibana中的应用程序UI并选择添加数据。在APM教程中，点击加载Kibana对象 以创建APM数据视图。

确保字段可搜索 如果您想确保字段可搜索，您可以执行以下两件事

  1. 将您的其他数据索引为 标签。这些标签默认情况下是动态的，这意味着它们将被索引并变得可搜索和聚合。
  2. 为该字段创建自定义映射。
服务地图：客户端和服务器之间没有连接
编辑

如果服务地图未显示客户端和服务器之间预期的连接，则可能是因为您未配置 distributedTracingOrigins。

例如，此设置对于跨源请求是必需的。如果您有一个基本的Web应用程序，它通过 localhost:4000 上的API提供数据，并从 localhost:4001 提供HTML，则需要设置 distributedTracingOrigins: ['https://127.0.0.1:4000'] 以确保源作为分布式跟踪的一部分进行监控。换句话说，在APM代理将分布式跟踪 traceparent 标头添加到每个请求之前，会先参考 distributedTracingOrigins。

« APM 故障排除 APM Server 或 Elasticsearch 宕机时会发生什么？ »