cat health APIedit

Returns the health status of a cluster, similar to the cluster health API.

Requestedit

GET /_cat/health

Descriptionedit

You can use the cat health API to get the health status of a cluster.

This API is often used to check malfunctioning clusters. To help you track cluster health alongside log files and alerting systems, the API returns timestamps in two formats:

  • HH:MM:SS, which is human-readable but includes no date information.
  • Unix epoch time, which is machine-sortable and includes date information. This is useful for cluster recoveries that take multiple days.

You can use the cat health API to verify cluster health across multiple nodes. See Example across nodes.

You also can use the API to track the recovery of a large cluster over a longer period of time. See Example with a large cluster.

Query parametersedit

format
(Optional, string) Short version of the HTTP accept header. Valid values include JSON, YAML, etc.
h
(Optional, string) Comma-separated list of column names to display.
help
(Optional, boolean) If true, the response includes help information. Defaults to false.
local
(Optional, boolean) If true, the request retrieves information from the local node only. Defaults to false, which means information is retrieved from the master node.
master_timeout
(Optional, time units) Specifies the period of time to wait for a connection to the master node. If no response is received before the timeout expires, the request fails and returns an error. Defaults to 30s.
s
(Optional, string) Comma-separated list of column names or column aliases used to sort the response.
time
(Optional, time units) Unit used to display time values.
ts (timestamps)
(Optional, boolean) If true, returns HH:MM:SS and Unix epoch timestamps. Defaults to true.
v
(Optional, boolean) If true, the response includes column headings. Defaults to false.

Examplesedit

Example with a timestampedit

By default, the cat health API returns HH:MM:SS and Unix epoch timestamps. For example:

$response = $client->cat()->health(['v' => true]);
var catResponse = client.Cat.Health(h => h.Verbose());
response = es.cat.health(v=True)
GET /_cat/health?v

The API returns the following response:

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

Example without a timestampedit

You can use the ts (timestamps) parameter to disable timestamps. For example:

GET /_cat/health?v&ts=false

The API returns the following response:

cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
elasticsearch green           1         1      1   1    0    0        0             0                  -                100.0%

Example across nodesedit

You can use the cat health API to verify the health of a cluster across nodes. For example:

% pssh -i -h list.of.cluster.hosts curl -s localhost:9200/_cat/health
[1] 20:20:52 [SUCCESS] es3.vm
1384309218 18:20:18 foo green 3 3 3 3 0 0 0 0
[2] 20:20:52 [SUCCESS] es1.vm
1384309218 18:20:18 foo green 3 3 3 3 0 0 0 0
[3] 20:20:52 [SUCCESS] es2.vm
1384309218 18:20:18 foo green 3 3 3 3 0 0 0 0

Example with a large clusteredit

You can use the cat health API to track the recovery of a large cluster over a longer period of time. You can do this by including the cat health API request in a delayed loop. For example:

% while true; do curl localhost:9200/_cat/health; sleep 120; done
1384309446 18:24:06 foo red 3 3 20 20 0 0 1812 0
1384309566 18:26:06 foo yellow 3 3 950 916 0 12 870 0
1384309686 18:28:06 foo yellow 3 3 1328 916 0 12 492 0
1384309806 18:30:06 foo green 3 3 1832 916 4 0 0
^C

In this example, the recovery took roughly six minutes, from 18:24:06 to 18:30:06. If this recovery took hours, you could continue to monitor the number of UNASSIGNED shards, which should drop. If the number of UNASSIGNED shards remains static, it would indicate an issue with the cluster recovery.