Grafana Tempo 2.8 版本特性详解:TraceQL 指标函数、内存优化与升级注意事项

发布时间:2026/9/18 3:21:17

Grafana Tempo 2.8 版本特性详解:TraceQL 指标函数、内存优化与升级注意事项 Grafana Tempo 2.8 版本特性详解TraceQL 指标函数、内存优化与升级注意事项【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempoTempo 2.8 是 Grafana Tempo 分布式链路追踪后端的一次重要版本更新核心亮点集中在三个方面为 TraceQL 增加了topk/bottomk排序函数、sum_over_time聚合函数与most_recent实验性查询提示帮助用户在成百上千的服务与端点中快速定位异常通过去除大 trace 的内存池化、迭代器优化与背压机制显著降低内存与查询开销同时在安全与运维层面落地了更安全的默认配置端口 3200、distroless 镜像、Go 1.24与若干破坏性变更。读完本文你将完整掌握 Tempo 2.8 新增 TraceQL 语法的用法、性能优化的实现思路、以及升级时必须处理的配置变更与安全修复清单。本文以 docs/sources/tempo/release-notes/version-2/v2-8.md 为骨架结合仓库源码如 pkg/traceql 下的解析器与执行引擎对各项特性做纵深补充。新增 TraceQL 语言特性Tempo 2.8 为 TraceQL 引入了三项强大的查询增强在 Grafana Cloud 中查询 trace 时拥有更高的灵活性与性能使用新的topk(n)与bottomk(n)函数对指标排序快速获得排名最高/最低的时间序列使用sum_over_time()按时间步长聚合数值实现内置的累计求和如总字节数、错误计数通过实验性的most_recenttrue查询提示优先取回最新 trace。指标排序函数 topk / bottomk在分析跨越数百上千个服务或端点的延迟、错误率、吞吐量时很容易在海量数据中迷失方向。过去你必须拉回全量聚合结果再人工检查或后处理才能找出最差或最好的对象。现在借助topk(n)与bottomk(n)可以在一条高效的查询中立即将视野收窄到排名前 n 或后 n 的 span 序列既节省时间又减少了后续需要扫描的数据量。其基本用法如下{} | avg_over_time(span:duration) by (span:name) | topk(10) {} | count_over_time() by (span:name) | bottomk(10)这两个函数都是第二级second stage函数作用于第一级聚合的中间结果topk(n)返回第一级聚合中取值最高的 n 个序列bottomk(n)返回取值最低的 n 个序列。从仓库源码看topk、bottomk作为关键字注册在 pkg/traceql/lexer.go 的 token 表中其执行语义定义在 pkg/traceql/ast_metrics.go 中String()方法分别返回topk与bottomk。pkg/traceql/test_examples.yaml 中收录了大量组合用法例如{} | rate() | topk(10) {} | rate() by (span.client_ip) | topk(10) {} | count_over_time() by (name) | topk(10) with(sample0.1) {} | quantile_over_time(duration, 0, 0.9, 1) by (span.http.path) | topk(10) ({} | rate()) ({} | rate()) | topk(5) 10可以看出topk/bottomk可以与rate()、count_over_time()、quantile_over_time()、avg_over_time()等第一级聚合自由组合甚至可以出现在算术表达式之后、与比较运算符连用如topk(5) 10实现“排名 阈值过滤”的复合筛选。sum_over_time 聚合函数sum_over_time()用于对数值型属性做累加聚合求和的时间区间由step参数决定。典型用法{ span.http.response_content_length 0 } | sum_over_time(span.http.response_content_length)有了sum_over_time()你可以在 TraceQL 内部直接计算累计和例如总传输字节数、总错误计数或资源消耗随时间的变化{} | sum_over_time(span.http.response_content_length)在每个 step 区间内sum_over_time(attr)会对所有匹配 span 的attr取值求和。该函数在 pkg/traceql/lexer.go 中注册为SUM_OVER_TIMEtoken与min_over_time、max_over_time、avg_over_time同属metricsAggregateSumOverTime一类聚合参见 pkg/traceql/ast_metrics.go。pkg/traceql/test_examples.yaml 中给出的示例{} | sum_over_time(duration) by (span.http.path)表明它还支持按标签分组后分别求和。实验性查询提示 most_recenttrue排查线上事故或监控生产健康时你往往需要最先看到最新的trace。默认情况下 Tempo 查询引擎偏向速度只返回最先匹配到的前 N 条 trace这些不一定是最新的。most_recent提示确保你始终看到最新数据从而避免因提前达到行数上限而错过最新的错误或性能回退。示例{} with (most_recenttrue) { span.foo bar } { status error } with (most_recenttrue)当设置most_recenttrue时Tempo 会在数据分片上执行更深的搜索、保留最新候选并按开始时间排序返回结果而不是在首次命中上限时就停止。该提示可作用于任何TraceQL 选择查询。从源码看most_recent是 pkg/traceql/enum_hints.go 中集中登记的查询提示之一HintMostRecent并被标记为非危险提示isUnsafe返回 false。在查询前端modules/frontend/search_sharder.go 通过MostRecentShards配置默认值 200见 modules/frontend/search_sharder.go控制该模式下用于回溯的 shard 数量因此更深的搜索也会带来更多的工作量。按父 span ID 查询2.8 还支持按父 span 的 ID 查询。使用span:parentID内在字段可以确保查询结果是指定父 span 的子 span这在 span 链接等场景中非常实用。该内在字段定义于 pkg/traceql/enum_attributes.goIntrinsicParentID对应的字符串形式为span:parentID见 pkg/traceql/enum_attributes.go并可通过span:parentID反向解析见 pkg/traceql/enum_attributes.go。主要的性能与内存改进Tempo 2.8 移除了大 trace 的池化pooling。测试表明移除大对象池化显著改善了内存占用在高流量/多租户部署下将内存高水位线high-water mark降低到不到原来的一半。不过仍保留部分池化以保证 CPU、吞吐量与 GC 频率处于合理水平现在使用固定的1M 默认分配大小足以覆盖大多数 trace。官方发布的 compactor 内存曲线图显示在 PR 4985 合入后 compactor 的内存占用获得了大幅改善该 PR 同时附有基准测试结果。性能改进清单TraceQL 与 Tempo 整体在本版本中获得了一系列性能提升还原 EqualRowNumber 为可内联函数以提升 TraceQL 性能PR 4705利用 max definition level 优化迭代器在 nexting大型查询中频繁调用的操作时忽略 RowNumber 的部分内容即使是微小的改进也会带来显著收益PR 4753增大 query-frontend 默认批处理大小TraceQL 性能已足以在一次 querier 上传递更大的批次并完成全部任务PR 4844改进 Tempo 构建选项PR 4755使用 rebatching 重写 tracePR 4690重排 span 迭代器PR 4754通过缓冲池化改进 memcached 内存占用PR 4970。特性与增强本节概括 Tempo 2.8 中最重要的特性与增强。TraceQL 正确性修复正确性correctness是本次版本的重点改进方向之一主要包括修复{.foo true}与{.foo || false}这类查询的行为PR 4855使与 nil 的比较对称化PR 4869修正 select 操作之后额外 spanset 过滤器导致的结果错误PR 4600修复非专用列non-dedicated columns中多个过滤器且按同一变量分组时 TraceQL 指标结果错误的问题PR 4887修复所有非平凡指标non-trivial metrics的流式输出PR 4624修复{} { span.attr-that-doesnt-exist ! foo }的行为PR 5007修复 query range 的各类边界情况PR 4962从compare()函数中排除nestedSetParent等其他值PR 5196。由于 query frontend 在执行 TraceQL 时会缓存单个 block 的任务结果这些修复也会影响缓存行为修复以.0结尾的浮点数导致的 TraceQL 结果缓存 bugPR 4539正确缓存 TraceQL 指标中 query range 的前端任务PR 4771修复 TraceQL 指标查询前端缓存 key 生成时的碰撞问题PR 5017。TraceQL 样例exemplar改进与修复Tempo 2.8 改善了 TraceQL 指标中的 exemplar将 exemplar 按时间分布并对 exemplar 数量设置硬上限PR 5158为直方图与分位数选择正确的 exemplarPR 5145修复被查询 exemplar 数量的问题PR 5115。此外在安全修复中还专门为 TraceQL 指标查询的 exemplar 提示增加了上限以防止无界内存分配对应 CVE-2026-27878。错误处理与日志改进Tempo 更新了错误处理方式使排障更简单更新 query range 错误消息PR 4929当 trace 大小超过速率限制时改进限流错误消息PR 4986恢复 compactor 中已完成 block 的专用列日志PR 4832query-frontend 日志在日志行中附加消息PR 4975。其他增强为TraceByID端点新增吞吐量 SLO 与指标可通过throughput_bytes_slo字段配置并会在 SLO 与吞吐量指标中填充optraces标签PR 4668防止 ingester 中的查询阻塞 trace 落盘与内存尖峰PR 4483Host Info Processor 现在在指标中跟踪标识主机的资源属性PR 5152distributor 新增 IPv6 支持PR 4840为 mutex 与阻塞值添加默认值PR 4979。升级注意事项升级到 Tempo 2.8 时需要注意以下破坏性变更与注意事项。默认监听端口变更Tempo 2.8 将默认http_listen_port从 80 改为3200。请检查 Tempo 配置文件中server:块的配置项server: # HTTP server listen host [http_listen_address: string] # HTTP server listen port [http_listen_port: int | default 3200]该变更的动机详见讨论 issue 4945实现于 PR 4960核心是让默认配置不再依赖特权端口从而降低部署与运维成本。移除 Tempo serverlessTempo serverless 已被移除以下配置项不再有效应从 Tempo 配置中删除PR 4599querier: search: prefer_self: int external_hedge_requests_at: duration external_hedge_requests_up_to: duration external_backend: string google_cloud_run: string external_endpoints: array此外以下与 serverless 相关的指标也已移除tempo_querier_external_endpoint_duration_seconds、tempo_querier_external_endpoint_hedged_roundtrips_total、tempo_feature_enabled。更新、移除或重命名的配置参数参数说明max_span_attr_byte重命名为max_attribute_bytesPR 4633tempo_discarded_spans_total从tempo_discarded_spans_total中移除internal_error原因PR 4554tempo_receiver_accepted_span与tempo_receiver_refused_spansname维度从tempo/jaeger_receiver变为jaeger/jaeger_receiverPR 4893其他升级注意点OTEL Collector 升级到 v0.122.1tempo_receiver_accepted_span与tempo_receiver_refused_spans的name维度从tempo/jaeger_receiver变为jaeger/jaeger_receiverPR 4893Tempo query 中将以otelgrpc替换opentracing-contrib/go-grpcPR 4958在 event、link 与 instrumentation scope 级别强制 max attribute size配置改为按租户per-tenant并将max_span_attr_byte重命名为max_attribute_bytesPR 4633SLO 指标query_frontend_bytes_processed_per_second从 histogram 转为 counter性能更高PR 4748移除已被弃用的 OpenTelemetry Jaeger exporterPR 4926。安全修复Tempo 2.8 在安全方面进行了密集的依赖升级与加固按补丁版本汇总如下。2.8.4Go 升级至 1.26.2修复 CVE-2026-25679PR 6800gRPC 模块补丁至 v1.79.3、go.opentelemetry.io/otel/sdk升级至 v1.40.0修复 CVE-2026-33186 与 CVE-2026-39883PR 6899otlptracehttp升级至 v1.43.0修复 CVE-2026-39882PR 6890otlpmetrichttp升级至 v1.43.0修复 CVE-2026-39882PR 6889github.com/go-jose/go-jose/v4升级至 v4.1.4修复 CVE-2026-34986PR 6908github.com/antchfx/xpath升级至 v1.3.6修复 CVE-2026-32287PR 6763为 TraceQL 指标查询的 exemplar 提示设置上限防止无界内存分配修复 CVE-2026-27878PR 6792将搜索的默认max_result_limit设为262144256×1024。此前默认值0允许无界搜索结果集修复 CVE-2026-21728PR 6525。2.8.3Go 升级至 1.25.5修复 CVE-2025-61729、CVE-2025-47907、CVE-2025-58183 与 CVE-2025-61727PR 6089、6096、6227github.com/expr-lang/expr升级至 v1.17.7修复 CVE-2025-68156PR 6230、6092。2.8.2Go 升级至 1.24.4修复 CVE-2025-22874、CVE-2025-4673、CVE-2025-0913 与 GHSA-FV92-FJC5-JJ9HPR 5323。2.8.0采用 distroless 基础容器镜像以提升安全性PR 4556Go 升级至 1.24.3PR 5110。Bug 修复摘要除上述内容外Tempo 2.8 各补丁版本还包含以下重要修复。2.8.3修复无效查询api/v2/search/tagsSearchTagsV2时的死锁PR 5607、6228修复query_rangeHTTP 处理中因取消或其他错误可能触发的 panicPR 5667、6229修复某些配置项总是被运行时 overrides 覆盖、导致无法在不使用 overrides 配置的情况下设置的问题PR 5202修复 ingester 中 trace 空闲周期未正确生效的问题并新增 max live trace period默认 30s防止跨长时间滴灌 span 的超大 trace 被无限期驻留内存PR 5346修复SearchTagValuesV2端点提供无效 tag 名称时应返回 400 Bad Request 而非 500 Internal Server ErrorPR 5493。2.8.2为partitionAssignmentVar增加 nil 检查PR 5198修正 instant query 计算PR 5252修复 distributor HTTP 写入请求中的 tracing context 传播PR 5312修复短 trace ID 的trace:id搜索PR 5331修复查询同时覆盖 ingester 与少量其他 block 时most_recenttrue不返回最新结果的问题PR 5438修复avg_over_time聚合期间 counter series 缺失时的 panicPR 5300。2.8.1修复 ingester 中哈希碰撞导致 span 存储错误的问题PR 5276。2.8.0为 gRPC 流式 query range 请求选择默认 step若未提供并正确复制| rate()等指标在 gRPC 流式传输时的 exemplarPR 4576修复 distributor 中哈希碰撞导致 span 存储错误的问题PR 5186在 ReadRange 的缓存 key 中加入对象名PR 4982修复压缩compaction期间罕见的 panicPR 4915若查询中已过滤某 tag则将操作数作为唯一值返回PR 4673从默认配置转换为旧版配置时包含成本归属PR 4937memcached 尊重被取消的 context 以防止 panicPR 5041修复通过 API 设置用户配置 overrides 中的 processorsPR 4741修复启动时的 panicPR 4744修复超出最大 tag 查询响应大小时内在 tag 查询被丢弃的问题PR 4784修复 SyncIterator 中的错误传播PR 5045修复 mixin 以包含otlp_v1_tracesHTTP 写入路由PR 5072修复TempoBlockListRisingQuickly告警分组PR 4876修复 metrics generator host info processor 的 overrides 配置PR 5118修复 metrics generatortarget_info跳过无名称属性以防止下游错误PR 5148。总结Tempo 2.8 是一次兼顾查询能力增强与资源占用瘦身的版本topk/bottomk与sum_over_time让 TraceQL 指标查询从拉全量再后处理进化为一条查询直接出排名与累计值most_recenttrue与span:parentID则补齐了排障与 span 关联场景的拼图大 trace 池化移除与迭代器优化把 compactor 等环节的内存高水位线大幅压低。升级前请务必核对本文升级注意事项部分的端口变更、serverless 配置删除、max_attribute_bytes重命名等破坏性变更并参考各补丁版本的安全修复清单及时跟进依赖版本。【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
延伸阅读

更多相关文章

2026/9/18 3:21:17

JSON.stringify深入指南:序列化规则、replacer参数与常见坑

在实际开发里,JSON.stringify大概是每个前端每天都离不开、却又很少真正读懂它的一个方法。多数人用它的场景就是JSON.stringify(obj)一把梭,用来调试日志、存localStorage、深拷贝数据,偶尔遇到循环引用报错、BigInt报错、undefined被丢掉&a…

2026/9/18 3:16:17

LeetCode 92题详解:反转链表II的两种解法与指针操作细节

LeetCode 92题是我在刷链表题时觉得最值得反复琢磨的一道。如果你刷过LeetCode 206题(反转整个链表),再来看这道“反转链表II”,会发现它其实是把反转动作限定在一个区间内,难度直接从“入门”跳到了“必须熟练”。面试…

2026/9/18 3:16:17

Java视频分片上传的组件化设计:跨平台兼容的实践之路

在国防信息化项目里,视频上传从来不是“调个SDK就完事”的活。我见过太多团队从业务开发一路做到现场部署,被Windows、国产操作系统、ARM盒子这一堆终端形态折磨得日夜改代码,最后发现问题根本不是“网络不好”,而是从一开始就没把…

2026/9/18 5:06:21

B站API与视频下载全解析:从URL参数到接口调用实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/9/18 5:06:21

回归实战全攻略:从线性回归到XGBoost与边缘端量化

1. 为什么是回归:从问题定义到实战思路1.1 回归到底在解决什么如果你翻开任何一本机器学习的实战教程,前几章多半是线性回归、逻辑回归、决策树这些基础模型,而到了第四章这种节点,通常就开始“动真格”了。回归在机器学习里的地位…

2026/9/18 5:01:21

COMSOL自由落体模拟实战:全局ODE建模与瞬态求解全解析

晚上十一点,一个朋友突然在微信上找我:他用Comsol做自由落体模型,一个直径10mm的小球从10米高度落下,结果算了半天,小球纹丝不动。他贴了设置截图:组件选的是三维、固体力学接口,研究类型用的稳…

2026/9/16 12:52:37

拯救者Y7000黑屏故障排查与维修实战指南

1. 项目概述:一台黑屏的拯救者Y7000,到底卡在哪一步? 联想拯救者Y7000系列笔记本,从2018年第一代搭载i5-8300H开始,到后来的i7-9750H、i7-10750H、i5-11400H,再到2023年款的R7-7840HS,它始终是学…

2026/9/18 0:01:09

Google Colab 实战:运行模型、数据加载与报错排查

1. 为什么我劝你先搞懂 Colab 的运行模型1.1 Colab 到底是什么,跟本地跑代码差在哪Google Colab 简单说就是一台跑在浏览器里的 Linux 虚拟机,你打开一个 Notebook,背后就连上了一台带 GPU 的远程机器。你在单元格里敲的每一行 Python&#x…

2026/9/18 0:01:09

C语言数据类型与表达式详解

1. C语言数据与数据类型概述在C语言编程中,数据是程序处理的核心对象。理解数据的分类和特性是掌握C语言的基础。C语言中的数据主要分为四大类:常量、变量、表达式和函数。这些数据类型构成了C语言程序的基本元素,每种类型都有其独特的特性和…

2026/9/18 0:01:09

SQL时间字段指定时间段查询:区间语义、索引与时区避坑

上周排查一个线上问题&#xff0c;用户反馈"昨天的订单一条都没查到"&#xff0c;但数据库里明明躺着两千多条。最后定位下来&#xff0c;不是数据丢了&#xff0c;也不是接口挂了&#xff0c;而是那个查询条件把时间段写成了> 2024-05-20 00:00:00 AND < 2024…

2026/9/16 22:55:57

USB Type-C PCB布局分区设计:电源、高速信号与PD协议全攻略

做硬件这行&#xff0c;Type-C接口算是典型的“看着简单&#xff0c;做起来全坑”的东西。光引脚就24个&#xff0c;高低速信号、电源、控制线全部塞在一个小小的连接器里&#xff0c;如果PCB布局不做规划&#xff0c;打样回来基本就是“插上没反应”、“高速掉线”、“静电一打…

2026/9/16 22:56:09

系统编程学习原型如何补齐稳定性边界

系统编程学习原型如何补齐稳定性边界预算有限时&#xff0c;我先优化明显多余的复制&#xff0c;而不是猜测性地换容器。用借用传递只读数据通常就能减少分配&#xff1a; fn parse(line: &str) -> Result<Item, Error> { /* ... */ }用基准确认热点确实在分配&am…

2026/9/16 22:56:16

雨花区哪家财务公司代理记账比较好?

在雨花区&#xff0c;企业处理财税事务常常面临诸多挑战&#xff0c;选择一家靠谱的财务公司至关重要。湖南巨勤财务管理咨询有限公司就是本地正规实体财税服务机构&#xff0c;深耕本地工商财税行业多年&#xff0c;熟悉当地工商局、税务局最新政策与申报流程。主营公司注册、…

还想了解更多?直接咨询顾问

免费诊断 + 免费方案 + 透明报价。

全国咨询热线400-8866-253
免费获取方案
咨询二维码