← Back to blog
Changelog 4 min read 炬鲸团队

Release Notes v2.4: Alert Convergence, Trace Sampling and Domestic-Platform Support

v2.4 adds alert grouping and inhibition, rule-based trace sampling, improved OceanBase compatibility, and write/search performance tuning for domestic ARM environments.

New: alert grouping and inhibition

The alerting module gains two of the most-requested features: grouping (merging alerts that share dimensions into one entry with a count and time window) and inhibition (auto-silencing downstream derived alerts once a root-cause alert fires).

alert_rules:
  - name: db-pool-exhausted
    expr: db_conn_wait > 100
    severity: P0
    inhibit: [api-timeout, queue-backlog]

When the database connection pool is exhausted, derived alerts such as API timeouts and queue backlogs no longer pile on — the on-call engineer receives a single root-cause notification. Grouping rules also gained a group_wait window, so alerts sharing the same dimensions are merged before dispatch instead of spamming the channel as a burst. A new group_interval setting controls how often a still-active group re-notifies, keeping long outages visible without becoming a firehose.

New: rule-based trace sampling

Sampling used to be a single global ratio. It now supports matching different rates by attribute, so critical transactions can be retained at 100%:

sampling:
  - match: attributes["tx_type"] == "transfer"
    rate: 1.0
  - match: service == "gateway"
    rate: 0.5
  - default: 0.1

A sampling-decision audit view shows how many requests each rule matched and how many were dropped, making it easy to reconcile cost against coverage. Rules are evaluated top to bottom and the first match wins, so keep the most specific rules at the top.

New: saved views and regex highlighting in log search

The search page can now save frequently used queries as named views that the whole team can reuse, and search results support regex highlighting so long log lines surface the keyword instantly.

New: dashboard template import and export

Dashboards can now be exported to a JSON template and imported into another tenant or deployment. This makes it practical to keep a library of standard views — error-rate overview, slow-endpoint ranking, on-call summary — and push them across teams, which is how most organizations end up with one consistent baseline instead of twenty subtly different dashboards.

Improved: OceanBase compatibility

The database layer received compatibility fixes for OceanBase (MySQL mode), including anomalies with certain partitioned-table queries and JSON-typed fields, making OceanBase integration more stable for government and enterprise customers.

Improved: domestic ARM performance

  • Log write throughput up roughly 35% on Kunpeng 920 / Phytium 2000+;
  • Lower memory usage for log search on Kylin V10, with smoother hot/cold tiering for large indices;
  • Single-binary installer slimmed down 20% for faster offline delivery.

Improved: log search query performance

Ad-hoc queries over large indices are faster in this release, with the planner now pruning cold tiers earlier and a new short-circuit path for common service-and-level filters. On a 60-day index, the median ad-hoc query in our benchmarks dropped from 2.8 seconds to 1.1 seconds.

Fixes

  • Fixed multi-line log truncation under certain container runtimes;
  • Fixed alert rules occasionally not taking effect immediately after editing;
  • Fixed dashboard panel timezone not following the tenant setting;
  • Fixed an issue where log ingestion could stall when a single large multi-line record exceeded the buffer;
  • Fixed occasional double-notification when a group's severity changed while active.

Deprecations and notes

No breaking changes in this release; all v2.3 configuration files load unchanged. The legacy single-ratio sampling_rate field is now deprecated in favor of the rules list above and will be removed in v2.5, so plan to migrate your sampling config before the next upgrade.

Upgrade notes

Upgrading from v2.3 to v2.4 only requires replacing the binary and restarting; the data format is compatible and no migration is needed. On domestic-computing environments we recommend canary-testing on a staging tenant for a week before rolling out fully. If you have custom dashboards, export them as templates before upgrading so they are easy to restore.