Heap区大小检查
默认情况下，ES会根据当前节点的角色（不同角色所需要的heap区大小不同）和主机的内存大小自动的设置heap区大小。如果你手动的覆盖了这些默认值并且初始值和最大值设置的不一样，可能会在系统运行的时候导致暂停用于等待heap区的扩大。如果你bootstrap.memory_lock，那么在ES启动的时候就会锁定heap区大小。如果初始值和最大值不等，在某些JVM下进行rezie操作后可能会破坏lock属性，因此推荐初始值和最大值保持一致。
文件描述符检查
文件描述符是Uinx系统用来跟踪打开的文件句柄的，在Unix系统中，所有的资源都是文件。例如文件可能是物理文件（文档），也可能是虚拟设备，还是网络的Socket连接。而ES则需要大量的文件描述符（例如每一个分片是由大量的段文件构成并且还持有大量的网络连接）。在MacOS和Linux中，文件描述符的检查是强制的。为了通过检查，你可能需要像前几章讲的配置 file descriptors。
内存锁定检查
当JVM做一次majorGC的时候，他会访问堆区里的所有的页。如果有些页已经被交换出了内存到了磁盘，他需要再拉回内存。这会导致大量的磁盘thrashing影响ES的运行。有好几种方式可以确认系统有没有禁用swapping。一种方式是使用mlockall（Unix系统）锁定内存里的堆区。这个可以通过配置bootstrap.memory_lock来实现。然而也有情况设置了这个值但是ES未能锁住内存区（例如 ES的启动账户无法memlock unlimited）。这项检查就是用来检查 bootstrap.memory_lock是否已经设置，如果不设置可能会导致检查不通过。
最大线程数检查
Elasticsearch执行请求，通过讲请求分解成多步，然后交给多个线程同时执行。有不同的线程池执行不同的任务。Elasticsearch所以需要创建大量的线程。最大线程数检查只在Linux系统上生效，他会强制检查ES是否有权限创建足够多的线程，最少的值是4096.可以在配置文件/etc/security/limits.conf中进行配置，使用nproc设置（确保你有root权限）
最大文件Size检查
段文件是分片的组成部分，translog产生的文件是translog的组成部分可能会非常大（超过好几个GB）。在操作系统中，ES能创建的最大文件被限制的，这可能会导致写入失败。所以这里安全的做法是文件的大小不被限制，这也是最大文件检查所检查的。要通过这个检查，可以通过/etc/security/limits.conf文件进行配置，通过fsize命令设置成无限制的（首先需要有root权限）
最大虚拟内存检查
ES和Lucene使用mmap将索引数据映射到ES的地址空间。这让不在heap区的数据能够放在内存里加速访问。为了让这种手段生效，ES必须拥有无限制的地址空间。最大虚拟内存检查确保ES在运行的时候拥有无限制的地址空间（在Linux系统上）。为了通过检查，你必须确保ES拥有最大地址空间。这个可以通过在/etc/security/limits.conf配置文件里增加 - as unlimited来实现。当然，首选需要你有root权限。
最大map数量检查
接上一个章节的点，为了有效的使用mmap，Elasticsearch同时需要有能力创建大量的内存映射区域。这个检查就是为了强制保障在Linux系统上拥有至少262,144个内存映射地址。为了通过检查，你最好通过sysctl命令配置vm.max_map_count至少为262,144。
这个配置只有你在索引里的存储类型为mmapfs或者hybridfs的时候才有效。如果你没有使用mmap的话，这个检查项目就不强制。
Client JVM检查
OpenJDK提供了两种不同的JVM：一种Client JVM和一种Server JVM。这两种VM使用了不同的编译器。Client JVM针对启动时间和内存占用做了优化，而Server JVM则做了最佳的优化。这项检查是为了确保ES运行在Client JVM下。默认情况下，现在的操作系统都是用的Server JVM。
垃圾回收器的检查
OpenJDK提供了很多种类的垃圾回收器。serial回收器是用来单核心小内存的机器，这两种都不是ES的运行机器。使用serial会严重的拖累ES得运行效率。这项检查就是用来确保你没有使用serial垃圾回收器的。无论是默认的还是通过参数 -XX:+UseSerialGC设置的都不应该存在。JDK14和以后的版本使用的是G1垃圾回收器，而之前的版本使用的是CMS。
系统调用过滤检查
系统调用过滤的安装类型取决于操作系统的类型（例如Linux上的seccomp）。系统过滤的安装能够阻止ES被任意代码执行的漏洞攻击。这项检查能够确保系统调用过滤被正确的安装。
OnError 和 OnOutOfMemoryError 检查
JVM的选项OnError和OnOutOfMemoryError能够在JVM遇到fatal error或者OOM的时候执行任意的命令。但是默认情况下，开启了系统调用过滤会预防forking。因此这两者是冲突的。这个检查项会检查是否同时开启了OnError、OnOutOfMemoryError和系统调用过滤。相反，升级到 Java 8u92 并使用 JVM 标志 ExitOnOutOfMemoryError。虽然这没有 OnError 或 OnOutOfMemoryError 的全部功能，但在启用 seccomp 的情况下，forking也将不受支持。
Early-access检查
OpenJDK也提供了一些early-access的快照版本，这个检查项就是检查是不是使用了快照版在生产环境中。如果要通过检查，需要使用JDK的release版。
All permission检查
这项检查是确保ES没有获得java.security.AllPermission权限，因为这项权限会导致所有的安全管理失效。
Discovery的配置检查
默认情况下，ES在启动的时候回去尝试发现在同一个host（同一个网段还是同一个物理机？）下的其他节点。如果master节点还未被选出的话，ES将会和其他被发现的机器形成一个集群。这个在测试环境下非常有用，可以在不用进行什么配置的情况下形成一个集群。但是在生产环境务必不要使用，因为很容易造成脑裂，形成多个集群丢失数据。
这个检查项是为了确保ES的discovery没有运行在默认配置下面。你可以通过下面的配置实现：
- discovery.seed_hosts
- discovery.seed_providers
- cluster.initial_master_nodes
需要注意的是，你的集群一旦第一次起来之后，你需要去掉cluster.initial_master_nodes这个配置，千万不要在集群重启或者加入新节点的时候启用这个配置。相反你应该配置discovery.seed_hosts or discovery.seed_providers。如果你不需要任何发现机制，比如你运行的是一个单节点的集群，你可以这么配置discovery.seed_hosts: [] 来禁用发现，从而通过此项检查。
X-Pack相关的检查
敏感数据加密检查
如果你使用了Watcher并且使用了加密敏感数据（通过设置xpack.watcher.encrypt_sensitive_data为true），你必须设置一个key在安全配置里。要通过这个检查，你必须在每个节点上配置xpack.watcher.encryption_key
(PKI) realm检查
如果你使用了ES的安全特征和PKI realm，你就必须配置传输层的安全（TLS）以及开启客户端的网络授权。要通过这个检查，确认在PKI realm开启的情况下你必须配置TLS并开启客户端的网络授权。
角色映射检查
其复制到集群中的每个节点。默认情况下，角色映射存储在 ES_PATH_CONF/role_mapping.yml 中。或者，可以为每种类型的领域指定不同的角色映射文件，并在 elasticsearch.yml 文件中指定其位置。有关更多信息，请参阅使用角色映射文件。要通过此引导检查，角色映射文件必须存在且必须有效。角色映射文件中列出的可分辨名称（DN）也必须有效。
SSL/TLS检查
如果启用了 Elasticsearch 的安全功能，那么除非你有试用许可证，否则必须为节点间通信配置 SSL/TLS。
:::info 使用环回接口的单节点集群没有这个要求。欲了解更多信息，请参阅“自动启用安全功能启动 Elastic Stack”。
:::
Token SSL 检查
如果使用 Elasticsearch 的安全功能且内置令牌服务已启用，必须将集群配置为对 HTTP 接口使用 SSL/TLS。为了使用令牌服务，需要 HTTPS。特别是，如果在 elasticsearch.yml 文件中将 xpack.security.authc.token.enabled 设置为 true，那么也必须将 xpack.security.http.ssl.enabled 设置为 true。有关这些设置的更多信息，请参阅安全设置和高级 HTTP 设置。要通过此引导检查，必须启用 HTTPS 或禁用内置令牌服务。
