v2.4 Release: Native OTLP, Alert Deduplication and Log Tiering

New: native OTLP ingestion

Previously, ingesting traces and metrics required deploying an OpenTelemetry Collector locally as a relay. Starting with v2.4, the platform exposes an OTLP endpoint directly, so applications can skip the Collector and point their SDK at the platform:

export OTEL_EXPORTER_OTLP_ENDPOINT=https://ob.example.com/otlp
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <token>"

Existing users who already run a Collector are unaffected — both paths coexist. Dropping the relay removes a single point of failure and simplifies small deployments. The trade-off is that there is no local batching buffer, so the platform enforces rate limits as a safety net. Both gRPC and HTTP OTLP endpoints are exposed at the same base path; prefer gRPC when your SDK supports it for lower overhead on high-volume services.

New: alert deduplication

Alert storms are an on-call nightmare: one database failure cascades into "dependency error" alerts across a dozen services, and the phone won't stop buzzing. v2.4 adds alert deduplication:

• Root-cause aggregation — alerts pointing at the same root cause within a time window merge into one, with the list of affected services attached.
• Dedup window — the same alert fires once within a configured window (10 minutes by default) unless it escalates.
• Silence periods — mute alerts during release or maintenance windows to stop false-positive spam.

Aggregation rules are configurable on the alert-rule page, grouped by service, error type or trace root cause. After deduplication, one database failure collapses from "a dozen alerts" into "one root cause plus blast radius," so the on-call engineer can see what to fix first. Escalation still works as before: if a deduplicated alert stays open beyond its escalation threshold, it re-fires at the next severity level.

New: log hot/cold tiering

Once log volume grows, storage becomes the biggest line item. v2.4 introduces hot/cold tiering:

• Hot tier — the last N days of logs (7 by default) live on SSD with instant search.
• Cold tier — older logs compress and archive to object storage at roughly a third of the cost.
• Transparent queries — querying cold data just means adding a time range; the platform searches across tiers behind the scenes.

In testing, 30 days of log storage cost dropped about 55%. Cold-data queries are 1–2 seconds slower, which is an acceptable trade-off. Set N based on how far back you actually search: teams that rarely look past 14 days can shrink the hot tier and push more into cold storage, widening the savings.

Improved: tracing performance

• Reworked hydration of long-span traces, cutting load time by about 40%.
• Filtering the trace list by service no longer does a full scan; response time dropped from seconds to hundreds of milliseconds.

Fixes

• Fixed alert rules not firing across midnight time windows.
• Fixed occasional index inconsistency during cold-tier archiving.
• Fixed compatibility issues with some collector binaries on ARM64.

Compatibility and migration

• v2.4 is backward compatible with v2.3 configuration; no data migration is required on upgrade.
• Alert rules created before v2.4 keep their old behavior until you opt into deduplication, so existing notification flows stay unchanged until you are ready.
• The OTLP endpoint is additive — the previous Collector-based path keeps working as-is.

Known issues and deprecations

• The legacy JSON-over-HTTP ingestion API is deprecated and will be removed in v2.6; migrating is a one-line endpoint change.
• Cold-tier archives are immutable for now; deleting a range of cold logs is not yet supported and is planned for v2.5.
• Alert deduplication relies on trace root cause; if a service does not emit trace context, dedup falls back to service + error type grouping.

What's next

v2.5 is already in development around two themes: a writable cold tier (delete and re-tier ranges) and cross-tenant alert grouping for managed-service deployments. If either matters to your environment, the relevant preview builds will land in the test channel first.

Upgrade notes

Upgrading to v2.4 is in-place; configuration and data remain backward compatible. Hot/cold tiering is off by default — enable it under Storage Settings and specify the object-storage endpoint for the cold tier. Native OTLP ingestion is on by default and reuses the ingestion token from Service Management, so there is nothing new to request.