Elasticsearch Reference 5.5 中文翻译3

Configuring Elasticsearch

配置Elasticsearch

 

Elasticsearch ships with good defaults and requires very little configuration. Most settings can be changed on a running cluster using the Cluster Update Settings API.

Elasticsearch使用了默认设置并且只需要一点点的配置。大部分配置可以在集群运行时使用集群更新设置的API来进行修改。

 

The configuration files should contain settings which are node-specific (such as node.name and paths), or settings which a node requires in order to be able to join a cluster, such as cluster.name and network.host.

配置文件应当包含指定节点的设置（例如node.name和paths），或设置一个节点的必要内容来加入集群中，例如cluster.name和network.host。

 

Config file location

配置位置

 

Elasticsearch has two configuration files:

Elasticsearch有两个配置文件

 

    elasticsearch.yml for configuring Elasticsearch, and

elasticsearch.yml用于配置Elasticsearch，并且

    log4j2.properties for configuring Elasticsearch logging.

log4j2.properties用于配置Elasticsearch的日志。

 

These files are located in the config directory, whose location defaults to $ES_HOME/config/. The Debian and RPM packages set the config directory location to /etc/elasticsearch/.

这些文件位于配置目录，当位置默认是$ES_HOME/config/。Debian和RPM包设置了配置目录指定为/etc/elasticsearch/。

 

The location of the config directory can be changed with the path.conf setting, as follows:

配置目录的位置可以被改变通过path.conf设置，如下：

 

./bin/elasticsearch -Epath.conf=/path/to/my/config/

 

Config file format

配置文件格式

 

The configuration format is YAML. Here is an example of changing the path of the data and logs directories:

配置文件格式是YAML。这里是改变数据和日志文件目录的设置：

 

path:

    data: /var/lib/elasticsearch

    logs: /var/log/elasticsearch

 

Settings can also be flattened as follows:

设置可以指定如下：

 

path.data: /var/lib/elasticsearch

path.logs: /var/log/elasticsearch

 

Environment variable substitution

环境变量替换

 

Environment variables referenced with the ${...} notation within the configuration file will be replaced with the value of the environment variable, for instance:

环境变量引用可以使用${...}方式使用在配置文件中见被替换为环境变量的值，例如：

 

node.name:    ${HOSTNAME}

network.host: ${ES_NETWORK_HOST}

 

Prompting for settings

设置的提示

 

For settings that you do not wish to store in the configuration file, you can use the value ${prompt.text} or ${prompt.secret} and start Elasticsearch in the foreground. ${prompt.secret} has echoing disabled so that the value entered will not be shown in your terminal; ${prompt.text} will allow you to see the value as you type it in. For example:

对于设置你可以存储在配置文件中，你可以使用${prompt.text}或${prompt.secret}并且在前台运行Elasticsearch。${prompt.secret}是显示关闭的因此键入的在终端不会显示；${prompt.text}将允许你看见键入的值。例如：

 

node:

  name: ${prompt.text}

 

When starting Elasticsearch, you will be prompted to enter the actual value like so:

当启动Elasticsearch时，你将不需要输入实际的值如下：

 

Enter value for [node.name]:

 

Note

注意

 

Elasticsearch will not start if ${prompt.text} or ${prompt.secret} is used in the settings and the process is run as a service or in the background.

Elasticsearch将不会启动如果${prompt.text}或${prompt.secret}是使用在设置中并且程序是作为服务来运行或在后台运行。

 

Logging configuration

日志配置

 

Elasticsearch uses Log4j 2 for logging. Log4j 2 can be configured using the log4j2.properties file. Elasticsearch exposes three properties, ${sys:es.logs.base_path}, ${sys:es.logs.cluster_name}, and ${sys:es.logs.node_name} (if the node name is explicitly set via node.name) that can be referenced in the configuration file to determine the location of the log files. The property ${sys:es.logs.base_path} will resolve to the log directory, ${sys:es.logs.cluster_name} will resolve to the cluster name (used as the prefix of log filenames in the default configuration), and ${sys:es.logs.node_name} will resolve to the node name (if the node name is explicitly set).

Elasticsearch使用Log4j2作为日志记录。Log4j2可以被配置使用log4j2.properties文件。Elasticsearch暴露了这些属性，${sys:ex.logs.base_path}、${sys:es.logs.cluster_name}和${sys:es.logs.node_name}（如果节点名字是通过node.name来指定的话）可以医用配置文件来决定日志文件的位置。属性${sys:es.logs.base_path}将解析为日志目录，${sys:es.logs.cluster_name}将解析为集群名字（使用日志文件名的前缀在默认的配置中），并且${sys:es.logs.node_name}将解析为节点名字（如果节点已经被设置的话）。

 

For example, if your log directory (path.logs) is /var/log/elasticsearch and your cluster is named production then ${sys:es.logs.base_path} will resolve to /var/log/elasticsearch and ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}.log will resolve to /var/log/elasticsearch/production.log.

例如，如果你的日志目录(path.logs)是/var/log/elasticsearch并且你的集群名字production则${sys:es.logs.base_path}将被解析为/var/log/elasticsearch并且${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}.log将被解析为/var/log/elasticsearch/production.log。

 

appender.rolling.type = RollingFile //1

appender.rolling.name = rolling

appender.rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}.log //2

appender.rolling.layout.type = PatternLayout

appender.rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c] %.10000m%n

appender.rolling.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}-%d{yyyy-MM-dd}.log //3

appender.rolling.policies.type = Policies

appender.rolling.policies.time.type = TimeBasedTriggeringPolicy //4

appender.rolling.policies.time.interval = 1 //5

appender.rolling.policies.time.modulate = true //6

 

1，Configure the RollingFile appender

配置RollingFile为appender

2，Log to /var/log/elasticsearch/production.log

日志记录在/var/log/elasticsearch/production.log中

 

3，Roll logs to /var/log/elasticsearch/production-yyyy-MM-dd.log

滚动日志记录在/var/log/elasticsearch/production-yyyy-MM-dd.log

4，Using a time-based roll policy

使用基于时间的滚动策略

 

5，Roll logs on a daily basis

按天来滚动日志

 

6，Align rolls on the day boundary (as opposed to rolling every twenty-four hours)

按天绑定对其（和二十四小时相对）

 

Note

注意

 

Log4j’s configuration parsing gets confused by any extraneous whitespace; if you copy and paste any Log4j settings on this page, or enter any Log4j configuration in general, be sure to trim any leading and trailing whitespace.

Log4j的配置解析使用了一些额外的空格符；如果你复制和机械这个页面的任何Log4j的设置或键入Log4j的配置，保证去掉了这些空格符。

 

If you append .gz or .zip to appender.rolling.filePattern, then the logs will be compressed as they are rolled.

如果你追加gz或zipDAOappender.rolling.filePattern之后，日志将在滚动后被压缩。

 

If you want to retain log files for a specified period of time, you can use a rollover strategy with a delete action.

如果你希望获取日志文件对于指定的时间，你可以使用一个滚动策略如下：

 

appender.rolling.strategy.type = DefaultRolloverStrategy //1

appender.rolling.strategy.action.type = Delete //2

appender.rolling.strategy.action.basepath = ${sys:es.logs.base_path} //3

appender.rolling.strategy.action.condition.type = IfLastModified //4

appender.rolling.strategy.action.condition.age = 7D //5

appender.rolling.strategy.action.PathConditions.type = IfFileName //7

appender.rolling.strategy.action.PathConditions.glob = ${sys:es.logs.cluster_name}-* //7

 

1，Configure the DefaultRolloverStrategy

配置DefaultRolloverStrategy

 

2，Configure the Delete action for handling rollovers

配置删除操作对于处理解析器

 

3，The base path to the Elasticsearch logs

Elasticsearch日志的基本路径

 

4，The condition to apply when handling rollovers

处理应用解析器的条件

 

5，Retain logs for seven days

保留7天的日志

 

6，Only delete files older than seven days if they match the specified glob

只删除七天之前的日志记录

 

7，Delete files from the base path matching the glob ${sys:es.logs.cluster_name}-*; this is the glob that log files are rolled to; this is needed to only delete the rolled Elasticsearch logs but not also delete the deprecation and slow logs

从基本目录删除文件，符合要求${sys:es.logs.cluster_name}-*;这是滚动日志文件的记录，只需要删除滚动的Elasticsearch日志而不是删除错误和慢日志。

 

Multiple configuration files can be loaded (in which case they will get merged) as long as they are named log4j2.properties and have the Elasticsearch config directory as an ancestor; this is useful for plugins that expose additional loggers. The logger section contains the java packages and their corresponding log level. The appender section contains the destinations for the logs. Extensive information on how to customize logging and all the supported appenders can be found on the Log4j documentation.

多个配置文件可以被加载（他们将会融合在一起）名字为log4j2.properties并且使用Elasticsearch的配置目录作为根目录，他们可以用于插件来暴露额外的设置。appender章节包含了日志的位置。扩展的信息有关如何自定义日志记录和所有支持的appender可以找到在http://logging.apache.org/log4j/2.x/manual/configuration.html中。

 

Configuring logging levels

配置日志级别

 

There are four ways to configuring logging levels, each having situations in which they are appropriate to use.

有四种方式来配置日志的级别，每种方式都有其各自的用途。

 

    1，Via the command-line: -E <name of logging hierarchy>=<level> (e.g., -E logger.org.elasticsearch.transport=trace). This is most appropriate when you are temporarily debugging a problem on a single node (for example, a problem with startup, or during development).

通过命令行：-E <name of logging hierarchy>=<level>（例如，-E logger.org.elasticsearch.transport=trace）。这种方式适合于你临时调试一个问题对于某一个节点（例如，在启动时的问题或开发中的问题）。

    2，Via elasticsearch.yml: <name of logging hierarchy>: <level> (e.g., logger.org.elasticsearch.transport: trace). This is most appropriate when you are temporarily debugging a problem but are not starting Elasticsearch via the command-line (e.g., via a service) or you want a logging level adjusted on a more permanent basis.

通过elasticsearch.yml：<name of logging hierarchy>: <level>（例如，logger.org.elasticsearch.transport: trace）。这种方式适用于当你临时调试一个问题但是不能通过命令行来启动Elasticsearch的时候（例如是一个服务）或者你希望记录级别基于更加持久化的方式保存。

3，Via cluster settings:

通过集群设置：

 

    PUT /_cluster/settings

    {

      "transient": {

        "<name of logging hierarchy>": "<level>"

      }

    }

 

    For example:

例如：

 

    PUT /_cluster/settings

    {

      "transient": {

        "logger.org.elasticsearch.transport": "trace"

      }

    }

 

    This is most appropriate when you need to dynamically need to adjust a logging level on an actively-running cluster.

这种方式适用于当你需要动态的调整日志的级别对于一个正在运行中的集群时。

    4，Via the log4j2.properties:

通过log4j2.properties文件

 

    logger.<unique_identifier>.name = <name of logging hierarchy>

    logger.<unique_identifier>.level = <level>

 

    For example:

例如：

 

    logger.transport.name = org.elasticsearch.transport

    logger.transport.level = trace

 

    This is most appropriate when you need fine-grained control over the logger (for example, you want to send the logger to another file, or manage the logger differently; this is a rare use-case).

这种方式适用于你需要细粒度的控制日志（例如，你希望记录到另一个文件中或管理不同的日志；就是一个很好的方式）。

 

Deprecation logging

 

In addition to regular logging, Elasticsearch allows you to enable logging of deprecated actions. For example this allows you to determine early, if you need to migrate certain functionality in the future. By default, deprecation logging is enabled at the WARN level, the level at which all deprecation log messages will be emitted.

除了正常的日志外，Elasticsearch允许你启用deprecated的操纵。例如允许你提前决定，如果你需要在未来迁移功能。默认的，deprecation日志是运行于WARN级别的，这个级别中所有的deprecation日志消息会被忽略。

 

logger.deprecation.level = warn

 

This will create a daily rolling deprecation log file in your log directory. Check this file regularly, especially when you intend to upgrade to a new major version.

浙江会创建一个日滚的deprecation日志文件在你的日志目录中。正常的检查这个文件，尤其是你需要更新到一个新的主版本的时候。

 

The default logging configuration has set the roll policy for the deprecation logs to roll and compress after 1 GB, and to preserve a maximum of five log files (four rolled logs, and the active log).

默认的日志配置设置了滚动机制用于deprecation日志进行了滚动和压缩在1GB之后并且最多五个日志文件（四个滚动日志和一个正在记录的日志）。

 

You can disable it in the config/log4j2.properties file by setting the deprecation log level to error.

你可以关闭它在config/log4j2.properties文件中通过设置deprecation的日志级别为error。

 

Important Elasticsearch configuration

重要的Elasticsearch配置

 

While Elasticsearch requires very little configuration, there are a number of settings which need to be configured manually and should definitely be configured before going into production.

当需要最小化配置Elasticsearch的时候，有一些设置需要被手动设置并且在投入生产之前提前配置。

 

    path.data and path.logs

    cluster.name

    node.name

    bootstrap.memory_lock

    network.host

    discovery.zen.ping.unicast.hosts

    discovery.zen.minimum_master_nodes

 

path.data and path.logs

 

If you are using the .zip or .tar.gz archives, the data and logs directories are sub-folders of $ES_HOME. If these important folders are left in their default locations, there is a high risk of them being deleted while upgrading Elasticsearch to a new version.

如果你使用zip或tar.gz的安装包，data和logs目录是$ES_HOME的子目录。如果这些重要的目录在默认目录下，当Elasticsearch更新的时候就会存在被删除的风险。

 

In production use, you will almost certainly want to change the locations of the data and log folder:

在生产中，你需要改变数据和日志的目录：

 

path:

  logs: /var/log/elasticsearch

  data: /var/data/elasticsearch

 

The RPM and Debian distributions already use custom paths for data and logs.

RPM和Debina的发行版已经使用了自定义的路径用于数据和日志。

 

The path.data settings can be set to multiple paths, in which case all paths will be used to store data (although the files belonging to a single shard will all be stored on the same data path):

path.date设置可以被设置为多个路径，所有的路径都会用于存储数据（尽管文件是单独的并且会存储于相同的路径下）：

 

path:

  data:

    - /mnt/elasticsearch_1

    - /mnt/elasticsearch_2

    - /mnt/elasticsearch_3

 

cluster.name

 

A node can only join a cluster when it shares its cluster.name with all the other nodes in the cluster. The default name is elasticsearch, but you should change it to an appropriate name which describes the purpose of the cluster.

一个节点可以加入集群只是因为他们使用了相同的集群名对于集群中的所有节点。默认的名字是elasticsearch，但是你应当改变他为适当的名字用于描述集群的目的。

 

cluster.name: logging-prod

 

Make sure that you don’t reuse the same cluster names in different environments, otherwise you might end up with nodes joining the wrong cluster.

保证你不会重用相同的集群的名字在不同的环境中，此外你可以不会让节点加入错误的集群。

 

node.name

 

By default, Elasticsearch will take the 7 first character of the randomly generated uuid used as the node id. Note that the node id is persisted and does not change when a node restarts and therefore the default node name will also not change.

默认的，Elasticsearch会使用随机生成的uuid的前七位作为节点id。注意节点id是持久的并且不会改变除非节点重启并且没有设置节点名字的情况下。

 

It is worth configuring a more meaningful name which will also have the advantage of persisting after restarting the node:

配置一个有意义的节点名字是有必要的优点是可以在重启节点后持久化存在：

 

node.name: prod-data-2

 

The node.name can also be set to the server’s HOSTNAME as follows:

node.name可以被设置为服务器的HOSTNAME如下：

 

node.name: ${HOSTNAME}

 

bootstrap.memory_lock

 

It is vitally important to the health of your node that none of the JVM is ever swapped out to disk. One way of achieving that is set the bootstrap.memory_lock setting to true.

对于节点的健康是十分重要的不管JVM是否换出到磁盘。一种打包的方式是设置bootstrap.memory_lock的设置为true。

 

For this setting to have effect, other system settings need to be configured first. See Enable bootstrap.memory_lock for more details about how to set up memory locking correctly.

为了设置的生效，其他系统设置需要首先被配置。见https://www.elastic.co/guide/en/elasticsearch/reference/5.5/setup-configuration-memory.html#mlockall中的细节来了解如何设置当前内存的锁定。

 

network.host

 

By default, Elasticsearch binds to loopback addresses only — e.g. 127.0.0.1 and [::1]. This is sufficient to run a single development node on a server.

默认的，Elasticsearch绑定回环地址————例如，127.0.0.1和[::1]。这是足够的运行单一部署的节点在一个服务器上。

 

Tip

提示

 

In fact, more than one node can be started from the same $ES_HOME location on a single node. This can be useful for testing Elasticsearch’s ability to form clusters, but it is not a configuration recommended for production.

事实上，多于一个节点可以被启动来自相同的$ES_HOME。这可以用于测试Elasticsearch的能力对于组件集群但是不建议将其在生产中使用。

 

In order to communicate and to form a cluster with nodes on other servers, your node will need to bind to a non-loopback address. While there are many network settings, usually all you need to configure is network.host:

为了和集群中的其他节点通信，你的节点将需要绑定到非回环的地址上。这里有许多网络的设置，通常你需要做的是配置network.host：

 

network.host: 192.168.1.10

 

The network.host setting also understands some special values such as _local_, _site_, _global_ and modifiers like :ip4 and :ip6, details of which can be found in Special values for network.host

network.host设置也要求一些指定的值例如_local_, _site_, _global_，和修改器就像:ip4 and :ip6，其中的细节可以在https://www.elastic.co/guide/en/elasticsearch/reference/5.5/modules-network.html#network-interface-values中找到。

 

Important

重要

 

As soon you provide a custom setting for network.host, Elasticsearch assumes that you are moving from development mode to production mode, and upgrades a number of system startup checks from warnings to exceptions. See Development mode vs production mode for more information.

由于你提供了自定义的设置对于network.host，Elasticsearch假设你已经从开发模式转换为生产模式，并且更新了系统的启动检查从警告道异常。见https://www.elastic.co/guide/en/elasticsearch/reference/5.5/system-config.html#dev-vs-prod来了解更多信息。

 

discovery.zen.ping.unicast.hosts

 

Out of the box, without any network configuration, Elasticsearch will bind to the available loopback addresses and will scan ports 9300 to 9305 to try to connect to other nodes running on the same server. This provides an auto- clustering experience without having to do any configuration.

此外，抛开任何的网络设置，Elasticsearch将绑定可用的回环地址并且将会扫描端口9300DAO9305来试图连接其他运行在同一个服务器的节点。这提供了自动的集群功能不需要进行额外的设置。

 

When the moment comes to form a cluster with nodes on other servers, you have to provide a seed list of other nodes in the cluster that are likely to be live and contactable. This can be specified as follows:

当节点和其他的服务器形成集群时，你需要提供一个其余节点的列表在集群中就是存活可以连接的节点。这些可以指定如下：

 

discovery.zen.ping.unicast.hosts:

   - 192.168.1.10:9300

   - 192.168.1.11 //1

   - seeds.mydomain.com //2

 

1，The port will default to transport.profiles.default.port and fallback to transport.tcp.port if not specified.

端口默认是transport.profiles.default.port并且如果没有指定transport.tcp.port的话。

 

2，A hostname that resolves to multiple IP addresses will try all resolved addresses.

主机名解析多个IP地址将会试图解析所有的地址

discovery.zen.minimum_master_nodes

 

To prevent data loss, it is vital to configure the discovery.zen.minimum_master_nodes setting so that each master-eligible node knows the minimum number of master-eligible nodes that must be visible in order to form a cluster.

处理数据丢失，配置了一个虚拟的discovery.zen.minimum_master_nodes设置隐藏每个主机节点知道最小的合法主机的数目必须出现在一个集群中。

 

Without this setting, a cluster that suffers a network failure is at risk of having the cluster split into two independent clusters — a split brain — which will lead to data loss. A more detailed explanation is provided in Avoiding split brain with minimum_master_nodes

忽略这个设置，集群提供了网络失败的风险对于集群分为两个独立的集群时————一个分开的司令部————将会导致数据的丢失。更多的细节请参考https://www.elastic.co/guide/en/elasticsearch/reference/5.5/modules-node.html#split-brain

 

To avoid a split brain, this setting should be set to a quorum of master- eligible nodes:

为了避免这种情况，下面的这应当被设置为合法主机的数目：

 

(master_eligible_nodes / 2) + 1

 

In other words, if there are three master-eligible nodes, then minimum master nodes should be set to (3 / 2) + 1 or 2:

也就是说，如果有三个合法的主机节点，最小的主节点数据应该是(3 / 2) + 1或者是2：

 

discovery.zen.minimum_master_nodes: 2

 

Secure Settings

安全设置

 

Some settings are sensitive, and relying on filesystem permissions to protect their values is not sufficient. For this use case, elasticsearch provides a keystore, which may be password protected, and the elasticsearch-keystore tool to manage the settings in the keystore.

一些设置是敏感的并且仅仅依赖于文件系统的权限来保护他们的值是不够的。对于这种情况，Elasticsearch提供了keystore，可以是密码保护和elasticsearch-keystore的工具来管理keystore中的设置。

 

Note

注意

 

All commands here should be run as the user which will run elasticsearch.

在这里所有的命令都必须以可以运行Elasticsearch的用户来执行。

 

Note

注意

 

Only some settings are designed to be read from the keystore. See documentation for each setting to see if it is supported as part of the keystore.

只有一些设置被设计来读取来自keystore。见每个设置的文档来了解他是否是keystore的一部分。

 

Creating the keystore

创建keystore

 

To create the elasticsearch.keystore, use the create command:

为了创建elasticsearch.keystore，使用create命令：

 

bin/elasticsearch-keystore create

 

The file elasticsearch.keystore will be created alongside elasticsearch.yml.

文件elasticsearch.keystore将被创建取决于elasticsearch.yml。

 

Listing settings in the keystore

列出在keystore中的设置

 

A list of the settings in the keystore is available with the list command:

在keystore中的设置可以使用list命令来列出：

 

bin/elasticsearch-keystore list

 

Adding string settings

添加字符串设置

 

Sensitive string settings, like authentication credentials for cloud plugins, can be added using the add command:

敏感的字符串设置，例如授权对于cloud插件可以被添加通过使用add命令：

 

bin/elasticsearch-keystore add the.setting.name.to.set

 

The tool will prompt for the value of the setting. To pass the value through stdin, use the --stdin flag:

工具将提供值的设置。为了使用标准输入来传递值，请使用--stdin的标志

 

cat /file/containing/setting/value | bin/elasticsearch-keystore add --stdin the.setting.name.to.set

 

Removing settings

删除设置

 

To remove a setting from the keystore, use the remove command:

为了删除keystore中的设置，请使用remove命令：

 

bin/elasticsearch-keystore remove the.setting.name.to.remove

 

Bootstrap Checks

启动检查

 

Collectively, we have a lot of experience with users suffering unexpected issues because they have not configured important settings. In previous versions of Elasticsearch, misconfiguration of some of these settings were logged as warnings. Understandably, users sometimes miss these log messages. To ensure that these settings receive the attention that they deserve, Elasticsearch has bootstrap checks upon startup.

共同点，我们有很多用户使用中异常出现的问题都是因为他们没有进行正确的设置。在Elasticsearch之前的版本中，一些设置是警告状态的。由于不被理解，用户有时会忽略这些日志消息。为了保证这些设置被注意到，Elasticsearch在启动之前进行了检查操作。

 

These bootstrap checks inspect a variety of Elasticsearch and system settings and compare them to values that are safe for the operation of Elasticsearch. If Elasticsearch is in development mode, any bootstrap checks that fail appear as warnings in the Elasticsearch log. If Elasticsearch is in production mode, any bootstrap checks that fail will cause Elasticsearch to refuse to start.

这些启动检查检查了Elasticsearch的配置以及系统的设置并且对于Elasticsearch的安全操作进行了对比。如果ELasticsearch在开发模式中，任何启动检查中的错误都会以警告的方式体现在Elasticsearch的日志中。如果Elasticsearch是在开发模式，任何启动检查的错误都会导致Elasticsearch不会正常启动。

 

There are some bootstrap checks that are always enforced to prevent Elasticsearch from running with incompatible settings. These checks are documented individually.

这列有一些开机检查将强制来避免Elasticsearch运行于错误的设置之中。这些检查项目以独立的文档方式体现如下。

 

Development vs. production mode

开发和生产模式

 

By default, Elasticsearch binds to localhost for HTTP and transport (internal) communication. This is fine for downloading and playing with Elasticsearch, and everyday development but it’s useless for production systems. To form a cluster, Elasticsearch instances must be reachable via transport communication so they must bind transport to an external interface. Thus, we consider an Elasticsearch instance to be in development mode if it does not bind transport to an external interface (the default), and is otherwise in production mode if it does bind transport to an external interface.

默认的，Elasticsearch绑定了本机用于HTTP和内部的通信。这对于下载和使用ELasticsearch是可以的，并且适用于平时的开发但是不适合于生产系统。为了形成集群，Elasticsearch实例必须互相可达因此他们必须绑定到额外的接口上。因此，我们建议Elasticsearch实例可以在开发模式中这样使用就是把那没有绑定传输的额外的接口（默认情况），但是在生产模式下需要绑定外部的接口。

 

Note that HTTP can be configured independently of transport via http.host and transport.host; this can be useful for configuring a single instance to be reachable via HTTP for testing purposes without triggering production mode.

注意HTTP可以被独立配置传输通过http.host和transport.host；他们是有用的用于配置单个可供连接的实例通过HTTP用于测试而不需要启动生产模式。

 

We recognize that some users need to bind transport to an external interface for testing their usage of the transport client. For this situation, we provide the discovery type single-node (configure it by setting discovery.type to single-node); in this situation, a node will elect itself master and will not form a cluster with any other node.

我们建议一些用户需要绑定一个外部接口用于测试的可以使用传输客户端。对于这种情况，我们提供了发现单节点的类型（通过设置discovery.type对于singl-node）；在这种情况下，节点可以选举自己为master并且不会和其他节点形成集群。

 

If you are running a single node in production, it is possible to evade the bootstrap checks (either by not binding transport to an external interface, or by binding transport to an external interface and setting the discovery type to single-node). For this situation, you can force execution of the bootstrap checks by setting the system property es.enforce.bootstrap.checks to true (set this in Setting JVM options, or by adding -Des.enforce.bootstrap.checks=true to the environment variable ES_JAVA_OPTS). We strongly encourage you to do this if you are in this specific situation. This system property can be used to force execution of the bootstrap checks independent of the node configuration.

如果你在生产中运行单个节点，可以规避启动检查（不绑定transport对于一个外部的接口，或绑定transport对于一个外部的接口并且设置discovery类型为single-node）。对于这种情况，你可以关注于启动检查的执行通过设置系统es.enforce.boostrap.checks为true（在设置JVM选项中设置这个参数，或通过添加-Des.enforce.bootstrap.checks=true对于环境变量ES_JAVA_OPTS）。我们强烈建议你这么做如果你在这样的特定环境中时。这个系统属性可以被用于强制节点配置的独立的启动检查。

 

Heap size check

堆大小检查

 

If a JVM is started with unequal initial and max heap size, it can be prone to pauses as the JVM heap is resized during system usage. To avoid these resize pauses, it’s best to start the JVM with the initial heap size equal to the maximum heap size. Additionally, if bootstrap.memory_lock is enabled, the JVM will lock the initial size of the heap on startup. If the initial heap size is not equal to the maximum heap size, after a resize it will not be the case that all of the JVM heap is locked in memory. To pass the heap size check, you must configure the heap size.

如果JVM启动时使用了不规则的初始化和最大的堆大小，他可能会暂停由于JVM堆在系统使用时会重新分配大小。为了避免这种重新分配造成的暂停，最好在启动JVM时指定初始堆大小等于最大的堆大小。此外，如果bootstrap.memory_lock是开启的，JVM将在启动时锁定初始的堆大小。如果初始堆大小不等于最大堆大小，在重新分配后将不会有问题因为JVM堆被锁定在内存中。为了通过堆大小检查，你必须配置堆的大小。

 

File descriptor check

文件描述符检查

 

File descriptors are a Unix construct for tracking open "files". In Unix though, everything is a file. For example, "files" could be a physical file, a virtual file (e.g., /proc/loadavg), or network sockets. Elasticsearch requires lots of file descriptors (e.g., every shard is composed of multiple segments and other files, plus connections to other nodes, etc.). This bootstrap check is enforced on OS X and Linux. To pass the file descriptor check, you might have to configure file descriptors.

文件描述符石Unix用于追踪打开的“文件”。在Unix中，任何事物都是文件。例如，“files”可以是物理文件、一个虚拟文件（例如，/proc/loadavg）或网络套接字。Elasticsearch要求很多的文件描述符（例如，每个分片是多个段的组合和其他文件，包括连接其他节点等等）。这个启动检查在OS X和Linux上是强制的。为了通过文件描述符检查，你必须要配置文件描述符。

 

Memory lock check

内存锁定检查

 

When the JVM does a major garbage collection it touches every page of the heap. If any of those pages are swapped out to disk they will have to be swapped back in to memory. That causes lots of disk thrashing that Elasticsearch would much rather use to service requests. There are several ways to configure a system to disallow swapping. One way is by requesting the JVM to lock the heap in memory through mlockall (Unix) or virtual lock (Windows). This is done via the Elasticsearch setting bootstrap.memory_lock. However, there are cases where this setting can be passed to Elasticsearch but Elasticsearch is not able to lock the heap (e.g., if the elasticsearch user does not have memlock unlimited). The memory lock check verifies that if the bootstrap.memory_lock setting is enabled, that the JVM was successfully able to lock the heap. To pass the memory lock check, you might have to configure mlockall.

JVM的主要垃圾回收重点是处理堆中的每个页。如果任何页被换出DAO磁盘他将必须在被换回内存。这回导致磁盘的负担并且Elasticsearch会使用服务请求。有一些方法来配置系统来避免交换。一种方式是通过请求JVM来锁定内存中的堆通过mlockall（Unix）或虚拟锁（Windows）。这是通过Elasticsearch的设置bootstrap.memory_lock来实现的。然而，但是也可能在传递给Elasticsearch时出现文件由于Elasticsearch不讷讷个锁定堆（例如，如果Elasticsearch的用户没有指定memlock）。内存锁定检查判断bootstrap.memory_lock设置是否是开启的，JVM是可以成功锁定内存的。为了通过内存检查，你必须配置mlockall。

 

Maximum number of threads check

最大线程数目的检查

 

Elasticsearch executes requests by breaking the request down into stages and handing those stages off to different thread pool executors. There are different thread pool executors for a variety of tasks within Elasticsearch. Thus, Elasticsearch needs the ability to create a lot of threads. The maximum number of threads check ensures that the Elasticsearch process has the rights to create enough threads under normal use. This check is enforced only on Linux. If you are on Linux, to pass the maximum number of threads check, you must configure your system to allow the Elasticsearch process the ability to create at least 2048 threads. This can be done via /etc/security/limits.conf using the nproc setting (note that you might have to increase the limits for the root user too).

Elasticsearch执行请求通过将请求分为不同阶段并且处理这些阶段将其分配给不同的线程池来执行。这些不同的线程池在Elasticsearch中用于不同的任务。因此Elasticsearch需要可以创建许多的线程。最大的线程数目的检查保证Elasticsearch有权利创建足够的线程来满足正常的使用。这个检查在Linux上是强制的。如果你是在LInux上运行，为了通过检查，你必须配置系统来允许Elasticsearch可以创建至少2048个线程。可以通过/etc/security/limits.conf使用nproc设置（注意你也可以为root用户提高限制）。

 

Maximum size virtual memory check

最大数目的虚拟内存检查

 

Elasticsearch and Lucene use mmap to great effect to map portions of an index into the Elasticsearch address space. This keeps certain index data off the JVM heap but in memory for blazing fast access. For this to be effective, the Elasticsearch should have unlimited address space. The maximum size virtual memory check enforces that the Elasticsearch process has unlimited address space and is enforced only on Linux. To pass the maximum size virtual memory check, you must configure your system to allow the Elasticsearch process the ability to have unlimited address space. This can be done via /etc/security/limits.conf using the as setting to unlimited (note that you might have to increase the limits for the root user too).

Elasticsearch和Lucene使用mmap用于匹配索引的部分到Elasticsearch的地址空间。这保证索引数据不在堆中但是在内存中用于加速访问。这是有效的，Elasticsearch没有限制地址空间。最大的虚拟内存检查强制了Elasticsearch处理无限制的地址空间并且在Linux上是强制检查的。为了通过检查，你必须设置你的系统允许Elasticsearch可以有权利处理无限制的地址空间。这可以通过/etc/security/limits.conf文件来设置（注意你也可以改变root用户的限制）。

 

Maximum map count check

最大匹配计数检查

 

Continuing from the previous point, to use mmap effectively, Elasticsearch also requires the ability to create many memory-mapped areas. The maximum map count check checks that the kernel allows a process to have at least 262,144 memory-mapped areas and is enforced on Linux only. To pass the maximum map count check, you must configure vm.max_map_count via sysctl to be at least 262144.

继续之前的点，为了使用mmap的功能，Elasticsearch也要求可以创建许多memory-mapped的空间。最大数量的匹配计数检查需要内核允许进程至少262144的memory-mapped的空间并且在Linux上是强制的。为了通过检查，你必须配置vm.max_map_count通过sysctl至少为262144.

 

Client JVM check

客户端JVM检查

 

There are two different JVMs provided by OpenJDK-derived JVMs: the client JVM and the server JVM. These JVMs use different compilers for producing executable machine code from Java bytecode. The client JVM is tuned for startup time and memory footprint while the server JVM is tuned for maximizing performance. The difference in performance between the two VMs can be substantial. The client JVM check ensures that Elasticsearch is not running inside the client JVM. To pass the client JVM check, you must start Elasticsearch with the server VM. On modern systems and operating systems, the server VM is the default. Additionally, Elasticsearch is configured by default to force the server VM.

对于OpenJDK-derived的JVM有两种不同的JVM，客户端JVM和服务器JVM。这些JVM使用不同的策略处理执行机器码对于Java的代码。客户端JVM协调启动时间和内存封装而服务器JVM是倾向于最高的性能。这两个JVM的性能是有很大的区别的。客户端JVM检查保证Elasticsearch不是运行在客户端JVM上。为了通过检查，你必须在服务器JVM上运行。对于当前的系统和操作系统。默认是服务器VM。此外，Elasticsearch被默认配置为强制要求服务器VM。

 

Use serial collector check

使用串行的收集器检查

 

There are various garbage collectors for the OpenJDK-derived JVMs targeting different workloads. The serial collector in particular is best suited for single logical CPU machines or extremely small heaps, neither of which are suitable for running Elasticsearch. Using the serial collector with Elasticsearch can be devastating for performance. The serial collector check ensures that Elasticsearch is not configured to run with the serial collector. To pass the serial collector check, you must not start Elasticsearch with the serial collector (whether it’s from the defaults for the JVM that you’re using, or you’ve explicitly specified it with -XX:+UseSerialGC). Note that the default JVM configuration that ships with Elasticsearch configures Elasticsearch to use the CMS collector.

对于OpenJDK-derived的JVM有不同的垃圾收集器处于不同的工作目的。串行收集器适用于单个本地CPU的情况或是在堆十分小的情况下，并且不适合运行Elasticsearch。使用Elasticsearch配合串行收集器可能导致极差的性能。串行收集器检查允许Elasticsearch不会配置在串行收集器上。为了通过检查，你在启动Elasticsearch之前就不应该使用串行收集器（就是他不送JVM默认使用的收集器，或者你可以明确指定通过使用-XX:+UseSerialGC）。注意默认的JVM配置中配合Elasticsearch的使用配置Elasticsearch使用CMS收集器。

 

System call filter check

系统调用过滤器检查

 

Elasticsearch installs system call filters of various flavors depending on the operating system (e.g., seccomp on Linux). These system call filters are installed to prevent the ability to execute system calls related to forking as a defense mechanism against arbitrary code execution attacks on Elasticsearch The system call filter check ensures that if system call filters are enabled, then they were successfully installed. To pass the system call filter check you must either fix any configuration errors on your system that prevented system call filters from installing (check your logs), or at your own risk disable system call filters by setting bootstrap.system_call_filter to false.

Elasticsearch安装系统调用过滤器出于不同的目的依赖于操作系统（例如，在Linux上是seccomp）。这是系统调用过滤器被安装避免执行系统调用依赖于防卫策略避免在Elasticsearch上执行的代码会产生攻击。系统调用过滤器可以来保证如果系统调用过滤器是开启的并且之前已经被成功安装。为了通过检查你必须修复任何配置错误对于你的系统并且保证系统调用过滤器已经被安装（检查你的日志），或你自己造成的风险关闭系统调用过滤器通过设置bootstrap.system_call_filter为false。

 

OnError and OnOutOfMemoryError checks

错误和内存溢出的检查

 

The JVM options OnError and OnOutOfMemoryError enable executing arbitrary commands if the JVM encounters a fatal error (OnError) or an OutOfMemoryError (OnOutOfMemoryError). However, by default, Elasticsearch system call filters (seccomp) are enabled and these filters prevent forking. Thus, using OnError or OnOutOfMemoryError and system call filters are incompatible. The OnError and OnOutOfMemoryError checks prevent Elasticsearch from starting if either of these JVM options are used and system call filters are enabled. This check is always enforced. To pass this check do not enable OnError nor OnOutOfMemoryError; instead, upgrade to Java 8u92 and use the JVM flag ExitOnOutOfMemoryError. While this does not have the full capabilities of OnError nor OnOutOfMemoryError, arbitrary forking will not be supported with seccomp enabled.

JVM选项OnError和OnOutOfMemoryError允许检查命令如果JVM出现了致命的错误（OnError）或一个OutOfMemoryError (OnOutOfMemoryError)。然而，默认的Elasticsearch系统调用过滤器（seccomp）是允许并且这些过滤器会避免问题。因此使用OnError或OnOutOfMemoryEoor和系统调用是不相容的。OnError和OnOutOfMemoryError检查避免Elasticsearch在启动时由于JVM选项的使用和系统调用过滤器被允许。为了通过检查，作为代替，升级到Java8u92版本并且使用JVM标志ExitOnOutOfMemoryError。这并没有完全避免OnError和OnOutOfMemoryError，任意的forking将不会被seccomp开启时支持。

 

Early-access check

事前的访问检查

 

The OpenJDK project provides early-access snapshots of upcoming releases. These releases are not suitable for production. The early-access check detects these early-access snapshots. To pass this check, you must start Elasticsearch on a release build of the JVM.

OpenJDK项目提供了事先访问检查快照对于后续的发布板。这些发布板不适用于生产环境。事前访问检查探测这些事先访问快照。为了通过检查，你必须使用发布板的JVM来启动Elasticsearch。

 

G1GC check

G1GC检查

 

Early versions of the HotSpot JVM that shipped with JDK 8 are known to have issues that can lead to index corruption when the G1GC collector is enabled. The versions impacted are those earlier than the version of HotSpot that shipped with JDK 8u40. The G1GC check detects these early versions of the HotSpot JVM.

HotSpot的JVM之前的版本使用对于JDK8就是引入了可以进行分区的收集上G1GC被开启的时候。使用了这个功能的最早版本是JDK8u40.G1GC检查探测是否是之前版本的HotSpot的JVM。