v2.4.0 release notes: trace comparison to diff call chains before and after an incident, enhanced alert silence and inhibition rules, DM database query optimization, and bug fixes.
v2.4.0 is out, focused on two frequent pain points: hard-to-compare call chains before and after an incident, and alert noise control that isn't granular enough. Both came directly from on-call feedback — the same two requests kept showing up in post-incident reviews, so they moved to the top of this cycle. Full release notes below.
A common incident scenario: everything was fine yesterday and slow today, and you need to see what changed in the call chain. Previously that meant manually diffing two traces side by side, which is slow and easy to get wrong. v2.4.0 adds a trace comparison view — pick two points in time and it automatically highlights newly added calls, spans whose latency changed, and new error nodes. Combined with release information, it quickly points to which change introduced the problem. Typical use: take the same endpoint's trace before and after a deploy and read the diff directly, instead of eyeballing two flame graphs paragraph by paragraph.
The view is deliberately small in scope: it doesn't try to be a general-purpose diff tool, just a way to answer "what changed" in the first minutes of an incident. If you pair it with a deploy that happened in the same window, the answer is usually obvious from the highlighted spans alone. The comparison accepts either two trace IDs or two time ranges, and renders the diff with color coding — new calls in red, latency regressions in yellow — so you can scan for suspicious spans in seconds rather than reading the whole flame graph. To get the most out of it, tag your traces with the release version at deploy time; the comparison then works against "release N-1" versus "release N" instead of two arbitrary timestamps, which is what turns a useful feature into a repeatable part of your incident workflow.
Two upgrades to noise reduction this release:
env=staging alerts while production keeps alerting.Together these turn noise control from an all-or-nothing switch into precise, per-environment silence, so staging noise stops burying production alerts. Teams that were muting entire notification channels during QA cycles can now target just the labels they need to, without losing coverage elsewhere. The same label matching also powers smarter escalation — a suppression rule can be scoped to one environment while a separate rule keeps production paging the on-call rotation as usual.
For Xinchuang deployments storing metadata in DM, this release tunes indexes and pagination for hot queries, noticeably cutting latency for the alert-rule list and log-search metadata queries. No config change needed — it takes effect automatically after upgrade. The two hot spots addressed are the alert-rule list, which now uses cursor-based pagination instead of offset, and log-search metadata queries, which gained a composite index to avoid full-table scans on large installations. If you run on DM, re-baseline your metadata query latency after upgrading to see the actual gain in your environment rather than trusting the numbers from ours.
Upgrade as usual: run the migration script, then rolling restart. Data is compatible — no index rebuild required. For production, verify trace comparison load times in staging first, then roll out gradually, since diffing high-volume traces can add load to the query engine if everyone does it at once.
No breaking changes in this release: existing alert rules, dashboards, and collector configurations keep working as-is, and the new silence and inhibition features are additive. If you were using the old global silence behavior, your existing rules are preserved and can be migrated to label-based matching at your own pace. As always, the migration script is idempotent — safe to re-run if a rolling restart gets interrupted halfway through.