集群健康

让我们从最基本的健康检查开始, 我们可以看到我们的集群如何工作. 我们会使用curl去请求, 当然你完全可以使用其他任何http/REST请求工具. 假设我们在启动Elasticsearch的节点上, 并且打开一个控制台窗口.

为了检查集群健康状态, 我们会使用_cat API. 你可以通过点击kibana控制台"VIEW IN CONSOLE"按钮来运行命令, 也可以点击"COPY AS CURL"复制链接在命令行里运行.

GET /_cat/health?v

响应如下

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%

我们可以看到名为elasticsearch的集群启动了,并且状态为green.

无论何时我们请求集群的健康状态, 我们只会得到 green, yellow和red三种状态.

  • Green - 一切良好(集群全功能)
  • Yellow - 所有数据都可用, 但是一切复制还未分配(集群全功能)
  • Red - 因为某些原因数据不可用(集群部分功能)

注意: 当集群状态为Red时, 你仍然可以继续从可用的分片中查询, 但是你应该尽快修复它, 因为还有未指定的分片.

而且, 从上面的响应中, 我们可以看到节点total为1, shards为0,因为我们还没有任何数据. 因为我们使用了默认的集群名称(elasticsearch)并且Elasticsearch使用了单播网络发现去搜索同一个机器上的其他节点, 所以有可能意外的在一个电脑上启动一个以上的节点并且他们都会加入同一个集群, 在这种情况下, 你可能会在响应中看到1个以上node.

我们可以可以看到集群里的节点列表:

GET /_cat/nodes?v

响应如下

ip        heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
127.0.0.1           15          72  12                          mdi       *      ASSPZbQ

这里我们可以看到集群里只有一个名为"ASSPZbQ"的节点.

results matching ""

    No results matching ""