JJHub OBSERVE v2.4: Alert Deduplication, Trace Sampling, and Domestic Platform Improvements

Alert Deduplication and Silencing

v2.4 rewrites alert deduplication. Previously the same alert would pester you on every recover-then-retrigger cycle. Now you get:

• Fingerprint-based dedup: same-source alerts (same rule + same dimensions) fire once per window, default 5 minutes, configurable.
• Silence plans: mute by schedule or by label in bulk; one click covers a release window.
• Alert grouping: related alerts merge into a single notification with a sub-alert list.

These three land as one feature because they solve the same problem from different angles: cutting the number of notifications a human has to read before finding the one that matters.

Tail-Based Trace Sampling

We previously only supported head-based sampling, where slow requests could be dropped at the entry. v2.4 adds tail-based sampling: the Collector buffers full traces and decides retention based on duration and error status after the trace completes. In testing at 30% sampling, slow-trace retention jumped from 18% to 92%. The tradeoff is Collector memory — budget 2–4GB per instance.

This matters most when you're trying to find the one slow request that caused a latency alert, only to discover your sampler discarded it at the front door. Tail-based sampling closes exactly that gap.

Domestic Platform and Storage Improvements

• Dameng DM8 added as a search storage option with automatic SQL dialect adaptation.
• ARM64/LoongArch64 images now cover the agents, so collection hosts deploy without compiling.
• Default compression switched to ZSTD, cutting cold-data volume by ~40% on average.

Upgrade Notes

1. Back up metadata before upgrading from v2.3 and run jjhub upgrade --from 2.3; you can't skip intermediate versions.
2. After enabling tail-based sampling, upgrade the Collector to 0.90+ or the policy won't take effect.
3. The silence-plan and alert-grouping APIs changed; older webhook scripts calling /api/alerts/silence need updating to the new signature.
4. See the full CHANGELOG on the site; run it in staging first.