v2.5.0 adds alert escalation (auto-escalate unanswered P0s), regex and fuzzy log search, a one-click deployment script for sovereign environments, broader agent support for domestic systems, and several fixes, with upgrade steps and compatibility notes.
v2.5.0 concentrates on three things: making sure critical alerts never fall through, making search more flexible, and making sovereign-environment deployment less painful. In a hurry? Jump to the end for upgrade steps and compatibility; the rest covers each change in turn.
v2.4 added on-call rotation, but one scenario was left uncovered: a P0 goes out, the person on call misses it, and the message just sinks. v2.5.0 adds escalation — if an alert gets no response within a set time, it automatically escalates to a supervisor or a backup channel.
escalation:
- wait: 5m
notify: [oncall-phone, oncall-sms]
- wait: 15m
notify: [team-leader, escalation-group]
- wait: 30m
notify: [manager]
Three steps in sequence, each with configurable wait time and recipients. The escalation chain records the trigger time and recipient of every step, so a post-incident review can see which step actually woke someone up. The default is opt-in: existing alert rules keep their current behavior until you attach an escalation policy, so nothing changes silently on upgrade.
A practical note on tuning the waits. The first step should be short (a few minutes) because a missed P0 is expensive; the later steps can be longer, since by then you are waking people up rather than nudging someone who is already at the keyboard. Resist the urge to add ten steps — escalation chains that are too long just spread noise, and a manager woken at 2 a.m. for a self-healing blip will stop trusting the system.
On top of the existing keyword and pipe-query syntax, log search gains regex and fuzzy matching:
source="order-service"
| where message =~ /(timeout|refused|reset)/
This suits cases where the exact error is not known but the general pattern is. Fuzzy matching adds spelling tolerance — for example, a user ID off by one digit still finds the record. Both are index-accelerated, so they do not degrade into full scans over large time ranges.
One thing to keep in mind: regex is powerful but easy to misuse. A pattern with heavy backtracking over a long time range can be slower than you expect, so anchor your queries with a source or service filter first, and prefer simple alternation over nested groups. If a query feels slow, explain shows how it was planned, just like in a database.
For Kylin V10, UOS, openEuler and other domestic systems, a one-click script handles dependency checks, schema setup, config generation and systemd registration automatically:
curl -fsSL https://dl.jjhub.cn/install/xinchuang.sh | bash
./xinchuang.sh --db kingbase --host 10.0.0.20 --port 54321
The script detects the CPU architecture (aarch64/x86_64) and database type and generates the matching configuration, cutting manual deployment from half a day to about fifteen minutes. Combined with the acceptance checklist in the docs, sovereign-project delivery gets noticeably faster. The script is also idempotent — run it again and it re-checks rather than re-creating, which makes it safe to use as part of an automated install pipeline.
v2.5.0 is backward compatible for the API, schema and ingest tokens; older agents do not need a synchronized upgrade. In production, upgrade during low traffic, gray-release one host first and watch for an hour before going wide. On trouble, roll back the binary and restore the backup — no destructive changes.
v2.6 plans to focus on customizable alert convergence, richer search-result visualization, adaptive degradation of trace sampling, and support for more domestic databases (GaussDB, GBase). These are directions, not commitments — the release notes are authoritative.