v2.6 ships three capabilities: database slow-query analysis, alert deduplication and noise reduction, and a trace diff view. This post explains each feature, when to use it, and upgrade notes.
v2.6 targets three recurring pain points: slow database queries that are hard to localize, alert storms that bury the signal, and the difficulty of comparing traces to spot regressions after a deploy. Here's what we shipped for each, how to use it, and what to watch when you upgrade.
The old debugging path was 'endpoint is slow → guess it's the database → manually enable slow logging in the DB,' with several hops in between, each of them slow and often blocked on DBA availability. v2.6 links database slow queries directly into traces. Onboarding is unchanged — it still uses OpenTelemetry database instrumentation — and the platform now extracts the SQL text, execution time, and rows returned from spans, then aggregates them into a slow-query list.
The entry point is Traces → Slow Queries: filter by service, database instance, and duration threshold, and click any slow SQL to see its owning span and full call chain. That last part is the real win — you finally see which upstream endpoint triggers the slow query, not just that the query is slow. Common configuration:
slow_query:
threshold_ms: 500 # SQL slower than this counts as a slow query
capture_statement: true # whether to capture the full SQL text
mask_parameters: true # mask parameter values in the SQLSet mask_parameters to true in production. Slow SQL often carries phone numbers, ID numbers, and other sensitive parameters, and you can only afford to retain it long-term once it's masked. Masking happens in the Collector or agent before data leaves your network, so the platform never stores the raw values.
Alert storms are the classic ops nightmare: one database goes down, dozens of upstream and downstream services error out together, and you get a hundred alerts in a minute. The signal is in there somewhere, but it's buried under the noise, and the person on call either misses it or mutes everything. v2.6 adds two layers of deduplication:
You enable it by adding a dedup policy to an alert rule — no extra components. The collapsed primary alert is tagged as a 'root-cause candidate,' with services auto-sorted by dependency direction so the most likely source sits at the top. Instead of reading a hundred alerts to figure out what broke first, you read one.
The worst part of a canary deploy is 'metrics look fine, but one endpoint quietly got slower.' Aggregate numbers hide a single endpoint regressing because the rest of the traffic averages it out. v2.6's trace diff view lets you select two traces — say a pre-release baseline versus the new build — and shows span-by-span latency differences side by side. Spans whose difference exceeds the threshold are highlighted in red; click one to see the log differences inside. It's especially effective for hunting 'this request type times out occasionally after deploy' bugs, and beats eyeballing flame graphs by hand. Pair it with a canary: keep a few percent of traffic on the old version, diff against the new one, and you'll catch regressions before they reach 100% of users.
Slow query analysis depends on database instrumentation, so after upgrading, bump each service's SDK to 1.30+ and restart, or the feature won't collect data. The topology-based dedup draws on the service dependency graph; if you haven't enabled dependency analysis yet, let it accumulate for a week after the upgrade so the graph is dense enough to collapse cascades reliably. Everything else is a compatible, rolling upgrade — no schema migration downtime required.