---
title: Plan your metrics setup
description: Understand how each metrics ingest path stores data, when to use the OpenTelemetry or ECS data model, and which ingest path fits your deployment type.
url: https://www.elastic.co/elastic/docs-builder/docs/4547/solutions/observability/metrics/plan-your-setup
products:
- Elastic Cloud Hosted
- Elastic Cloud Serverless
- Elastic Documentation
- Elastic Observability
applies_to:
- Serverless Observability projects: Generally available
- Elastic Stack: Generally available
---
# Plan your metrics setup
Before you ingest metrics at scale, decide on two things: the data model your metrics are stored in, and the ingest path for your deployment type. Elastic doesn't convert metrics between schemas at ingest, so the ingest path you use determines how your data is stored, which field names you query, and which prebuilt dashboards work.
## Choose a data model
The data model is the schema your metrics are stored with: the naming conventions that determine your metric and field names. Use the OpenTelemetry schema unless you need existing Elastic Common Schema (ECS) integrations, dashboards, and alerts to keep working without customization. For that and other use cases where ECS might work better, refer to [Know when to keep using classic Elastic components](/elastic/docs-builder/docs/4547/solutions/observability/get-started/opentelemetry/start-with-otel#start-with-otel-when-classic).
Metrics follow the OpenTelemetry semantic conventions, for example the metric `system.cpu.utilization`, with attributes stored under `attributes.*` and `resource.attributes.*`. This is the default. It matches the OpenTelemetry ecosystem and the Elastic OpenTelemetry ingest paths.
Metrics follow Elastic's original field naming conventions, for example `system.cpu.user.pct`. Elastic Agent integrations write this schema, as does [Metricbeat](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/4547/reference/beats/metricbeat), the standalone Beats shipper for metrics. Use ECS when you need existing ECS integrations, dashboards, and alerts to keep working without customization.
Prometheus remote write uses neither schema. It stores Prometheus metric and label names as they arrive, for example the metric `node_cpu_seconds_total`, with labels stored under `labels.*`. You get this data model when you keep Prometheus and add Elastic as a remote write target.
Use one schema. Mixing OpenTelemetry and ECS in one deployment works, but requires two sets of field names in your queries and dashboards.
### How each ingest path stores metrics
| Ingest path | Stored as | Metric values and labels |
|----------------------------------------------------------------------------------------------------------------|-----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Managed OTLP Endpoint, Elastic Agent configured as an OTel Collector gateway, Elasticsearch OTLP/HTTP endpoint | OpenTelemetry-native | `metrics.`, with OpenTelemetry attributes under `attributes.*` and `resource.attributes.*`, in `metrics-*.otel-*` data streams |
| Elastic Agent integrations, Metricbeat, Beat receivers | ECS | ECS field names, for example `system.cpu.user.pct`, in the integration's data streams |
| APM Server or managed inputs OTLP intake (the `.apm` endpoint) | ECS | Legacy path that translates OTLP data to ECS. Not recommended for new setups. |
| Prometheus remote write (Managed Prometheus Remote Write endpoint or Elasticsearch endpoint) | Prometheus names, unchanged | `metrics.`, with labels as `labels.` dimensions, in `metrics-*.prometheus-*` data streams. No conversion to OpenTelemetry or ECS. |
For the OpenTelemetry Protocol (OTLP) paths, refer to [How your ingest path determines the data format](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/4547/reference/opentelemetry/compatibility/data-streams#ingest-path-data-format). For Prometheus remote write, refer to [Data mapping](/elastic/docs-builder/docs/4547/manage-data/data-store/data-streams/tsds-ingest-prometheus-remote-write#data-mapping).
### Implications of your choice
The schema you choose affects how you ingest, which metric names you query, and which dashboards work without customization:
| Aspect | OTel schema | ECS |
|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------|---------------------------------------------------------------------------|
| **Ingest using** | EDOT SDKs, any OTLP-compatible client, Elastic Agent configured as an OTel Collector | Elastic Agent integrations, Metricbeat |
| **Metric names** | OpenTelemetry semantic conventions (`system.cpu.utilization`) | ECS (`system.cpu.user.pct`) |
| **Prebuilt dashboards** | OpenTelemetry content packs from the Kibana Integrations UI | Elastic Agent integration dashboards |
| Elastic Stack: Generally available since 9.5, Elastic Stack: Preview in 9.4 Elastic Cloud Serverless: Generally available **PromQL support** | Yes | Yes, when the integration stores data as a time series data stream (TSDS) |
| **Recommended for** | Default | Existing ECS integrations, dashboards, and alerts |
Prometheus remote write isn't in the table because it isn't a schema you choose: metrics ingested that way always keep their Prometheus names.
PromQL support depends on storage, not schema. Elasticsearch evaluates PromQL over any TSDS matched by `metrics-*`, whichever ingest path filled it. OTLP and Prometheus remote write metrics always land in a TSDS. Elastic Agent integration data streams are a TSDS when the integration enables it. Refer to the [PromQL reference](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/4547/reference/query-languages/promql) for how Elasticsearch evaluates PromQL.
## Choose an ingest path
Your deployment type determines the recommended path. Use Elastic Agent integrations instead of the recommended path only when you need ECS.
| Deployment | Recommended path | Also available |
|-----------------------------------------------------------------------------------|-------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Elastic Cloud Serverless | Managed OTLP Endpoint | - Managed Prometheus Remote Write endpoint- Elastic Agent integrations |
| Elastic Cloud Hosted | Managed OTLP Endpoint | - Managed Prometheus Remote Write endpoint Elastic Stack: Generally available since 9.4- Elastic Agent integrations |
| Self-managed Elastic Stack, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes | Elastic Agent configured as an OTel Collector gateway | - Elasticsearch OTLP/HTTP endpoint Elastic Stack: Generally available since 9.2- Elasticsearch Prometheus remote write endpoint Elastic Stack: Generally available since 9.5, Elastic Stack: Preview in 9.4- Elastic Agent integrations |
For configuration details for each path, refer to [Ingest metrics](https://www.elastic.co/elastic/docs-builder/docs/4547/solutions/observability/metrics/ingest).