ElasticSearch 监控

aa0660

es可以监控很多东西，最重要的是集群的健康状况，三个级别：红，黄，绿。
 
GET /_cluster/health
 
一个单个节点的集群，没有所以，返回的信息
 
{
   "cluster_name":          "elasticsearch",
   "status":                "green",
   "timed_out":             false,
   "number_of_nodes":       1,
   "number_of_data_nodes":  1,
   "active_primary_shards": 0,
   "active_shards":         0,
   "relocating_shards":     0,
   "initializing_shards":   0,
   "unassigned_shards":     0
}
 
status字段提供了一个总体的集群状况，三个颜色的意思：
green：所有的主从分片都是良好的。
yellow：所有的主分片良好，不是所有的从分片正常。
red：不是所有的主分片正常ot all primary shards are active.
 
下面详细解释。http://my.oschina.net/qiangzigege/blog/264146
 
 
 
 
 
要想增加数据到es,需要一个索引，索引用来存储数据，索引是一个逻辑空间指向一个/多个物理分片。
 
一个分片是一个底层的工作单元，每一个分片是一个lucene单例，是一个完整的搜索引擎，我们的文档被存储存储并且被索引在分片里，客户端不是与分片直接交互而是与索引直接交互。
 
分片就是es在集群里分发数据的意思，分片包含了数据，文档存储在分片里，分片在各个节点，一旦集群扩容/减容，es自动在节点间迁移分片，这样集群仍然保持平衡。
 
一个分片是主分片/从分片。你的任何一个文档都属于一个主分片。所以主分片的数量决定了你索引可以容纳的最大的数据量。
 
PS:我自己加的：主分片就是平时所说的分片，从分片是对某个主分片的冗余复制备份。
这里是分片+主从的机制。分片在前，主从在后。
 
主分片的容量没有限制，但是有一个限制：硬件，文档，如何索引和查询，希望的响应时间。
 
一个从分片仅仅是主分片的复制，主从机制用来提供冗余备份来抵御灾难。并且服务于都请求比如查询和检索文档。
 
主分片在索引创建时就已经固定了，以后不可以更改了，但是从分片的数量可以修改。
 
创建一个叫blogs的索引，默认情况下，索引分配了5个主分片，但是为了演示，我们分配3个主分片和1个从分片。
 
PUT /blogs
{
   "settings" :
   {
      "number_of_shards" : 3,
      "number_of_replicas" : 1
   }
}
 
 
如上所示，3个主分片都分配给了唯一的一个节点，这个时候查询集群的健康，我们看到：
{
   "cluster_name":          "elasticsearch",
   "status":                "yellow",
   "timed_out":             false,
   "number_of_nodes":       1,
   "number_of_data_nodes":  1,
   "active_primary_shards": 3,
   "active_shards":         3,
   "relocating_shards":     0,
   "initializing_shards":   0,
   "unassigned_shards":     3
}
 
集群的健康是黄色。
 
 "unassigned_shards": 3表示3个从分片还没有分配给节点。
  
集群健康状况为黄色表明：所有的主分片正常运行，集群可以正常服务，但是不是所有的从分片正常，
事实上，3个从分片都没有分配，因为没有多余的节点，你分配在本机上也失去了主从的用意啊，
原文说了:在同一个节点上存储同样的数据备份无任何意义。如果这个节点挂了，我们就失去了所有的备份。
 
目前我们的集群可以正常运行，但是存在硬件挂掉而数据失去的风险（因为只有一个节点）
 
 
 
 
 

只有一个节点运行，意味着你有单一故障点：没有冗余备份。 只需要启动另外一个节点。一个新的节点将自动加入集群只要有同样的集群名字，可以互相交互。   此时，我们启动第二个节点，所有的主从分片都正确分配了。 第2个节点已经加入集群，并且三个从分片已经分配给第2个节点，意味着我们可以失去任何一个节点并且数据都是完好无缺的。   那么一个文档要增加，怎样的过程呢？ 先根据分片策略，存储在一个主分片里，然后并行复制到对应的从分片，保证我们的文档可以从主分片或者任何一个从分片里查询到。   当前查询集群健康：绿色。 意味着6个分片（3主3从）都是OK的。   {    "cluster_name":          "elasticsearch",    "status":                "green",    "timed_out":             false,    "number_of_nodes":       2,    "number_of_data_nodes":  2,    "active_primary_shards": 3,    "active_shards":         6,    "relocating_shards":     0,    "initializing_shards":   0,    "unassigned_shards":     0 }   集群良好!

为了大家理解更深刻：
这里把前后放在一起：
?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

XXX@UBUNTU ~$ curl http://localhost:9200/_cluster/health?pretty {   "cluster_name" : "elasticsearch",   "status" : "yellow",   "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" : 10 } XXX@UBUNTU ~$ curl http://localhost:9200/_cluster/health?pretty {   "cluster_name" : "elasticsearch",   "status" : "green",   "timed_out" : false,   "number_of_nodes" : 2,   "number_of_data_nodes" : 2,   "active_primary_shards" : 10,   "active_shards" : 20,   "relocating_shards" : 0,   "initializing_shards" : 0,   "unassigned_shards" : 0 }

 
 
当项目需要时如何扩容？
如果我们启动第3个节点，我们的集群识别它。见图4.“3个节点的集群-主从分片已经重新部署来分摊负载”
 
节点1和节点2分别有一个分片移动到了节点3.每个节点有2个分片，有助于减少负载。
注意，此时并不是每个节点都有所有的数据，我的意思是任何一个节点，就算有主和从分片加起来。，也没有保证任何一个文档在当前机器上。
 
一个分片是一个搜索引擎，可以使用当前节点的所有资源，当前有6个分片（3主3从），我们的索引可以扩容到最大6个节点，每个节点1个分片，并且，每个分片可以使用节点的所有资源。
 
如果我们想扩容到多于6个节点呢？
 
前面说过：主分片的个数在创建时已经指定了，数量决定了数据的最大容量，尽管如此，读请求，比如搜索或者文档检索，可以被主分片或者从分片处理，所以如果你有更多的从分片冗余备份，我们可以处理更多的读请求来获得更多的吞吐量。
 
虽然主分片的个数在创建时已经指定不可更改，但是从分片可以更改，只要你有这个需求就可以，让我们把从分片的数量从1变到2.
 
PUT /blogs/_settings
{
   "number_of_replicas" : 2
}
 
 
如图5所示, the blogs 索引现在有了9个分片，3主6从. 如果我们想要增加另外3个节点到我们的6个节点集群里，会是什么情况？
自然是9个节点每个节点1个分片。并且我们的集群可以获得50%的增长来处理查询请求。
 
注意：有更多的主从分片在同样数量的节点情况下，不会提高性能，因为每个分片可获取的资源更小，你需要增加硬件。
但是更多的分片意味着我们有更多的冗余，这样节点挂了也不会失去数据。