v2.4 ships alert aggregation and deduplication, trace flame graphs, enhanced DM/OceanBase support, and faster log search on high-cardinality data, plus a batch of fixes.
v2.4 is the first release of the quarter, and it concentrates on three areas our users asked about most: quieter alerting, faster performance triage, and deeper support for domestic databases. Here is the full list of what changed.
One of the big themes this release is the alerting experience. Previously a single underlying fault could fire dozens of alerts, drowning the on-call engineer and hiding the real issue. When a database goes down, every service that depends on it starts failing, and each failure triggers its own alert — fifty messages that all describe the same root cause.
v2.4 adds alert aggregation: multiple alerts that share a root cause within an aggregation window are merged into one primary alert, with the rest attached as related items. The primary alert carries the summary; the related items stay visible as evidence but don't page anyone again.
# Example aggregation rule: group by service + root cause
aggregation:
group_by: [service, root_cause]
window: 5m
mode: deduplicatePaired with alert suppression, you can silence related alerts during a maintenance window or a known incident so they don't escalate to people who shouldn't be paged. Notification channels now include Feishu and DingTalk, joining the existing email, webhook and WeCom options to cover the mainstream team tools.
Aggregation happens on the server side, so it works uniformly across all notification channels — no client-side logic to maintain. The grouping keys are configurable, so you can aggregate by service, by root cause, by host, or any combination that fits your on-call model. Related alerts remain visible in the console, so nothing is hidden — they simply stop competing for attention.
When you're hunting performance bottlenecks, a picture beats lists and tables. v2.4 adds a flame graph view to the trace detail page: the width of each stack frame represents its share of total time, so you can see at a glance which function or downstream call ate the most time.
The flame graph supports:
Combined with the existing "longest span" sorting, performance work changes from "walk the spans one by one" to "jump straight to the hotspot". Whether a function is doing real CPU work or spending most of its time waiting on one slow database call becomes obvious in a single glance.
For teams migrating from a separate profiler, the flame graph reuses the same trace data you already collect, so there is no second agent to install or additional overhead to budget for.
v2.4 continues to strengthen the domestic-computing path, focusing on database compatibility:
There's also a new slow-query panel for domestic databases, linking slow SQL at the storage layer to the tenant and query source, so you can tell whether the platform's own queries or a user's custom query is dragging the system down. All of this runs behind the same MySQL protocol, so the switch between MySQL, OceanBase and DM remains a connection-string change — no application code to modify.
How to upgrade: private-deployment users download the new single binary and swap it in — the configuration is backward-compatible, so no migration step is required. SaaS users are upgraded automatically with no action required. Please review the breaking-change notes before upgrading if you use custom alert webhooks, as the payload schema was standardized in this release. The full changelog is in the official documentation.