v2.4 ships alert suppression and silences, dynamic trace sampling, deeper Kingbase/Dameng compatibility, and query engine speedups—with upgrade steps and caveats.
v2.4 adds alert suppression rules: when a P0 alert fires (say "gateway unavailable"), you can configure it to automatically suppress downstream P1/P2 alerts (like "gateway latency high" or "thread pool exhausted"), avoiding an alert storm. Rules are defined by label matching—for example, suppress when the source matches and the level is lower. A concrete rule: "when an alert named gateway-down fires, suppress any alert whose labels include the same gateway and whose severity is below P0 for 15 minutes." The suppression window is configurable and auto-expires, so a genuinely independent second fault still surfaces.
It also adds silence windows: mute by time range (such as the weekly release window) or by label (such as a specific environment). Alerts during a silence are not notified but are recorded in the audit log for later review.
Previously the sampling rate was fixed at startup, and changing it meant restarting the service. v2.4 supports dynamic sampling policies pushed through the config center—switch the rate without a restart. You can set different rates per service, per route, and per error status, with error requests kept at 100% by default. The SDK polls for the policy every 30 seconds, so propagation takes about half a minute.
sampling:
default: 0.05
rules:
- service: order-service
route: /order/*
sample: 1.0
- error: true
sample: 1.0The database compatibility layer now fully supports KingbaseES V8. Dameng DM8 gains support for case-sensitive collation, and a bug where indexes were lost during metadata migration on DM8 is fixed. ARM images now cover all of 2.4, including the new alert aggregation component.
The columnar store's aggregation path was rewritten, cutting GROUP BY aggregation time on million-shard datasets by about 40%. A new query result cache (default TTL 60 seconds) lets repeated dashboard queries hit the cache directly, noticeably reducing query load at peak. The cache key includes the query text and the resolved time range, so two dashboards with different relative windows won't collide.
Two behavior changes are worth flagging. The query result cache now defaults to on with a 60-second TTL; dashboards that show near-real-time data should lower the TTL or bypass the cache for those panels. Alert suppression rules are evaluated top-down and the first match wins, so order your rules from specific to general.
Agents older than 2.3 won't pick up dynamic sampling policies—upgrade agents to 2.4 first if you want the sampling feature to take effect uniformly across the fleet.
A handful of issues didn't make the 2.4 cut and are documented in the release notes. The query result cache can briefly serve stale data during a config roll, and dynamic sampling policies take up to 30 seconds to reach every SDK, so a short window of over-sampling is possible right after a policy change. If either matters to you, pin the cache TTL to 10 seconds and stage sampling changes during off-peak hours. Both are tracked for a 2.4.1 patch.
Back up metadata first, then roll the upgrade in component order: storage → ingester → querier → gateway, and finally the agents and SDKs. The data format is forward compatible; you can upgrade in place from 2.3 with no data migration. Run ob-compat-check.sh afterward to verify.
The full change list is in the release notes document; this covers only the items with the broadest impact.