Elasticsearch 常見問題的解決思路

本文爲es性能監控基礎的擴展，你們能夠先看下性能監控基礎，熟悉下es的基本原理。爲翻譯性質文檔，感謝原做者,原始文檔地址

相似於汽車的運行方式，Elasticsearch旨在讓用戶快速上手和運行，而無需瞭解其全部的內部工做。然而咱們在使用過程當中，總會遇到這樣那樣的問題。下文將介紹Elasticsearch使用時常常遇到的一些挑戰，以及咱們如何應對這些挑戰。以下列舉了5個常見問題：

1、個人es集羣是紅色或者黃色的，我該如何處理？

正如性能監控基礎中所講，若是缺乏一個或多個主分片（及其副本），則集羣狀態將報告爲紅色，若是缺乏一個或多個副本分片，則集羣狀態將呈黃色。一般狀況下，當某個節點因爲某種緣由（硬件故障，較長的垃圾收集時間等）而退出羣集時，會發生這種狀況。一旦節點回復，其分片在轉爲active以前會處於initializing。（這個在head中能夠經過觀察分片顏色獲得）
當節點從新加入羣集時，initializing 分片的數量會達到峯值，而後隨着分片轉爲active，峯值回落。以下圖：

在此initializing 期間，集羣狀態可能會從綠色轉換爲黃色或紅色，直到恢復節點上的分片從新轉爲active。 在許多狀況下，黃色或紅色的簡單狀態更改可能不須要您採起任何行動。

可是，若是您注意到羣集狀態長時間處於紅色或黃色狀態，請檢查集羣節點的數量。

若是活動節點的數量低於預期，則表示至少有一個節點丟失鏈接，而且沒法從新加入羣集。 要查找離開集羣的節點，請檢查相似於如下行的日誌（默認位於Elasticsearch主目錄的logs文件夾中）。

[TIMESTAMP] ... Cluster health status changed from [GREEN] to [RED] (reason: [[{<NODE_NAME>}...] left])

節點故障的緣由可能會有所不一樣，從硬件或管理程序故障，到內存不足錯誤。檢查節點失敗的同一時間發生的任何性能指標異常。例如當前搜索速率或索引請求忽然增長，若是確認是請求增長致使，那麼這是一個暫時的故障，能夠嘗試讓該斷開的節點從新加入集羣。若是你沒法恢復該節點，則能夠添加新節點，並讓Elasticsearch從任何可用的副本分片恢復; 副本分片能夠升級到主分片，並從新分發到剛剛添加的新節點上。

若是主分片和副分片都丟失了，則可使用Elasticsearch的快照和還原模塊儘量多地恢復丟失的數據。可是，若是您丟失了分片的主副本和副本副本，則可使用Elasticsearch的快照和還原模塊儘量多地恢復丟失的數據。 若是您還不熟悉此模塊，則能夠將其用於在遠程存儲庫中存儲索引的快照以進行備份。

2、數據節點磁盤空間不夠了

若是全部數據節點的磁盤空間不足，將須要在集羣中添加更多的數據節點。 還須要確保您的索引具備足夠的主分片，以便可以在全部這些節點之間平衡其數據。

然而，若是隻有某些節點的磁盤空間不足，這一般是索引分片太少的一個標誌。 若是一個索引由幾個很是大的分片組成，那麼Elasticsearch很難在各數據節點之間進行數據均衡。

將分片分發給各節點時，Elasticsearch會考慮各個節點的磁盤可用空間。默認狀況下，不會將分片分發給磁盤使用率超過85%的節點。在Datadog中，您能夠設置閾值警報，以便在任何單個數據節點的磁盤空間使用率達到80％時通知您，以便足夠的時間採起行動。

低磁盤使用空間有兩種補救措施。 （1）刪除過期的數據。 這對全部用戶來講可能不是一個可行的選擇，可是若是您正在存儲基於時間的數據，則能夠存儲舊索引數據的快照，用於備份，同時更新索引設置以關閉這些過期索引的副本功能。（2）若是你須要全部的數據都存在集羣中備用，要麼升級硬件資源（vertically scale ）、要麼水平擴展集羣（horizontally scale增長節點，這個是比較合適的）。爲了更好適應數據不斷的增加，應該要多指定主分片的個數。

水平擴展集羣的另一個方法是建立一個新的索引並使用一個別名to join the two indices together under one namespace. 雖然單個分片存儲數據無技術意義上的上限，可是通常建議每一個分片不超過50GB。

3、個人搜索執行時間過長怎麼辦？

根據正在搜索的數據類型和每一個查詢的結構方式，搜索性能有很大差別。根據您的數據的組織方式，你可能須要嘗試幾種不一樣的方法，以便找到一個能提升搜索性能的方法。這裏介紹兩個： 自定義路由和強制合併

一般，當節點接收到搜索請求時，它須要將該請求傳達給索引中每一個分片的副本。 自定義路由容許將相關數據存儲在相同的分片上，以便您只需搜索單個分片來知足查詢。

例如，您能夠經過在索引blog_index中的mapping中指定_routing值，將全部blogger1的數據存儲在同一個分片上。

curl -XPUT "localhost:9200/blog_index" -d '
{
  "mappings": {
    "blogger": {
      "_routing": {
        "required": true 
      }
    }
  }
}'

當您準備索引與blogger1相關的文檔時，請指定路由值：

curl -XPUT "localhost:9200/blog_index/blogger/1?routing=blogger1" -d '
{
  "comment": "blogger1 made this cool comment"
}'

如今，爲了搜索blogger1的註釋，您須要記住在查詢中指定路由值，以下所示：

curl -XGET "localhost:9200/blog_index/_search?routing=blogger1" -d '
{
  "query": {
    "match": {
      "comment": {
        "query": "cool comment"
      }
    }
  }
}'

在Elasticsearch中，每一個搜索請求必須檢查所命中的每一個分片的每一個segment。還能夠經過在一個或多個索引上觸發Force Merge API來減小每一個分片的segment數。 Force Merge API（或2.1.0以前的版本中的Optimize API）將提示索引中的segment繼續合併，直到每一個碎片的segment計數減小爲max_num_segments（默認爲1）。若是大量觸發merges的成本相對下降，這種方法能夠進行嘗試。

當分片上segment的數量不少時，強制merge segment將很是浪費。例如，強制將一個索引中的10000個segments壓縮到5000個並不耗費太多時間。可是，若是將這10000個segments壓縮爲1個，將耗費數個小時的時間。The more merging that must occur, the more resources you take away from fulfilling search requests,這可能背離你的初衷。所以一般在非高峯時段（午夜）安排強制合併。

4、如何加快個人index速度

Elasticsearch預先配置了許多設置，嘗試確保您保留足夠的資源來搜索和索引數據。可是，若是您使用Elasticsearch嚴重偏向寫入，則可能會發現調整某些設置以提升索引性能是有意義的，即便這意味着丟失一些搜索性能或副本數據。 下面，咱們將探討一些方法來優化用例來進行索引，而不是搜索數據。 （預設值是兼顧搜索和索引）

• 分片分配: 若是你要建立一個更新頻繁的索引，請確保指定足夠的主分片，以便您能夠在全部節點間均勻分佈索引負載。通常建議是每一個集羣中的節點分配一個主分片。若是你的CPU和磁盤夠用，2個或者更多的主分片是可行的（注意：這個是對單個索引來描述的）。可是，請記住，分片過分分配會增長開銷，並可能會對搜索產生負面影響，由於搜索請求須要打到索引中的每一個分片。另外一方面，若是分配的分片數少於節點數，you may create hotspots？由於包含這些分片的節點須要處理比不包含任何索引分片的節點更多的索引請求。


• 禁止 merge throttling: merge throttling是elasticsearch的一個自動機制：當es檢測到合併速度落後於索引速度時，es會throttle 索引請求。 若是要優化索引性能，而不是搜索性能，能夠經過更新集羣設置來禁止掉merge throttling（經過將indices.store.throttle.type設置爲「none」）。You can make this change persistent (meaning it will persist after a cluster restart) or transient (resets back to default upon restart), based on your use case.


• 增長indexing buffer的大小: 這個index-level 設置（indices.memory.index_buffer_size）決定了在將文檔寫入到磁盤上的segment以前buffer的總大小。默認爲總heap的10%，以便爲索引請求預留更多的heap，which doesn’t help you if you’re using Elasticsearch primarily for indexing.？？


• 先index，後replicate: 初始化索引時，在索引設置中指定零個複本分片，並在索引完成後添加副本。 這將提升索引性能。可是有必定的風險。


• 刷新間隔拉長: 增長Index Settings API中的刷新間隔。 默認狀況下，索引刷新過程每秒都會發生一次，可是在較大的索引期間，下降刷新頻率能夠幫助減輕部分工做量。


• 調整translog設置: 從版本2.0開始，Elasticsearch將在每次請求後將Translog數據刷新到磁盤，從而下降硬件故障時數據丟失的風險。若是你中索引性能，而且不太擔憂潛在的數據丟失的可能，您能夠將index.translog.durability更改成異步。 有了這一點，索引只會在每一個sync_interval上提交寫入磁盤，而不是在每一個請求以後提交寫入磁盤，從而使其更多的富餘資源能夠提供索引請求。

5、如何處理buik thread pool rejections ?

Thread pool rejections 一般是發送過多過快請求的標誌。若是這是一個暫時故障（例如，您本週必須索引異常大量的數據，而且您預計很快就會恢復正常），你能夠嘗試減慢請求的速度。 可是，若是但願集羣可以維持當前的請求速率，則可能須要經過添加更多的數據節點來擴展集羣。爲了利用增長節點數的處理能力，您還應確保您的索引包含足夠的分片，以便可以均勻地將全部節點的負載分散。

總結：

因爲優化結果將根據您的具體用例和設置而有所不一樣，您能夠測試不一樣的設置和索引/查詢策略，以肯定哪些方法對您的集羣最有效。

總之尋找合適本身場景的優化和解決辦法，拈輕怕重、合理選擇。