OBSERVE v2.4: Alert Grouping, Trace Sampling, and Xinchuang Compatibility

v2.4 is a significant update to OBSERVE's alerting experience and Xinchuang compatibility, focused on three questions: how to tame alert storms, how to stop losing slow requests, and how to make domestic databases run faster. The release adds ten features and five improvements, and fixes six issues. All v2.3 users should plan an upgrade.

New Features

• Alert grouping: multiple notifications from the same rule are merged into one, deduplicated by dimension (service, host, labels), so fifty hosts failing at once won't blow up your phone. Custom aggregation windows and dedup keys are supported; the default window is 30 seconds, and the dedup key can be "service + host + alert name".
• Alert silences: temporarily mute alerts by time rule or label match, so releases and load tests no longer drown you in repeat pages.
• Tail-based trace sampling: the agent samples by error rate and slow-request ratio, so rare but valuable slow calls stop getting dropped by fixed-rate sampling.
• Automatic log field typing: timestamps, numbers, and IPs are recognized on ingest, enabling numeric-range and IP-segment filters in search without hand-built mappings.
• Log export: search results can be exported to CSV/JSON in one click, up to 500,000 rows at a time, for audits and secondary analysis.
• RBAC improvements: new read-only role and project-level isolation let you restrict members to the services and alerts they own.
• New notification channels: WeCom, Feishu, and DingTalk bot webhooks are now supported, with custom message templates so alerts can carry a summary and a jump link.
• Dashboard sharing: generate read-only share links with an optional expiry and password, handy for handing key charts to business stakeholders.
• Service topology: auto-generate a call graph between services, annotated with error rate and average latency, so dependencies and bottlenecks are visible at a glance.
• Alert event timeline: record the full lifecycle of an aggregated alert — trigger, silence, and recovery — into a replayable event history.

Improvements

• Better DM8 and KingbaseES V8 compatibility: fixed slow queries on time-partitioned tables under wide ranges, and improved write throughput by roughly 30%.
• The alert-rule editor now supports expression validation and historical backtesting: before saving a threshold, you can simulate it against the past 24 hours to see how many alerts it would have fired. A misconfigured rule now fails before you save it.
• The query engine adds memory protection for GROUP BY on high-cardinality fields, truncating automatically with a notice when limits are hit, so one bad query can't take down a node.
• Dashboard loading is faster: first-paint time for pages with 100+ charts dropped by about 40%.
• Grok-based log parsing: custom grok rules can now structure non-standard log formats, extending the collector's parsing and pairing well with automatic field typing.

Fixes

• Fixed occasional log-write data loss under extreme concurrency (a WAL flush ordering issue).
• Fixed the boot-time auto-start script failing intermittently on Kylin V10.
• Fixed silently dropped OTLP reports when the protocol header was missing; these now produce a warning log.
• Fixed a time_bucket boundary calculation error when ranges span a month.
• Fixed dashboards not refreshing their charts after a time-range change.
• Fixed an occasional missed notification when alert grouping and a silence were both active.

Known Issues

• On Loongson 3A5000, the trace graph view can stutter under extreme concurrency; a fix is planned for v2.5. Disabling the flame-graph view is a temporary workaround.
• Jumping straight from v2.2 to v2.4 is not supported; upgrade to v2.3 first.

Upgrade Notes

Upgrading from v2.3 requires backing up the metadata database first and running the v2.3 → v2.4 migration scripts in order. Alert rules go through a one-time format migration during the upgrade, so schedule it for a low-traffic window. After upgrading, confirm all component versions on the System Status page before restoring traffic. If you use DM8 or KingbaseES for storage, run jjhub-storage check again after upgrading to confirm the partition-key migration succeeded. If you run into problems after upgrading, restore the metadata database from backup and roll back to v2.3; keep the rollback window within 24 hours to avoid mixing old and new data formats. Before going live, stage the upgrade on a single test tenant, replay a day of traffic, and compare alert output against the previous version — especially if you lean on the new alert grouping rules. That catches most migration surprises before they reach production.