Cluster health API in Elasticsearch - Step-by-Step Execution

Concept Flow - Cluster health API

Send HTTP GET request to /_cluster/health

↓

Elasticsearch receives request

↓

Check cluster state: nodes, shards, status

↓

Prepare JSON response with health info

↓

Send JSON response back to client

↓

Client reads cluster health status

The client sends a request to the cluster health API, Elasticsearch checks cluster status, then returns a JSON with health details.

Execution Sample

Elasticsearch

GET /_cluster/health

Response:
{
  "cluster_name": "my_cluster",
  "status": "green"
}

This request asks Elasticsearch for the cluster health, which responds with the cluster name and status.

Execution Table

Step	Action	Request/Response	Result
1	Client sends GET request to /_cluster/health	GET /_cluster/health	Request received by Elasticsearch
2	Elasticsearch checks cluster state	Internal check	Determines nodes, shards, and status
3	Elasticsearch prepares JSON response	Response JSON	{"cluster_name":"my_cluster","status":"green"}
4	Elasticsearch sends response to client	Response sent	Client receives cluster health data
5	Client reads status field	status: green	Cluster is healthy

💡 Response sent and client received cluster health status, process ends.

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
cluster_name	undefined	my_cluster	my_cluster	my_cluster
status	undefined	green	green	green
request	undefined	GET /_cluster/health	GET /_cluster/health	GET /_cluster/health
response	undefined	undefined	{"cluster_name":"my_cluster","status":"green"}	{"cluster_name":"my_cluster","status":"green"}

Key Moments - 3 Insights

Why does the client get a 'green' status even if some nodes are down?

The 'green' status means all primary and replica shards are allocated. Some nodes can be down if shards are still healthy, as shown in step 2 and 3 of the execution_table.

What does the 'status' field represent in the response?

The 'status' field shows overall cluster health: 'green' means all shards are allocated, 'yellow' means some replicas are unassigned, 'red' means some primary shards are unassigned. See step 5 in execution_table.

Can the cluster health API response change between requests?

Yes, because cluster state can change anytime. Each request triggers a fresh check (step 2), so the response (step 3) may differ.

Visual Quiz - 3 Questions

Look at the execution_table, what is the cluster status after step 3?

A "green"

B "yellow"

C "red"

D "unknown"

💡 Hint

Check the 'Result' column in row 3 of execution_table for the JSON response.

At which step does Elasticsearch prepare the JSON response?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Action' column in execution_table to find when response is prepared.

If the cluster had unassigned primary shards, how would the 'status' value change in variable_tracker?

A "green"

B "red"

C "yellow"

D "blue"

💡 Hint

Refer to key_moments explanation about 'status' meanings and variable_tracker 'status' variable.

Concept Snapshot

Cluster health API syntax:
GET /_cluster/health

Returns JSON with cluster_name and status.
Status values: green (all good), yellow (some replicas missing), red (primary shards missing).
Used to monitor cluster health quickly.

Full Transcript

The Cluster health API in Elasticsearch lets clients check the health of the cluster by sending a GET request to /_cluster/health. Elasticsearch receives this request, checks the current state of nodes and shards, then prepares a JSON response containing the cluster name and health status. The status can be green, yellow, or red, indicating how healthy the cluster is. The client reads this response to understand cluster health. This process repeats each time the API is called, reflecting the current cluster state.

Practice

1. What does the Elasticsearch Cluster Health API primarily provide?

easy

A. The current health status of the Elasticsearch cluster

B. The list of all documents in the cluster

C. The configuration settings of the cluster nodes

D. The query performance statistics

Solution

1. Step 1: Understand the purpose of Cluster Health API

   The Cluster Health API is designed to report the health status of the Elasticsearch cluster, such as green, yellow, or red status.

2. Step 2: Compare with other options

   Options B, C, and D relate to documents, configuration, and performance, which are not the main focus of the Cluster Health API.

3. Final Answer:

   The current health status of the Elasticsearch cluster -> Option A

4. Quick Check:

   Cluster Health API = Cluster health status [OK]

Hint: Cluster Health API shows cluster status, not data or config [OK]

Common Mistakes:

• Confusing cluster health with document data
• Thinking it shows node configuration
• Assuming it reports query stats

2. Which of the following is the correct syntax to get the cluster health using Elasticsearch REST API?

easy

A. GET /_cluster/health

B. POST /_cluster/health

C. GET /_cluster/status

D. POST /_health/cluster

Solution

1. Step 1: Recall the correct HTTP method and endpoint

   The Cluster Health API uses the GET method with the endpoint /_cluster/health.

2. Step 2: Eliminate incorrect options

   POST is not used for this API, and the endpoint must be exactly /_cluster/health. Options C and D have wrong endpoints.

3. Final Answer:

   GET /_cluster/health -> Option A

4. Quick Check:

   GET + /_cluster/health = Correct syntax [OK]

Hint: Use GET method with /_cluster/health endpoint [OK]

Common Mistakes:

• Using POST instead of GET
• Wrong endpoint like /_cluster/status
• Mixing endpoint parts

3. What will be the output status if the cluster has all primary and replica shards allocated properly?

medium

A. "status": "red"

B. "status": "yellow"

C. "status": "blue"

D. "status": "green"

Solution

1. Step 1: Understand cluster health statuses

   Green means all primary and replica shards are allocated properly, yellow means replicas missing but primaries allocated, red means some primaries missing.

2. Step 2: Match the condition to status

   Since all primary and replica shards are allocated, the status is green.

3. Final Answer:

   "status": "green" -> Option D

4. Quick Check:

   All shards allocated = green status [OK]

Hint: Green means all shards allocated, yellow means some replicas missing [OK]

Common Mistakes:

• Confusing yellow with green
• Thinking red means healthy
• Assuming blue is a valid status

4. You run GET /_cluster/health?level=shards but get an error. What is the likely cause?

medium

A. The query parameter should be detail=shards instead

B. The HTTP method should be POST, not GET

C. The level parameter does not accept 'shards' as a value

D. The endpoint should be /_cluster/status

Solution

1. Step 1: Check valid values for level parameter

   The Cluster Health API accepts level values like 'cluster', 'indices', and 'shards'. However, 'shards' is only supported in newer versions and may cause errors if unsupported.

2. Step 2: Analyze other options

   GET is correct method, endpoint is correct, and detail is not a valid parameter for this API.

3. Final Answer:

   The level parameter does not accept 'shards' as a value -> Option C

4. Quick Check:

   Invalid level value causes error [OK]

Hint: Check if 'level=shards' is supported in your Elasticsearch version [OK]

Common Mistakes:

• Using POST instead of GET
• Wrong endpoint /_cluster/status
• Using invalid query parameters

5. You want to monitor your cluster health and get detailed info about each index's health. Which API call should you use?

hard

A. GET /_cluster/health?level=cluster

B. GET /_cluster/health?level=indices

C. GET /_cluster/state?filter_path=metadata.indices

D. GET /_nodes/stats

Solution

1. Step 1: Identify the parameter for detailed index health

   The level=indices parameter in the Cluster Health API returns health info for each index.

2. Step 2: Compare with other options

   level=cluster gives overall cluster health only; /_cluster/state and /_nodes/stats provide different info unrelated to health per index.

3. Final Answer:

   GET /_cluster/health?level=indices -> Option B

4. Quick Check:

   Use level=indices for per-index health details [OK]

Hint: Use level=indices to get health info per index [OK]

Common Mistakes:

• Using level=cluster for detailed index info
• Confusing cluster state with health API
• Requesting node stats instead of health