How to Use Cluster Stats API in Elasticsearch

Introduction

The cluster health API allows you to quickly obtain the basic status of the health of the Elasticsearch cluster and the cluster stats API allows you to retrieve the statistics from a cluster-wide perspective.

The API can return basic index metrics, such as shard numbers, store size and memory usage as well as information regarding the current nodes that make up the cluster numbers, roles, OS, JVM versions, total memory usage, CPU data and installed plugins.

When performing a health check with the cluster stats API, the index-level status is set by the worst shard status, whereas the cluster status is set by the worst index status. One of the key benefits of the API is to give the system the ability to obtain a specific high-water mark health level for the cluster.

How to Check Cluster Health

While you can use any tool that will allow you to make HTTP/REST calls to perform a basic health check on the cluster, we will be using cURL. Assuming you are on the same node as when you started Elasticsearch, you will need to open a new command-shell window.

You can check the cluster health by using the _cat API. Execute the below command in the Kibana console by clicking “View in Console.” Alternatively, you can execute the command with cURL by clicking the “Copy as cURL” link and then pasting it into the terminal.

GET /_cat/health?v

If done properly, the response should look like:

epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1475247709 17:01:49 elasticsearch green 1 1 0 0 0 0 0 0 - 100.0%

This should return a green status for the Elasticsearch cluster.

You will receive a status of a green, yellow or red whenever you use cluster stats API to preform a cluster health check. Each color has the following significance:

  • Green indicates the cluster is fully functional and everything is working properly.

  • Yellow indicates all the data is available and the cluster is fully functional, but some replicas have not yet been allocated.

  • Red indicates some data is missing or otherwise unavailable, for whatever reason. Even if the status is red, the cluster is still partially functional and will continue to serve search requests from the available shards. However, you will need to find and fix the issue that is causing the missing data as soon as possible.

Also notice there is a total of one (1) node and zero (0) shards in the above example, because no data has been entered yet. It is possible you may unintentionally start up multiple nodes on your computer when using Elasticsearch as the default cluster name, with the nodes all joining a single cluster. This is due to Elasticsearch using unicast network discovery by default to locate additional nodes on the same machine. However, this error may also result whenever using any default cluster name. As such, in this example, it may show more than one (1) node in the above response.

You can also obtain a list of nodes in the cluster with the following command:

GET /_cat/nodes?v

The response should look something like this:ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name 127.0.0.1 10 5 5 4.46 mdi * PB2SGZY —(https://www.elastic.co/guide/en/elasticsearch/reference/5.5/_cluster_health.html)

After you have performed a simple cluster-status check you can then use cURL to get the full cluster status with the following command

curl -XGET 'localhost:9200/_cluster/health?pretty'

curl -XGET 'ht
tp://localhost:9200/_cluster/stats?human&pretty'

You can compare the response with the data on this site: https://www.elastic.co/guide/en/elasticsearch/reference/2.0/cluster-stats.html

Conclusion

In this tutorial you learned how to use the cluster health API to quickly obtain the basic status of the health of the Elasticsearch cluster. The cluster stats API feature confirms whether or not the BIGSQL database and all Big SQL nodes are running. It will verify database connections, add missing database partitions and register any new database partitions. Big SQL nodes that are not accessible, or otherwise unable to communicate over the network, are “dead” nodes and therefore must be removed before performing a cluster-health check. Remember that the cluster will still partially functional even if the simple health check returns a status of yellow or red, but you will need to address the issue causing those two status results indicators.

Keep in the know!

Subscribe to our emails and we’ll let you know what’s going on at ObjectRocket. We hate spam and make it easy to unsubscribe.