在整理操作流程之前，先了解如何分配索引以及副本個數~
集群(cluster):由一個或多個節點組成, 並通過集群名稱與其他集群進行區分
節點(node):單個ElasticSearch實例. 通常一個節點運行在一個隔離的容器或虛擬機中
索引(index):在ES中, 索引是一組文檔的集合
分片(shard):因為ES是個分布式的搜索引擎, 所以索引通常都會分解成不同部分, 而這些分布在不同節點的數據就是分片. ES自動管理和組織分片, 並在必要的時候對分片數據進行再平衡分配, 所以用戶基本上不用擔心分片的處理細節，一個分片默認最大文檔數量是20億.
副本(replica):ES默認為一個索引創建5個主分片, 並分別為其創建一個副本分片. 也就是說每個索引都由5個主分片成本, 而每個主分片都相應的有一個copy.
對於分布式搜索引擎來說, 分片及副本的分配將是高可用及快速搜索響應的設計核心.主分片與副本都能處理查詢請求, 它們的唯一區別在於只有主分片才能處理索引請求.
謹慎分配你的分片
當在ElasticSearch集群中配置好你的索引后, 你要明白在集群運行中你無法調整分片設置. 既便以后你發現需要調整分片數量, 你也只能新建創建並對數據進行重新索引(reindex)(雖然reindex會比較耗時, 但至少能保證你不會停機).
主分片的配置與硬盤分區很類似, 在對一塊空的硬盤空間進行分區時, 會要求用戶先進行數據備份, 然后配置新的分區, 最后把數據寫到新的分區上.
分配分片時主要考慮的你的數據集的增長趨勢.
我們也經常會看到一些不必要的過度分片場景. 從ES社區用戶對這個熱門主題(分片配置)的分享數據來看, 用戶可能認為過度分配是個絕對安全的策略(這里講的過度分配是指對特定數據集, 為每個索引分配了超出當前數據量(文檔數)所需要的分片數).
稍有富余是好的, 但過度分配分片卻是大錯特錯. 具體定義多少分片很難有定論, 取決於用戶的數據量和使用方式. 100個分片, 即便很少使用也可能是好的;而2個分片, 即便使用非常頻繁, 也可能是多余的.
要知道, 你分配的每個分片都是有額外的成本的:
每個搜索請求會調度到索引的每個分片中. 如果分片分散在不同的節點倒是問題不太. 但當分片開始競爭相同的硬件資源時, 性能便會逐步下降
ES使用詞頻統計來計算相關性. 當然這些統計也會分配到各個分片上. 如果在大量分片上只維護了很少的數據, 則將導致最終的文檔相關性較差
堆內存配置建議：
-
將最小堆大小（Xms）和最大堆大小（Xmx）設置為彼此相等。
-
Elasticsearch可用的堆越多，可用於緩存的內存就越多。但請注意，太多的堆內存可能會使您長時間垃圾收集暫停。
-
將Xmx設置為不超過物理內存的50％，以確保有足夠的物理內存留給內核文件系統緩存。
-
不要將Xmx設置為JVM超過32GB。
分片大小建議：
● 宿主機內存大小的一半和31GB，取最小值。
大規模以及日益增長的數據場景
對大數據集, 我們非常鼓勵你為索引多分配些分片--當然也要在合理范圍內. 上面講到的每個分片最好不超過30GB的原則依然使用.
不過, 你最好還是能描述出每個節點上只放一個索引分片的必要性. 在開始階段, 一個好的方案是根據你的節點數量按照1.5~3倍的原則來創建分片. 例如,如果你有3個節點, 則推薦你創建的分片數最多不超過9(3x3)個.
隨着數據量的增加,如果你通過集群狀態API發現了問題,或者遭遇了性能退化,則只需要增加額外的節點即可. ES會自動幫你完成分片在不同節點上的分布平衡.
再強調一次, 雖然這里我們暫未涉及副本節點的介紹, 但上面的指導原則依然使用: 是否有必要在每個節點上只分配一個索引的分片. 另外, 如果給每個分片分配1個副本, 你所需的節點數將加倍. 如果需要為每個分片分配2個副本, 則需要3倍的節點數。
再次聲明, 數據分片也是要有相應資源消耗,並且需要持續投入：
當索引擁有較多分片時, 為了組裝查詢結果, ES必須單獨查詢每個分片(當然並行的方式)並對結果進行合並. 所以高性能IO設備(SSDs)和多核處理器無疑對分片性能會有巨大幫助. 盡管如此, 你還是要多關心數據本身的大小,更新頻率以及未來的狀態.
好了，理論知識曉得了，下面看看實際怎么操作，在創建索引的時候指定分片以及副本的個數：
[root@VM-75-64 conf.d]# curl -XPUT 'http://192.168.75.64:9200/75-64-zabbix' -d '
> {
> "settings" : { #這里的內容是以交互式界面編輯的
> "index" : {
> "number_of_shards" : 6,
> "number_of_replicas" : 0
> }
> }
> }'
{"acknowledged":true,"shards_acknowledged":true,"index":"75-64-zabbix"}[root@VM-75-64 conf.d]#
上面是創建75-64-zabbix索引的指令，設置的分片數為6，副本數為0 ，並且在交互式界面直接就返回了創建結果：true！也就是成功的！
[root@VM-75-64 conf.d]# curl -XGET 'http://192.168.75.64:9200/75-64-zabbix/_settings,_mappings?pretty'
{
"75-64-zabbix" : {
"settings" : {
"index" : {
"creation_date" : "1554175133035",
"number_of_shards" : "6",
"number_of_replicas" : "0",
"uuid" : "_B7JAlnFSwCD694BHxA-zQ",
"version" : {
"created" : "5061699"
},
"provided_name" : "75-64-zabbix"
}
},
"mappings" : { }
}
}
上面就是查看某個索引的指令，其中
_settings：表示基本設置
_mappings：mappings信息
?pretty：以友好的格式展現
索引創建好了，就能在head界面看到配置結果了：
可以看到，分片被均勻的分配在了兩個節點中！
那么如何接入logstash呢？
下面跟之前一樣，修改logstash的配置文件：
這里分別在input和output中，添加了兩段該索引的配置，注意，這里索引的名稱一定要嚴格對應！
重啟zabbix服務，讓系統產生日志，在區head界面看看有沒有收集到！
OK，這里看日志拿到了！
同時這里要說明下，一個index創建了之后，分片數時不可修改的，但是副本數是可以隨時修改的，那么在哪里修改？
Kibana里！
在kibana的管理界面，有個Dev tools的入口，其中就是執行console語句的框：
PUT：相當於在命令行的-XPUT
75-64-nginx：index名稱
_settings：上面提到過了，相關的配置選項
number_of_replicas：副本數量的指定字段
refresh_interval：副本與分片之間的數據延遲時間！這里已經設置成了0，延遲已經沒意義了！
回到head界面看下：
還記得在上篇中，nginx標簽的分片配置如下圖：
此時我們修改了副本數為0，也就是說，上面一排灰色的副本現在沒有了，那么，系統會自動重新分配現有的分片數到當前的集群中，效果如下：
可以看到nginx索引副本數已經沒有了，分片被重新分配到其他節點上了，之前默認的五個分片是在同一個節點上的！
自動化，科技化，人性化！
以上，共勉！