v2.4.0 Release: Faster Trace Hydration, Alert Inhibition and a Better NL2Query

Trace hydration optimization: long-span traces open faster

Previously, opening a trace with over a thousand spans could take seconds or even tens of seconds to hydrate — that is, to assemble the span data into a call tree by parent-child relationships. For an on-call engineer staring at a red dashboard, those seconds feel like forever, and they add up across a team during an incident. The slowness came from the old logic, which fetched spans one at a time and then assembled the tree in memory, so the cost grew linearly with span count.

This release rewrites the hydration logic to use bulk loading instead of per-span queries:

• Opening a trace with thousands of spans is now about 60% faster
• Very large traces support lazy loading: the first two levels render immediately, and deeper levels load on expand

The change is transparent to callers — the trace_id query API signature is unchanged, so no client updates are required. Under the hood, the new path issues a single indexed range query for all spans of a trace instead of one query per span, which is why the improvement is most visible on traces with thousands of spans.

Alert inhibition: put an end to alert storms

A single flaky upstream service can trigger dozens of alerts and flood the on-call channel, burying the one alert that actually matters. v2.4.0 adds inhibition rules to keep the noise down:

• Inhibit by source: the same service and metric alert only once within a window
• Inhibit by dependency: when service A going down causes B and C to alert, only the root cause A is reported
• Silence windows: manually mute during maintenance to avoid false alarms

Example configuration:

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"

Inhibition reduces alert fatigue, which matters because an on-call engineer who has been woken up by noise five times stops trusting the pager. Note that inhibition is different from deduplication: deduplication collapses identical alerts, while inhibition suppresses downstream alerts whose root cause is already being reported, so the channel shows the cause rather than the symptoms.

NL2Query upgrade: query logs in plain language

The natural-language-to-query feature (NL2Query) improves on two fronts this release:

• Multi-turn follow-up: say "check recent errors in the payment service," and it asks whether you mean ERROR or WARN and over what window before generating the SQL.
• Explainable results: the generated SQL is shown so you can edit it directly instead of blindly trusting the model.

You: Anything wrong with the payment service in the last hour?
Assistant: Generated a query showing the ERROR and WARN distribution for the last hour.
     SQL: SELECT level, count(*) FROM logs
          WHERE service='pay-service' AND ts > now()-1h
          GROUP BY level

Showing the SQL is a deliberate choice: the model proposes, you dispose. If the generated query is wrong, you see exactly why and fix it in place, rather than wondering why the results look off. NL2Query works in both Chinese and English, and it confirms with you before running anything expensive — a broad time range or an unconstrained full-text scan — so a casual question can't accidentally trigger a heavyweight query. For teams whose day-to-day operations run in Chinese, the dual-language support means everyone can use it, not just those comfortable composing queries by hand.

Fixes and known issues

Fixes

• Fixed alert rules not triggering under GROUP BY aggregation
• Fixed garbled Chinese characters when exporting logs to CSV
• Fixed startup crashes of the ARM build on certain Kylin patch versions

Known issues

• Lazy loading of very large traces (tens of thousands of spans) can still stutter in extreme cases; further optimization is planned for v2.5.0
• The equal matcher in alert inhibition does not support regular expressions yet

Upgrade notes

Upgrading from v2.3.x requires no data migration; the hydration rewrite is backward-compatible with existing stored spans. Alert inhibition rules are additive and disabled by default, so existing alerting behavior is unchanged until you opt in.

See the release page for the full changelog, and back up your configuration before upgrading.