引導檢查可以確保es能夠更好的提供服務，以及提前發現一些問題。
單點模式下可以通過設置es.enforce.bootstrap.checks = true或者配置在JVM配置中ES_JAVA_OPTS添加-Des.enforce.bootstrap.checks=true配置強制進行與節點配置無關的引導檢查。
堆內存大小檢查（Heap size check）
要通過堆大小檢查，必須配置堆大小，並且將初始大小與最大配置成一樣，避免在擴展時導致系統暫停。如果
bootstrap.memory_lock=trueJVM將在啓動時鎖定堆的初始大小
文件描述符大小檢查（File descriptor check）
系統限制了應用打開的文件描述符數量，需要進行配置允許一個應用打開的文件描述符多少，es檢查需要的文件描述符需要大於等於65535.
應用內存鎖定檢查（Memory lock check）
當jvm進行majorGC時，他會觸及所有應用內存分頁，單某些內存被交換到硬盤的虛擬內存中時，他需要被重新交換回來，會帶來大量的性能損耗，所以鎖定內存，禁止交換是很有必要的。要通過這個檢查，可以設置bootstrap.memory_lock=true來進行鎖定。
最大線程數檢查（Maximum number of threads check）
Elasticsearch通過將請求分解爲步驟並將這些步驟傳遞給不同的線程池執行器來執行請求。Elasticsearch中有不同的線程池執行器，用於執行各種任務。因此，Elasticsearch需要創建大量線程的能力。Elasticsearch進程至少創建4096個線程。這可以通過/etc/security/limits.conf使用nproc設置
最大文件數檢查（Max file size check）
在Elasticsearch進程可以創建的最大文件大小受到限制於系統，當寫入文件太大時可能導致寫入失敗。因此需要設置寫入最大文件限制，可以通過設置/etc/security/limits.conf fsize不受限。
最大虛擬內存檢查（Maximum size virtual memory check）
Elasticsearch使用了內存映射mmap 技術提升訪問索引的速度，在linux系統中可以通過設置/etc/security/limits.conf，指定運行es的用戶不受限制。
最大映射數檢查（Maximum map count check）
內存映射mmap除了需要設置虛擬內存不受限，還需要設置內核是否允許進程擁有262144個內存映射區域，你可以通過設置
sysctl vm.max_map_count = 262144。
僅當使用mmapfs或hybridfs作爲索引的存儲類型時，才需要最大映射計數檢查，如果你不需要使用內存映射技術，此項不會強制引導檢查
JVM檢查（Client JVM check）
OpenJDK派生的JVM提供了兩種不同的JVM：客戶機JVM和服務器JVM。這些jvm使用不同的編譯器從Java字節碼生成可執行的機器代碼。客戶機JVM針對啓動時間和內存佔用進行了優化，而服務器JVM則針對最大化性能進行了優化。兩個vm之間的性能差異可能很大。客戶端JVM檢查確保Elasticsearch不在客戶端JVM中運行。要通過客戶機JVM檢查，必須使用服務器VM啓動Elasticsearch。在現代系統和操作系統中，服務器VM是默認的
串行收集器檢查（Use serial collector check）
串行收集器適合於單邏輯CPU機器或非常小的堆內存，它不適合運行Elasticsearch。將串行收集器與Elasticsearch結合使用可能會對性能造成破壞。串行收集器檢查確保Elasticsearch未配置爲與串行收集器一起運行。要通過串行收集器檢查，不能使用串行收集器啓動Elasticsearch（無論是使用的JVM的默認值，還是使用-XX:+UseSerialGC顯式指定的值）。
注意，Elasticsearch附帶的默認JVM配置將Elasticsearch配置爲使用CMS收集器。
系統調用過濾器檢查（System call filter check）
Elasticsearch根據操作系統（例如，Linux上的seccomp）安裝不同風格的系統調用過濾器。安裝這些系統調用過濾器是爲了防止執行與forking相關的系統調用，以此作爲對Elasticsearch上任意代碼執行攻擊的防禦機制。系統調用篩選器檢查確保如果啓用了系統調用篩選器，則它們已成功安裝。要通過系統調用篩選器檢查，您必須修復系統上阻止安裝系統調用篩選器的任何配置錯誤（檢查日誌），或者自行承擔通過設置禁用系統調用篩選器的風險,關閉系統調用過濾檢查bootstrap.system_call_fiter=false。
錯誤或者內存溢出錯誤檢查 (OnError and OnOutOfMemoryError checks)
此檢查總是強制的。若要通過此檢查，請不要啓用OnError或onoutfmemoryerror；而是升級到Java 8u92並使用JVM標誌ExitOnOutOfMemoryError。雖然這不具備OnError或OnOutOfMemoryError的全部功能，但啓用seccomp時將不支持任意分叉
JVM穩定版本檢查（Early-access check）
OpenJDK項目提供了即將發佈的版本的早期訪問快照。這些版本不適合生產。早期訪問檢查檢測這些早期訪問快照。要通過此檢查，必須在JVM的發佈版本上啓動Elasticsearch。
G1垃圾收集器檢查（G1GC check）
衆所周知，JDK 8附帶的HotSpot JVM的早期版本存在一些問題，當G1GC收集器啓用時，這些問題會導致索引損壞。受影響的版本是那些早於JDK 8u40附帶的HotSpot版本的版本。G1GC檢查檢測這些早期版本的熱點JVM
所有權限檢查（All permission check）
所有權限檢查確保在引導期間使用的安全策略不會授予Elasticsearch java.security.all.AllPermission 。在授予所有權限的情況下運行等同於禁用安全管理器。
發現配置檢查（Discovery configuration check）
默認情況下，當Elasticsearch首次啓動時，它將嘗試發現運行在同一主機上的其他節點。如果在幾秒鐘內找不到選定的主節點，則Elasticsearch將形成一個集羣，其中包括已發現的任何其他節點。在開發模式下可以在不進行任何額外配置的情況下形成此羣集是很有用的，但這不適合生產，因爲這樣可能會形成多個羣集並因此丟失數據。
此引導檢查可確保發現未使用默認配置運行。可以通過設置以下至少一個屬性來滿足：
discovery.seed_hostsdiscovery.seed_providerscluster.initial_master_nodes