OBSERVE v2.6.0 ships three capabilities—alert silencing with dynamic baselines, traceId-based log context search, and eBPF agentless tracing—plus fixes for Dameng compatibility and timezone handling, along with upgrade notes.
You can now set calendar-based silence windows (for example a call auction or a weekly maintenance period), during which alerts can be downgraded or muted entirely. Alert rules gain a "dynamic baseline" mode where thresholds are computed from historical same-period data instead of being hard-coded. This pairs with tiered notification: P1 goes to phone + SMS, P2 to WeCom, and P3 to email only, so low-severity alerts stop flooding your channels.
The dynamic-baseline algorithm takes the median of "the same window yesterday + the same window a week ago" and multiplies it by a configurable deviation factor (2x by default). That absorbs normal fluctuation while still firing quickly on real anomalies.
Click any line in the log detail view to see the surrounding logs for that traceId and jump straight to the corresponding span. Investigating "why is this request slow" no longer means grepping across dozens of services—you go from a log line to its span in one step. By default the context shows 50 lines before and after, and it's configurable.
A new eBPF probe collects HTTP / gRPC traces and basic metrics without changing application code or restarting services—ideal for legacy systems that can't be instrumented. It currently supports kernel 4.18+ with BPF enabled. Coverage is at the protocol layer; custom in-process spans still require SDK instrumentation. The probe runs as a sidecar, is transparent to the application process, and keeps CPU overhead under 3%.
Back up your metadata before upgrading, and verify the eBPF probe's kernel compatibility in a staging environment first. Dynamic baselines need at least 14 days of history to stabilize, so enable them gradually and observe for a week before going all-in. Upgrading from earlier versions to v2.6.0 keeps existing configuration compatible—no collector-side changes required. If you enable the eBPF probe, upgrade the kernel to a supported version first.
Silence windows are evaluated server-side at alert-rule evaluation time, so a muted alert still records the event in history—you just don't get paged. That means you can audit later whether a silenced window hid a real incident and tune the window boundaries instead of blindly trusting them.
The log context search is backed by the traceId correlation already present in the ingestion pipeline; existing data needs no re-indexing. For older logs that predate traceId extraction, the feature degrades gracefully to a time-window fallback so you can still page through surrounding lines.
The eBPF probe attaches kprobes/uprobes at the network and syscall layers, so it sees wire-level request/response pairs without touching application memory. Because it operates below the application, it also captures calls that in-process SDKs miss when a process is thrashing or about to crash—useful for reconstructing the moments right before an outage.
A note on dynamic baselines: the median-based baseline deliberately ignores the top and bottom of the distribution, which makes it robust to occasional spikes like a burst of retries, but it also means a genuinely new, sustained traffic level takes a couple of days to become the new baseline. If alerts lag a real traffic shift, shorten the baseline window rather than raising the deviation factor.
Nothing is removed in v2.6.0; all existing configuration remains valid. We do plan to retire the legacy per-service token scheme in favor of the Collector-based token model in a future 3.x release, so start consolidating your tokens now. The dynamic-baseline feature will also gain weekly seasonality awareness—holidays, month-end settlements—in an upcoming minor release.
To try the new features, upgrade the control plane first, then roll the collectors. The eBPF probe ships as an optional sidecar image tagged v2.6.0-ebpf; it needs the kernel headers matching your running kernel, so install those before enabling it.
If you hit any issue with these features, open a support ticket with the exact kernel version, Collector version, and a sample trace—the eBPF path in particular behaves differently across kernels, and those three fields get us most of the way to a diagnosis.