炬鲸 OBSERVE v2.4: Alert Grouping, Trace Sampling, and DM Support

Overview

v2.4 focuses on three things: quieter alerting, cheaper trace storage, and smoother domestic (信创) deployments. This is a stable release; upgrade directly from v2.3. If you're on v2.2 or earlier, go to v2.3 first, then v2.4.

For operators, the headline is the alert grouping work: if you've ever been paged a dozen times for what turned out to be a single network partition, this release is aimed squarely at you.

New features

Alert grouping and suppression: multiple alerts from the same root cause now collapse into a single alert that lists the number of affected instances. A datacenter-level outage (an entire availability zone down) suppresses downstream service alerts, preventing an alert storm. Grouping rules are configurable under "告警 → 分组规则" by service, host and labels. Under the hood this runs a two-phase pipeline — correlation by root-cause signature, then suppression by dependency graph — so grouping stays correct even when an incident unfolds over several minutes.

Head-based trace sampling: new sampling policies let you set sampling rates per service and per endpoint. For production we recommend dropping high-frequency health-check endpoints to 1% while keeping core transaction endpoints at 100%; in testing this cuts trace storage costs by roughly 40–60%. The sampler runs at the Collector ingress, so the decision is made once and propagated downstream, keeping each trace either complete or fully absent — no orphaned spans.

Official DM8 / KingbaseES V8 support: previously beta, now fully dialect-adapted and compatibility-tested, making them production-ready datasource options. Existing MySQL/PostgreSQL users get a one-click migration tool (bin/migrate-db.sh). This matters for regulated industries where a domestic database is a hard requirement rather than a preference.

Log search performance: index optimizations for aggregation over high-cardinality fields speed up common GROUP BY queries by 2–5×; new p50/p99 aggregation functions and time_bucket bucketing.

Improvements and fixes

• The Collector onboarding page now has a "copy OTLP config" button with the auth token baked in, reducing transcription errors.
• Fixed miscalculated alert silence windows across time zones.
• Fixed table creation failures for some wide fields under the DM driver (requires 32K page size).
• Reduced memory usage for large exports; exports over 100k rows no longer OOM.
• UI: the trace detail page gains a flame graph view, sortable by duration.

Deprecations and compatibility

v2.4 keeps full backward compatibility with v2.3 configuration and API endpoints — nothing changes on the Collector or SDK side. One deprecation: the legacy query API used by early v1.x clients is now marked deprecated and will be removed in v3.0; migrate to the SQL-style search API. The old alert rule format is still read but no longer written, so newly created rules use the grouping-aware schema.

Upgrade notes

1. Back up your database before upgrading — especially DM/KingbaseES users, since the upgrade script applies minor schema changes.
2. Sampling policies change how much trace data you store; validate in a staging environment before going full production.
3. The upgrade script is idempotent and safe to re-run; if interrupted, run upgrade.sh again.
4. Clear your browser cache after upgrading to avoid mixing old frontend assets.

Known issues

• The flame graph occasionally mis-renders on Safari 16 and below; use Chrome/Edge or upgrade Safari.
• The full migration tool for DM is slow on very large datasets (>500M records); migrate in batches.

Who should upgrade now

If you run in a 信创 environment on DM or KingbaseES, upgrade now — the beta limitations are gone and migration is a single script. If your on-call team is drowning in duplicate alerts, grouping is the single biggest quality-of-life improvement in this release. Everyone else can follow the normal cadence, but there's no reason to hold back: the release is stable and the search speedups are free.

See the full changelog on the website. For upgrade problems, open a ticket or reach out through the 炬鲸团队 support channel.