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

ThreadPool部分

Elasticsearch 內部使用了線程池，經過這些線程池之間的合做完成工做，在須要時傳遞工做。通常來講你不須要調整和優化線程池。可是有時候你看着這些線程池的狀態，對你掌握你的集羣行爲是頗有幫助的。

這有十幾個線程池，他們的格式都是相似的：

"index": {
     "threads": 1,
     "queue": 0,
     "active": 0,
     "rejected": 0,
     "largest": 1,
     "completed": 1
  }

每一個線程都列出了配置的線程數，其中有多少個線程是正在處理事務的，也就是活動的，還有多少等待處理的事務在隊列裏。

若是隊列滿了，超出了限制，新的事務就會開始被拒絕，你能夠看到拒絕的事務的統計，這一般表示你的集羣正處在一個資源瓶頸，由於一個滿的隊列表示你的集羣或者節點正在以最大的速度處理事務，可是依然趕不上新事務增長的速度。

關於bulk的拒絕

若是你的線程隊列出現拒絕請求的事情，那麼醉有可能發生的就是bulk批量索引的請求，經過採用併發導入線程，很容易發給elasticsearch不少的bulk請求，併發請求越多越好嗎？

現實中，任何集羣都有必定的線程，形成入不敷出。一旦這個閾值達到了，你的隊列就會被迅速的填滿，新的bulk請求就會被拒絕。

這是一個好事，隊列的拒絕是對壓力的一個有效措施，他們告訴你你的集羣正在處於最大的容量，這要好過把數據所有塞到內存隊列裏。增大隊列大小不會提高性能，它只會隱藏問題，若是你的集羣每秒只能處理1萬個文檔，這和你的隊列大小是100仍是一千萬沒有任何關係，你的集羣每秒的處理能力仍然是1萬個文檔。

隊列只會隱藏性能問題，而且帶來數據丟失的風險，在隊列裏的表示尚未被處理的，若是你的節點掛了，那麼這些請求就會永遠的丟失了，此外隊列會消耗很大的內存，這不是個好主意。

最好咱們經過優雅的解決隊列滿了的問題來清理隊列。當你遇到bulk拒絕請求時候，你應該採起以下措施：

一、中止插入線程3-5秒
二、從bluk請求裏提取被拒絕的操做，可能大部分請求都成功了。bulk的響應裏會告訴你哪些操做成功了，哪些操做被拒絕了。
三、把拒絕的操做從新生成一個新的bulk請求。
四、若是再有拒絕請求發生，就重複上面的步驟。

經過這種方式，你的代碼會天然的適應你的集羣的負載，天然的減壓。

請求拒毫不是錯誤，它們只是表示你須要過會重試。

有十幾個線程池，大部分你能夠忽視，可是有少部分須要你特別注意：

indexing 正常的索引文檔的請求
bulk 批量請求，這有區別於非批量的請求
get 根據id獲取文檔的操做
search 索引的檢索和查詢請求
merging 專門管理lucene合併的線程池

FS和Network部分（剩餘空間和網絡）

繼續看node stats api返回的信息，你會看到一個關於文件系統的統計信息，剩餘空間，數據存放目錄，磁盤io等待。若是你沒有監控剩餘磁盤空間大小，你能夠從這裏獲得。磁盤io也是很容易獲得，可是一些更專業的命令行工具（例如iostat）可能更有用。

很顯然，若是你的磁盤空間不足了，elasticsearch確定完蛋了，因此必定要保證充足的磁盤空間。

下面是關於network統計的兩個部分：

"transport": {
	"server_open": 13,
	"rx_count": 11696,
	"rx_size_in_bytes": 1525774,
	"tx_count": 10282,
	"tx_size_in_bytes": 1440101928
 },
 "http": {
	"current_open": 4,
	"total_opened": 23
 },

transport: 顯示了網絡傳輸的基本信息，這涉及到節點之間的通訊（一般是9300端口）和一些客戶端和節點之間的連接。若是你看到不少連接在這裏，不要擔憂，elasticsearch會保持大量的節點之間的連接。

http表示關於http端口（一般是9200）的基本信息，若是你看到一個很是大的total_opened,而且在不斷增長，這是一個很明確的信號：你的客戶端沒有使用HTTP的keep-alive。keep-alive的連接對性能很重要，由於不斷的建立和斷開socket連接是很昂貴的（同事也會浪費open files個數），確保你的客戶端都使用了正確的配置。

Circuit Breaker(斷路器）

最後咱們來到最後一個部分，關於fieldata 阻斷的統計（在《Circuit Breaker》章節中有介紹。

"fielddata_breaker": {
	"maximum_size_in_bytes": 623326003,
	"maximum_size": "594.4mb",
	"estimated_size_in_bytes": 0,
	"estimated_size": "0b",
	"overhead": 1.03,
	"tripped": 0
 }

這裏，你能夠看到最大阻斷的大小（例如，你的查詢請求使用多大的內存的時候，這個斷路器就會進行左右）。這個部分就是告訴你斷路器發揮做用的次數，以及當前配置的過載值，這個值是用來估計的（譯者注：用來估計查詢可能須要使用的內存）。由於有些查詢比其它的比較難估計。

最主要的東西仍是關於斷路器起做用的次數的統計，若是這個值很大而且持續增長，表示你的查詢須要優化，或者你須要更多的內存（總體上增長內存，或者增長更多的節點）。