v3.6.0 Release: Alert Noise Reduction, Domestic CPU Support, and Kubernetes Collection

Jujing OBSERVE v3.6.0 is out. This release focuses on three areas: alerts moving from "sent" to "worth handling," domestic chip and OS adaptation, and the Kubernetes collection experience. Here is the full changelog.

Monitoring and alerting: noise-reduction engine

A new alert aggregation and noise-reduction engine is live. The evaluation target for alert rules upgrades from "a single point" to "an aggregation window," with two parameters — duration and minimum trigger count. Alerts sharing a root cause collapse into a parent alert with child items, and a rule whose state hasn't changed sends exactly one notification instead of re-paging.

Severity is now inferred from blast radius instead of set manually: anything touching a public-facing core endpoint, exceeding a user-impact threshold, or lasting too long is automatically escalated to P0/P1 and routed to phone call, WeCom, and SMS channels. Silence windows are new, with filtering by rule, data source, and tag, plus one-off and recurring silences. Weekly alert reports arrive alongside, tracking false-positive rate, mean response time, and escalation count.

Xinchuang: Phytium/Kunpeng and Kylin/UOS support

The backend and collector now ship official arm64 multi-arch images that run on Phytium and Kunpeng chips, compatible with Kylin and UOS. The build chain locks a glibc baseline to fix startup failures from missing GLIBC symbol versions on older systems; collector worker count now derives from CPU cores, fixing collection halts caused by hitting the file-descriptor limit on Kunpeng. Both rpm (Kylin) and deb (UOS) packages are provided with a shared config format. The console frontend is compatible with Qi'anxin and 360 Safe browsers, regression-tested against a compatibility list before each release.

Kubernetes collection enhancements

The collector gains namespace filtering (include/exclude) with wildcard support, preventing accidental collection of system namespaces that bloats data volume. Multiline log merging reassembles Java stack traces and Python tracebacks into a single entry using a start-line regex, with a maxLines cap. Kubernetes metadata labels — namespace, pod, container, node, labels, annotations — are injected into every log line, and business labels pass through from Pod labels.

Tracing: tail sampling

A tail-sampling policy is new: alongside head sampling, you can tail-sample errors and high-latency requests so the full trace and logs of slow and failing requests are always retained. Sampling is configured per service, with a ratio knob and a "retain all errors" switch.

Other updates

• The search API gains a dedicated trace_id index for filtering all logs of one request exactly.
• Dashboards support cross-data-source variable linking.
• Collectors gain per-tag collection on/off switches to silence noisy data sources.
• Fixed unstable result ordering in some search scenarios and chart overflow on very long labels.

Performance and stability

• Alert evaluation batch optimization lifts single-instance alert throughput by about 40%.
• Time-series write batching lifts write throughput by about 30%.
• Collector memory stays stable over long runs; fixed slow memory growth under high load.

Known issues

Dashboards imported from versions before v3.4 may need their alert-rule bindings re-selected once after upgrade; this is a one-time action and does not affect data. The "retain all errors" tail-sampling switch requires collector v3.6.0 or later — enabling it on an older collector is silently ignored until the collector is upgraded.

Usage advice

• After the noise-reduction engine goes live, pilot one high-frequency rule and check whether the duration and trigger-count settings fit before rolling out.
• Before cutting over to Phytium/Kunpeng, benchmark collection throughput and confirm worker count and open-files limits are tuned to core count.
• Verify the multiline start-line regex against real logs before enabling it everywhere.
• Validate in staging first, focusing on alert noise reduction and namespace filtering behavior.

Upgrade notes

To upgrade, roll the backend progressively and restart the collector with the new image tag. Data and alert rules are compatible — no migration needed. Older clients (v3.4 and below) still work, but the noise-reduction engine, tail sampling, and namespace filtering require a collector upgrade to take effect. See the "v3.6.0 Upgrade Guide" for full steps; open a ticket in the console for any issue and we'll prioritize by impact.