v2.4 adds tail sampling, alert silence windows, native OceanBase connectivity and faster log search, along with a batch of fixes.
Previously we only supported head sampling, which drops spans randomly at the entry point. That often meant discovering mid-investigation that the slow request's trace had been sampled away. v2.4 adds tail sampling: the decision is made after the whole trace finishes, with policies based on status code and latency thresholds.
tail_sampling:
policies:
- name: keep-slow-errors
type: and
and:
and_sub_policy:
- name: errors
type: status_code
status_code: { status_codes: [ERROR] }
- name: slow
type: latency
latency: { threshold_ms: 500 }Tail sampling cuts storage cost significantly while guaranteeing that slow and failing requests are kept at 100%. Policies support combined conditions (and / or) and can filter by span attributes such as service name or route. The decision wait defaults to 10 seconds and can be tuned. If you already use head sampling, tail sampling can replace it in the same pipeline; the two can coexist but will compound, so pick one per pipeline to keep your effective sample rate predictable.
Schedule quiet periods so alerts inside a release window are downgraded automatically instead of paging the on-call. Both one-off and recurring schedules (for example, every Wednesday 02:00-04:00) are supported, configurable directly in the console. Windows are evaluated in the tenant's configured timezone, so a recurring window defined in Beijing time behaves correctly for teams spread across regions. Silence windows compose with the existing suppression and tiering: during a release everything below P0 is silenced, while P0 still reaches the responsible person through the escalation chain.
Database connections now include an OceanBase option that connects natively over the MySQL protocol, with no extra compatibility layer. Connection pooling parameters have been tuned for OceanBase's proxy layer to reduce reconnect churn under bursty write load. Adapted and tested against OceanBase 4.x (MySQL mode). In domestic-computing environments you can select it directly with no application code changes.
The tiering change is transparent to queries: hot data is served from fast storage and cold data from compressed storage, and cross-tier queries are stitched together automatically.
This release keeps the API and configuration backward compatible — existing env files and alert rules work unchanged. One exception: the database driver now prefers the native OceanBase connector when DB_TYPE is set to oceanbase. If you previously pointed at OceanBase through the MySQL compatibility layer, no action is required, but we recommend switching to the native option during your next maintenance window.
decision_wait can increase tail latency on long traces; keep the default 10s unless you have a specific reason.On the near-term roadmap: anomaly-based alerting that learns seasonal baselines, a first-class Fluent Bit integration for container log shipping, and extended DM/openGauss support in the domestic database matrix. If any of these matter to your environment, tell us — priority order is driven by customer demand. We also plan to publish per-release migration notes and a public roadmap page; subscribe to the changelog channel for details as they land.
This is a backward-compatible upgrade; no config changes are required. Back up the database before upgrading and run a regression pass in a test environment first. Tail sampling and silence windows are opt-in and off by default after the upgrade; enable them from the console as needed.