cat health API
编辑cat health API编辑
cat API 仅供人类通过命令行或 Kibana 控制台使用。它们*不*适用于应用程序。对于应用程序使用,请使用 集群健康状况 API。
返回集群的健康状况,类似于 集群健康状况 API。
请求编辑
GET /_cat/health
描述编辑
您可以使用 cat health API 获取集群的健康状况。
此 API 通常用于检查故障集群。为了帮助您跟踪日志文件和警报系统 alongside 的集群健康状况,API 以两种格式返回时间戳
-
HH:MM:SS
,它是人类可读的,但不包含日期信息。 -
Unix
epoch
时间,它是机器可排序的,并且包含日期信息。这对于需要多天才能恢复的集群很有用。
您可以使用 cat health API 验证多个节点的集群健康状况。请参阅 跨节点示例。
您还可以使用 API 在更长的时间段内跟踪大型集群的恢复情况。请参阅 大型集群示例。
查询参数编辑
-
格式
- (可选,字符串)HTTP 接受标头的简短版本。有效值包括 JSON、YAML 等。
-
h
- (可选,字符串)要显示的列名称的逗号分隔列表。
-
帮助
- (可选,布尔值)如果为
true
,则响应包含帮助信息。默认为false
。 -
s
- (可选,字符串)用于对响应进行排序的列名称或列别名的逗号分隔列表。
-
时间
- (可选,时间单位)用于显示时间值的单位。
-
ts
(时间戳) - (可选,布尔值)如果为
true
,则返回HH:MM:SS
和 Unixepoch
时间戳。默认为true
。 -
v
- (可选,布尔值)如果为
true
,则响应包含列标题。默认为false
。
示例编辑
带时间戳的示例编辑
默认情况下,cat health API 返回 HH:MM:SS
和 Unix epoch
时间戳。例如
response = client.cat.health( v: true ) puts response
GET /_cat/health?v=true
API 返回以下响应
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%
没有时间戳的示例编辑
您可以使用 ts
(时间戳)参数禁用时间戳。例如
response = client.cat.health( v: true, ts: false ) puts response
GET /_cat/health?v=true&ts=false
API 返回以下响应
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%
跨节点示例编辑
您可以使用 cat health API 验证跨节点的集群健康状况。例如
% 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
大型集群示例编辑
您可以使用 cat health API 在更长的时间段内跟踪大型集群的恢复情况。您可以通过在延迟循环中包含 cat health API 请求来做到这一点。例如
% 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
在此示例中,恢复大约花费了六分钟,从 18:24:06
到 18:30:06
。如果此恢复花费了数小时,您可以继续监控 UNASSIGNED
分片的数量,该数量应该会下降。如果 UNASSIGNED
分片的数量保持不变,则表明集群恢复存在问题。