英文版地址: https://www.elastic.co/guide/en/elasticsearch/guide/current/_cluster_health.html
本书基于 Elasticsearch 2.x 版本,有些内容可能已经过时。
集群健康edit
一个 Elasticsearch 集群可以由单个索引的单个节点组成。或者它可能有一百个数据节点、三个单独的主节点,几十个客户端节点 —— 这些共同操作一千个索引(以及上万个分片)。
不管集群扩展到多大规模,你都会想要一个快速获取集群状态的途径。Cluster Health
API 充当的就是这个角色。你可以把它想象成是在一万英尺的高度鸟瞰集群。它可以告诉你安心吧一切都好,或者提醒你注意集群中某个地方的问题。
让我们执行一下 cluster-health
API 然后看看响应体是什么样子的:
GET _cluster/health
和 Elasticsearch 里其他 API 一样,cluster-health
会返回一个 JSON 响应。这为自动化和警报分析提供了方便。响应中包含了与集群有关的一些关键信息:
{ "cluster_name": "elasticsearch_zach", "status": "green", "timed_out": false, "number_of_nodes": 1, "number_of_data_nodes": 1, "active_primary_shards": 10, "active_shards": 10, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 0 }
响应信息中最重要的就是 status
字段。状态可能是下列三个值之一:
-
green
- 所有的主分片和副本分片都已分配。集群是 100% 可用的。
-
yellow
-
所有的主分片都分配了,但至少还有一个副本是缺失的。没有数据丢失,所以搜索结果依然是完整的。不过,你的高可用性在某种程度上被弱化。如果 更多的 分片消失,你可能会丢失数据。把
yellow
看作是一种警告,应该引起调查。 -
red
- 至少一个主分片(以及它的全部副本)丢失了。这意味着数据丢失:搜索只能返回部分结果,而分配到这个分片上的写入请求会返回异常。
green
/yellow
/red
状态是一个概览你的集群并了解眼下正在发生什么的好办法。其他指标告诉你集群的状态概要:
-
number_of_nodes
和number_of_data_nodes
这个命名完全是自描述的。 -
active_primary_shards
表示集群中的主分片数量。所有索引的汇总值。 -
active_shards
是所有索引的所有分片的汇总值,包括副本分片。 -
relocating_shards
显示当前正在从一个节点迁往其他节点的分片的数量。通常来说应该是 0,不过在 Elasticsearch 发现集群不太均衡时,该值会上涨。比如说:添加了一个新节点,或者下线了一个节点。 -
initializing_shards
是刚刚创建的分片的个数。比如,当你刚创建第一个索引,分片都会短暂的处于initializing
状态。这通常会是一个临时事件,分片不应该长期停留在initializing
状态。你还可能在节点第一次启动的时候看到initializing
状态的分片:当分片从磁盘上加载后,它们会从initializing
状态开始。 -
unassigned_shards
是在集群状态中存在,但是在集群里又找不着的分片的个数。通常未分配的分片的来源是未分配的副本。比如,一个有 5 分片和 1 副本的索引,在单节点集群上,就会有 5 个未分配副本分片。如果你的集群是red
状态,也会长期保有未分配分片(因为缺少主分片)。
钻更深点:找到问题索引edit
想象一下某天碰到问题了,而你发现你的集群健康状态看起来像是这样:
{ "cluster_name": "elasticsearch_zach", "status": "red", "timed_out": false, "number_of_nodes": 8, "number_of_data_nodes": 8, "active_primary_shards": 90, "active_shards": 180, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 20 }
好了,从这个健康状态里我们能推断出什么呢?嗯,集群状态是 red
,意味着我们缺数据(主分片 + 副本分片)了。我们知道集群原先有 10 个节点,但是在这个健康状态里列出来的只有 8 个数据节点。有两个数据节点不见了。我们看到有 20 个未分配分片。
这就是我们能收集到的全部信息。缺失分片的具体情形依然是个谜。是缺了 20 个索引,每个索引里少 1 个主分片?还是缺 1 个索引里的 20 个主分片?还是 10 个索引里的各 1 主 1 副本分片?具体是哪个索引?
要回答这个问题,我们需要使用 level
参数让 cluster-health
给出更多信息:
GET _cluster/health?level=indices
这个参数会让 cluster-health
API 在我们的集群信息里添加一个索引清单,以及有关每个索引的细节(状态、分片数、未分配分片数等等):
{ "cluster_name": "elasticsearch_zach", "status": "red", "timed_out": false, "number_of_nodes": 8, "number_of_data_nodes": 8, "active_primary_shards": 90, "active_shards": 180, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 20 "indices": { "v1": { "status": "green", "number_of_shards": 10, "number_of_replicas": 1, "active_primary_shards": 10, "active_shards": 20, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 0 }, "v2": { "status": "red", "number_of_shards": 10, "number_of_replicas": 1, "active_primary_shards": 0, "active_shards": 0, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 20 }, "v3": { "status": "green", "number_of_shards": 10, "number_of_replicas": 1, "active_primary_shards": 10, "active_shards": 20, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 0 }, .... } }
一旦我们要求输出索引信息,哪个索引有问题立马就很清楚了:v2
索引。我们还可以看到这个索引有 10 个主分片和 1 个副本分片,而现在这 20 个分片全不见了。可以推测,这 20 个分片就是位于集群中丢失的那两个节点上。
参数level
还可以接受其他选项:
GET _cluster/health?level=shards
shards
选项会输出非常详细的信息:列出每个索引里每个分片的状态和位置。这个输出有时候很有用,但是由于太过详细会比较难用。如果你知道哪个索引有问题了,本章讨论的其他 API 显得更加有用一点。
阻塞并等待状态的变化 (Blocking for Status Changes)edit
当构建单元和集成测试时,或者使用 Elasticsearch 相关的自动化脚本时,cluster-health
API 还有另一个小技巧非常有用。你可以指定一个 wait_for_status
参数,它只在满足状态(status)之后才会返回。比如:
GET _cluster/health?wait_for_status=green
这个调用会阻塞住(不给你的程序返回控制权)直到cluster-health
的状态变成green
,也就是所有主分片和副本分片都分配完成了。这对自动化脚本和测试来说非常重要。
如果你创建了一个索引,Elasticsearch 必须将集群状态的变更广播到所有节点。那些节点必须初始化这些新的分片,然后响应给主节点说这些分片已经Started
。这个过程很快,但是因为网络延迟,可能要花 10–20ms。
如果你有个自动化脚本是 (a) ”创建一个索引”,然后 (b) “逻辑尝试索引一个文档”,这个操作可能会失败,因为索引还没完全初始化完成。在 (a) 和 (b) 两步之间的时间可能不到 1ms —— 对网络延迟来说这可不够。
比起使用休眠(sleep),不如让你的脚本或者测试调用cluster-health
时带上参数wait_for_status
。一旦索引完全创建好,cluster-health
就会变成green
,这个调用就会把控制权交还给你的脚本,然后你就可以开始索引文档了。
可用的选项是green
、yellow
和red
。当达到你要求的状态(或"更高的"状态)时调用会返回。比如,如果你要求的状态是yellow
,当状态变成yellow
或者green
时都会解除阻塞并返回。