Version 2.4 ships three headline features, a SQL-like log query language, alert deduplication and grouping, and trace hydration that links spans to logs and metrics, plus a set of collection and storage fixes.
v2.4 targets three complaints we've heard repeatedly: log search forced you to learn a proprietary syntax, alerts duplicated into a storm, and you couldn't pull up context while looking at a trace. The three features below went through canary validation before the general rollout.
Previously, log search meant regex or the built-in filter panel, both awkward for complex conditions. v2.4 adds a full SQL-like query language with SELECT, WHERE, GROUP BY, ORDER BY, and LIMIT, plus the aggregates count, avg, sum, and percentile.
SELECT host, count(*) AS cnt
FROM logs
WHERE service = 'payment-service' AND level = 'ERROR'
AND ts > now() - interval '1 hour'
GROUP BY host
ORDER BY cnt DESC;The syntax matches metric queries, so a team learns one way to write and can query both logs and metrics. The old filter panel remains, so migration is gradual. A few conveniences worth calling out: interval literals for time windows, LIMIT for paging through results, and a DOWNLOAD clause that exports a query result to CSV for offline analysis. The query editor also autocompletes field names from the log schema, which removes most of the guesswork about what a field is actually called.
Alert storms got the biggest rework here. Two mechanisms are new: grouping merges alerts sharing the same host, service, or custom label into a single notification, and silence periods add a cooldown after an alert resolves to stop the "recover then re-trigger" flapping. Example config:
alerting:
group_by: [host, alertname]
group_wait: 30s
silence_after_resolved: 10m
dedup_window: 5mgroup_wait batches the first wave so a burst of simultaneous failures arrives as one message, and dedup_window collapses repeats inside five minutes. In a test where 200 containers on one host went OOM, alerts collapsed from 200 to a single message. The on-call engineer went from muting the channel to actually reading it. Grouping also shapes the notification itself: the message lists how many distinct hosts or services are affected, so you can tell "one host" from "the whole fleet" at a glance.
"Hydration" means pulling the logs and host metrics attached to each span in a trace directly into the span detail view. Open any span and the right side shows the error logs and CPU/memory curves from its time window, with no need to hop to the log and metric pages. Under the hood it relies on the trace_id field in logs and the host label on metrics, so make sure both are populated when onboarding. For spans with no matching logs, the panel says so explicitly rather than showing an empty view, which helps you spot services that haven't wired up log-trace correlation yet.
Upgrade path: offline upgrade bundles are provided for both Xinchuang and general environments. Run bin/upgrade.sh; the process backs up your configuration automatically and restores it if the upgrade fails. One breaking change to be aware of: alert rules using the old expression field are auto-migrated on upgrade, but we recommend reviewing the migrated rules once after the upgrade completes, since the grouping behavior changes how the same rule is delivered. The full changelog is on the release notes page.
Two items are already in development for v2.5. The first is a natural-language query assistant that turns plain-language questions into the SQL-like syntax above, so a new hire can ask "which hosts threw the most errors this morning" and get a valid query back. The second is anomaly detection on metric series, so the platform can flag a deviation before you have written the alert rule yourself. Both are in early canary; sign up in the console if you want on the list.