v2.4 is out this week: SQL search autocomplete and highlighting, alert silence windows and escalation, native OTLP metrics ingestion, a flame graph view, ~40% faster search, and fixes for Dameng case-sensitivity.
Jujing OBSERVE v2.4 shipped this week. The release focuses on search performance, alerting ergonomics, and Xinchuang compatibility. Here are the highlights.
The OTLP metrics support is the one to try first if you're on OpenTelemetry already. Removing the remote-write translation layer means fewer moving parts and lower end-to-end latency between a metric being emitted and it showing up in a dashboard or alert.
The alert silence window is also worth adopting immediately if your team has off-hours noise. Scoping non-critical alerts to business hours cuts pager fatigue fast, and the escalation rule means genuinely important alerts still find a human even when the first responder is asleep. Together these two features target the two biggest sources of on-call burnout: alert volume and the feeling that nothing is ever really seen.
The flame graph is a small addition but a high-leverage one for incident review: instead of clicking through dozens of spans to find where time went, it shows the hot path immediately. Pair it with the existing trace-log correlation and a root-cause review that used to take twenty minutes often takes two.
The search gains depend heavily on field cardinality and retention, so validate against your own workload: run your three most common incident queries before and after the upgrade and compare. That's the number that matters, not the vendor benchmark.
v2.4 is validated on Kylin V10 SP3 and UOS 1060 (both aarch64), against Dameng DM8 and KingbaseES V8. The Collector and agent now ship aarch64 builds as first-class artifacts, no longer tagged as preview. For the database layer, Dameng's compatibleMode=oracle parameter should be left unchanged during the upgrade—the platform reads it at startup and changing it mid-version can break query semantics.
The flame graph view currently renders large traces on a best-effort basis; traces with more than 5,000 spans may be truncated in the visualization (the underlying data is unaffected). A fix is planned for v2.5. The OTLP metrics path also has a minor gap: histogram buckets are ingested as-is, so exponential and explicit buckets are both accepted but not yet normalized to a single scheme.
Back up your database and configuration directory before upgrading, and validate in staging before production. v2.3 upgrades to v2.4 in place with no data migration; v2.2 and earlier must upgrade to v2.3 first. After upgrading, rebuild the search index once so the performance improvements take effect—it's a background job, so schedule it for a low-traffic window; search remains available during the rebuild, but the gains don't kick in until it finishes. In Xinchuang environments, double-check the Dameng connection compatibility parameter before and after the upgrade and confirm it's unchanged. Upgrade time on a medium deployment (a few hundred thousand log lines per minute) is typically under ten minutes, excluding the index rebuild. For teams on earlier releases, plan a short maintenance window rather than an in-place hot upgrade; the index rebuild is the slowest step and it is what makes the search gains visible. The full changelog and upgrade manual are in the documentation center.