Elasticsearch6.x使用初探(二)
1.集群健康
让我们从基本运行状况检查开始，我们可以使用它来查看集群的运行情况。
我们将使用curl来执行此操作，但您可以使用任何允许您进行HTTP / REST调用的工具。
要检查群集运行状况，我们将使用_cat。查询语句如下：
127.0.0.1:9200/_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
1554206831 12:07:11 elasticsearch yellow 1 1 140 140 0 0 140 0 - 50.0%
我们可以看到名为“elasticsearch”的群集处于黄色状态。
集群健康有绿色，黄色或红色三个值。
- 绿色 - 一切都很好（集群功能齐全）
- 黄色 - 所有数据都可用，但尚未分配一些副本（集群功能齐全）
- 红色 - 某些数据由于某种原因不可用（集群部分功能）
当群集为红色时，它将继续提供来自可用分片的搜索请求，但您可能需要尽快修复它，因为存在未分配的分片。
同样从上面的响应中，我们可以看到总共1个节点，并且我们有140个分片（建立了28个索引）。
请注意，由于我们使用默认集群名称（elasticsearch），并且由于Elasticsearch默认使用单播网络发现来查找同一台计算机上的其他节点，因此您可能会意外启动计算机上的多个节点并且所有人都加入一个集群。
在这种情况下，您可能会在上面的响应中看到多个节点。
我们还可以获得群集中的节点列表，如下所示（请求和响应）：
127.0.0.1:9200/_cat/nodes?v
ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
10.14.69.19 37 80 6 2.13 2.91 3.39 mdi * node-123
2.列出所有索引
查询语句如下：
127.0.0.1:9200/_cat/indices?v
返回结果：
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size yellow open tracelog-2019-03-25 7uVYIfGGQY-iPVTx7OvdYQ 5 1 0 0 1.2kb 1.2kb yellow open operatelog-2019-02 hpnxDk4SQPu6wC-3R144FQ 5 1 400 0 162.2kb 162.2kb yellow open operatelog-2019-4 GwiWuPKIRumHGJtJ0_2A_A 5 1 7 0 83.9kb 83.9kb yellow open systemlog-2019-03-21 1FPM8uhNSve_WB5qqiCWGQ 5 1 0 0 1.2kb 1.2kb yellow open systemlog-2019-03-27 scKu_VvkTAC-loSCRvMMOw 5 1 33039 0 4.4mb 4.4mb
现在让我们创建一个名为“customer”的索引，然后再次列出所有索引：
curl -X PUT "localhost:9200/customer?pretty"
curl -X GET "localhost:9200/_cat/indices?v"
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open customer 7uVYIfGGQY-iPVTx7OvdYQ 5 1 0 0 1.2kb 1.2kb
上面的结果告诉我们，我们现在有一个名为customer的索引，它有5个主分片和1个副本（默认值），并且它包含0个文档。
您可能还注意到customer索引标记了黄色运行状况。回想一下我们之前的讨论，黄色表示某些副本尚未（尚未）分配。
此索引发生这种情况的原因是因为默认情况下Elasticsearch为此索引创建了一个副本。
由于我们目前只有一个节点在运行，因此在另一个节点加入集群的稍后时间点之前，尚无法分配一个副本（用于高可用性）。
将该副本分配到第二个节点后，此索引的运行状况将变为绿色。
现在让我们在customer索引中加入一些内容。我们将一个简单的客户文档索引到客户索引中，ID为1，如下所示：
curl -X PUT "localhost:9200/customer/_doc/1?pretty" -H 'Content-Type: application/json' -d' { "name": "John Doe" } '
应答如下：
{ "_index" : "customer", "_type" : "_doc", "_id" : "1", "_version" : 1, "result" : "created", "_shards" : { "total" : 2, "successful" : 1, "failed" : 0 }, "_seq_no" : 0, "_primary_term" : 1 }
从上面可以看出，在客户索引中成功创建了一个新的文档。该文档还具有我们在索引时指定的内部标识（id）1。
值得注意的是，Elasticsearch不需要在将文档编入索引之前先显式创建索引。在前面的示例中，如果客户索引事先尚未存在，则Elasticsearch将自动创建客户索引。
我们现在检索刚刚写入索引的文档（这里id=1）：
GET /customer/_doc/1?pretty
查询结果如下：
{ "_index" : "customer", "_type" : "_doc", "_id" : "1", "_version" : 1, "_seq_no" : 25, "_primary_term" : 1, "found" : true, "_source" : { "name": "John Doe" } }
我们找到了一个具有请求ID 1的文档，它返回我们从上一步索引的完整JSON文档。
现在让我们删除刚刚创建的索引，然后再次列出所有索引：
curl -X DELETE "localhost:9200/customer?pretty/customer?pretty"
curl -X GET "localhost:9200/_cat/indices?v/_cat/indices?v"
查询结果如下：
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size.count docs.deleted store.size pri.store.size
这意味着索引已成功删除，现在我们回到了我们在集群中没有任何内容的地方。
在我们继续之前，让我们再仔细看看到目前为止我们学到的一些API命令：
curl -X PUT "localhost:9200/customer" curl -X PUT "localhost:9200/customer/_doc/1" -H 'Content-Type: application/json' -d' {{ "name": "John Doe""name": "John Doe" }} ' curl -X GET "localhost:9200/customer/_doc/1" curl -X DELETE "localhost:9200/customer"
如果我们仔细研究上述命令，我们实际上可以看到我们如何在Elasticsearch中访问数据的模式。该模式可归纳如下：
<HTTP Verb> /<Index>/<Type>/<ID>
这种REST访问模式在所有API命令中都非常普遍，如果您能够简单地记住它，您将在掌握Elasticsearch方面有一个良好的开端。
