本章內容
如何為集群選擇合適的分片數和副本數。
路由是什么以及它對ElasticSearch的意義。
分片分配器是怎樣工作的，如何配置它。
怎樣調節分片分配機制以滿足應用需求。
怎樣確定應該在哪個分片上執行指定的操作。
怎樣結合我們已有的知識來配置一個真實的集群。
如何應對數據和查詢數量的增長。
4.1 選擇合適的分片和副本數
簡單的計算公式如下:
節點最大數=分片數*(副本數+1)換句話說，如果你計划使用10個分片和2個備份，那么這個設置的最大節點數將會是30.
4.1.2 一個過度分配的正面例子
如果你仔細閱讀了本章前面的內容，就會強烈地意識到:我們應該使用最少的分片。 但有時候擁有更多的分片有其便利之處，因為分片事實上是lucene的一個索引。更多的分 片意味着每個在較小的lucene索引上執行的操作會更快(尤其是索引過程)。有時這是一個使用更多分片的很好的理由。當然，將查詢分散成對每個分片的請求，然后合並結果。也是有代價的，但這對於使用固定參數來過濾查詢的應用程序是可以避免的。有這種現實的案例，例如，那種每個查詢都在指定用戶的上下文中執行的多租戶系統。原理很簡單，即把每個用戶的數據都索引到一個獨立分片中，在查詢時只查詢那個用戶的分片。這時就需要使用路由(我們將在4.2節中詳細討論它)。
4.1.4 副本
分片處理使我們能存儲超過單機容量的數據，而使用副本則解決了日漸增長的吞吐量 和數據安全方面的問題。當一個存放主分片的節點失效后，ElasticSearch能夠將一個可用的副本升級為新的主分片。默認情況下，ElasticSearch只創建一個副本。然而，不同於分片處理，副本的數量可以通過使用相關API隨時更改。該功能讓構建應用程序變得非常方便， 因為查詢吞吐量會隨着用戶的增長而增長，而使用副本則可以應對增長的並發查詢。使用過多副本的缺點也很明顯:各個分片的副本占用了額外的存儲空間，主分片及其副本之間的數據拷貝也存在時間開銷。
4.2 路由
4.2.1 分片和數據
引言
通常情況下，ElasticSearch將數據分發到哪個分片，以及哪個分片上存放特定的文檔 都不重要。查詢時，請求會被發送至所有的分片，所以最關鍵的事情是使用一個能均勻分發數據的算法。而當我們想刪除文檔或者增加一個文檔的新版本時，情況就有些復雜了，ElasticSearch必須知道文檔在哪里。實際上，這並不是一個問題，只要分片算法能對同一個文檔標識符永遠生成相同的值就足夠了，如此ElasticSearch在處理文檔時就知道該去找對應的分片了。
難道沒有一個更智能的方法來決定文檔應當儲存在哪個分片上嗎?舉例來說，我們希望將某一類書籍都存在一個特定的分片上，因而在查詢這類書時就無需查詢多個分片及合並搜索結果。這就是路由要做的事情。它允許我們提供信息給ElasticSearch, 而ElasticSearch根據這個信息來決定用哪個分片來存儲文檔和執行查詢。相同的路由值會指向同一個分片、也就是說“之前你使用某個路由值將文檔存放在特定的分片上，那么搜索時，也去相應的分片查找該文檔”。
4.2.2 測試路由功能
現在啟動兩個ElasticSearch節點，然后用下面的命令創建一個索引:
curl -XPUT localhoat:9200/documents -d'{
settings:{
number_of_replicas:0,
number_of_shards:2
}
}'在索引過程中使用路由
我們可以通過路由來控制ElasticSearch將文檔發送到哪個分片。路由參數值無關緊要， 可以取任何值。重要的是在將不同文檔放到同一個分片上時，需要使用相同的值。
第一種方法：URI參數
向ElasticSearch提供路由信息有多種途徑。最簡單的辦法是在索引文檔時加一個URI 參數routing。例如下面的例子:
curl -XPUT localhoat:9200/documents/doc/1?routing=A -d'{
"title":"Document"
}'第二種方法：基於Mapping
另一個選擇是在文檔里放一個_routing字段，如下所示:
curl -XPUT localhoat:9200/documents/doc/1 -d'{
"title":"Document No. 1",
"_routing":"A"
}'然而這種情況僅在mappings中定義了_routing字段時才會生效。例如:
{
"mappings":{
"doc":{
"_routing":{
"required":true,
"path":"_routing"
},
"properties":{
"title":{
"type":"string"
}
}
}
}
}在這里稍微停頓一下。在這個例子里我們使用了_routing字段，且值得一提的是，path 參數可以指向文檔中任意未分詞字段。這是一個十分強大的功能，也是路由特性最主要的優勢所在。舉例來說，如果我們用代表圖書所在圖書館的library_id字段擴展文檔，那么當基於library_id來設置路由時，有理由認為所有基於圖書館的查詢更有效率。
第三種方法：匹配插入指定路由
現在回到定義路由的多種途徑上。最后一種方式是在執行批量索引時使用路由。使用 時路由值在每個文檔的頭部給出，例如:
curl -XPUT localhost:9200/_bul --data-binary '
{
"index":{
"_index":"documents",
"_types":"doc",
"_routing":"A"
}
}
{
"title":"Document No. 1"
}
'4.2.3 索引時使用路由
仍然使用前面的例子，只是這次使用路由。首先要刪除舊文檔，如果不這么做，那么 使用相同的標識符添加文檔時，路由會把相同的文檔存放到另一個分片上。因此，我們執行下面的命令從索引中刪除所有文檔:
curl -XDELETE localhost:9200/documents/_query?q=*:*然后重新索引數據，但是這次添加路由信息。索引文檔的命令如下:
標識符優先於路由！
路由參數指示ElasticSearch應該將文檔放到哪個分片上。當然，這並不是說擁有不同 路由值的文檔就會放到不同的分片上。
查詢
路由允許用戶構建更有效率的查詢，並且用戶也可以使用路由。
curl -XGET 'localhost:9200/documents/_search?pretty&q=*:*&routing=A'路由是優化集群的一個很強大的機制。它能讓我們根據應用程序的邏輯來部署文檔， 從而可以用更少的資源構建更快速的查詢。
然而，有件重要的事情需要再強調一下。路由確保了在索引時擁有相同路由值的文檔會索引到相同的分片上，但一個給定的分片上可以有很多擁有不同路由值的文檔。路由可以限制查詢時使用的節點數，但是不能替代過濾功能。這意味着無論一個查詢有沒有使用路由都應該使用相同的過濾器。
4.2.4 別名
一個簡化了的路由功能
讓程序員們可以快速地工作而不必關心搜索細節。在理 想的世界里，他們不需要擔心路由、分片、副本。而別名就能讓我們像使用普通索引那樣使用路由。例如，用下面的命令創建一個別名:
curl -XPOST 'http://localhost:9200/_aliases' -d '
{
"actions":[
{
"add":{
"index":"documents",
"alise":"documentsA",
"routing":"A"
}
}
]
}'我們創建了一個叫doucmentsA的虛擬索引(一個別名)，用來代表來自doucments索引 的信息。然而，除了這個，查詢被限定在路由值A相關的分片上。感謝這個功能，你可以將別名documentsA的信息提供給開發者，並用它進行查詢和索引，就像其他索引一樣。
4.2.5 多個路由值
就像查詢多個索引一樣
ElasticSearch允許我們在一次查詢中使用多個路由值。文檔放置在哪個分片上依賴於 文檔的路由值，多路由值查詢意味着在一個或多個分片上查詢。我們看看下面的查詢:
curl -XGET 'localhost:9200/documents/_search?routing=A,B'當然，多路由值也支持別名。下面的例子展示了如何使用這些特性:
curl -XPOST 'http://localhost:9200/_aliases' -d '
{
"actions":[
{
"add":{
"index":"documents",
"alise":"documentsA",
"search_routing":"A,B",
"index_routing":"A"
}
}
]
}'上面的例子里有兩個額外的配置參數是我們之前沒有提到過的，我們可以為查詢和索 引配置不同的路由。例子中，我們定義在查詢時(search_routing參數)使用兩個路由值(A和B)，而索引時(index_routing參數)僅使用了一個路由值(A)。
4.3 調整默認的分片分配行為
ElasticSearch給我們提供了使用特定分片 部署策略來構建先進系統的可能性。在本節中，我們將深人探討關於分配分片的其他選擇。
4.3.1 分片分配器簡介
ElasticSearch提供了下面兩 種類型的分配器:
- even shard
- balanced(默認)
通過在elasticsearch.yml中設置cluster.rounting.allocation.type屬性或者使用設置API 我們可以指定具體的分配器實現。讓我們進一步了解前面提到的分配器類型。
4.3.2 even shard
它能確保每個節點上具有相同數 量的分片(當然，並不是總能滿足這樣的情形)，同時也能禁止主分片及其副本存儲在同一 節點上。在需要重新分配且使用even shard分片分配器時，ElasticSearch從存儲負載最高的節點向存儲負載較低的節點移動分片，直到集群完全平衡或者無法移動。需要注意的是，這個分配器並排工作在索引級別。這意味着只要分片及其副本在不同的節點上，分配器就認為工作正常，而不關心來自同一索引的不同分片存放到哪里。
4.3.3 balanced分片分配器
這個分配器是在ElasticSearch 0.90.0版本以后新引人的。它基於一些可控制的權重進 行分配。相比前面討論過的even shard分片分配器，它通過暴露一些參數而引入調整分配過程的能力，從而使我們可以通過使用集群更新API ( update API)來動態改變這些參數。
可調整的參數如下所示:
- cluster.routing.allocation.balance.shard:默認值為0.45.
- cluster.routing.allocation.balance.index:默認值為0.5.
- cluster.routing.allocation.balance.primary默認值為0.05.
- cluster.routing.allocation.balance.threshold:默認值為1.0.
第一個參數告訴ElasticSearch每個節點都分配數量相近的分片對我們有多么重要。
第二個參數類似，但不是基於所有的分片數，而是基於同一個索引的分片數。
第三個參數告訴ElasticSearch將主分片平均分配到節點有多么重要。
最后，如果所有因子與其權重的乘積的總和大於已定義的閡值，那么這類索引上的分 片就需要重新分配了。而如果出於某些原因，你希望忽略一個或多個因子，只要把它們的權重設為0就可以了。
4.3.5 裁決者
為了理解分片分配器是如何決定分片移動的時機和目標節點，我們需要討論一下 ElasticSearch內部的裁決者(decider)，它們是做出分配決定的大腦。ElasticSearch允許同時使用多個裁決者，而且它們會在決策過程中投票。這里有一個規則共識，例如，如果某裁決者投票反對重新分配一個分片的操作，那么該分片就不能移動。裁決者只有固定的十來個，如果想添加新的決策者，只能通過修改ElasticSearch源碼。
-
SameShardAllocationDecider
顧名思義，該裁決者禁止將相同數據的拷貝(分片和其副本)放到相同的節點上。注意屬性 cluster.routing.allocation.same_shard.host屬性。它控制了ElasticSearch 是否需要考慮分片放到物理機器上的位置。它默認為false，因為許多節點可能運行在同一台運行着多個虛擬機的服務器上。而當設置成true時，這個裁決者會禁止將分片和其副本 放置在同一台物理機器上。 -
ShardsLimitAllocationDecider
ShardsLimitAllocationDecider確保一個給定索引在某節點上的分片不會超過給定 數量。這個數量是由index.routing.allocation.total_ shards_per_node屬性控制的，可以在elasticsearch.yml文件中設置，或者通過索引更新API在線更新。屬性的默認值是-1，表明沒有限制。 -
FiIterAllocationDecider
-
RepIicaAfterPrimaryActiveAllocationDecider
這個裁決者使得ElasticSearch僅在主分片都分配好之后才開始分配副本。 -
ClusterRebalanceAllocationDecider
ClusterRebalanceAllocationDecider允許根據集群的當前狀態來改變集群進行重新平衡 的時機。該裁決者可以通過cluster.routing.allocation.allow_rebalance屬性來控制，它支持以下這些值:
indices_all_active :這個默認值表明重新平衡僅在集群中所有已存在的分片都分配好后才能進行。
indices_primaries_active:這個設置表明重新平衡只在主分片分配好以后才進行。
always:這個設置表明重新平衡總是可以進行，甚至在主分片和副本還沒有分配好 時也可以。注意這些設置在運行時不能更改。
-
ConcurrentRebalanceAllocationDecider
ConcurrentRebalanceAllocationDecider用於調節重新部署操作，並基於cluster.routing. allocation.cluster_concurrent_rebalance屬性。在該屬性的幫助下，我們可以設置給定集群上可以並發執行的重新部署操作的數量，默認是2個，意味着在集群上只有不超過2個的分片可以同時移動。把這個值設為-1將沒有限制。 -
DisabIeAlIocationDecider
DisableAllocationDecider是一個可以調整自身行為來滿足應用需求的裁決者。有以下配置
cluster.routing.allocation.disable_allocation:這個設置允許我們禁止所有的分配。
cluster.routing.allocaiotn.disable_new_allocation:這個設置允許我們禁止新主分片的分配。
cluster.routing.allocation.disable_replica_allocation:這個設置允許我們禁止副本的分配。
所有這些設置的默認值都是false。它們在你想要完全控制分配時非常有用。例如，當 你想要快速地重新分配和重新啟動一些節點時，便可以禁止重新分配。另外請記住盡管你可以在elasticsearch.yml文件里設置前面提到的那些屬性，但這里使用更新API會更有意義。利用該配置可快速重啟節點，而不進行分片分配
-
AwarenessAllocationDecider
AwarenessAllocationDecider是用來處理意識部署功能的。無論什么時候使用了cluster. routing.allocation.awareness.attributes設置，它都會起作用。更多關於它是如何工作的信息可參見4.4節內容。 -
ThrottlingAllocationDecider
ThrottlingAllocationDecider與前面討論過的ConcurrentRebalanceAllocationDecider類 似，該裁決者允許我們限制分配過程產生的負載。我們可以使用下面的屬性控制恢復過程:
cluster.routing.allocation.node_initial_primaries_recoveries:參數值默認為4。它描述了單節點所允許的最初始的主分片恢復操作的數量。
cluster.routing.allocation.node_concurrent_recoveries:參數值默認為2。它定義了單節點上並發恢復操作的數量。 -
RebalanceOnlyWhenActiveAllocationDecider
-
DiskThresholdDecider
DiskThresholdDecide:在ElasticSearch的0.90.4版本里引人，它允許我們基於服務器上 的空余磁盤容量來部署分片。默認它是禁用的，因而必須設置cluster.routing.allocation.disk.threshold_enabled屬性為true來啟用它。該裁決者允許我們配置一些閾值，以決定何時將分片放到某個節點上以及ElasticSearch應該何時將分片遷移到另一個節點上。
cluster.routing.allocation.disk.watermark.low：屬性允許我們在分片分配可用時指定一個 閥值或絕對值。例如，默認值是0.7，這告訴Elasticsearch新分片可以分配到一個磁盤使用率低於70%的節點上。
cluster.routing.allocation.disk.watermark.high：屬性允許我們在某分片分配器試圖將分片 遷移到另一個節點時指定一個閥值或絕對值:‘默認值是0.85，意味着ElasticSearch會在磁盤空間使用率上升到85%時重新分配分片。
cluster.routing.allocation.disk.watermark.low和cluster.routing.allocation.disk.watermark. high這兩個屬性都可以設置成百分數(如0.7或0.85 )，或者絕對值(如1 OOOmb )。另外，本節提到的所有屬性都可以在 elasticsearch.yml里靜態設置，或使用ElasticSearch API動態更新。
4.4 調整分片分配
我們的集群由4個節點構成，每個節點都綁定了一個指定的IP地址，而 且都被賦予了一個tag屬性和一個group屬性(在elasticsearch.yml文件里對應的是node.tag和node.group屬性)。這個集群用來展示分片分配的過濾處理是如何工作的。
4.4.1 部署意識
部署意識允許我們使用通用參數來配置分片及其副本的部署。 我們在elasticsearch.yml文 件里加人下列屬性:
cluster.routing.allocation.awareness.attributes:group這會告訴ElasticSearch使用node.group屬性作為意識參數。
然后，我們先啟動前兩個節點，即node.group屬性值是groupA的那兩個。接下來用下 而的命令創建一個常引：
curl -XPOST 'localhoat:9200/mastering' -d '
{
"settings":{
"index":{
"number_of_shards":2,
"number_of_replicas":1
}
}
}'執行前面的命令后，兩個節點的集群看起來類似於下面的截圖:
如你所見，索引平均部署到了兩個節點上。現在我們來看看換成另外兩個節點時會發 生什么(node.group設置成groupB的那兩個):
換成另外兩個節點意思應該是啟動另外兩個節點。
請注意區別:主分片沒有從原來部署的節點上移動，但是副本分片卻移動到了有不同 node.group值的節點上。這恰恰是對的。當使用分片部署意識的時候，ElasticSearch不會將分片和副本放到擁有相同屬性值(用來決定部署意識，如例子中的node.group)的節點上。 例如從虛擬機或物理位置的角度分割集群的拓撲結構，以確保不會有單點故障。
在使用部署意識的時候，分片不會被部署到沒有設定指定屬性的節點上所以對我 們的例子來說，一個沒有設置node.group屬性的節點是不會被部署機制考慮的。
4.4.2 過濾
ElasticSearch允許我們在整個集群或是索引的級別來配置分片的分配。其中在集群的 級別上我們可以使用帶有下面前綴的屬性:
cluster.routing.allocation.include
cluster.routing.allocation.require
cluster.routing.allocation.exclude而處理索引級分配時，將上述cluster字段換成index即可。
上述前綴可以與我們在elasticsearch.yml文件里定義的屬性一起使用(tag屬性和group屬性)。只需使用一個名為_ip的特殊屬性，就可以使用IP地址來進行包含或排除特定的節點。例如:
cluster.routing.allocation.include._ip:192.168.2.1如果希望包含一組group屬性是groupA的節點，應該設置下面的屬性:
cluster.routing.allocation.include.group:groupA這些屬性意味着什么
- include:這種類型會包含所有定義了某參數的節點。 擁有include參數類型的節點，ElasticSearch在選 擇放置分片的節點時會加以考慮，但這並不意味着ElasticSearch一定會把分片放到這些節點上。
- require:它要求所有 節點都必須擁有和這個屬性值相匹配的值。
- exclude :這個屬性允許我們在分片分配過程中排除具有特定屬性的節點。
屬性值可以使用簡單的通配符。
4.4.3 運行時更新分配策略
除了在elasticsearch.yml文件里設置我們討論過的那些屬性外，在集群已經啟動運行 后，也可以通過更新API來實時更新這些設置。
索引級更新
為了更新一個給定索引(如mastering索引)的設置，我們執行下面的命令:
curl -XPUT 'localhost:9200/mastering/_settings' -d '{
"index.routing.allocation.require.group":"groupA"
}'集群級更新
臨時更新
為了更新整個集群的設置，我們執行下面的命令，（重啟集群后失效）：
curl -XPUT 'localhost:9200/_cluster/settings' -d '{
"transient":{
"cluster.routing.allocation.require.group":"groupA"
}
}'永久更新
用persistent屬性替換上述transient屬性 即可。
4.4.4 確定每個節點允許的總分片數
除了前面提到的屬性，我們還能定義每個節點可分配給索引的分片總數(主分片和副 本)。為了實現該目的，我們需要給index.routing.allocation.total_shards_per_node屬性設置一個期望值。例如在elasticsearch.yml文件里做如下設置:
index.routing.allocation.total_shards_per_node:4這樣，單個節點上最多會為同一個索引分配4個分片。
這個屬性同樣可以在一個運行中的集群上使用更新API來改變，例如:
curl -XPUT 'localhost:9200/mastering/_settings -d '{
"index.routing.allocation.total_shards_per_node":"4"
}'4.4.5 更多的分片分配屬性
- cluster.routing.allocation.allow_rebalance:這個屬性允許我們基於集群中所有分片的 狀態來控制執行再平衡(rebanlance)的時機。可選的值包括:always、indices_primaries_active 、indices_all_active （默認）。
- cluster.routing.allocation.cluster concurrent_rebanlance:這個屬性控制我們的集群內有多少分片可以並發參與再平衡處理，默認值為2。
- cluster.routing.allocation.node_initial_primaries_recoveries:這個屬性指定了每個節 點可以並發恢復的主分片數量。基於主分片恢復通常比較快，即使把屬性值設置得較大，也不會給節點本身帶來過多的壓力。這個屬性的默認值為4.
- cluster.routing.allocation.node_concurrent_recoveries:這個屬性指定了每個節點允 許的最大並發恢復分片數，默認值是2。
- cluster.routing.allocation.disable_new_allocaiton:默認值是false。該屬性用來控制是否禁止為新創建的索引分配新分片(包括主分片和副本分片)。
- cluster.routing.allocation.disable_allocation:默認值是false。該屬性用來控制是否禁 止針對已創建的主分片和副本分片的分配。請注意，將一個副本分片提升為主分片(如果主分片不存在)的行為不算分配。
- cluster.routing.allocation.disable_replica_allocation:這個屬性默認是false。當它設 為true時，將會禁止將副本分片分配到節點。
前面所有的屬性既可以在elasticsearch.yml文件里設置，也可以通過更新API來設置。然而在實踐中，通常只使用更新API來配置一些屬性，如cluster.routing.allocation.disable_new_allocation、cluster.routing.allocation.disable_allocation、cluster.routing.allocation. disable_replica_allocation.
4.5 查詢執行偏好
除了ElasticSearch允許我們設置分片和副本 的那些技巧以外，我們還能夠指定查詢(以及其他操作，如實時獲取)在哪里執行。
介紹preference參數
為了控制我們所發送查詢(和其他操作)執行的地點，可以使用preference參數，它可 以取下面這些值:
- _primary:使用這個屬性，發送的操作僅會在主分片上執行。
- _primary_first:這個屬性的行為很像primary，但它有一個自動故障恢復機制。 該選項與primary非常相似，只是當主分片由於某些原因不可用時可以轉而使用其 副本。
- _local:ElasticSearch在可能的情況下會優先在本地節點上執行操作。 這在最小化網絡延時時尤為有用，當使用local時，確保盡可能(如從本地節點發起的客戶端連接或向某節點發送查詢)地在本地執行查詢。
- _only_node:wJqOkPSHTHCovjuCsVKO-A:這個操作只會在擁有指定標識符的節點上執行(例子里用了wJqOkPSHTHCovjuCsVKO-A )。因此在我們的例子里，查詢會在部署在node3上的兩個副本上執行。請注意，如果沒有足夠的分片來覆蓋所有的索引數據，查詢只會在指定節點的可用分片上執行。例如當我們知道某個節點比其他節點性能好，且希望 某些查詢只在那個節點上執行的時候。
- _prefer_node:wJqOkPSHTHCovjuCsVKO-A:與_only_node選項類 似，_prefer_node可以用來選擇一個特定的節點，只是當特定節點不可用時可以轉而使用其他節點。
- _shards:0,1:這個preference參數值既指定了操作將在哪個分片上執行。是唯一一個可 以和其他選項值組合的preference參數值。例如，為了在本地的0和1分片上執行查詢，我們用分號連接0，1和_local，最終preference參數看起來就像是這樣:0,1;_local。對調試來說，允許我們在一個分片上執行查詢非常有用。
- custom:這是一個自定義值，它確保了具有相同值的查詢會在相同的分片上執行。 例如，發送一個preference參數值為mastering_ elasticsearch的查詢，那么查詢會在名稱是nodel和node2的節點的主分片上執行。如果我們發送另一個具有相同preference參數值的查詢，那么該查詢將在相同的分片上執行。這個功能在需要有不同的刷新頻率，並且不希望用戶在重復查詢時看到不同結果的時候尤為有用。
- 默認行為。ElasticSearch默認會在分片和副本之間隨機執 行操作。如果我們發送大量的請求，那么最終每個分片和副本上將會執行相同(或者幾乎相同)數量的查詢。
4.6 應用我們的知識
性能測試開源工具
- ApacheJMeter
- ActionGenerator
- ElasticSearch paramedic的插件
- ElasticSearch BigDesk的插件
避免單個節點上運行多個ElasticSearch實例
將node.max_local_storage_nodes屬性值設為1，是為了避免單個節點上運行多個ElasticSearch實例。
發現
在發現模塊的配置中，我們僅僅設置了一個屬性，即設置discovery.zen.minimum_master_nodes的屬性值為3。它能指定組成集群所需的且可以成為主節點的最小節點數，取值至少是集群節點數的一半加1.
記錄慢查詢
協同ElasticSearch工作時，有件事情非常重要:記錄那些執行時間大於等於某個閾值的查詢。請注意，這個日志記錄的不是查詢的全部執行時間，而是查詢在每個分片上執行的時間，這意味着日志記錄的只是執行時間的一部分。
在例子里，我們想使用INFO級日志記錄執行超過500毫秒的查詢和執行超過1秒的實時讀取操作。對於調試級日志，這里分別設置為100毫秒和200毫秒。下面是這部分內容的配置片段:
index.search.slowlog.threshold.query.info:500ms
index.search.slowlog.threshold.query.debug:100ms
index.search.slowlog.threshold.fetch.info:1s
index.search.slowlog.threshold.fetch.debug:200ms記錄垃圾回收器的工作情況
最后，由於我們在沒有監控的情況下就開始了，因而想看看垃圾回收器表現如何。例如，想要搞清楚是否以及何時垃圾回收器消耗了太多的時間。為了實現這個目的，我們在elasticsearch.yml文件里加人下面幾行內容:
monitor.jvm.gc.ParNew.info:700ms
monitor‘jvm.gc.ParNew.debug:400ms
monitor.jvm.gc.ConcurrentMarkSweep.info:5s
monitor.jvm.gc.ConcurrentMarkSweep.debug:2s通過使用INFO級日志，當並發標記清除(concurrent mark sweep)執行等於或超過5秒時，以及新生代收集(younger generation collection)執行超過700毫秒時，ElasticSearch會記錄垃圾回收器工作超時的信息。同時也加上了DEBUG級日志，用來應對我們想要調試或者修復問題的情況。
內存設置
通常的建議是不要使Java虛擬機堆的大小超過可用內存總量的50%。
在前面所展示的配置中，我們設置了ElasticSearch記錄垃圾回收器的信息，然而為了長期監控，你可能還需要使用類似SPM ( http://sematext.com/spm/index.html)或Munin(http://munin-monitoring.org/)的監控工具。
參考資料
BigDesk
ApacheJMeter
SPM
Munin