v2.4.0 is out. This release adds alert grouping and deduplication, histogram and regex support in SQL search, DM and KingbaseES database dialects, plus a batch of performance and stability fixes. Upgrade steps included.
v2.4.0 is released today. This release targets the three most-reported problems: alert storms, slow search over large log volumes, and domestic database compatibility. The full change list is below.
Alert grouping and deduplication: multiple alerts triggered by the same root cause are now grouped into a single alert by "service + rule + time window", with all affected instances and sample traceIds attached. Combined with silence windows and tiered notification (warning and critical route to different channels), alert storms are largely under control. In our own load test, a simulated full-cluster outage produced one consolidated alert instead of the previous 200-plus individual pages.
SQL search improvements: a new histogram() aggregation function for time-bucketed statistics; regex matching via the ~ operator; and range filtering on extracted fields inside WHERE. Search results can now be exported to CSV and shared via link. Aggregation queries over indexes up to 1 billion entries now complete reliably within the SLO, which was the top performance complaint from the previous release.
Domestic database support: dialect adapters for DM8 and KingbaseES V8. db.dialect in the deployment config now accepts mysql/pg/dm/kingbase, and the migration tool supports one-click metadata migration from MySQL or PostgreSQL. Both dialects passed the same conformance suite as the existing MySQL/PostgreSQL adapters.
Metrics query API: a new /api/v1/query_range endpoint with Prometheus-style semantics, so existing Grafana panels migrate over without rewriting queries.
GLIBC version mismatches for some prebuilt dependencies in aarch64 environments.Under the hood, the Collector throughput improvement comes from a rewritten OTLP receiver that batches payload parsing, and the search timeout fix comes from moving aggregate state out of the hot query path. In our benchmark suite, v2.4.0 sustains 150K log lines/sec ingestion on 16 cores with search P99 under 800ms on a 1-billion-entry index.
Back up the metadata database and export your current config with the official script before upgrading. For containerized deployments:
docker pull jjhub/observe:v2.4.0
docker-compose down
# back up volumes, then:
docker-compose up -dAfter upgrading, the platform runs schema migration automatically; the first startup is 1-2 minutes slower than usual, which is normal. Note: upgrading from v2.3.x or earlier requires going to v2.3.5 first, then v2.4.0 — jumping across major versions is not supported.
If you need to roll back, restore the metadata backup and redeploy the previous image tag. Schema changes in v2.4.0 are backward-compatible with v2.3.5, so a rollback does not require a second data migration.
histogram queries over extra-large indexes (over 5 billion entries) can still be occasionally slow, and will be optimized in v2.4.1.v2.4.1 is already in progress and focuses on two things: optimizing histogram queries over extra-large indexes, and a long-requested template feature for alert notification messages so teams can format their own pages using the same fields that drive the alerts. If you're on v2.3.x, we recommend planning the v2.3.5 → v2.4.0 upgrade during your next maintenance window; the migration is automatic and typically completes in under two minutes on a production-sized metadata store.
A note on how this release came together: the alert-grouping behavior was shaped directly by customer incident reports, and the DM/KingbaseES adapters came out of two xinchuang pilots. If a feature is missing or a bug is annoying you, opening a ticket is the fastest way to get it onto the roadmap — several items in this release started as tickets.
See the documentation center for the full change list. Report issues via ticket or contact support; we'll follow up with fixes in the next minor release.