Elasticsearch Exporter

Last reviewed Sep 13, 2026 · 819 words

Elasticsearch Exporter is a 64 MB Go binary that turns the _cluster/health, _nodes/stats and index stats APIs into Prometheus series, and the single decision that shapes the deployment is which of its flags you switch on. With defaults it emits a few hundred series per node and costs nothing. With --es.indices --es.shards against a cluster holding 800 indices it emits tens of thousands, scrapes take seconds, and Prometheus grows by gigabytes a week. Start with the small set and add flags only when a dashboard demands them.

One exporter per cluster, not per node

This is not an agent. It talks to the REST API, so one instance pointed at any node covers the whole cluster, and --es.all makes it collect node stats for every member rather than only the node it connected to. Run it next to Prometheus, give it a URL, and it does a handful of HTTP calls per scrape.

services:
  elasticsearch-exporter:
    image: quay.io/prometheuscommunity/elasticsearch-exporter:latest
    command:
      - --es.uri=http://es01:9200
      - --es.all
      - --es.indices
    environment:
      - ES_USERNAME=prometheus
      - ES_PASSWORD=change-me
    ports:
      - "9114:9114"
    restart: unless-stopped

Metrics appear on port 9114 at /metrics. Keeping credentials in environment variables rather than inside the URI matters because the command line shows up in docker inspect and in process listings, and the URI is also what the exporter logs when a request fails.

Create the monitoring role before you point it at production

With security enabled, the exporter needs the monitor cluster privilege plus monitor on the indices you care about, and nothing else. Do not hand it the elastic superuser; a leaked password from a metrics box should cost you read access to statistics, not the cluster.

POST _security/role/prometheus_monitor
{
  "cluster": ["monitor"],
  "indices": [{ "names": ["*"], "privileges": ["monitor"] }]
}

Create a user with that role, put its credentials in the environment above, and confirm with curl -u prometheus http://es01:9200/_cluster/health before blaming the exporter. The same binary works against OpenSearch for the health, node and index endpoints; only the newer Elastic-specific APIs come back empty.

The flags are a cardinality dial

A daily-index logging cluster is where this bites: 30 days of retention times 20 indices a day times 5 replicas of shard series adds up fast. If you only need to know which index is eating disk, --es.indices alone answers it.

Six alerts, in the order they matter

elasticsearch_cluster_health_status{color="red"} == 1 for 2 minutes means a primary shard is gone; page on it. elasticsearch_cluster_health_number_of_unassigned_shards > 0 for 15 minutes is yellow that has not resolved on its own. Disk comes next, because Elasticsearch stops allocating at 85 percent and forces indices read-only at 95 percent: alert when elasticsearch_filesystem_data_available_bytes / elasticsearch_filesystem_data_size_bytes < 0.2. Heap pressure at elasticsearch_jvm_memory_used_bytes{area="heap"} / elasticsearch_jvm_memory_max_bytes{area="heap"} > 0.9 predicts the long garbage-collection pauses that make a node drop out. increase(elasticsearch_breakers_tripped[10m]) > 0 catches queries that would have blown the heap. Finally rate(elasticsearch_thread_pool_rejected_count{type="write"}[5m]) > 0 tells you ingest is being refused, which your log shippers will notice long before your users do.

Versus Elastic's own Stack Monitoring

Stack Monitoring ships free with the basic licence, but it wants Metricbeat or Elastic Agent on every node, ideally a second cluster to hold the data, and Kibana to view it. That is a lot of Elastic to monitor Elastic. The exporter gets the cluster onto the same Grafana dashboards and Alertmanager routes as the rest of your stack, which is the point of running Prometheus in the first place. What you lose is the per-query profiling and the index lifecycle views; nobody has built those on top of the exporter, and I would not wait for it.

What I'd do

One exporter container beside Prometheus with --es.all and --es.indices, a dedicated prometheus_monitor role, and the 6 alerts above with red-cluster and disk as the two that page. Leave --es.shards off until a specific question needs it, and revisit the flag list the first time the scrape takes more than a second. If you are not already running Prometheus for everything else, Stack Monitoring on a small Elasticsearch install is less work; the exporter earns its place the moment the cluster is one target among many.