# Stats endpoint for checking a single node health **URL:** \ **Category:** Elasticsearch\ **Created:** [May 24, 2017, 9:52am UTC](https://discuss.elastic.co/t/stats-endpoint-for-checking-a-single-node-health/86937 "2017-05-24T09:52:19Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![joanvila](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/joanvila/32/18471_2.png) [@joanvila](https://discuss.elastic.co/u/joanvila)\ **Post date:** [May 24, 2017, 9:52am UTC](https://discuss.elastic.co/t/stats-endpoint-for-checking-a-single-node-health/86937/1 "2017-05-24T09:52:19Z")
I'm facing an elasticsearch cluster with 6 nodes and a load balancer that sends requests to those nodes. The load balancer needs to query the nodes periodically in order to check their healtcheck (if they are alive ready to serve requests). For that purpose, I was using the `_nodes/stats` endpoint with a timeout of 2 seconds. With this configuration, it happened to me that when a node went down, the load balancer marked all the nodes as unhealthy instead of only the one that was failing. This made me think that the `_nodes/stats` endpoint internally, does a query to all the nodes in the cluster and since one of them was not responding, every healthcheck was failing. Looking at the docs ([https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-stats.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-stats.html)) I saw the `_nodes/_local/stats` endpoint which requests should be resolved on the node that gets the request without asking anything to the other nodes. My question is... The assumption I did about thinking that the `_nodes/stats` endpoint was querying all the nodes internally is correct? In that case, changing the endpoint to the \_local one should solve the issue. Then, is this the proper way to get the health of a single node of elasticsearch? I only want to know if this node is able to reply requests. ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 24, 2017, 9:58am UTC](https://discuss.elastic.co/t/stats-endpoint-for-checking-a-single-node-health/86937/2 "2017-05-24T09:58:44Z")
> [@joanvila](#): > > This made me think that the \_nodes/stats endpoint internally, does a query to all the nodes in the cluster Yes it does. Try `_nodes/_local` as you mention - [Cluster APIs | Elasticsearch Reference [5.4] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/5.4/cluster.html#cluster-nodes) Otherwise use the high level `IP:9200`, if a node replies then it's ok, if not then something is up/ ---
**Author:** ![pfreixes](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pfreixes/32/11611_2.png) [@pfreixes](https://discuss.elastic.co/u/pfreixes)\ **Post date:** [June 2, 2017, 2:17pm UTC](https://discuss.elastic.co/t/stats-endpoint-for-checking-a-single-node-health/86937/3 "2017-06-02T14:17:53Z")
Yeps, We changed the strategy to the URL proposed by @warkolm \_\_nodes/_local/stats/http_ and we had the same issue, one node went down for an unknown reason and all of the other nodes couldnt reply to the load balancer during a short period of time - btw 10 and 20 seconds. However, other regular requests like the search one continued working like a charm. could the URL \_\_nodes/_local/stats/http_ has some internal communications that involves all of the nodes in the cluster? What do you recommend, check to another network level such as TCP ? is it enough trustable to infer that a node is up and healthy? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [June 30, 2017, 2:18pm UTC](https://discuss.elastic.co/t/stats-endpoint-for-checking-a-single-node-health/86937/4 "2017-06-30T14:18:10Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.