Elasticsearch的引导性检查(bootstrap check)

引导性检查主要检查各种Elasticsearch和系统设置，并与操作安全的值进行对比，需要注意的是，如果es处于开发模式时，检查错误es会报warn日志提醒，但如果是正式生产模式的话，那就直接启动不了了。

开发模式和生产模式

一般es通过检查http.host和transport.host来判断是哪个模式，如果这些配置选项被配置成本地地址，例如127.0.0.1,那这个es就无法被外部访问，也无法加入集群，es就认为这个是开发模式，毕竟是单机节点，生产环境很少也不建议使用单机节点的。如果选项被配置成可以外部访问的地址，那就可以被访问，可以加入集群了，也就是正式环境了。

单节点发现模式

可以设置discovery.type:single-node把es设置成单节点，这样你的transport.host可以绑定外部地址。为啥要这么做呢？主要是为了测试其他客户端像logstash或者filebeat这类向es传输数据的组件向es传输数据，这种情况你是必须要绑定外部地址的，除非你连filebeat也在本地。

我就想在生产环境运行单节点es，但我又想检查es的配置

一般来说，如果你在单节点运行es，是不会进行bootstrapcheck的，但是总是会有特殊情况，比如业务量较小，或者比较穷，没能力运行集群，但又想进行引导性检查，看一下配置情况之类的，那么可以这样设置：在jvm设置中设置es.enforce.bootstrap.checks=true，这样es不管你什么想法什么模式，统统强制检查配置。

bootstrap checks的主要检查项

堆的大小检查

如果jvm在启动的时候，初始堆大小和最大堆大小不一样，那么在运行过程中可能会进行调整，在调整的过程中就很有可能暂停，一旦暂停，那就…。
为了防止这种调整的情况发生，最好设置-Xms2g 和-Xmx2g 相等，这里就都是2g大小。
此外，如果启用了bootstrap.memory_lock，则JVM将在启动时锁定堆的初始大小。如果初始堆大小不等于最大堆大小，则在调整大小后不会出现所有JVM堆都锁定在内存中的情况。

文件描述符

这个一般在linux中会遇到，时不时的es就挂了，很有可能是文件描述符没有配置的足够大。在linux中，一切皆文件嘛，大家都知道，所以在linux中运行es需要更多的文件描述符。
通过配置ulimit -n 65536 或者配置/etc/security/limits.config配置nofile为65536即可。

最大线程数

** 此检查仅在Linux上强制执行。**es通过把一个请求分为不同的阶段，每个阶段都交给不同线程进行梳理，所以每个阶段后面都连着一个不同的线程池，所以需要很多的线程。
通过设置/etc/security/limits.conf的nproc选项，线程数最少为4096.

文件大小限制

在/etc/security/limits.conf 设置fsize为unlimited。这主要是为了放开es在文件创建文件大小方面的限制，免得文件达到系统规定得上限而写不进去。

最大虚拟内存

** 此检查仅在Linux上强制执行。**Elasticsearch和Lucene使用mmap将索引的某些部分映射到Elasticsearch地址空间。这样可以将某些索引数据从JVM堆中移除，但在内存中可以实现快速访问。为了使其有效，Elasticsearch应具有无限的地址空间。
设置方法：/etc/security/limits.conf 设置 as 为unlimited

最大映射数

** 此检查仅在Linux上强制执行。**为了有效地使用mmap,es需要大量创建内存映射空间，所以就要求系统的最大映射数不得小于262144.
设置方法：使用系统命令sysctl设置vm.max_map_count最小为262144.

客户端jvm检查

这个配置项主要检查es是否运行在客户端jvm上。因为OpenJDK派生出来的jvm有两种，一种是客户端jvm，一种是服务端jvm。客户端在占用内存这些方面做了一些调整，服务端则是最大的使用机器的性能，所以性能方面差异较大，es为了运行良好，所以要检查一下是否运行在客户端jvm,免得掉链子。不过不用太担心，现在的机器默认都是服务端jvm。

串行垃圾收集器检查

主要检查系统上jvm默认垃圾收集器是不是串行的或者jvm配置文件有没有指定-XX:+UseSerialGC。
有就不行，因为串行收集器对es来说性能太差了，它需要更强有力的收集器，所以它的jvm默认收集器都是CMS的。

系统调用过滤器检查

系统调用过滤器主要是防止任意代码攻击漏洞的。es为了安全，一般会安装过滤器。或者直接把bootstrap.system_call_filter设置为false来禁用过滤器。

OnError和OnOutOfMemoryError检查

这项检查也是为了安全性，并且也是强制性的。jvm的这两项配置可能会导致任意命令执行漏洞，所以一旦启用或者配置了这两项，并且又启用了系统调用过滤器，es就会启动失败。所以为了这个问题，要么不配置这两项，要么禁用过滤器。

all permission检查

a所有权限检查确保在引导期间使用的安全策略不会将java.security.AllPermission授予Elasticsearch。使用所有权限运行等同于禁用安全管理器。

结语

看的出来，Elasticsearch要求还挺多，但也是为了顺畅运行和安全运行着想，所以尽量满足它的需求，不然，频繁的系统崩溃还是挺让人崩溃的。