Elasticsearch 參考指南（引導檢查）

時間 2019-11-09

原文原文鏈接

引導檢查

總的來講，咱們有不少用戶由於沒有配置重要的設置而遇到意外問題的經驗，在之前版本的Elasticsearch中，這些設置的錯誤配置被記錄爲警告，能夠理解的是，用戶有時會錯過這些日誌消息，爲了確保這些設置獲得應有的關注，Elasticsearch在啓動時進行引導檢查。java

這些引導檢查各類Elasticsearch和系統設置，並將它們與Elasticsearch操做安全的值進行比較，若是Elasticsearch處於開發模式，任何失敗的引導檢查都會在Elasticsearch日誌中顯示警告，若是Elasticsearch處於生產模式，任何引導檢查失敗都會致使Elasticsearch拒絕啓動。node

有一些引導檢查老是強制執行，以防止Elasticsearch在不兼容的設置下運行，這些檢查是單獨記錄的。bootstrap

開發與生產模式

默認狀況下，Elasticsearch綁定到迴環地址，用於HTTP和transport（內部）通訊，這對於下載和把玩Elasticsearch以及平常開發來講是很好的，但對於生產系統則毫無用處。要加入集羣，Elasticsearch節點必須經過transport通訊到達。要經過非迴環地址加入集羣，節點必須將transport綁定到非迴環地址，而不是使用單節點發現。所以，若是一個Elasticsearch節點不能經過非迴環地址與另外一臺機器造成集羣，咱們將其考慮爲處於開發模式，若是它能夠經過非迴環地址加入集羣，則處於生產模式。segmentfault

注意，HTTP和transport能夠經過http.host和transport.host單獨配置，這對於將單個節點配置爲能夠經過HTTP訪問的節點，以便在不觸發生產模式的狀況下進行測試很是有用。安全

單節點發現

咱們認識到，有些用戶須要將transport綁定到外部接口，以測試他們對transport客戶端的使用，對於這種狀況，咱們提供發現single-node類型（經過將discovery.type設置爲single-node來配置），在這種狀況下，節點將選擇本身爲主節點，而不會與任何其餘節點加入集羣。服務器

強制執行引導檢查

若是你在生產環境中運行單個節點，有可能會避開引導檢查（經過不綁定到外部接口的transport，或者綁定到外部接口並將發現類型設置爲single-node）。對於這種狀況，你能夠經過將系統屬性es.enforce.bootstrap.checks設置爲true以強制執行引導檢查（在設置JVM選項中設置這個，或經過添加-Des.enforce.bootstrap.checks=true到環境變量ES_JAVA_OPTS）。若是你在這種狀況下，咱們強烈建議你這樣作，此係統屬性可用於強制執行引導檢查，獨立於節點配置。網絡

堆大小檢查

若是JVM啓動時初始堆大小和最大堆大小不相等，那麼在系統使用期間JVM堆大小調整時很容易暫停，爲了不這些調整大小的暫停，最好以初始堆大小等於最大堆大小啓動JVM。此外，若是啓用了bootstrap.memory_lock，JVM將在啓動時鎖定堆的初始大小。若是初始堆大小不等於最大堆大小，那麼在調整大小以後，不會將全部JVM堆鎖定在內存中，要經過堆大小檢查，必須配置堆大小。多線程

文件描述符檢查

文件描述符是用於跟蹤打開的「文件」的Unix構造，可是在Unix中，一切都是文件。例如，「文件」能夠是物理文件、虛擬文件（例如/proc/loadavg）或網絡socket。Elasticsearch須要大量的文件描述符（例如，每一個碎片由多個片斷和其餘文件組成，以及與其餘節點的鏈接等）。這個引導檢查是在OS X和Linux上執行的，要經過文件描述符檢查，你可能須要配置文件描述符。socket

內存鎖定檢查

當JVM執行主要的垃圾收集時，它會觸及堆的每一個頁面，若是這些頁面中的任何一個被交換到磁盤上，它們就必須被交換回內存中，這會致使不少磁盤超負荷，而Elasticsearch更願意使用這些磁盤來服務請求。有幾種方法能夠配置系統來禁止交換，一種方法是請求JVM經過mlockall（Unix）或虛擬鎖（Windows）在內存中鎖定堆，這是經過Elasticsearch設置bootstrap.memory_lock完成的。可是，在某些狀況下，這個設置能夠被Elasticsearch經過，但Elasticsearch沒法鎖定堆（例如，若是elasticsearch用戶沒有memlock unlimited）。內存檢查驗證，若是bootstrap.memory_lock設置已啓用，則JVM可以成功鎖定堆。要經過內存鎖檢查，你可能須要配置bootstrap.memory_lock。elasticsearch

最大線程數檢查

Elasticsearch經過將請求分解爲多個階段並將這些階段分配給不一樣的線程池執行器來執行請求，對於Elasticsearch中的各類任務，有不一樣的線程池執行器，所以，Elasticsearch須要可以建立許多線程。最大線程數檢查確保Elasticsearch進程有權在正常使用時建立足夠的線程，此檢查僅在Linux上執行。若是你在Linux上，爲了經過最大線程數檢查，你必須配置你的系統，使Elasticsearch進程可以建立至少4096個線程。這能夠經過/etc/security/limits.conf使用nproc設置完成（注意，你可能還須要增長對於root用戶的限制）。

最大文件大小檢查

做爲單個碎片的組件的片斷文件和做爲translog組件的translog生成文件可能會變大（超過多個gb），在容許Elasticsearch進程建立的文件的最大大小有限的系統中，這可能致使寫失敗，所以，這裏最安全的選項是，最大文件大小是無限的，這就是最大文件大小引導檢查所執行的。要經過最大文件檢查，你必須配置系統，使Elasticsearch進程可以寫入無限大小的文件，這能夠經過/etc/security/limits.conf使用fsize設置爲unlimited實現（注意，你可能還須要增長對於root用戶的限制）。

最大虛擬內存大小檢查

Elasticsearch和Lucene使用mmap以極大的效果將索引的部分映射到Elasticsearch地址空間，這使某些索引數據遠離JVM堆，但在內存中用於高速訪問。要使其有效，Elasticsearch應該有無限的地址空間，最大的虛擬內存檢查強制使Elasticsearch進程具備無限的地址空間，而且只在Linux上執行。要經過最大大小的虛擬內存檢查，你必須配置你的系統，使Elasticsearch進程可以擁有無限的地址空間，這能夠經過/etc/security/limits.conf使用as設置爲unlimited完成（注意，你可能還須要增長對於root用戶的限制）。

最大map計數檢查

繼續前面的內容，要有效地使用mmap, Elasticsearch還須要建立許多內存映射區域，最大映射計數檢查檢測內核容許進程至少有262,144個內存映射區域，而且僅在Linux上執行。要經過最大映射計數檢查，你必須經過sysctl配置vm.max_map_count將爲至少262144。

客戶端JVM檢查

OpenJDK派生JVM提供了兩種不一樣的JVM：客戶端JVM和服務器JVM。這些JVM使用不一樣的編譯器從Java字節碼生成可執行的機器碼，客戶端JVM爲啓動時間和內存佔用調優，而服務器JVM爲性能最大化調優。這兩個VM之間的性能差別可能很大，客戶端JVM檢查確保Elasticsearch不在客戶端JVM中運行，要經過客戶端JVM檢查，必須使用服務器VM啓動Elasticsearch，在現代系統和操做系統中，服務器VM是默認的。

使用串行收集器檢查

針對不一樣工做負載的OpenJDK派生JVM有各類垃圾收集器，串行收集器特別適合於單個邏輯CPU機器或很是小的堆，它們都不適合運行Elasticsearch。使用串行收集器與Elasticsearch一塊兒會對性能形成極大的破壞，串行收集器檢查確保Elasticsearch沒有配置爲與串行收集器一塊兒運行。要經過串行收集器檢查，你不能啓動Elasticsearch與串行收集器一塊兒（不管是你使用的JVM的默認值，仍是用-XX:+UseSerialGC顯式地指定它）。注意，與Elasticsearch一塊兒附帶的默認JVM配置配置使Elasticsearch可以使用CMS收集器。

系統調用過濾器檢查

Elasticsearch根據操做系統（如Linux上的seccomp）安裝各類類型的系統調用過濾器，安裝這些系統調用過濾器是爲了防止執行與分叉相關的系統調用，做爲在Elasticsearch上針對任意代碼執行攻擊的防護機制，系統調用過濾器檢查確保若是啓用了系統調用過濾器，那麼就成功安裝了它們。要經過系統調用過濾器檢查，你必須修復系統上阻止系統調用過濾器安裝的任何配置錯誤（檢查日誌），或者經過將bootstrap.system_call_filter設置爲false，在你本身的風險下禁用系統調用過濾器。

OnError和OnOutOfMemoryError檢查

若是JVM遇到致命錯誤（OnError）或OutOfMemoryError （OnOutOfMemoryError），JVM選項OnError和OnOutOfMemoryError容許執行任意命令。可是，默認狀況下，啓用了Elasticsearch系統調用過濾器（seccomp），這些過濾器防止分叉，所以，使用OnError或OnOutOfMemoryError和系統調用過濾器是不兼容的。若是使用了這些JVM選項中的任何一個，而且啓用了系統調用過濾器，OnError和OnOutOfMemoryError檢查阻止了Elasticsearch啓動。這個檢查老是強制執行的，要經過此檢查，請不要啓用OnError或OnOutOfMemoryError。相反，升級到Java 8u92並使用JVM標誌ExitOnOutOfMemoryError，雖然它不具有OnError和OnOutOfMemoryError的所有功能，但啓用了seccomp的狀況下不支持任意分叉。