引导检查
总的来说，我们积累了大量用户因未配置重要设置而遭受意外问题的经验。在 Elasticsearch 的早期版本中，这些设置中的一些配置错误会被记录为警告。可以理解，用户有时会错过这些日志消息。为了确保这些设置得到应有的重视，Elasticsearch 在启动时引入了引导检查（bootstrap checks）。
这些引导检查会检查各种 Elasticsearch 和系统设置，并将它们与 Elasticsearch 安全运行的值进行比较。如果 Elasticsearch 处于开发模式，任何失败的引导检查都会作为警告出现在 Elasticsearch 日志中。如果 Elasticsearch 处于生产模式，任何失败的引导检查都会导致 Elasticsearch 拒绝启动。
有一些引导检查总是被强制执行，以防止 Elasticsearch 使用不兼容的设置运行。这些检查单独记录。
开发模式与生产模式
默认情况下，Elasticsearch 将 HTTP 和传输（内部）通信绑定到环回地址。这对于下载和试用 Elasticsearch 以及日常开发来说很好，但对生产系统没有用。要加入集群，Elasticsearch 节点必须可以通过传输通信访问。要通过非环回地址加入集群，节点必须将传输绑定到非环回地址，并且不使用单节点发现。因此，我们认为，如果 Elasticsearch 节点无法通过非环回地址与另一台机器组成集群，则它处于开发模式；否则，如果它可以通过非环回地址加入集群，则处于生产模式。
请注意，HTTP 和传输可以通过 http.host 和 transport.host 独立配置；这对于配置单个节点以便出于测试目的可以通过 HTTP 访问而不触发生产模式非常有用。
单节点发现
我们认识到，一些用户需要将传输绑定到外部接口以测试远程集群配置。对于这种情况，我们提供了单节点发现类型（通过将 discovery.type 设置为 single-node 来配置）；在这种情况下，节点将自行选举为主节点，并且不会与任何其他节点组成集群。
强制执行引导检查
如果你在生产环境中运行单个节点，可以规避引导检查（要么不将传输绑定到外部接口，要么将传输绑定到外部接口并将发现类型设置为单节点）。对于这种情况，你可以通过在 JVM 选项中将系统属性 es.enforce.bootstrap.checks 设置为 true 来强制执行引导检查。如果你处于这种特定情况，我们强烈建议你这样做。此系统属性可用于独立于节点配置强制执行引导检查。