Best metrics exporters for Linux, Redis, and Elasticsearch

Forecasting only works if your metrics are complete, consistent, and cheap to collect. Exporters are the layer that turns raw service internals into clean time series. Pick ones that cover the right subsystems, use stable labels, and survive short scrape intervals. Below are the exporters that reliably power capacity planning and predictive alerting for Linux, Redis, and Elasticsearch.

What we value: strong metric coverage, predictable labels, low overhead, fast and safe scrapes, clear docs, and a path to trend and headroom calculations. Everything here speaks OpenMetrics and is widely used with Prometheus.

Best metrics exporters by stack

Linux: Node Exporter

Why it stands out. The Node Exporter is the standard for host telemetry. It exposes CPU times and saturation, memory and swap usage, filesystem capacity with mountpoint labels, network device stats, interrupts, and pressure stall information on modern kernels. Collectors are modular, so you can disable high-churn sources and keep cardinality steady. The textfile collector lets you publish custom metrics from scripts without writing a service.

Pros. Low CPU and memory overhead, stable metric names, deep filesystem and network coverage, PSI metrics for early saturation signals, textfile collector for custom gauges and counters.
Cons. No built-in TLS or auth. Per-process and container metrics require separate exporters. Some collectors produce high cardinality if you do not filter devices and mounts.
Practical setup. Run as a service or container, bind to localhost. Common flags: --collector.filesystem.mount-points-exclude='^/(dev|proc|sys|run|var/lib/docker/.+)', --collector.filesystem.fs-types-exclude='^(tmpfs|devtmpfs|overlay|squashfs)$', and --collector.textfile.directory=/var/lib/node_exporter/textfile_collector. Disable what you do not need with --no-collector.<name>.
Key signals. node_cpu_seconds_total by mode, node_filesystem_avail_bytes by mount, node_network_receive_bytes_total and _transmit_bytes_total, and PSI such as node_pressure_cpu_waiting_seconds_total and node_pressure_memory_stalled_seconds_total.

Redis: Redis Exporter

Why it stands out. The canonical Redis exporter translates INFO into clear metrics with useful labels. You get memory usage and fragmentation ratio, keyspace hits and misses, ops per second, slowlog counters, expired and evicted keys, replication role and sync state, and cluster or sentinel details. Labels map cleanly to instances and databases, which makes trend analysis and alerting straightforward.

Pros. Broad coverage including eviction pressure and replication status, supports standalone, sentinel, and cluster modes, works with password or ACL auth, can connect over TCP or a Unix socket.
Cons. Must run close to Redis to keep latency consistent. Some features need explicit flags. Avoid per-key scans to keep cardinality in check.
Practical setup. Start with redis_exporter --redis.addr=redis://127.0.0.1:6379 or point to a socket. Add auth in the URI if required. Keep --redis.exporter.client-timeout conservative for busy nodes. Do not enable key-level checks in production.
Key signals. redis_memory_used_bytes, redis_memory_max_bytes, redis_memory_fragmentation_ratio, redis_evicted_keys_total and its rate, redis_keyspace_hits_total and _misses_total, and redis_connected_slaves or replica sync metrics.

Elasticsearch: Elasticsearch Exporter

Why it stands out. This exporter surfaces the cluster view operators actually use. It reports cluster health and status, node roles, JVM heap and GC activity, thread pool queues and rejections, shard counts and states, indexing and search throughput, and I/O. Labels let you filter by cluster, node, index, and thread pool. It stays responsive at short scrape intervals.

Pros. Clear cluster and node summaries, actionable shard and thread pool signals, stable metric names, low overhead on the data nodes.
Cons. Secure access requires basic auth or tokens. Some ILM and ingest pipeline internals are better read from logs or APIs.
Practical setup. Run near the cluster, bind to localhost, and connect with a least-privilege user. Example: elasticsearch_exporter --es.uri=http://user:pass@127.0.0.1:9200 --es.all. Grant the ES user monitor at the cluster level and monitor on indices you care about.
Key signals. elasticsearch_cluster_health_status, elasticsearch_jvm_memory_bytes_used and _max, elasticsearch_thread_pool_queue_count and _rejected_count by pool, shard counts by state, and indexing or search rates.

Deployment and validation checklist

Plan network access. Bind exporters to 127.0.0.1 or a private interface. Only expose scrape ports needed by your Prometheus server or collector. If exposure is required, place a reverse proxy in front and enforce auth or mTLS.
Install predictably. Use distro packages or official containers. Pin to a known version and capture flags in systemd unit files or container manifests. Keep one exporter per job to avoid noisy multi-tenant hosts.
Enable only what you need. For Node Exporter, exclude virtual and ephemeral mounts. For Redis, avoid per-key collectors. For Elasticsearch, verify the user can read node, cluster, and index stats without admin privileges.
Scrape on a sane cadence. Start with 15 s for Redis, 30 s for hosts, and 30–60 s for Elasticsearch depending on cluster size. Keep scrape_timeout at least 2x the 99th percentile of scrape_duration_seconds.
Prometheus jobs. Example minimal jobs:

scrape_configs:
- job_name: 'node'
  static_configs: [{ targets: ['localhost:9100'] }]
  metric_relabel_configs:
  - source_labels: [device]
    regex: '^(loop|ram|dm-\d+)$'
    action: drop
  - source_labels: [fstype]
    regex: '^(tmpfs|devtmpfs|overlay|squashfs)$'
    action: drop
- job_name: 'redis'
  static_configs: [{ targets: ['localhost:9121'] }]
- job_name: 'elasticsearch'
  static_configs: [{ targets: ['localhost:9114'] }]

Validate baseline metrics. curl -s localhost:9100/metrics | grep node_filesystem_avail_bytes, curl -s localhost:9121/metrics | grep redis_memory_used_bytes, and curl -s localhost:9114/metrics | grep elasticsearch_cluster_health_status. Confirm up is 1 and scrape_duration_seconds is well below your timeout.
Harden and document. Record ports, flags, owner, and update procedure. Keep firewall rules tight. If an endpoint is accidentally exposed on a public IP, a continuous scanner such as buggy.run can alert you to risky misconfigurations before they become incidents.
Add high-signal alerts first.

# Disk free < 15% on real filesystems
(node_filesystem_avail_bytes{fstype!~"tmpfs|devtmpfs|overlay|squashfs"}
 /
 node_filesystem_size_bytes{fstype!~"tmpfs|devtmpfs|overlay|squashfs"})
 < 0.15

# Redis evictions occurring
rate(redis_evicted_keys_total[5m]) > 0

# Elasticsearch thread pool pressure
rate(elasticsearch_thread_pool_rejected_count{thread_pool=~"write|search"}[5m]) > 0

# Optional: PostgreSQL replica lag
pg_replication_lag_bytes > 134217728  # >= 128 MiB

Common pitfalls and tuning

Cardinality blowups. Device and mountpoint labels often explode on ephemeral volumes. Drop loopback, tmpfs, and container overlays at scrape time with metric_relabel_configs. For Redis, avoid per-key metrics. For Elasticsearch, avoid per-shard label explosions if your cluster churns indices hourly.
Slow collectors. One slow family can cause timeouts. Watch exporter self-metrics such as scrape_duration_seconds and collector-specific durations. Disable expensive collectors you do not use and raise scrape_timeout only as a last resort.
Exporters are not security tools. Most ship without TLS or auth. Keep them private, audit firewall rules, and rotate credentials used to reach Elasticsearch or Redis.
Alert on trends, not snapshots. Rates and percentiles reduce noise. Use the rate of redis_evicted_keys_total and thread pool rejections over 5–15 minutes. For capacity, compute time to breach. Example idea: time to disk full ≈ node_filesystem_avail_bytes divided by the negative rate of change over a 6 h window.
Right-size scrape intervals. Faster is not always better. 15 s for spiky Redis workloads, 30 s for hosts, and 30–60 s for Elasticsearch unless you are chasing latency regressions.

Use Foreseer forecasts alongside exporters

Exporters give you raw signals. Forecasts and correlations turn those signals into early warnings you can act on. Foreseer is an AI-driven monitoring platform for self-hosted services that you install with a one-line agent on your VM. During onboarding it detects cloud metadata, auto-discovers Elasticsearch, Redis, Logstash, and disks, and lets you choose what to monitor. One install yields cluster and node views with aggregation-aware charts that respect time ranges.

Its trend modeling fits linear and rate-of-change curves to telemetry like disk fill rate, JVM heap growth, Redis eviction pressure, and Logstash queue depth. The result is hours of lead time before a threshold is crossed. Per-service analyzers improve accuracy for each engine. Cross-metric correlation calls out the likely cause and blast radius. Example: rising elasticsearch_thread_pool_queue_count with GC pauses and hot shards isolates which index and nodes need attention. Insights are written in plain English and include symptom, cause, impact, and exact remediation steps. When conditions clear, insights auto-resolve.

Credentials for services stay on the VM. Foreseer reads local config at runtime and does not store secrets centrally. Role-based access control gives Admin, Project Manager, and Viewer roles with per-VM grants and email invites so you can share visibility without oversharing access.

Keep exporters for broad observability and alerting, including PostgreSQL replication lag via postgres_exporter. Run Foreseer’s agent on the same hosts to forecast capacity for Elasticsearch and Redis, correlate signals across metrics, and get human-readable remediation that shortens time to fix.

Key takeaways

Use Node Exporter, Redis Exporter, and Elasticsearch Exporter for stable, well-labeled metrics at low overhead.
Secure endpoints, validate scrapes, and start with alerts that track rates and trend to breach.
Control cardinality with filesystem and device filters, and avoid per-key or per-shard explosions.
Pair exporters with Foreseer to predict incidents and recommend fixes before users feel pain.

FAQ

What is a metrics exporter and how is it different from an agent?

A metrics exporter exposes a read-only HTTP endpoint with service statistics for a scraper like Prometheus. An agent often collects, processes, and forwards data, sometimes with buffering or local storage.

How should I secure Prometheus exporters?

Bind to localhost or a private interface, restrict ports with a firewall, and place exporters behind a reverse proxy with authentication or mTLS. Avoid exposing metrics on public IPs.

What should I alert on for PostgreSQL replication lag?

Use postgres_exporter and alert on lag bytes or seconds above a threshold for sustained periods. Include rate-of-change so you catch growing lag before read replicas fall behind.

What scrape intervals work best for Linux, Redis, and Elasticsearch?

Start with 30 seconds for Linux hosts, 15 seconds for Redis, and 30 to 60 seconds for Elasticsearch. Adjust based on churn and the fastest signals you need to catch.

Can I run exporters in containers and still monitor VMs?

Yes. Many exporters have container images. Ensure they have access to the host namespaces or sockets they need, and expose the ports so your monitoring server can scrape them.