Migrate from Prometheus

If you're already running Prometheus, you can start sending metrics to Elastic while your existing scrape configurations and alerting rules continue to work. Grafana Alloy and other Prometheus remote write clients use the same endpoint.

You need:

  • An Elastic deployment that can ingest metrics.
  • An API key for the ingest path you use. Managed inputs, the Managed OTLP and Managed Prometheus Remote Write endpoints that Elastic Cloud runs for you, authenticate with the event:write privilege for the apm application. The Elasticsearch remote write endpoint authenticates with an API key that can ingest metrics.
  • Your existing pipeline left running. Send data to both systems until you have rebuilt the queries, dashboards, and alerts you rely on.

  1. Send samples to Elastic

    Add a remote write target so Prometheus also sends samples to Elastic. The endpoint depends on your deployment.

    Use the Managed Prometheus Remote Write endpoint. In the Elastic Cloud Console, open your project, select Manage, then under Application endpoints, cluster and component IDs select Prometheus and copy the endpoint. Authenticate with an API key that has the event:write privilege for the apm application.

    remote_write:
  - url: "<prometheus-endpoint>"
    authorization:
      type: ApiKey
      credentials: <api_key>

    Replace <prometheus-endpoint> with the value you copied and <api_key> with that API key.

    Managed inputs provide durable buffering, unified authentication, and back-pressure handling. URL-path routing to custom data streams isn't supported on this endpoint. Use label-based routing instead. For authentication, routing labels, and limitations, refer to Ingest Prometheus metrics with the Managed Prometheus Remote Write endpoint.

    Use the Managed Prometheus Remote Write endpoint. In the Elastic Cloud Console, open your deployment, select Manage, then under Application endpoints, cluster and component IDs select Prometheus and copy the endpoint. Authenticate with an API key that has the event:write privilege for the apm application.

    remote_write:
  - url: "<prometheus-endpoint>"
    authorization:
      type: ApiKey
      credentials: <api_key>

    Replace <prometheus-endpoint> with the value you copied and <api_key> with that API key.

    Managed inputs provide durable buffering, unified authentication, and back-pressure handling. URL-path routing to custom data streams isn't supported on this endpoint. Use label-based routing instead. For authentication, routing labels, and limitations, refer to Ingest Prometheus metrics with the Managed Prometheus Remote Write endpoint.

    Use this endpoint rather than sending remote write traffic directly to Elasticsearch, which bypasses the buffering and back-pressure handling that managed inputs provide.

    The Managed Prometheus Remote Write endpoint isn't available. Send remote write traffic to Elasticsearch directly by adding this block to prometheus.yml:

    remote_write:
  - url: "https://<es_endpoint>/_prometheus/api/v1/write"
    authorization:
      type: ApiKey
      credentials: <api_key>

    Replace <es_endpoint> with your Elasticsearch URL and <api_key> with an API key that can ingest metrics.

    For the endpoint URL, authentication, Grafana Alloy configuration, and how to route metrics to different data streams, refer to Prometheus remote write endpoint.

    By default, samples land in the metrics-generic.prometheus-default data stream. Prometheus metric names become metrics.<metric_name> fields, and labels become labels.<label_name> dimensions. PromQL continues to use the original Prometheus names. ES|QL uses the Elasticsearch field names. For the mapping table, refer to Data mapping.

    Grafana Alloy and other Prometheus remote write clients send to the same URL you configured in this step. For an Alloy example that targets the Elasticsearch endpoint, refer to From Grafana Alloy. On Elastic Cloud Serverless and Elastic Cloud Hosted, use the managed Prometheus endpoint as the URL instead.

    To confirm that samples are arriving, open Index Management using the global search field, select the Data Streams tab, and check that the data stream exists and its storage size grows as Prometheus sends samples.

  2. Query and visualize

    After samples are in Elastic, explore and visualize the metrics in Kibana. Your existing Grafana dashboards can keep working while you migrate.

    In Kibana, run ES|QL time-series queries over the migrated metrics, browse them in the Discover chart grid, and add charts to dashboards. For the query languages and the Discover workflow, refer to Explore metrics.

    To keep using PromQL, query the metrics with the PROMQL ES|QL command or the Prometheus-compatible API. If you use Grafana, point it at Elasticsearch as a Prometheus data source. Grafana treats Elasticsearch like any other Prometheus backend, so existing dashboards and template variables keep working as long as they use supported PromQL. For the data source URL and authentication, refer to Use Elasticsearch as a Prometheus data source in Grafana. For constructs Elasticsearch doesn't support, refer to PromQL limitations.

  3. Recreate alerts

    Elastic has no built-in import for Prometheus Alertmanager rules. After you can query the same time series in Elastic, recreate the alerts you still need.

    If your alerts already run in Grafana against Prometheus, point those alert rules at the Elasticsearch Prometheus data source after you switch the dashboards. Confirm each expression against PromQL limitations before you stop alerting against Prometheus.

    To alert in Elastic, create a custom threshold rule on the metrics data view. For host, pod, and similar resource checks, use an inventory rule. For the full list of Observability rule types, refer to Create and manage rules.