乾貨 | Elasticsearch集羣黃色緣由的終極探祕

一、Elasticsearch集羣不一樣顏色表明什麼？
綠色——最健康的狀態，表明全部的主分片和副本分片均可用；
黃色——全部的主分片可用，可是部分副本分片不可用；
紅色——部分主分片不可用。（此時執行查詢部分數據仍然能夠查到，遇到這種狀況，仍是趕快解決比較好。

二、Elasticsearch 集羣顏色變黃色了要沒關係？
Elasticsearch集羣黃色表明：

分配了全部主分片，但至少缺乏一個副本。
沒有數據丟失，所以搜索結果仍將完整。
注意：您的高可用性在某種程度上會受到影響。
若是更多分片消失，您可能會丟失數據。 將黃色視爲應該提示調查的警告。

三、Elasticsearch集羣健康狀態如何排查？
3.1 集羣狀態查看
curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'  
{
 "cluster_name" : "astrung",
 "status" : "yellow",
 "timed_out" : false,
 "number_of_nodes" : 2,
 "number_of_data_nodes" : 2,
 "active_primary_shards" : 22,
 "active_shards" : 22,
 "relocating_shards" : 0,
 "initializing_shards" : 2,
 "unassigned_shards" : 20
}

3.2 分片狀態查看
curl -XGET 'http://localhost:9200/_cat/shards?v'
 index          shard prirep state        docs  store ip          node 
 _river         0     p      STARTED         2  8.1kb 192.168.1.3 One  
 _river         0     r      UNASSIGNED                                
 megacorp       4     p      STARTED         1  3.4kb 192.168.1.3 One  
 megacorp       4     r      UNASSIGNED                                
 megacorp       0     p      STARTED         2  6.1kb 192.168.1.3 One  

3.3 查看unsigned 的緣由
GET /_cluster/allocation/explain

3.4 查看集羣中不一樣節點、不一樣索引的狀態
GET _cat/shards?h=index,shard,prirep,state,unassigned.reason

3.5 Head插件直觀排查

四、Elasticsearch集羣黃色的緣由排查及解決方案
4.1 緣由1：Elasticsearch採用默認配置（5分片，1副本），但實際只部署了單節點集羣。
因爲只有一個節點，所以羣集沒法放置副本，所以處於黃色狀態。
elasticsearch 索引的默認配置以下：

index.number_of_shards：5
index.number_of_replicas：1

解決方案以下：
您能夠將副本計數下降到0或將第二個節點添加到羣集，以即可以將主分片和副本分片安全地放在不一樣的節點上。
這樣作之後，若是您的節點崩潰，羣集中的另外一個節點將擁有該分片的副本。
（1）設置副本數爲0，操做以下：

PUT /cs_indexs/_settings
{
  "number_of_replicas": 0
}

進行段合併，提高訪問效率，操做以下：
POST /cs_indexs/_forcemerge?max_num_segments=1
（2）再也不物理擴展集羣，將後續全部的索引自動建立的副本設置爲 0。

PUT /_template/index_defaults 
{
  "template": "*", 
  "settings": {
  "number_of_replicas": 0
  }
}

4.2 緣由2：Elasticsearch分配分片錯誤。
進一步可能的緣由：您已經爲集羣中的節點數過度分配了副本分片的數量，則分片將保持UNASSIGNED狀態。其錯誤碼爲：ALLOCATION_FAILED。
解決方案以下：
reroute：從新路由命令容許手動更改羣集中各個分片的分配。
核心操做以下：

POST /_cluster/reroute
  {
  "commands": [
    {
      "allocate_replica": {
        "index": "cs_indexs",
        "shard": 0,   # 從新分配的分片（標記黃色的分片）
        "node": "es-2"
      }
    }
  ]
}

reroute擴展使用——能夠顯式地將分片從一個節點移動到另外一個節點，能夠取消分配，
而且能夠將未分配的分片顯式分配給特定節點。
舉例使用模板以下：

POST /_cluster/reroute
{
    "commands" : [
        {
            "move" : {
                "index" : "test", "shard" : 0,
                "from_node" : "node1", "to_node" : "node2"
            }
        },
        {
          "allocate_replica" : {
                "index" : "test", "shard" : 1,
                "node" : "node3"
          }
        }
    ]
}

其中：
1）move表明移動；
2）allocate_replica 表明從新分配；
3）cancel 表明取消；

4.3 磁盤使用過載。
緣由3：磁盤使用超過設定百分比85%。
cluster.routing.allocation.disk.watermark.low——控制磁盤使用的低水位線。 它默認爲85％，這意味着Elasticsearch不會將分片分配給使用磁盤超過85％的節點。 它也能夠設置爲絕對字節值（如500mb），以防止Elasticsearch在小於指定的可用空間量時分配分片。
解決方案：
（1）查看磁盤空間是否超過85%。

[root@localhost home]# df -h
Filesystem           Size  Used Avail Use% Mounted on
/dev/xvda1          1014M  165M  849M  17% /boot
/dev/mapper/cl-home  694G  597G   98G  86% /home

（2）刪除沒必要要的索引，以釋放更多的空間。

DELETE  cs_indexs

4.4 磁盤路徑權限問題。
緣由4：磁盤路徑權限問題。安全起見，默認Elasticsearch非root帳戶和啓動。
相關的Elasticsearch數據路徑也是非root權限。
解決方案：
去數據存儲路徑排查權限，或者在data的最外層設置：

chown -R elasticsearch:elasticsearch data