v2.5.0 ships three headline updates — metric-based anomaly detection, alert deduplication and silence rules, and full ARM support — plus stability fixes, with upgrade steps and caveats.
v2.5.0 adds metric-based anomaly detection that fits a baseline from historical data instead of relying on fixed thresholds. Fixed thresholds are brittle: a static "CPU > 90%" rule fires uselessly during a planned batch window and stays silent during a slow leak at 75%. The new detector models each metric's seasonal pattern (time of day, day of week) and fires when actual values deviate from the fitted baseline beyond a configurable factor. It's especially effective for cases fixed thresholds miss — small anomalies during off-peak hours, holiday traffic-shape changes, or a gradual drift that never crosses any single threshold. To configure, switch the trigger type in an alert rule from "threshold" to "anomaly detection," choose a sensitivity (low/medium/high), and the system builds a baseline from the last 7 days of data. Sensitivity trades recall against precision; medium flags roughly a 3x deviation from the baseline band. Start with medium for a week, watch the false-positive rate, then tune — don't jump to high, or alerts will bury your on-call team. Baselines also need a warm-up: at least a full week of history, ideally two, before the detector is trustworthy.
Alert storms are an operator's nightmare — one failed dependency can cascade into hundreds of pages. v2.5.0 adds three layers of noise reduction. First, deduplication: identical alerts are sent only once within a cooldown window, so one failure doesn't blast you repeatedly; the notification counts occurrences instead. Second, grouping: multiple alerts from the same cluster or service are merged into a single notification with the list of affected instances, so "service X is down" arrives once, not once per pod. Third, silence rules: temporarily suppress alerts by time window (e.g. a weekly release window) or by label (e.g. env=staging). Deduplication and grouping are on by default; silence rules live under Alert Center → Silence Management, with scheduled activation and manual release. After rollout, on-call channel volume typically drops by more than half, and — more importantly — the alerts that truly need a response are no longer drowned out, which measurably cuts response time.
This release closes the last ARM gap: the collector and query service already ran on ARM, but the alert engine and part of the built-in storage still ran on x86. From v2.5.0, every component ships a native arm64 package, so Kunpeng and Phytium servers no longer need x86 emulation, and collection throughput and query latency match x86. Deployment templates for Kylin V10 SP3 and UOS 22 are included, and precheck.sh now detects and warns about 64KB page sizes. Xinchuang customers can deploy fresh with arm64 packages or migrate smoothly from x86; the migrate.sh script supports cross-architecture data migration. If you've been running the storage engine under emulation on ARM, this is the release that removes the performance tax — worth planning an upgrade around.
This release fixes 23 issues, the highlights being: occasional notification loss in the alert engine under high concurrency (a race in the dispatch queue); timeouts on large-time-range queries in specific shards (an index-boundary bug); and a memory leak from metadata accumulation when Pods churn frequently in Kubernetes. Upgrade steps: first upgrade a test environment from v2.4.x with upgrade.sh and run regression, then promote to production. The upgrade briefly interrupts alert delivery (about 2 minutes) while the alert engine restarts, so schedule it during a low-traffic window. Back up configuration and alert rules before upgrading, and verify alert channels still reach you afterward — a quick test page through each channel is cheap and catches silent breakage. The full changelog is on the console's Release Notes page.
A note on the alert-engine change: because deduplication and grouping now run centrally, existing webhook and email integrations keep working unchanged, but if you were doing your own client-side dedup, you can retire it — double-dedup can suppress alerts you actually wanted to see. Also, anomaly detection consumes extra compute during baseline training, so on very large metric fleets, stagger enablement across services rather than flipping it on for everything at once.