JJHub OBSERVE v2.4: Silence Windows, Trace Sampling and Xinchuang Support

Overview

JJHub OBSERVE v2.4 is out. This release focuses on three areas: alert noise reduction, tracing sampling control, and additional Xinchuang component adaptations. Here are the headline changes; existing users should skim the upgrade notes at the end before rolling out.

Alerts: silence windows and group suppression

Alert storms are one of the worst parts of on-call. A single flaky core node can fire hundreds of alerts in seconds, drowning the ones that matter. v2.4 adds two capabilities:

Silence windows: schedule a silence for an alert rule — for example, between 3am and 4am when batch jobs run, CPU alerts automatically downgrade to log-only with no notification. Configure it on the rule detail page with a cron expression:

silence:
  cron: "0 3 * * *"
  duration: 1h
  action: log

action supports log (record but don't notify) and drop (produce no alert event at all). Start with log, watch it for a while, and only then decide whether to switch to drop.

Group suppression: multiple alerts from the same root cause collapse into one. The system groups by "service + error type", notifies on the first alert, folds subsequent ones into an incrementing count, and sends one summary notification on recovery. This is especially useful for the classic "one database dies and dozens of endpoints all alert at once". The incrementing count shows up as a badge on the alert, so on-call can tell at a glance whether a single incident is still spreading or has stabilized.

Tracing: configurable sampling

Sampling was previously 100% head-based, which is fine for low-traffic services but wasteful and costly for high-traffic ones. v2.4 adds per-service sampling policies:

sampling:
  service: order-service
  strategy: parentbased_traceidratio
  ratio: 0.1
  rules:
    - match: "http.route == /pay/**"
      ratio: 1.0

This keeps 100% sampling on the /pay/** payment path and 10% everywhere else. Rules match on span attributes and are evaluated in order, first match wins — enough to cover "sample all critical paths, sample some of the rest".

Sampling is enforced at the collection layer, so no service restart is needed after changing the policy; the Agent picks it up on its next sampling cycle.

Xinchuang adaptations

v2.4 adds three items on the Xinchuang front:

• JDBC adaptation for GBase 8a, as a database option alongside Dameng, aimed at analytical workloads.
• Compatibility validation for the UOS desktop, so the admin console works fully in a UOS browser.
• Collector support for Kylin V10 SP3, fixing the eBPF probe load failure that appeared after the SP3 kernel upgrade.

Other improvements and fixes

Beyond the three headline areas, this release ships a batch of smaller improvements:

• Saved queries in log search, so high-frequency investigation statements can be stored and shared across the team.
• Regex hit highlighting in the query panel, making it faster to pick out key lines in long stack traces.
• A WeCom (WeChat Work) bot notification channel — just fill in the webhook URL.
• Namespace filtering on the trace topology, so you don't have to search manually once microservices multiply.
• Import/export for sampling policies, so you can reuse one config across test and production environments.
• A "copy as cURL" button on the trace detail page, so you can replay a failing request straight from the trace.

On the fix side, 12 known issues are resolved. One is an occasional query timeout on large time ranges — we recommend upgrading sooner rather than later — and another was slow alert-history queries on the Dameng backend. Several smaller fixes address memory growth in the trace store and flaky eBPF probing under sustained load.

Upgrade and compatibility

The upgrade path is unchanged, with about ten minutes of downtime:

./bin/observe-server upgrade v2.4.0.tar.gz

Two compatibility notes: the alert rule export format has changed, so rules exported from older versions need a one-time migration through the tool in tools/; and v2.3 client SDKs still report normally, so no forced client upgrade — though the new sampling features only take effect on v2.4 Agents.

See the release page for the full changelog, and report issues in the community.