无法查询到所需的 Trace

目录

问题描述

在服务网格中查询 Trace 时,可能会遇到无法获取目标 Trace 的情况。

根因分析

1. Trace 采样率配置过低

当 Trace 的采样率参数设置过低时,系统只会按比例采集 Trace 数据。在请求量不足或低峰期时,采样数据可能低于可见阈值。

2. Elasticsearch 实时性限制

Elasticsearch 索引的默认配置为 "refresh_interval": "10s",导致数据从内存缓冲刷新到可搜索状态存在 10 秒的延迟。查询最近生成的 Trace 时,可能因数据尚未持久化而出现查询结果缺失。

该索引配置能有效降低 Elasticsearch 的数据合并压力,提高索引速度和首次查询速度,但也在一定程度上降低了数据的实时性。

3. 查询条件设置不当

进行 Trace 查询时,如果对 Span kind 参数背后的技术原理理解不充分,可能导致无数据返回。因此不建议随意使用该参数。尤其是同时指定 ClientServer 时,可能导致查询结果为空。

示例 1:Span kind 设置为 Root Span,同时指定 ClientServer

此时查询将返回无数据。原因是当客户端和服务器均由 OTel Agent 管控时,Trace 的根 Span 通常在客户端,服务器端数据不会被检索。解决方法是移除 Server 条件或避免选择 Root Span

示例 2:Span kind 设置为 Service Entry Span,同时指定 ClientServer

同样,该查询也会返回无数据。原因是当客户端和服务器均注入 Sidecar 时,Service Entry Span 指服务器接收的第一个请求,但 Trace 数据存储在客户端。解决方法是移除 Client 条件或避免选择 Service Entry Span

根因 1 的解决方案

  • 根据需求适当提高采样率。
  • 使用更丰富的采样方式,如尾采样(tail sampling)。

根因 2 的解决方案

通过 jaeger-collector 的启动参数 --es.asm.index-refresh-interval 调整刷新间隔,默认值为 10s

如果该参数值为 "null",则不会配置索引的 refresh_interval

注意:设置为 "null" 会影响 Elasticsearch 的性能和查询速度。

根因 3 的解决方案

使用 Trace 查询中的 Span kind 参数时:

  • 避免同时使用 ClientServer 条件
  • 对于 Root Span 查询:
    • 若客户端和服务器均存在,移除 Server 条件
    • 或者若需要服务器端数据,避免选择 Root Span
  • 对于 Service Entry Span 查询:
    • 若客户端和服务器均存在,移除 Client 条件
    • 或者若需要客户端数据,避免选择 Service Entry Span