Buyer’s Guide - August 2026

The 11 best Elasticsearch monitoring tools, ranked

An Elasticsearch cluster is a distributed Java system with failure modes that generic host monitoring never sees: shard allocation stalls, JVM heap pressure, garbage collection pauses, circuit breaker trips, and thread pool rejections. This ranking grades 11 tools on how deeply they cover that surface, how fast they collect it, and how the bill grows as your cluster does.

Start with Netdata (free) Jump to rankings

Why this list exists

Elasticsearch monitoring is its own category, and buyers who treat it as just another Java app or another log backend get burned. The failure modes that actually take clusters down - unassigned shards, heap pressure, GC pauses, thread pool rejections, circuit breaker trips - are invisible to generic host monitoring, and they are transient. A red cluster rarely announces itself an hour in advance; it degrades in bursts that 60-second polling averages into invisibility.

The second mistake is assuming Kibana’s built-in Stack Monitoring settles the question. It is genuinely the most Elasticsearch-native option and core features ship with the Basic license, but the monitoring data lives in the same cluster you are watching, and the features teams actually want in production - advanced alerting, cross-cluster views - sit behind paid tiers. The third mistake is picking a pricing model without modeling it: per-host, per-GB ingest, and per-service bills grow in very different ways as a cluster scales.

Three dimensions decide the outcome more than any feature checklist:

Metric depth. Does the tool cover shard states, JVM heap and GC, thread pools, circuit breakers, and per-index stats - or just CPU and a health endpoint?
Collection granularity. Elasticsearch anomalies are transient. Tools polling every 10-60 seconds smooth away the spikes that precede an outage; per-second collection catches them.
Cost shape. Per-node, per-host, per-GB, per-service, per-monitor. The model matters more than the sticker, because the bill tracks cluster growth, cardinality, and log volume differently in each.

We do not quote competitor list prices in this guide. Vendor pricing changes, is negotiated, and is often gated behind sales calls; a dollar figure copied here would be stale within a quarter. Instead we describe each tool’s pricing shape and link the official pricing page so you can model your own fleet. Netdata’s own pricing is public and per-node, so we use it as the baseline. For hands-on configuration walkthroughs, see our Elasticsearch monitoring guides.

The shortlist was assembled from vendor documentation, collector source code, integration catalogs, and practitioner write-ups, then filtered to tools with real Elasticsearch coverage rather than a generic HTTP health check. Every tool on this page collects cluster, node, and JVM metrics at minimum; tools that only scrape a status endpoint did not make the cut.

Elasticsearch metric depth and real-time granularity carry the most weight (45% combined) because they determine whether the tool sees the failures that matter. Alerting quality and cost shape follow, because a tool you cannot afford at 50 nodes or that pages you on static thresholds fails in production regardless of its dashboard polish.

Tester credit

Compiled by the Netdata team - Updated August 12, 2026

Sources verified

Scoring criteria

Elasticsearch metric depth 25%
Cluster health, shards, JVM heap/GC, thread pools, circuit breakers, per-index stats
Real-time granularity 20%
Collection interval and end-to-end latency; transient anomalies die in averaging
Alerting and anomaly detection 15%
Built-in health, heap, and rejection alerts plus ML baselines over static thresholds
Deployment and cost shape 15%
SaaS vs self-hosted and what the bill is metered on
Ease of setup and use 10%
Zero-config collectors vs assembling exporters and learning a query language
Ecosystem and correlation 10%
Correlating ES metrics with host metrics, logs, and APM in one place
Openness and portability 5%
Open source, no lock-in, OpenSearch compatibility

Vendor 01 / 11 · #netdata

Netdata

Real-time infrastructure monitoring with a zero-configuration Elasticsearch and OpenSearch collector, per-second granularity, and ML anomaly detection on every metric.

Best for

Teams that want cluster health, JVM, thread pool, and search/indexing metrics within seconds of installing an agent
SRE and DevOps teams monitoring Elasticsearch alongside the rest of the stack without assembling exporters or learning a query language
Fleets that want predictable per-node pricing instead of per-GB ingest or per-host metering

Pricing

Per-node pricing: Cloud Business from $4.50/node/month on annual plans, with the per-node price decreasing as node count grows
Agents are open source (AGPL) and can be self-hosted at no license cost; a free Cloud tier covers small fleets
Unlimited metrics, logs, users, and retention; no per-GB or per-metric charges

Pros

Dedicated Elasticsearch collector (go.d.plugin) using the Cluster APIs: cluster health, node stats, cluster stats, and optional per-index stats, with auto-discovery on port 9200
Per-second collection with sub-2-second end-to-end latency (ES collector defaults to 5s, tunable to 1s), catching transient spikes that 10-15s polling misses
Built-in alerts for red/yellow cluster health, index health, and slow search/fetch, plus unsupervised ML anomaly detection on every metric
Top-queries function reads the Tasks API to surface currently running search tasks and long-running queries in real time
Monitors Elasticsearch and OpenSearch with the same collector, and correlates them with host metrics on the same node
800+ integrations cover the rest of the stack without additional exporters

Where teams pair it

Per-index metrics are off by default; deep index-level analysis requires enabling collect_indices_stats in the collector configuration
No historical slow-query analytics or index lifecycle tooling beyond the live top-queries function; teams doing query forensics over weeks pair it with dedicated tooling
Log correlation is built in, but Netdata does not replace Elasticsearch’s own full-text search and analytics role - it monitors the cluster, it is not a log platform

Verdict

Netdata is the only tool in this list that combines per-second collection with a zero-configuration Elasticsearch/OpenSearch collector, built-in ML anomaly detection, and preconfigured alerts for cluster health and slow search, at flat per-node pricing with unlimited metrics. Everything else on this page either polls every 10-60 seconds, requires assembling an exporter pipeline, or meters the bill by ingest volume. The honest caveat: per-index depth requires a config flag, and if your primary need is historical query analytics or index lifecycle management rather than operational health, you will pair Netdata with a specialist tool rather than replace one.

Start free -> See database monitoring ->

Vendor 02 / 11 · #elastic-stack-monitoring

Elastic Stack Monitoring (Kibana)

Elastic’s native monitoring for Elasticsearch, Kibana, Beats, and Logstash, viewed through Kibana dashboards and alerting.

Best for

Teams already on the Elastic Stack that want zero extra tooling and native context for cluster, node, and index health
Organizations that need a centralized monitoring cluster to watch multiple Elastic Stack deployments

Pricing

Key monitoring features ship with the Basic license; advanced alerting and cross-cluster features sit behind paid subscription tiers
Self-managed deployments are license-based, priced per node and RAM at the upper tiers
Elastic Cloud Hosted is resource-based pay-as-you-go or prepaid; Serverless is usage-based and scales with search and indexing load

Pros

Native integration: no separate agents or exporters, with cluster, node, index, JVM, and shard metrics out of the box
Core monitoring, alerting, and Kibana dashboards included with the Basic license
A centralized monitoring cluster can record, track, and compare health across multiple deployments
Deepest Elasticsearch-specific context available: shard states, JVM, indexing/search performance, plus Kibana, Logstash, and Beats

Cons

Monitoring data is stored in the same cluster (or one you must provision), adding load and storage cost to the system you are watching
Advanced alerting, cross-cluster monitoring, and other features require paid subscription tiers
Per-node views make cluster-wide comparison harder than in purpose-built tools

Verdict

The most Elasticsearch-native option on this page, and the right default if you live in Kibana already. The catch is architectural: self-monitoring adds load to the cluster under stress, which is exactly when you need the telemetry most, so production best practice is a separate monitoring cluster - extra infrastructure to run and pay for. An external tool gives you an independent view that keeps working when the cluster does not.

Read full Netdata vs ELK -> Elastic pricing ->

Vendor 03 / 11 · #grafana-prometheus

Grafana + Prometheus (elasticsearch_exporter)

The open-source standard: Prometheus scrapes Elasticsearch via the elasticsearch_exporter and Grafana visualizes it with pre-built dashboards.

Best for

Teams already running Prometheus who want Elasticsearch metrics in the same TSDB and alerting pipeline
Organizations that prefer open source and have the engineering time to assemble and maintain the stack

Pricing

Grafana OSS, Prometheus, and the elasticsearch_exporter are open source and self-hosted; you run and operate them, and the operational cost is yours
Grafana Cloud offers a free tier capped by active series, log/trace volume, and retention, with Pro billed per active series, per GB of logs, and per host-hour

Pros

The prometheus-community elasticsearch_exporter exposes cluster, node, and index metrics for Elasticsearch and OpenSearch, with a Helm chart for Kubernetes
Pre-built dashboards, alerting rules, and recording rules from Grafana Labs and the community
PromQL gives flexible querying, and Grafana Alerting integrates with Slack, PagerDuty, and more
Fully open source and portable; no vendor lock-in

Cons

DIY assembly: exporter, Prometheus, Grafana, retention, and alerting are separate components to deploy and operate
Steep learning curve across PromQL, relabeling, and service discovery
No built-in Elasticsearch awareness: no shard-level views or ES-specific troubleshooting out of the box
Default scrape intervals are typically 15-30s, so transient problems can be missed

Verdict

If your organization already runs Prometheus, this is the path of least resistance and the strongest open-source answer. What you give up is Elasticsearch-specific intelligence - no query analytics, no index lifecycle context - and you own the whole pipeline, including the scrape intervals that determine whether you see a 10-second heap spike at all. Budget engineering time, not just infrastructure.

Read full Netdata vs Grafana -> Grafana Cloud pricing ->

Vendor 04 / 11 · #datadog

Datadog

SaaS infrastructure and APM platform with a mature Elasticsearch integration, pre-built dashboards, and ML-assisted alerting.

Best for

Teams standardized on Datadog who want Elasticsearch metrics alongside the rest of their infrastructure and APM
Organizations that want managed SaaS with pre-built dashboards and anomaly detection without running their own stack

Pricing

Per-host per month for infrastructure monitoring, with per-GB log ingest and per-metric overages billed separately
Modular per-product billing: APM per host, logs per GB, database monitoring per database host
Free tier limited by host count and short metric retention

Pros

Mature Elasticsearch integration covering cluster health, JVM, search/indexing latency, thread pools, and shard metrics with pre-built dashboards
Anomaly detection and ML-assisted alerting on top of collected metrics
Correlates Elasticsearch metrics with host, container, and APM data in one platform
Dedicated integration for Elastic Cloud deployments

Cons

Per-host plus per-GB pricing scales with both cluster size and log volume; bills grow unpredictably at scale
Elasticsearch-specific depth is limited compared with purpose-built tools: no query analytics, limited index-level intelligence
SaaS only; data leaves your infrastructure, and collection is on the order of 10-15 seconds

Verdict

A solid general-purpose Elasticsearch integration inside the broadest SaaS platform on this list. If Datadog is already your standard, enabling the integration is an easy yes. The two things to model before committing: the bill compounds across hosts, logs, and database monitoring as the cluster grows, and the 10-15 second collection interval averages away the sub-minute anomalies that precede shard and heap failures.

Read full Netdata vs Datadog -> Datadog pricing ->

Vendor 05 / 11 · #sematext

Sematext

Full-stack observability SaaS with a purpose-built Elasticsearch integration covering 100+ metrics plus log correlation.

Best for

Elasticsearch-heavy teams that want a purpose-built ES dashboard set plus log analytics in one SaaS
Teams that want metrics and logs correlated without building their own pipeline

Pricing

Metered per-host for infrastructure monitoring, per-agent for service monitoring, and per-GB for logs
No fixed data buckets or overage charges; unlimited sources and users, with a 14-day trial
SaaS only; data is collected by an open-source agent

Pros

Purpose-built Elasticsearch integration with 100+ metrics across JVM, cluster health, shards, indices, search, thread pools, and circuit breakers
Automatic log structuring for Elasticsearch logs with metrics-to-logs correlation
Out-of-the-box dashboards and default alert rules, including statistical anomaly detection
Open-source agent with service auto-discovery; setup in minutes

Cons

SaaS only, with no self-hosted platform option
Per-host plus per-GB log pricing means the bill grows with both cluster size and log volume
Smaller ecosystem and fewer integrations than the largest platforms

Verdict

One of the few tools built specifically around Elasticsearch monitoring rather than treating it as integration number 400. The metric depth and log correlation are genuinely strong for ES-heavy teams. The trade-offs are structural: SaaS-only delivery and a pricing model that meters both hosts and log volume, so model your log ingest before you commit.

Visit Sematext -> Sematext pricing ->

Vendor 06 / 11 · #new-relic

New Relic

Usage-based full-stack observability SaaS with a native Elasticsearch integration and an OpenTelemetry option.

Best for

Teams that want Elasticsearch metrics plus APM, browser, and infrastructure in one usage-based SaaS
Organizations that prefer ingest-based pricing over per-host pricing

Pricing

Usage-based: per-GB data ingest plus per-user licenses, or a compute-based full consumption option
Not per-host: unlimited hosts and agents are included
Free tier with a monthly ingest allowance and limited retention

Pros

Native Elasticsearch integration collects cluster, node, and index metrics with pre-built dashboards and alerts via an Instant Observability quickstart
OpenTelemetry-based integration collects 50+ metrics covering cluster health, JVM, and infrastructure
Full-stack correlation across APM traces, logs, and infrastructure around the cluster
Unlimited hosts and agents at no extra cost

Cons

Usage-based ingest pricing can escalate with high-cardinality metrics and log volume
Limited Elasticsearch-specific intelligence compared with purpose-built tools
SaaS only

Verdict

New Relic’s differentiator here is the pricing model: unlimited hosts means a growing Elasticsearch cluster does not grow the bill by itself - your ingest volume does. That rewards metric hygiene and punishes sloppy cardinality. The ES coverage itself is competent but general-purpose; you get correlation with the rest of your stack, not deep shard-level intelligence.

Read full Netdata vs New Relic -> New Relic pricing ->

Vendor 07 / 11 · #dynatrace

Dynatrace

AI-powered full-stack observability with an Elasticsearch extension that remotely monitors clusters, nodes, and indexes.

Best for

Enterprises already on Dynatrace that want Elasticsearch health inside their AI-driven full-stack platform
Teams that want automated discovery, dependency mapping, and root cause analysis around Elasticsearch

Pricing

Per-host (per-hour) for infrastructure; full-stack billed per memory-GiB-hour
Logs, metrics, and traces billed per GiB ingested and retained; RUM per session volume
Metric ingestion consumes Dynatrace metric units, which adds cost at scale; 15-day trial

Pros

Official extension scrapes /_cluster/health, /_nodes/stats, and index stats remotely via API, with topology mapping for clusters, nodes, indexes, disks, and thread pools
Built-in alerts for CPU, filesystem, file descriptors, heap, and rejected threads, plus anomaly detection
Unified Analysis pages for cluster, node, and index health with root cause analysis
Supports Elasticsearch 8.0+ and OpenSearch 2.12+, though full OpenSearch compatibility is not guaranteed

Cons

Extension ingests metrics minutely, so sub-minute spikes are not visible
Complex platform with a steep learning curve and enterprise-oriented pricing
Metric ingestion consumes metered units, adding cost as metric volume grows

Verdict

A capable Elasticsearch extension with real depth and the strongest automated root-cause story on this list. The limiting factors are the minutely ingestion interval - which hides the transient spikes this category exists to catch - and an enterprise platform cost structure that only makes sense if you are already buying into Dynatrace broadly.

Read full Netdata vs Dynatrace -> Dynatrace pricing ->

Vendor 08 / 11 · #zabbix

Zabbix

Open-source infrastructure monitoring with an official script-free Elasticsearch template covering cluster, node, and JVM metrics.

Best for

Organizations that want open-source, self-hosted monitoring with no per-host license costs
Teams that already run Zabbix and want Elasticsearch added via an official template

Pricing

Open source and self-hosted; you run and operate it yourself, so infrastructure and maintenance effort are your real costs
Paid support subscriptions priced by response coverage and server count, with unlimited hosts and devices

Pros

Official Elasticsearch Cluster by HTTP template works without external scripts, using the REST API endpoints for cluster health, cluster stats, and node stats
Covers cluster health, shard states, node discovery, JVM heap, thread pools, query/fetch/indexing latency, and file stores
Built-in triggers for red/yellow health, high heap, thread pool rejections, and slow query/fetch latency
Works with standalone and cluster instances; template versions available for Zabbix 5.0 through 7.4

Cons

No log analytics or metrics-to-log correlation
Dated UI and configuration workflow compared with modern SaaS tools
Template tested against Elasticsearch 6.5-7.6; newer versions may need adjustments
No built-in query analytics or index lifecycle context

Verdict

The strongest no-license-fee option after the Prometheus stack, and easier to stand up: the official template gives real Elasticsearch depth with prebuilt triggers rather than a DIY exporter pipeline. The trade-offs are a dated operator experience, no log correlation, and a tested version range that lags current Elasticsearch releases, so validate the template against your version in staging first.

Read full Netdata vs Zabbix -> Zabbix subscriptions ->

Vendor 09 / 11 · #checkmk

Checkmk

Open-core infrastructure monitoring with Elasticsearch checks for clusters, nodes, indices, and shards.

Best for

Teams that want agent-based infrastructure monitoring with Elasticsearch checks and no per-host pricing
Organizations running Checkmk who need cluster, node, index, and shard visibility

Pricing

Open-source Raw edition, self-hosted, with a capped service count
Commercial subscriptions priced per service rather than per host, with custom metrics and synthetic tests as add-on units
Available as SaaS (Checkmk Cloud) or self-managed editions

Pros

Elasticsearch special agent checks cluster health, node statistics, and cluster/indices/shard statistics via the REST API
Monitors shard states (active, unassigned, relocating), document counts and growth, index sizes, and pending tasks
Pairs with Checkmk JVM checks for Java heap and garbage collection on ES nodes
Per-service pricing avoids the per-host multiplier that punishes dense clusters

Cons

The Elasticsearch check is a special agent, not a deep ES product: no query analytics or index lifecycle context
Only monitors the first reachable instance when multiple are configured
Per-service commercial pricing grows with the number of monitored services

Verdict

Good general-purpose Elasticsearch coverage with agent-based depth and companion JVM checks, and the per-service pricing model is friendlier to dense clusters than per-host metering. It is infrastructure monitoring with an ES plugin rather than an Elasticsearch specialist, so treat it as a solid choice for Checkmk shops rather than a reason to adopt Checkmk.

Read full Netdata vs Checkmk -> Checkmk pricing ->

Vendor 10 / 11 · #manageengine

ManageEngine Applications Manager

On-premises application performance monitoring with dedicated Elasticsearch cluster, node, and index monitoring plus anomaly baselines.

Best for

Enterprises that want on-premises APM with Elasticsearch monitoring and dependency mapping
Teams that need automated discovery of ES nodes plus threshold and anomaly alerting

Pricing

Priced by number of monitors and users, as an annual subscription or perpetual license
Free edition limited to a small number of apps and servers
Add-ons priced separately: APM agents, RUM by page views, logs per GB

Pros

Dedicated Elasticsearch monitoring covering cluster health, node metrics, shard distribution, JVM heap and GC, buffer pools, thread pools, and index performance
Automated discovery of Elasticsearch nodes with real-time dashboards
Dynamic baseline anomaly detection that learns normal CPU, query latency, and JVM heap behavior
Alerts via email, SMS, and ITSM integrations on thread pool rejections or node drops

Cons

Feature depth means a learning curve; configuration is heavier than zero-config tools
Per-monitor licensing grows with cluster size
An on-premises product to install, patch, and maintain

Verdict

A comprehensive Elasticsearch module inside an enterprise APM suite, with real depth and genuinely useful anomaly baselines for shops that cannot or will not send telemetry to a SaaS. The cost is operational weight: heavier configuration, per-monitor licensing that scales with the cluster, and a platform you run yourself. It fits enterprises already standardized on ManageEngine more than ES-focused teams evaluating fresh.

Read full Netdata vs ManageEngine -> ManageEngine pricing ->

Vendor 11 / 11 · #instana

IBM Instana

Automatic APM platform whose Elasticsearch sensor auto-discovers clusters and collects node and index metrics at 1-second granularity.

Best for

Teams that want automatic Elasticsearch discovery with 1-second metric granularity and curated health signatures
Organizations standardized on IBM Instana for APM and infrastructure

Pricing

Per host (Managed Virtual Server) per month, billed annually, with a minimum order quantity
Unlimited users included; logs add-on per GB; synthetic tests per execution
Free 14-day trial across Essentials (infrastructure) and Standard (full-stack) tiers

Pros

Elasticsearch sensor auto-deploys with the agent and auto-discovers clusters, nodes, and up to 1,000 indices
1-second default polling for node and cluster metrics: query latency, docs, shards, thread pools, transport
Health signatures provide curated, continuously evaluated issue detection per sensor
Supports Elasticsearch 0.17 through 8.x, with supported versions tracked per release

Cons

Per-host pricing with a minimum order quantity; not economical for small fleets
In-depth index monitoring requires regex configuration and is limited to a subset of indices
Does not monitor OpenSearch with the ES sensor, and ES 8.17+ security entitlements can affect JVM instrumentation

Verdict

The most granular APM option for Elasticsearch on this list: automatic discovery, 1-second polling, and health signatures that remove threshold-tuning work. Ranked last not on capability but on fit - the per-host minimum order and IBM ecosystem positioning make it a choice for Instana-standardized enterprises, and OpenSearch users should look elsewhere.

Read full Netdata vs Instana -> Instana pricing ->

Frequently asked questions

What is the best Elasticsearch monitoring tool?

For most teams, the best Elasticsearch monitoring tool is the one that fits their existing stack: Netdata for per-second collection without exporter assembly, Elastic Stack Monitoring for existing Kibana users, Grafana + Prometheus for open-source shops, and Datadog for SaaS-standardized teams. Netdata ranks first in this guide because it is the only option combining per-second granularity, a zero-configuration ES/OpenSearch collector, built-in ML anomaly detection, and flat per-node pricing with unlimited metrics.

What are the most important Elasticsearch metrics to monitor?

Start with cluster health status (green/yellow/red) and shard states, especially unassigned, relocating, and initializing shards. Because Elasticsearch runs in a JVM, heap usage and garbage collection behavior are first-class signals, and thread pool rejections plus circuit breaker trips are the earliest failure indicators most teams miss. Round that out with indexing and search rates, query and fetch latency, and disk space and node count for capacity planning.

Is Kibana Stack Monitoring enough, or do I need a separate Elasticsearch monitoring tool?

For small clusters, Kibana Stack Monitoring is enough; for production at scale, most teams need a separate monitoring tool or at least a separate monitoring cluster. The structural problem is that self-monitoring stores telemetry data in the same cluster you are watching, adding load under stress - exactly when you need it most. Production best practice is a separate monitoring cluster, which is extra infrastructure to run. Advanced alerting and cross-cluster features also require paid subscription tiers, and an external tool gives an independent view that keeps working when the cluster is degraded.

How does Netdata monitor Elasticsearch?

Netdata uses a dedicated go.d.plugin collector that queries the Cluster APIs: _cluster/health, _cluster/stats, and _nodes/stats. It auto-discovers Elasticsearch and OpenSearch on port 9200 with zero configuration and collects cluster, node, JVM, thread pool, and circuit breaker metrics, with optional per-index stats. The collector defaults to a 5-second interval tunable to 1 second, ships with built-in alerts, and includes a top-queries function that reads the Tasks API to show currently running searches.

What is the difference between Prometheus + Grafana and a SaaS tool for Elasticsearch monitoring?

Prometheus + Grafana is open source and self-hosted: you assemble the exporter, TSDB, dashboards, and alerting yourself, learn PromQL, and live with scrape intervals that are typically 15-30 seconds. SaaS tools like Datadog, New Relic, and Sematext are managed for you but meter the bill by hosts or ingest volume. Netdata sits between the two models: an open-source agent with per-second collection and flat per-node pricing, with no exporter assembly required.

Can I monitor OpenSearch with these tools?

Mostly yes. Netdata’s collector supports both Elasticsearch and OpenSearch, and the prometheus-community elasticsearch_exporter supports OpenSearch. Dynatrace’s extension supports OpenSearch 2.12+ with full compatibility not guaranteed. Zabbix and Checkmk work against ES-compatible REST APIs. The notable exception is IBM Instana, whose Elasticsearch sensor does not monitor OpenSearch (AWS OpenSearch is covered separately).

How often should I collect Elasticsearch metrics?

Collect Elasticsearch metrics at least every 5 seconds, and ideally every 1 second, to catch transient spikes that precede shard and heap failures. Common operational advice to check cluster health every 30-60 seconds is a floor for critical alerts, not a collection strategy - that cadence smooths away the microbursts that signal real trouble. For reference: Netdata collects per second (ES collector defaults to 5s, tunable to 1s) and Instana polls at 1s, while Datadog collects on the order of 10-15s, Prometheus scrapes are typically 15-30s, and Dynatrace ingests minutely.

Why is my Elasticsearch cluster health yellow or red?

Yellow means replica shards are unassigned; red means primary shards are missing, and some data is unavailable. The usual causes are node loss, disk pressure, or allocation settings, so monitor shard states, disk space, and node count to catch the drift before the status flips. Alert on health transitions and on unassigned or relocating shards persisting. Netdata, Zabbix, and Dynatrace all ship built-in alerts for red/yellow health.

How much does Elasticsearch monitoring cost?

Elasticsearch monitoring ranges from free open-source tools you self-host to enterprise SaaS that bills per host, per GB, or per node as your cluster scales. The pricing shapes are stable even when list prices change: per-host plus per-GB (Datadog, Sematext, Instana), per-GB ingest (New Relic, Dynatrace), per-service (Checkmk), and per-monitor (ManageEngine). Open-source options you operate yourself include Zabbix, Prometheus/Grafana, and Elastic Stack Monitoring at the Basic license. Netdata charges per node with unlimited metrics, logs, users, and retention, and the agent is open source. Whichever model you pick, the bill grows with cluster size, metric cardinality, and log volume - model all three before signing.

The 11 best Elasticsearch monitoring tools, ranked

How we evaluated Elasticsearch monitoring tools

Netdata

Elastic Stack Monitoring (Kibana)

Grafana + Prometheus (elasticsearch_exporter)

Datadog

Sematext

New Relic

Dynatrace

Zabbix

Checkmk

ManageEngine Applications Manager

IBM Instana

Frequently asked questions

Book Your Free Demo