v2.4 ships faster log-search indexing, native OpenTelemetry Collector support, alert silences and on-call scheduling, plus fixes and compatibility improvements.
Once log volume grows, slow search is the most common complaint. v2.4 rewrites the time-partitioned index and adds inverted-index pre-aggregation; P99 latency for high-frequency queries (filtered by service, level and time range) drops by about 50% on average. No config changes are required after upgrading — the index rebuilds automatically in the background.
The platform now ships a built-in OTel Collector. Enable it with one click in the console and it generates the OTLP endpoint config and token for you. Java, Go and Node applications can copy and paste the snippet — no need to maintain your own Collector deployment:
curl -X POST https://ob.example.com/otlp -H "Authorization: Bearer <token>" -d '{"resourceLogs": [...]}'Silence alerts by time window (for example, a maintenance window in the early hours, or the duration of a known incident) and rotate alert recipients on a schedule, so the whole team doesn't get paged by the same alert. Both the on-call roster and silence rules can be referenced directly inside alert rules, and can be configured per environment (production vs. staging).
LIMIT pagination syntax.Everything in this release is opt-in except the index rebuild and the bug fixes, so upgrading is low-risk for existing installations. Here's how to validate each change in a few minutes.
Faster search — nothing to enable; the index rebuilds automatically after upgrade. To confirm it's active, run a broad query against a large service and compare latency to your v2.3 baseline.
Built-in OTel Collector — open Settings → Ingestion → OpenTelemetry, toggle it on, and copy the generated endpoint and token. Point an application at it and check that traces appear within a minute. The snippet supports both gRPC (port 4317) and HTTP (port 4318).
Alert silences — create a silence from any alert rule. Pick a time window (a one-off maintenance slot or a repeating weekly pattern) and optionally scope it to an environment:
silences:
- name: "nightly-maintenance"
match: { env: "prod" }
schedule: "0 2 * * *" # every day 02:00
duration: "2h"
comment: "database backup window"Silences suppress notifications but still record the alert event, so you keep the history for post-incident review.
On-call rotation — define a roster with shifts and handoff times, then reference the roster in an alert rule's notification target. Only the person currently on shift is paged; if they don't acknowledge within the timeout, the alert escalates to the next person. Silences and rotations are evaluated together, so a maintenance-window silence takes precedence over a rotation that would otherwise page the on-call engineer.
The 50% P99 improvement was measured on a tenant ingesting roughly 300 million events per day, querying by service, level and a one-hour time range. Your results depend on query shape and index warm-up: run the heaviest recurring queries once after the rebuild so the index is warm before the team hits it during an incident.
Upgrading from v2.3 only requires swapping the binary and restarting; configuration is backward-compatible. Enabling the new index requires triggering a one-time rebuild in the background. Run a round in staging first, then promote to production.
Known issue: in extreme cases (a single tenant ingesting over one billion log events per day) the new index's compression ratio fluctuates by about 5%. A fix is planned for v2.4.1.
Compatibility: v2.4 agents and SDKs are fully backward-compatible with v2.3 backends, and the new index format requires no schema changes to existing stored data. If you run multiple environments, upgrade staging and production in sequence rather than simultaneously to keep the shared ingestion endpoint stable.