查询 Trace 时的常见问题
目录
为什么找不到需要的 Trace 数据？
1. Trace 采样率过低
如果 Service Mesh 中的 Trace 采样率设置过低，可能只有在请求量足够大时才能看到 Trace 数据。
您可以根据需求提高采样率。
2. 查询非常近期的 Trace 数据
当查询近期时间段（例如最近 30 分钟）的 Trace 数据时，如果查询结果中不包含最近 10 秒内的数据，这是正常现象。您可以稍等片刻，刷新页面后重试。
这是因为 Trace 数据存储在 Elasticsearch 中，Elasticsearch 提供近实时的搜索能力。
此外，ASM 在 Elasticsearch 中配置的 Trace 索引默认设置为 "refresh_interval": "10s"，意味着 Elasticsearch 每 10 秒将内存中的数据刷新到磁盘，刷新后数据才可被搜索。
该索引配置有效降低了 Elasticsearch 的数据合并压力，提高了索引速度和初次查询性能，但会略微降低数据的实时性。
您可以通过 jaeger-collector 的启动参数 --es.asm.index-refresh-interval 调整此配置，默认值为 10s。
如果该参数设置为 "null"，则不会配置索引的 refresh_interval。
3. 查询条件设置不当
在进行 Trace 查询时，如果对 Span kind 参数背后的技术原理理解不足，可能导致查询无数据返回。因此，不建议随意使用该参数。特别是同时指定 Client 和 Server 时，可能会导致查询结果为空。
示例 1：Span kind 设置为 Root Span，且同时指定了 Client 和 Server
此时查询将返回无数据。原因是当客户端和服务端均由 OTel Agent 管控时，Trace 的根 Span 通常在客户端，服务端数据不会被检索。解决方法是移除 Server 条件或避免选择 Root Span。
示例 2：Span kind 设置为 Service Entry Span，且同时指定了 Client 和 Server
同样，此查询也会返回无数据。原因是当客户端和服务端均注入了 Sidecar 时，Service Entry Span 指的是服务端接收的第一个请求，但 Trace 数据存储在客户端。解决方法是移除 Client 条件或避免选择 Service Entry Span。
为什么查询到的 Trace 不完整？
1. 当前时间段的 Trace 数据不完整
当查询近期时间段（例如最近 30 分钟）的 Trace 数据时，如果 Trace 中的 Span 不完整，这是正常现象。您可以稍等片刻，刷新页面后重试。
这是因为 Elasticsearch 正在将最新的 Span 刷新到磁盘，有些 Span 可能尚未生成或写入磁盘，导致 Trace 结果不完整。
2. 长时长 Span 的 Trace 不完整
如果查询的 Trace 时长较长（例如超过一小时），返回不完整数据也是正常的。
默认情况下，ASM 查询某个 Span 的 Trace 时，查询时间范围会在该 Span 的开始和结束时间基础上各延长一小时。
例如，某个 Span 开始时间为 08:12:30 ，结束时间为 08:12:32 ，则该 Trace 的查询时间范围为 07:12:30 到 09:12:32 。
因此，如果 Trace 时长超过一小时，通过该 Span 查询可能无法获取完整 Trace。
如果您环境中的 Trace 通常时长较长，可以通过 jaeger-query 的启动参数 --es.asm.span-trace-query-time-adjustment-hours 调整单个 Trace 的查询时间范围。
该参数默认值为一小时，您可以根据需要增加。