Release notes for v2.6 covering log pipelines, metric query performance gains, expanded domestic-stack support, plus alerting and tracing improvements and one breaking change.
v2.6 introduces log pipelines, which parse, filter, and mask logs at the collection side. Example:
pipeline:
- name: nginx-parse
match: source == "nginx"
actions:
- grok: '%{IP:client_ip} %{WORD:method} %{URIPATH:path}'
- mask: field=client_ip, pattern=ipv4, keep_prefix=2Grok, regex, field masking, and log dropping are supported, and processing happens at the collector, cutting down on pointless storage and search costs. Masking is especially useful for compliance: sensitive fields are stripped before they ever reach storage, so you don't have to redo it at the storage layer. Each pipeline is a list of actions that run in order against a match filter, so a single source can be split into multiple pipelines for different log shapes — one for access logs, one for error logs, and so on. Pipelines run in the collector process, not on the agent, so they add no CPU to your application hosts and you can edit them centrally without redeploying collectors. A useful pattern is to keep the raw, untouched log in one pipeline while a second pipeline produces the parsed and masked copy, so you always have the original line for forensics even after normalizing the fields you query.
The metric query engine rewrote its storage format to a columnar layout, speeding up aggregation queries 3–5x on average. Wide-range queries spanning more than seven days now return in seconds instead of timing out, which matters most when you're comparing a metric to last month's baseline during an incident. Log search gained index sharding, roughly doubling the sustained log throughput per cluster. The changes are fully compatible with the query API, so older clients need no changes — the speedup shows up without any client-side work. These numbers come from internal benchmarks on a 30-node cluster ingesting roughly 120 GB of logs per day; your mileage will vary with your query mix, but the columnar rewrite is the single biggest query-latency change since v2.0, and it applies automatically to existing data after the migration step. One note on the metric rewrite: the migration re-encodes existing data into the new columnar format, so on very large clusters run it during a maintenance window, since it reads and rewrites your current metric store once.
For teams already running on the domestic stack, this release removes the last manual dependency steps on Kylin and UOS, which was the most common source of installation friction reported against v2.5. The bundled-dependency ARM package also drops the previous requirement to install several system libraries by hand — previously the top support ticket for domestic-stack deployments.
Alert rules gain "silence windows" and "grouped notifications" to prevent alert storms, and the trace view now supports filtering by custom tags. One breaking change: the old operator: gt syntax in alert rules is now uniformly operator: ">". Export your rules and batch-replace before upgrading — the upgrade script checks and warns automatically, but it will not silently rewrite your rules for you. Grouped notifications are worth enabling even without an active storm: they collapse related alerts into a single digest, which keeps the channel readable as you add more rules over time.
The upgrade is in-place for most deployments and does not disrupt the collection side, so your agents keep sending data while the backend restarts. The recommended sequence: back up config.yaml and your alert rules, run the migration check, export rules that use the old operator syntax and batch-replace them, then run the upgrade script and verify the console comes up before restarting anything else. Validate your pipeline rules and alert-rule migration in a test environment before touching production, paying special attention to existing rules that still use the old operator syntax. If you run a large number of alert rules, the export-and-replace step is worth scripting: the console downloads all rules as JSON, and a one-line find/replace on operator handles the bulk of the migration.
See the "Release Notes" page in the console for the full list.