The v2.4 release: 60% faster log search, alert deduplication and silence windows, stronger Xinchuang support, plus upgrade notes and commands.
OBSERVE v2.4 was released in October 2026, focusing on three areas: log search performance, alert deduplication, and stronger support for Xinchuang environments. This release came out of the most common complaints from the last quarter: aggregation queries that timed out on large clusters, alert storms during incident weekends, and collectors that wouldn't start on freshly deployed domestic OS images. The main changes are below — read the upgrade notes at the end before you start.
Rewritten SQL Engine for Log Search: the query engine now uses vectorized execution. Complex aggregations (multi-field GROUP BY plus regex filters) over tens of millions of log lines are on average 60% faster. On the reference benchmark — 50 million lines, a three-field GROUP BY with a regex filter — median query time dropped from 8.2s to 3.1s. Added JOIN support, so you can join the log table with the alert table in a single query — for example, listing a service's error logs from the last hour together with the alerts they triggered.
Alert Deduplication and Silence: new auto-deduplication keyed by service + rule, merging alerts with the same root cause into one entry. The merged alert carries an impact summary (how many hosts and instances are affected) plus a sample of the underlying events, so the evidence behind the rollup is still visible. Silence windows are now cron-style recurring schedules rather than one-off toggles, so overnight maintenance no longer pages you — and doesn't come back to bite you the next week when you forget to re-enable.
Xinchuang Support: the Agent now officially supports UOS and Kylin V10 SP3, with collection stability verified on Kunpeng 920 and Phytium D2000; the storage layer passed Dameng 8 compatibility certification.
for duration, so transient spikes no longer trigger false alerts.Two things to note. The legacy field:value shorthand query syntax is now deprecated and will warn in the UI; it still works but will be removed in v3.0, so migrate saved queries before the next major release. The otel_collector_receiver metric namespace was renamed to align with the upstream OTel schema — update any dashboards that reference the old names before upgrading, or they will render empty.
The headline 60% figure is an average across workloads; your mileage depends on how selective your filters are and how wide your result sets are. To confirm on your own data, re-run a few of the saved queries that used to be slow, before and after the upgrade, and compare wall-clock time. Queries dominated by a highly selective time-range filter will see the least change — they were already fast — while broad GROUP BY scans over days of data are where vectorized execution pays off most. A useful habit is to capture a handful of representative queries now and store them as a named benchmark set, so future releases can be compared against the same baseline instead of anecdotes. If a specific query regressed, grab its plan from the new slow-query panel and open an issue with the query text attached, since the execution-plan view is what makes these regressions diagnosable rather than mysterious. Finally, note that the 60% improvement is measured on the new storage format, so run the upgrade on a staging cluster first if you want a clean before/after comparison without touching production data.
Back up the metadata database first, and make sure your Collector is at least 0.88 — otherwise new protocol fields may be dropped. This upgrade rebuilds the columnar storage format for log indexes, so large clusters (terabyte-scale data) should run it during low-traffic hours; expected duration scales with historical data volume.
Upgrade command:
jjhub-tools upgrade --from 2.3 --to 2.4 --backup-dir /data/backupAfter upgrading, run jjhub-tools verify for a data-consistency check before rolling out to all users. If anything looks off, the --backup-dir you passed is your rollback path — keep it until the cluster has run clean for a full day.