v2.6 bridges trace-log correlation, centralizes sampling policies in the console, and adds sparse log indexing with query pushdown for major speedups — with upgrade steps and compatibility notes.
Before v2.5, traces and logs were two separate systems. To investigate a slow request you'd copy the time window out of the trace, then filter logs by time in the other system, flipping back and forth. v2.6 bridges the two: the trace detail page shows the logs within each span's time window, and the reverse works too — from an error log, one click jumps to the trace it belongs to.
The implementation is unglamorous: the collector stamps the trace_id onto the log as a field, and the query engine correlates by trace_id plus time window. For existing data, if your logs already carry a trace_id, it just works after the upgrade — no re-ingestion needed.
The correlation removes a whole category of copy-paste work during incidents. Instead of eyeballing two dashboards and aligning timestamps by hand, you stay in one screen and follow the relationship in either direction. That's a few minutes saved per investigation, which compounds when you're on your fourth incident of the week.
Sampling rates used to be scattered across each agent's config; changing one service meant logging into that machine. v2.6 consolidates sampling policies into the console, configurable per service and per namespace, with:
/pay.Policy changes take effect within a minute — agents pull them automatically, no restart. This is a big deal for the pre-peak "temporarily set the core path to 100%" operation, which used to mean touching dozens of machines and now is one click in the console.
Measured: on a 100-million-log database, a point query by service + keyword dropped from 40s to 3s; a 30-day time-series aggregation dropped from 18s to 5s.
The index covers a handful of high-cardinality, frequently filtered fields — not every column. That keeps index size small enough to stay in cache while covering the queries people actually run. If your workload filters heavily on a field we don't index yet, file a request; the index is designed to be extended field by field without a re-index of existing data.
v2.6 is backward compatible with v2.5, data format unchanged, in-place upgrade supported. Upgrade order: storage → ingester → querier → gateway → agent. Note that after sampling policies are centralized, the console policy overrides any local sampling config on the agent — export and archive your scattered local configs before upgrading. The three xinchuang images — Phytium + UOS + Kingbase, Kunpeng + Kylin + Dameng, and Loongson + Kylin + openGauss — are all synced to 2.6.
The legacy per-agent sampling config is now deprecated and will stop being read in v2.7. If you rely on it, plan the move to console policies during the v2.6 cycle rather than at the v2.7 deadline.
All v2.5 dashboards and alert rules load unchanged in v2.6 — the query language is backward compatible and no saved view needs rewriting. The only behavioral change is the new trace-log panel, which appears automatically wherever a dashboard references a trace; it can be toggled off per panel without affecting the underlying data. After upgrading, verify the trace-log correlation on one service first, then check that your sampling policies migrated correctly by spot-checking a few agents in the console — a mismatched policy is the most common post-upgrade surprise we see.