OBSERVE v2.7.0 Released: 4x Faster Log Search, Alert Silencing, and Tail-Based Trace Sampling

v2.7.0 focuses on three areas: log search performance, alert ergonomics, and trace cost control. Below is what's new, what changed, and what to watch when upgrading.

New features

Alert silencing windows. You can now define silencing rules by alert rule or by label. Two patterns we see most: time-based windows like "no pages between 00:00 and 06:00" for non-critical services, and maintenance windows like "silence everything tagged env=staging during the Friday deploy." Silences are first-class objects in the API, so you can schedule them from your CI/CD pipeline ahead of a release. Silencing doesn't drop the underlying events — suppressed alerts are still recorded and marked as silenced in the alert history, so you can audit what you missed after the window closes:

silence:
  - name: nightly-window
    match: { level: [warning, info] }
    window: "00:00-06:00"
  - name: staging-deploy
    match: { env: staging }
    duration: 30m

Tail-based trace sampling. Until now, head-based sampling decided whether to keep a trace before it finished, which meant rare errors could be dropped by luck of the draw. Tail-based sampling defers the decision until the trace completes, so you can keep every trace where error=true, or every trace slower than 2s, and drop the rest. The result is a large drop in trace storage cost with no loss of the traces you actually open during an incident. On a high-QPS service, keeping 10% of traces instead of 100% typically cuts trace storage cost by more than half while still preserving every error and slow path:

sampling:
  tail:
    - name: keep-errors
      keep: "error == true"
    - name: keep-slow
      keep: "duration_ms > 2000"
    default: 0.1

SQL query views. Frequent queries can now be saved as named views and referenced from dashboards and alert rules. This removes the copy-paste drift where five team members maintain five slightly different versions of the same query. Views are versioned: when you change one, dashboards keep the previous definition until you explicitly republish, so a bad edit can't silently break a board someone else owns.

Improvements

Log search is on average 4x faster. We rebuilt time-partition pruning so long-range queries no longer scan the entire store; a query with a time range now touches only the relevant partitions. The 4x figure is an average across our benchmark suite; the biggest wins come on multi-day range queries, where the old path scanned partitions it didn't need — short one-hour queries were already fast and improved modestly. Aggregations gained subquery support and multi-field GROUP BY, so complex statistics run engine-side instead of being exported and re-processed in a spreadsheet. The collector's ingestion path added an OTLP/HTTP endpoint, which widens SDK and client compatibility beyond gRPC.

Fixes

Three fixes worth calling out: the collector occasionally pegged a core at 100% CPU on Kylin V10 (a scheduler interaction, now fixed); traces broke across data centers in MQ scenarios where the message header didn't carry trace context (now propagated); and the console occasionally rendered a blank screen under heavy log volume (a pagination bug, now fixed). All three are backported to the v2.6 patch line, so if you pinned to v2.6.x you can pick them up without a full feature upgrade.

Deprecations

Two things are deprecated but not removed in v2.7: the legacy gRPC-only ingestion endpoint (still works, but prefer OTLP/HTTP) and the old per-rule sampling UI (now covered by the policy file). Both will be removed in v3.0, so migrate at your own pace. Nothing in this release is a breaking change.

Upgrade notes

Back up your configs and alert rules before upgrading. v2.7 is backward-compatible with v2.6 rule formats, so a hot upgrade is supported and no rule migration is required. Upgrade your collectors to v0.105 or later to use the new OTLP/HTTP endpoint and the file-storage queue; older collectors continue to work but won't benefit from the new ingestion features. If you run collectors in a three-center setup, upgrade them in a rolling fashion and keep at least one old-version collector live until the new ones have run for 24 hours, so you can fall back if the new ingestion path surfaces an issue in your environment. The full changelog is on the docs site, and if you hit anything during the upgrade, open a ticket — we track upgrade issues separately and respond fast.