Metrics at scale: One engine for all your telemetry

Every node, pod, and container your team runs generates its own metric series. When those metrics live in a purpose-built store and your logs live somewhere else, correlation becomes a manual job: different query languages, different timestamps, joined together by hand during an incident.

This Omdia white paper examines why log-shaped engines break under metric workloads and what it costs to keep running separate stores. It covers the structural differences between row and columnar storage, the engineering decisions behind Elastic's metrics engine, and what a single store changes for the teams querying across logs, metrics, and traces.

Highlights

• Why log-shaped engines break under metric workloads and what the structural fix looks like
• What separate telemetry stores cost in storage, query latency, and incident correlation
• How a single columnar engine handles metrics, logs, and traces without federation
• How to keep existing PromQL dashboards and alerts while consolidating onto one back end
• How automation changes the stakes when telemetry is fragmented across multiple stores

Additional resources

• Webinar: APM and OpenTelemetry: The key to unlocking insights from your logs
• Doc: Use OpenTelemetry with Elastic APM
• Tutorial: Get started with ES|QL queries