Elasticsearch重要文章之四：監控每一個節點(Indices部分)

集羣的健康只是一個方面，它是對整個集羣全部方面的一個很高的歸納。節點狀態的api是另一個方面，它提供了關於你的集羣中每一個節點令你眼花繚亂的統計數據。

節點的狀態提供了那麼多的統計數據，在你很熟悉它們執勤，你可能不肯定哪些指標是相當重要。咱們會把須要監控的最重要的幾個指標跳出來（咱們建議你把全部的統計指標記錄下來，例如使用Marvel插件，由於你不知道你哪天可能就須要）。

節點狀態的API能夠經過下面的方式執行
GET _nodes/stats

在輸出內容的開頭，咱們能夠看到集羣的名字和咱們第一個node的信息：

{
"cluster_name": "elasticsearch_zach",
"nodes": {
  "UNr6ZMf5Qk-YCPA_L18BOQ": {
	 "timestamp": 1408474151742,
	 "name": "Zach",
	 "transport_address": "inet[zacharys-air/192.168.1.131:9300]",
	 "host": "zacharys-air",
	 "ip": [
		"inet[zacharys-air/192.168.1.131:9300]",
		"NONE"
	 ],
   ...

節點會根據一個hash值的順序來顯示，也就是node的uuid值。還有一些關於node的網絡屬性會顯示（例如傳輸地址和HOST）。這些信息有助於調試發現問題，好比那些節點沒有加入集羣。一般你可能會發現端口用錯了，或者節點綁錯了IP地址等等。

Indices部分

indices部分列出的是對於全部的索引在該節點上的彙總信息。

"indices": {
"docs": {
   "count": 6163666,
   "deleted": 0
},
"store": {
   "size_in_bytes": 2301398179,
   "throttle_time_in_millis": 122850
},

它返回的統計信息能夠分紅這樣幾個部分：
docs: 顯示有多少文檔在該節點，以及有多少刪除的文檔尚未從數據段中清除出去。
store: 顯示該節點消耗了多少物理存儲，這個數據包含主分片和副分片，若是throttle_time_in_millis太大，說明你設置的磁盤流量過低（參考段的合併一章節）

"indexing": {
   "index_total": 803441,
   "index_time_in_millis": 367654,
   "index_current": 99,
   "delete_total": 0,
   "delete_time_in_millis": 0,
   "delete_current": 0
},
"get": {
   "total": 6,
   "time_in_millis": 2,
   "exists_total": 5,
   "exists_time_in_millis": 2,
   "missing_total": 1,
   "missing_time_in_millis": 0,
   "current": 0
},
"search": {
   "open_contexts": 0,
   "query_total": 123,
   "query_time_in_millis": 531,
   "query_current": 0,
   "fetch_total": 3,
   "fetch_time_in_millis": 55,
   "fetch_current": 0
},
"merges": {
   "current": 0,
   "current_docs": 0,
   "current_size_in_bytes": 0,
   "total": 1128,
   "total_time_in_millis": 21338523,
   "total_docs": 7241313,
   "total_size_in_bytes": 5724869463
},

indexing： 表示索引文檔的次數，這個是經過一個計數器累加計數的。當文檔被刪除時，它不會減小。注意這個值永遠是遞增的，發生在內部索引數據的時候，包括那些更新操做。

search：列出了主動檢索的次數（open_contexts），查詢總數，以及從節點啓動到如今花在這些查詢上的總時間。query_time_in_millis / query_total的比值能夠做爲你的查詢效率的粗略指標。比值越大，每一個查詢用的時間越多，你就須要考慮調整或者優化。

後面關於fetch的統計，是描述了查詢的第二個過程（也就是query_the_fetch裏的fetch)。fetch花的時間比query的越多，表示你的磁盤很慢，或者你要fetch的的文檔太多。或者你的查詢參數分頁條件太大，（例如size等於1萬）

merges：包含lucene段合併的信息，它會告訴你有多少段合併正在進行，參與的文檔數，這些正在合併的段的總大小，以及花在merge上的總時間。
若是你的集羣寫入比較多，這個merge的統計信息就很重要。merge操做會消耗大量的磁盤io和cpu資源。若是你的索引寫入不少，你會看到大量的merge操做，一低昂要閱讀《關於索引數據性能方面的提示》這一章節。

注意：更新和刪除都會致使大量的合併，由於它們會產生段碎片，這些都須要進行合併。

"filter_cache": {
   "memory_size_in_bytes": 48,
   "evictions": 0
},
"id_cache": {
   "memory_size_in_bytes": 0
},
"fielddata": {
   "memory_size_in_bytes": 0,
   "evictions": 0
},
"segments": {
   "count": 319,
   "memory_in_bytes": 65812120
},
...

filter_cache：表示緩存的filter bitset所佔的內存大小，以及一個filter緩存被淘汰的次數。大量的緩存淘汰預示着你可能須要增長你的filter緩存大小，或者你的filter不太適合緩存（例如，你的filter基數比較大，例如緩存當前時間的表達式。譯註：意思就是你的filter基數很大，例如你的某個field是表示當前時間，你的filter確定很大，緩存不容易利用上）

可是淘汰是個很難度量的評價，filter 是被緩存到每一個段（segement)上的，在一個小段上淘汰比在一個大段上淘汰容易一些。若是你有不少淘汰，可是都是發生在小的段上，那對查詢的性能影響也不大。

把這個淘汰的統計做爲一個粗略的指導，若是你看到大量的淘汰，就要調查下你的filter，確保它們是比較適合緩存的。若是filters不斷的淘汰，即使是在小的段上，對性能仍是有影響的，因此你最好使用適合緩存的filter

id_cache：顯示了父子mapping使用的內存，若是你使用了父子映射，id_cache就會在內存裏位置一張連接表包含這種關係，這個統計告訴你多少內存正在使用。由於它和父子文檔的個數有個明確的線性關係，因此對於這部份內存的使用，你能夠作的事情不多，它是常駐內存的，因此你最好常常關注它。

field_data：顯示了fielddata使用的內存，fielddata用於聚合、排序等。這裏也有一個淘汰數，不像filter_cache，這裏的淘汰數頗有用，它必須是0或者接近0，由於fielddata 不是緩存，任何淘汰的代價都是很大的，必需要避免的。若是你看到了淘汰，你必須從新評估你的內存狀況，關於fielddata的限制，以及查詢，或者三者所有。

segments：告訴你當前節點的lucene 段的個數，這多是一個很重要的數字。大多數的索引應該在50到150個段左右，即使是幾T大小的數十億的文檔。大量的段會帶來合併的問題（例如：合併趕不上段的產生）。注意這個統計是對一個節點上全部的索引而言的，記住喲。

其中內存的統計，能夠告訴你Lucene的段自身須要多少內存。這裏包括基礎的數據結構，包括提交列表，詞典，bloom過濾器等。段的數量多會增長承載這些數據結構的開銷，這個內存的使用就是對這個開銷的度量。