Grafana Tempo中TraceQL Metrics字段检索问题的分析与解决

问题背景

在Grafana Tempo的TraceQL查询中，当使用结构运算符(如父子关系操作符">")进行指标计算时，发现某些字段无法正确检索。这个问题在简单的查询场景下就能复现，例如：

{ span:name = "article-to-cart" } > { } | rate() by (span:name)

上述查询本应计算满足条件的span的速率并按span名称分组，但返回的结果却不正确。

问题现象

开发人员发现，当使用结构运算符后跟指标计算函数(如rate())时，指定的分组字段(如span:name)经常无法正确获取。这导致分组指标计算出现偏差或完全错误的结果。

有趣的是，这个问题可以通过以下两种方式临时解决：

1. 在结构运算符的右侧添加非空条件：

{ span:name = "article-to-cart" } > { span:name != nil } | rate() by (span:name)

2. 在指标计算前显式选择字段：

{ span:name = "article-to-cart" } > { } | select(span:name) | rate() by (span:name)

深入分析

这个问题不仅出现在简单的父子关系查询中，也出现在其他更复杂的场景。例如，有用户报告在尝试计算特定服务的API请求速率时遇到了类似问题：

{resource.service.name="server_foo" && name="GET /api/user" } >> {kind=client && span.server.address="server_bar"} | rate() by (span.client.address)

在这种情况下，虽然基础查询能返回正确的trace结果，但应用rate()或count_over_time()函数后却返回零值或空结果。

技术根源

经过分析，这个问题源于TraceQL引擎在处理结构运算符后的字段检索逻辑存在缺陷。当使用结构运算符时，引擎未能正确保留和传递后续指标计算所需的字段信息，特别是在以下情况：

1. 结构运算符右侧没有显式引用需要分组的字段
2. 查询管道中没有显式选择需要分组的字段

这种问题在以下场景更为明显：

• 当匹配的trace较为稀少时
• 当使用count_over_time等时间窗口函数时

解决方案

开发团队已经提交了修复代码，主要改进了以下方面：

1. 优化了结构运算符后的字段保留机制
2. 确保指标计算函数能够正确访问所需的分组字段
3. 改进了字段传递的可靠性

用户可以通过测试镜像zalegrala/tempo:tempoMetricsExemplarBy-e2b6fb48a来验证修复效果。

最佳实践建议

在使用TraceQL进行指标计算时，建议：

1. 对于结构运算符后的指标计算，显式选择需要的分组字段
2. 在结构运算符的右侧添加非空条件来确保字段可用性
3. 对于复杂的指标查询，分步验证各阶段的字段可用性

这个问题提醒我们，在使用高级查询功能时，理解底层数据检索机制的重要性，以及显式指定所需字段的价值。