v2.4 adds alert rule templates, a rebuilt trace waterfall, natural-language-to-SQL search (NL2Query), faster cold-storage queries and a new alert channel, plus upgrade notes.
v2.4 is about removing three kinds of friction we kept hearing about: the friction of re-creating the same alerts for every service, the friction of hunting through flat trace tables, and the friction of learning a query language just to search logs. Each headline feature targets one of those, and the rest of the release is performance and hardening.
Previously, every onboarded service meant hand-writing four alerts — CPU, memory, error rate and slow endpoints — repetitive and easy to miss. v2.4 turns the common alerts into templates you apply with one click when creating a service, then tune the thresholds as needed.
templates:
- name: java-service-default
rules:
- cpu_usage > 80% for 5m
- jvm_heap_used > 85% for 5m
- error_rate > 1% for 5m
- p99_latency > 500ms for 5mTemplates support the {{service}} and {{env}} variables, substituted automatically when applied to multiple services. Change a threshold once and it syncs to every service using that template. You can also override a single rule per service without breaking the template link, so the common case is automatic and the edge case is still possible.
The old trace view was a flat table — long traces meant a lot of scrolling to find the slow span. v2.4 rebuilds it as a waterfall laid out along the time axis, with parent and child spans aligned and indented, so you can see at a glance which segment ate 90% of the time. There's also a span comparison view: pick two spans from the same endpoint and compare them side by side to spot which run picked up an extra slow SQL.
Log search now accepts natural language that gets translated to SQL. Type "last hour's error logs from order-service, newest first" and it renders a query before running it. The rendered query is shown for confirmation first, so ambiguous input doesn't trigger a bad search. The feature is off by default; enable it under Experimental Features. If a translation looks wrong, you can edit the generated SQL before running it, and your edit is fed back to improve later translations.
v2.4 is backward-compatible with v2.3 config and storage formats — swap the binary and go, no data migration needed. NL2Query depends on a large-language-model service, so private deployments must configure the model endpoint and key separately. Alert templates and the trace waterfall are local capabilities with no external dependency, so they work out of the box. If you've customized alert rules heavily, export them before upgrading and diff against the template defaults afterward.
To try alert templates, create any new service and pick a template from the dropdown — you'll see the four rules appear, editable before you save. For the trace waterfall, open any existing trace; it now renders as a waterfall by default, with a toggle back to the table view if you prefer the old layout. For NL2Query, flip the switch under Experimental Features, then type a plain-English query into the log search box and confirm the generated SQL before it runs. All three are available to existing tenants with no data migration, and the waterfall and templates require no extra configuration beyond the upgrade itself. If anything regresses, the previous table view and manual alert creation remain available as fallbacks, so you can upgrade with the confidence that the old workflow is still there if you need it.
Finally, a note on the feedback loop: the NL2Query edits you make are reviewed in aggregate (never exposing your data) to improve the translation model over time. The more you correct bad translations early on, the fewer you'll need to make later, so a few minutes of confirmation now pays off as the feature matures.