Exploring your Cluster
- The REST API
现在我们已经建立并运行了节点(和集群),下一步是了解如何与它沟通,幸运的是，Elasticsearch提供了一个非常全面和强大的REST API，您可以使用它与集群交互,使用该API可以做的事情如下:
- 检查集群、节点和索引健康状态、状态和统计信息
- 管理你的集群，节点，和索引数据和元数据
- 对索引执行CRUD(创建、读取、更新和删除)和搜索操作
- 执行高级搜索操作，如分页、排序、筛选、脚本、聚合等
- Check your cluster, node, and index health, status, and statistics
- Administer your cluster, node, and index data and metadata
- Perform CRUD (Create, Read, Update, and Delete) and search operations against your indexes
- Execute advanced search operations such as paging, sorting, filtering, scripting, aggregations, and many others
2. Cluster Health
让我们从一个基本的健康检查开始，我们可以使用它来查看集群的运行情况，我们将使用curl做这个但是你也可以使用任何允许你发送HTTP/REST调用的工具，假设我们仍然在启动Elasticsearch的节点上，并打开另一个命令shell窗口。
检查集群健康，我们使用_cat API， 你可以在Kibana Console中运行下面的命令：
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 - everything is good (cluster is fully functional) #一切正常(集群功能齐全)
- Yellow - all data is available but some replicas are not yet allocated (cluster is fully functional)
- Red - some data is not available for whatever reason (cluster is partially functional)
注意：当集群为红色时，它将继续为来自可用shards的搜索请求提供服务，但是您可能需要尽快修复它，因为存在未分配的shard。
从上面的响应中，我们还可以看到总共有1个节点，其中有0个碎片，因为其中还没有数据，请注意，因为我们使用默认的集群名称(elasticsearch)，而且elasticsearch默认使用单播网络发现来查找同一机器上的其他节点，您可能会意外地启动计算机上的多个节点，并让它们都加入单个集群，在这种场景下，在上面的响应中，你可能会看到多于1个节点，
我们也可以获取我们集群中节点的列表 ，如下
GET /_cat/nodes?v响应：
ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
127.0.0.1 10 5 5 4.46 mdi * PB2SGZY在这里，我们可以看到名为“PB2SGZY”的节点，它是当前集群中的单个节点。
3. List All Indices 所有索引的列表
现在让我们看一眼我们的索引
GET /_cat/indices?v响应为：
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size这仅仅意味着我们在这个集群中还没有索引。
4. Create an Index 创建索引
现在让我们创建一个名为“customer”的索引，然后再次获取所有索引的列表
PUT /customer?pretty
GET /_cat/indices?v第一个命令使用动词 PUT 创建一个名为“customer”的索引，我们只是在调用的末尾追加pretty，告诉它漂亮地打印JSON响应(如果有的话)。
响应内容为：
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open customer 95SQ4TSUT7mWBT7VNHH67A 5 1 0 0 260b 260b第二个命令的结果告诉我们现在我们有1个名为customer的索引，这个索引默认有5个 primary shard 和 1个 replica shard,
并且该索引包含0个document
您可能还会注意到customer索引被标记了一个黄色的health。回想一下我们之前的讨论，黄色意味着还没有(还)分配一些副本。这个索引出现这种情况的原因是Elasticsearch默认情况下为这个索引创建了一个副本。由于目前我们只有一个节点在运行，因此直到稍后另一个节点加入集群时，才可以(为高可用性)分配该副本。一旦将该副本分配到第二个节点上，该索引的健康状态将变为绿色。
5. Index and Query a Document
现在让我们将一些内容放入到我们的customer索引中，记住上一个，为了索引一个document,我们必须告诉Elasticsearch它应该属于索引中的哪一种类型。
让我们将一个简单的customer document 编入“external”类型的客户索引中，ID为1，如下所示:
PUT /customer/external/1?pretty
{
"name": "John Doe"
}响应为：
{
"_index" : "customer",
"_type" : "external",
"_id" : "1",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"created" : true
}从上面看来，在customer index 和 external type内一个新的customer document被成功地创建。文档的内部id也为1，这是我们在索引时指定的。
需要注意的是，Elasticsearch不要求您先显式地创建索引，然后才能将文档索引到其中，在前面的示例中，Elasticsearch将自动创建客户索引(如果之前不存在的话)
现在让我们检索刚刚编入索引的文档:
GET /customer/external/1?pretty响应如下：
{
"_index" : "customer",
"_type" : "external",
"_id" : "1",
"_version" : 1,
"found" : true,
"_source" : { "name": "John Doe" }
}在这里，除了一个字段found之外，没有什么不同寻常的，它表明我们找到了一个具有所请求的ID 1的文档和另一个字段_source，后者返回我们从上一步索引的完整JSON文档
6. Delete an Index
现在让我们删除刚刚创建的索引，并且再次列出所有索引
DELETE /customer?pretty
GET /_cat/indices?v响应如下：
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size这意味着索引被成功删除，现在我们回到了集群中从零开始的状态。
在继续之前，让我们再仔细看看到目前为止学到的一些API命令
PUT /customer
PUT /customer/external/1
{
"name": "John Doe"
}
GET /customer/external/1
DELETE /customer如果我们仔细研究上面的命令，我们可以看到一个在Elasticsearch中访问数据的模式。这种模式可以总结如下:
<REST Verb> /<Index>/<Type>/<ID>REST访问模式在所有API命令中都非常普遍，如果您能够简单地记住它，那么您将在掌握Elasticsearch方面有一个良好的开端。
