v2.4.0 更新：追踪水合优化、告警抑制与 NL2Query 升级

追踪水合优化：大跨度 Trace 打开更快

之前查一个上千 Span 的 Trace，水合（把 Span 数据按父子关系组装成调用树）要几秒甚至十几秒。对盯着红盘的值班工程师来说，这几秒像一辈子，故障期间全队人加起来就是一大块时间。慢的根源是老逻辑按 Span 逐个查库、再在内存里拼树，Span 越多越慢。

这个版本重写了水合逻辑，用批量加载替代逐 Span 查询：

• 千级 Span 的 Trace 打开耗时降低约 60%
• 超大 Trace 支持懒加载，先渲染前两层，展开时再取

改动对调用方透明，trace_id 查询接口签名不变，客户端无需任何升级。

告警抑制：告别告警风暴

一个上游服务抖动，可能触发几十条告警，把值班群刷屏，把真正要紧的那条淹没掉。v2.4.0 新增告警抑制规则：

• 按源抑制：同一服务、同一指标在窗口内只发一次
• 按依赖抑制：A 服务挂导致 B、C 告警时，只报根因 A
• 静默窗口：维护期手动静默，避免误报

配置示例：

alerting:
  inhibition:
    - source_match: {service: "db-master"}
      target_match: {service: ".*-consumer"}
      equal: [alertname]
  silence:
    - matcher: {env: "staging"}
      starts_at: "2026-10-07T02:00:00Z"
      ends_at: "2026-10-07T04:00:00Z"

抑制降的是告警疲劳——一个被噪音叫醒五次的值班工程师，很快就不再相信告警了。

NL2Query 升级：说人话查日志

自然语言转查询（NL2Query）这版升级了两点：

• 多轮追问：说“查一下最近支付服务的报错”，它会问你要 ERROR 还是 WARN、看多久，再生成 SQL。
• 结果可解释：生成的 SQL 会展示出来，你可以直接改，不必盲信模型。

你：支付服务最近一小时有什么问题？
助手：已生成查询，展示支付服务近 1 小时的 ERROR 与 WARN 分布。
     SQL: SELECT level, count(*) FROM logs
          WHERE service='pay-service' AND ts > now()-1h
          GROUP BY level

把 SQL 展示出来是刻意的设计：模型负责提议，你来拍板。生成的查询错了，你能直接看到错在哪、当场改。

修复与已知问题

修复

• 修复告警规则在 GROUP BY 聚合下不触发的问题
• 修复日志导出 CSV 时中文乱码
• 修复 ARM 版在部分麒麟小版本上的启动崩溃

已知问题

• 超大 Trace（万级 Span）的懒加载在极端情况下仍可能卡顿，计划 v2.5.0 继续优化
• 告警抑制的 equal 匹配暂不支持正则

完整变更记录见发布页，升级前请先备份配置。