Release Notes v2.4: Metric Monitoring, Alert Templates, and Log Alert Silence

v2.4 is a metrics-focused release. It adds the metric dimension to Observe, makes alert rules reusable through templates, and rounds out the silence and tracing features you have been asking for. Full details below.

New: host and JVM metric monitoring

v2.4 completes the metrics dimension alongside logs and traces. The Agent now collects host CPU, memory, disk and network, plus JVM heap memory, GC count and thread count, in one pass. Metrics are shown as time-series charts with a custom time range and baseline comparison:

system.cpu.usage{host="app-01"} > 0.85 for 5m

You can write threshold expressions directly in the metric alert editor, exactly as you would in a Prometheus-style query, so engineers who already know that syntax feel at home immediately.

Metrics are linked to logs and traces: from an alert notification you can jump to the host's logs and to the traces in that time window, without switching between three pages. If you have been alerting only on log patterns, adding a few metric rules — CPU, heap usage, error rate — is the fastest way to catch problems the logs never mention, like a slow memory leak or CPU saturation that produces no error lines at all.

New: alert templates

Previously every team had to configure dozens of near-identical alert rules. v2.4 introduces alert templates: turn common rules like "error rate", "latency" and "CPU" into parameterized templates and apply them to many services at once:

alert_template:
  name: service-error-rate
  params: [service, threshold]
  condition: error_rate{service=${service}} > ${threshold}

When a new service goes live, apply the template and fill in the parameters — no hand-written rules, and no inconsistency between teams. Templates also make it practical to enforce a company-wide standard for what "healthy" looks like across every service: change the template once and every service picks up the change.

New: silence windows for log alerts

Log alerts (keyword- and error-count-based) now support silence windows, so planned releases and load tests no longer flood the channel. Alerts are still recorded during the silence period and remain visible in the audit log, so nothing is hidden — it is simply not paging anyone. Combined with alert templates, you can now plan a release end to end: template the rules, silence the window, and get a clean signal when the release is actually finished.

Improved: trace hydration speed

Hydration for long-span traces is about 50 percent faster; a trace with tens of thousands of spans now opens in under three seconds, down from six. Span storage compression was also improved, cutting disk usage by roughly 20 percent. Both changes matter most at the scale of high-traffic services, where long traces are the rule rather than the exception.

Fixes

• Fixed alert webhook delivery not retrying after failure; it now retries three times with exponential backoff, so a transient gateway error no longer drops an alert.
• Fixed log search returning incomplete results for ORDER BY ts DESC LIMIT on some data volumes.
• Fixed a bias in JVM thread-count collection under JDK 17.

Upgrade notes

This release is backward compatible: older Agents can keep sending logs and traces without an upgrade, so you do not need to touch every host at once. Metric collection requires upgrading the Agent to v2.4. Back up the configuration store before upgrading and follow the test → canary → full rollout order. If you run a large fleet, roll the Agent upgrade out gradually and watch the metric ingestion rate, since host and JVM metrics add a new stream of data to your storage. As always, report any regressions through the usual channel and we will follow up in the next patch release.