How to check Elasticsearch node stats

Checking Elasticsearch node stats reveals node-local pressure before cluster-wide health turns yellow or red, which makes it easier to catch JVM saturation, write backlog, and disk exhaustion before they degrade search or indexing.

The Nodes stats API (/_nodes/stats) returns per-node runtime data such as JVM memory, thread pools, filesystem usage, and indexing pressure. A node selector such as a node name, node ID, or _local narrows the response, while metric paths and filter_path keep the JSON focused on the fields that matter for a quick operational check.

Access commonly requires cluster monitoring privileges when security is enabled, so production requests often need HTTPS, authentication, and a trusted CA. Current Elastic versions also expose bulk coordination pressure in the write_coordination thread pool, so watch that alongside write when troubleshooting indexing or bulk ingestion backlog.

1. List node names and basic pressure counters before choosing a selector for a deeper stats query.

   $ curl -sS --fail "http://localhost:9200/_cat/nodes?v&h=name,ip,node.role,master,heap.percent,ram.percent,cpu,load_1m"
   name    ip         node.role   master heap.percent ram.percent cpu load_1m
   node-01 192.0.2.40 cdfhilmrstw *                21          73  26    3.80

   Use the node name, node ID, or _local selector in subsequent /_nodes/... requests. The CAT APIs are intended for human checks, so use the JSON stats endpoints for scripts and automation.

2. Check the current host's heap usage and write queue pressure with a filtered local node stats request.

   $ curl -sS --fail \
     "http://localhost:9200/_nodes/_local/stats/jvm,thread_pool?filter_path=nodes.*.name,nodes.*.jvm.mem.heap_used_percent,nodes.*.thread_pool.write.queue,nodes.*.thread_pool.write_coordination.queue&pretty"
   {
     "nodes" : {
       "GypMFaXrSMewmvoJY_PHHA" : {
         "name" : "node-01",
         "jvm" : {
           "mem" : {
             "heap_used_percent" : 21
           }
         },
         "thread_pool" : {
           "write" : {
             "queue" : 0
           },
           "write_coordination" : {
             "queue" : 0
           }
         }
       }
     }
   }

   Replace _local with a node name or node ID when the target node is not the host handling the request. Current Elastic versions expose bulk coordination backlog under write_coordination, while older clusters may show more of that load under write.

   Add nodes.*.thread_pool.search.queue or rejection counters to the filter when search latency or rejected requests are the main symptom.

   On secured clusters, use the cluster HTTPS endpoint and the authentication method already used by operators for that cluster.

3. Inspect filesystem headroom and current indexing pressure for a specific node.

   $ curl -sS --fail "http://localhost:9200/_nodes/node-01/stats/fs,indexing_pressure?filter_path=nodes.*.name,nodes.*.fs.total.total_in_bytes,nodes.*.fs.total.available_in_bytes,nodes.*.indexing_pressure.memory.current.combined_coordinating_and_primary_in_bytes,nodes.*.indexing_pressure.memory.current.replica_in_bytes&pretty"
   {
     "nodes" : {
       "GypMFaXrSMewmvoJY_PHHA" : {
         "name" : "node-01",
         "fs" : {
           "total" : {
             "total_in_bytes" : 62671097856,
             "available_in_bytes" : 19652075520
           }
         },
         "indexing_pressure" : {
           "memory" : {
             "current" : {
               "combined_coordinating_and_primary_in_bytes" : 0,
               "replica_in_bytes" : 0
             }
           }
         }
       }
     }
   }

   Low available_in_bytes can trigger shard allocation throttling or index write blocks when disk watermarks are crossed.

   0 under the current indexing pressure fields means no write memory pressure was active at that instant, not that the node never experienced write load.

   Related: How to configure Elasticsearch disk watermarks

4. Compare the same key fields across all nodes to spot outliers quickly.

   $ curl -sS --fail "http://localhost:9200/_nodes/stats/jvm,thread_pool,fs,indexing_pressure?filter_path=nodes.*.name,nodes.*.jvm.mem.heap_used_percent,nodes.*.thread_pool.write.queue,nodes.*.thread_pool.write_coordination.queue,nodes.*.fs.total.available_in_bytes,nodes.*.indexing_pressure.memory.current.combined_coordinating_and_primary_in_bytes&pretty"
   {
     "nodes" : {
       "GypMFaXrSMewmvoJY_PHHA" : {
         "name" : "node-01",
         "jvm" : {
           "mem" : {
             "heap_used_percent" : 21
           }
         },
         "thread_pool" : {
           "write" : {
             "queue" : 0
           },
           "write_coordination" : {
             "queue" : 0
           }
         },
         "fs" : {
           "total" : {
             "available_in_bytes" : 19652075520
           }
         },
         "indexing_pressure" : {
           "memory" : {
             "current" : {
               "combined_coordinating_and_primary_in_bytes" : 0
             }
           }
         }
       }
     }
   }

   A one-node lab only shows one entry. In production, compare heap percentage, queued writes, and available bytes across nodes to find hot data nodes or coordinators.

5. Save the full node stats payload when a deeper review is needed and confirm the capture size.

   $ curl -sS --fail "http://localhost:9200/_nodes/stats?pretty" > node-stats.json
   $ wc -c node-stats.json
      91493 node-stats.json

   Full node stats can be large and may expose topology, role, path, and runtime details. Review _nodes.failed in the saved JSON before treating the file as a complete cluster snapshot, and share the raw payload only through trusted troubleshooting channels.