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

常见问题

编辑

常见问题

编辑

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

APM Server:

Applications UI:

没有数据被索引
编辑

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

Elastic Agent 是否健康？

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

APM Server 是否正常运行？

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

APM 代理能否连接到 APM Server

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

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

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

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

检测间隙

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

常见的 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编辑

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

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

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

getsockopt：连接被拒绝编辑

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

由于目标计算机主动拒绝连接，因此无法建立连接编辑

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

I/O 超时
编辑

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

您可能会在 APM 代理日志中看到如下错误，和/或在 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 代理到负载均衡器再到 APM Server 递增。

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

例如

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

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

超出字段限制
编辑

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

例如，您应该避免将用户指定的数据（如 URL 参数）用作标签键。同样，将当前时间戳或用户 ID 用作标签键不是一个好主意。但是，具有高基数的标签值不是问题。只需尽量减少不同标签键的数量即可。

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

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

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

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

过多的唯一事务名称
编辑

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

要修复大量唯一事务名称，您需要更改使用 APM 代理 API 命名事务的方式。为此，请确保您不根据可能更改的参数进行命名。例如，应删除用户 ID、产品 ID、订单号、查询参数等，并且应在唯一 URL 之间找到共性。

让我们来看一下 RUM 代理文档中的示例。以下是一些您可能在 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 unknown route”或“unknown route”，则可能表明某些地方没有按预期工作。

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 中，转到Stack Management > 数据视图。您应该看到 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 宕机时会发生什么？ »