v2.6.0 adds metric anomaly detection with dynamic thresholds, alert deduplication and silencing, regex highlighting and field aliases in log search, improved DM8 support, and 12 bug fixes. Includes upgrade notes.
v2.6.0 ships three new capabilities. First, metric anomaly detection based on historical baselines — dynamic thresholds instead of hand-picked fixed numbers. Suppose an endpoint normally fluctuates between 800 and 1200 QPS; at 3 a.m. the system spots an abnormal dip to 50 and alerts, while a fixed rule of 'below 100' would never fire. Enabling it is simple: in the alert rule, switch the threshold type from static to dynamic and pick a training window (7 days is recommended). The detector learns a per-signal baseline and fires only when the current value falls outside it by a configurable margin, so it catches both spikes and silent drops.
Second, alert deduplication and silencing: multiple alerts from one fault are merged automatically, with deduplication by service or by rule, plus a silencing window to pause alerts during releases or maintenance. This is the feature that stops a single database outage from waking up the entire on-call rotation with forty separate pages.
Third, log search gains regex highlighting and field aliases, so long field names can be mapped to short aliases for cleaner queries. Highlighting makes the matching portion of a long stack trace visible at a glance — a small change that saves real time during an incident.
Search performance: the inverted-index rebuild strategy was optimized, cutting P95 latency for common queries from 3.2s to 0.9s at 1TB scale. High-frequency fields (trace_id, status) now use columnar indexes automatically, which speeds up aggregation queries noticeably — most of the gains come from avoiding a full index scan when you filter by trace_id. Compatibility: DM8 support was improved, fixing the pagination dialect and millisecond timestamp precision. UOS Server V20 is now officially supported, with aarch64 and x86_64 install packages.
This release fixes 12 issues. A few of the high-impact ones: occasional page-skipping when logs are ordered by descending time; notification groups being lost after duplicating an alert rule; occasional Collector OOM under high concurrency; and trace sampling config not taking effect in certain scenarios. The full list is in the release notes bundled with the package.
For anomaly detection, start with low-risk metrics: enable dynamic thresholds on a handful of stable traffic and error-rate signals, keep the default margin, and watch for a week before expanding. The detector needs history to learn, so do not switch it on for a brand-new metric with a day of data.
For deduplication, configure grouping by service first — this collapses a database outage into one alert per affected service. Reserve rule-level grouping for cases where one rule genuinely spans many services.
For field aliases, alias the fields your team actually greps for: trace_id, status, request_time, and your longest nested JSON keys. Aliases are shared across the workspace, so agree on names up front to avoid two teams inventing two different aliases for the same field.
Back up your database and config directory before upgrading. You can upgrade in place from 2.5.x without rebuilding indexes; upgrading from 2.4.x or earlier requires migrating to the 2.5 storage format first, and an official migration script is provided. After upgrading, check that dynamic thresholds in your alert rules behave as expected, and keep at least 7 days of history so the anomaly detection training window is satisfied. Known issue: dynamic thresholds may false-alarm when data has a gap longer than 24 hours; this will be fixed in 2.6.1, and in the meantime you can temporarily switch that rule back to static thresholds.
If you are on 2.5.x, the upgrade is a straightforward in-place install with no data migration, so we recommend upgrading promptly — the search latency improvement alone is worth it for teams past a few hundred gigabytes of logs. For the anomaly detection rollout, keep an eye on the first week of alerts: a false positive here is cheap to silence, but a missed real anomaly is expensive, so tune the margin down only after you have watched the detector behave for a full week. Regex highlighting is on by default in the search page; field aliases are managed under workspace settings and apply to both search and alert rules.