配置 Elasticsearch

Elasticsearch 几乎不需要配置即可开始使用，但在将集群用于生产之前，有一些项目必须考虑：

我们的 Elastic Cloud 服务会自动配置这些项目，使您的集群默认情况下即可投入生产。

Elasticsearch 将您索引的数据写入索引和数据流到 data 目录。Elasticsearch 将其自身的应用程序日志（包含有关集群健康状况和操作的信息）写入 logs 目录。

对于macOS .tar.gz、Linux .tar.gz和 Windows .zip安装，data和logs默认是$ES_HOME的子目录。然而，$ES_HOME中的文件在升级过程中有被删除的风险。

在生产环境中，我们强烈建议您在 elasticsearch.yml 中将 path.data 和 path.logs 设置为 $ES_HOME 之外的位置。Docker、Debian 和 RPM 安装默认会将数据和日志写入 $ES_HOME 之外的位置。

支持的 path.data 和 path.logs 值因平台而异：

path:
  data: /var/data/elasticsearch
  logs: /var/log/elasticsearch

path:
  data: "C:\\Elastic\\Elasticsearch\\data"
  logs: "C:\\Elastic\\Elasticsearch\\logs"

如果需要，您可以在 path.data 中指定多个路径。Elasticsearch 将节点数据存储在所有提供的路径中，但会将每个分片的数据保持在同一路径上。

Elasticsearch 不会在节点的数据路径之间平衡分片。单个路径中的高磁盘使用率可能会触发整个节点的 高磁盘使用率水位线。如果触发，Elasticsearch 将不会向该节点添加分片，即使该节点的其他路径有可用磁盘空间。如果需要额外的磁盘空间，我们建议您添加一个新节点，而不是添加额外的数据路径。

path:
  data:
    - /mnt/elasticsearch_1
    - /mnt/elasticsearch_2
    - /mnt/elasticsearch_3

path:
  data:
    - "C:\\Elastic\\Elasticsearch_1"
    - "E:\\Elastic\\Elasticsearch_1"
    - "F:\\Elastic\\Elasticsearch_3"

对多数据路径的支持在7.13版本中已被弃用，并将在未来的版本中移除。

作为多数据路径的替代方案，您可以创建一个跨越多个磁盘的文件系统，使用硬件虚拟化层如RAID，或软件虚拟化层如Linux上的逻辑卷管理器（LVM）或Windows上的存储空间。如果您希望在单个机器上使用多数据路径，则必须为每个数据路径运行一个节点。

如果您目前在高可用性集群中使用多个数据路径，那么您可以通过类似于滚动重启的过程，迁移到每个节点使用单一路径的设置，而无需停机：依次关闭每个节点，并将其替换为一个或多个配置为使用单一路径的节点。更详细地说，对于当前具有多个数据路径的每个节点，您应遵循以下过程。原则上，您可以在滚动升级到8.0期间执行此迁移，但我们建议在开始升级之前迁移到单数据路径设置。

您可以选择向集群中添加一些单数据路径节点，使用分配过滤器将所有数据迁移到这些新节点上，然后从集群中移除旧节点。这种方法会暂时使集群的大小翻倍，因此只有在您有能力以这种方式扩展集群时才能使用。

如果您目前使用多个数据路径，但您的集群不是高可用的，那么您可以通过创建快照、使用所需配置创建新集群并将快照恢复到其中来迁移到非弃用配置。

一个节点只有在与其他集群中的所有节点共享其cluster.name时才能加入集群。默认名称是elasticsearch，但您应该将其更改为一个适当的名称，以描述集群的用途。

cluster.name: logging-prod

Elasticsearch 使用 node.name 作为特定 Elasticsearch 实例的人类可读标识符。此名称包含在许多 API 的响应中。节点名称在 Elasticsearch 启动时默认为机器的主机名，但可以在 elasticsearch.yml 中显式配置：

node.name: prod-data-2

默认情况下，Elasticsearch 仅绑定到环回地址，例如 127.0.0.1 和 [::1]。这对于在一台服务器上运行一个或多个节点的集群进行开发和测试是足够的，但一个 高可用的生产集群 必须涉及 其他服务器上的节点。有许多 网络设置，但 通常您只需要配置 network.host：

network.host: 192.168.1.10

在进入生产环境之前，配置两个重要的发现和集群形成设置，以便集群中的节点能够相互发现并选举出一个主节点。

开箱即用，无需任何网络配置，Elasticsearch 将绑定到可用的环回地址，并扫描本地端口 9300 到 9305 以连接到在同一服务器上运行的其他节点。此行为提供了无需任何配置的自动集群体验。

当您想在其他主机上的节点上形成集群时，请使用静态 discovery.seed_hosts 设置。此设置提供集群中其他节点的列表，这些节点有资格成为主节点，并且可能处于活动状态并可联系，以启动发现过程。此设置接受 YAML 序列或集群中所有有资格成为主节点的节点的地址数组。每个地址可以是 IP 地址或通过 DNS 解析为一个或多个 IP 地址的主机名。

discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11 
   - seeds.mydomain.com 
   - [0:0:0:0:0:ffff:c0a8:10c]:9301 

如果你的主节点候选节点没有固定的名称或地址，请使用 替代主机提供者 来动态查找它们的地址。

当你第一次启动Elasticsearch集群时，一个 集群引导步骤 决定了在第一次选举中计票的主节点集合。在开发模式下，没有配置发现设置，这一步骤由节点自身自动执行。

因为自动引导是固有的不安全， 在生产模式下启动新集群时，您必须明确列出在第一次选举中应计票的主节点。 您可以在每个主节点上使用cluster.initial_master_nodes设置来设置此列表。不要在非主节点上配置此设置。

discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11
   - seeds.mydomain.com
   - [0:0:0:0:0:ffff:c0a8:10c]:9301
cluster.initial_master_nodes: 
   - master-node-a
   - master-node-b
   - master-node-c

参见引导集群和 发现和集群形成设置。

默认情况下，Elasticsearch 会根据节点的 角色 和总内存自动设置 JVM 堆大小。 我们建议大多数生产环境使用默认大小。

如果需要，您可以通过手动设置JVM堆大小来覆盖默认大小。

默认情况下，Elasticsearch 配置 JVM 在内存不足异常时将堆转储到默认数据目录。在 RPM 和 Debian 软件包中，数据目录是 /var/lib/elasticsearch。在 Linux 和 MacOS 以及 Windows 发行版中， data 目录位于 Elasticsearch 安装的根目录下。

如果此路径不适合接收堆转储，请修改jvm.options文件中的-XX:HeapDumpPath=...条目：

默认情况下，Elasticsearch 启用垃圾回收（GC）日志。这些日志在 jvm.options 中配置，并输出到与 Elasticsearch 日志相同的默认位置。默认配置每 64 MB 轮换一次日志，最多可占用 2 GB 的磁盘空间。

您可以使用JEP 158: Unified JVM Logging中描述的命令行选项重新配置JVM日志记录。除非您直接更改默认的jvm.options文件，否则Elasticsearch的默认配置将应用于您的自定义设置。要禁用默认配置，首先通过提供-Xlog:disable选项来禁用日志记录，然后提供您自己的命令行选项。这将禁用所有JVM日志记录，因此请务必查看可用选项并启用您所需的所有内容。

要查看原始 JEP 中未包含的更多选项，请参阅 使用 JVM 统一日志框架启用日志记录。

将默认的GC日志输出位置更改为/opt/my-app/gc.log，通过创建$ES_HOME/config/jvm.options.d/gc.options并添加一些示例选项：

# Turn off all previous logging configuratons
-Xlog:disable

# Default settings from JEP 158, but with `utctime` instead of `uptime` to match the next line
-Xlog:all=warning:stderr:utctime,level,tags

# Enable GC logging to a custom location with a variety of options
-Xlog:gc*,gc+age=trace,safepoint:file=/opt/my-app/gc.log:utctime,level,pid,tags:filecount=32,filesize=64m

配置一个Elasticsearch Docker容器以将GC调试日志发送到标准错误（stderr）。这使得容器编排器可以处理输出。如果使用ES_JAVA_OPTS环境变量，请指定：

MY_OPTS="-Xlog:disable -Xlog:all=warning:stderr:utctime,level,tags -Xlog:gc=debug:stderr:utctime"
docker run -e ES_JAVA_OPTS="$MY_OPTS" # etc

默认情况下，Elasticsearch 使用一个私有临时目录，该目录由启动脚本在系统临时目录下立即创建。

在某些Linux发行版上，系统实用程序会在文件和目录长时间未被访问时从/tmp中清理它们。如果长时间不使用需要临时目录的功能，这种行为可能会导致Elasticsearch运行时私有临时目录被删除。如果随后使用需要此目录的功能，删除私有临时目录会导致问题。

如果您使用 .deb 或 .rpm 包安装 Elasticsearch 并在 systemd 下运行它，Elasticsearch 使用的私有临时目录将不会被定期清理。

如果您打算在 Linux 或 MacOS 上长时间运行 .tar.gz 发行版，请考虑为 Elasticsearch 创建一个专用的临时目录，该目录不在会清理旧文件和目录的路径下。此目录应设置权限，以便只有运行 Elasticsearch 的用户可以访问它。然后，在启动 Elasticsearch 之前，将 $ES_TMPDIR 环境变量设置为指向此目录。

默认情况下，Elasticsearch 配置 JVM 将致命错误日志写入默认日志目录。在 RPM 和 Debian 包中，此目录为 /var/log/elasticsearch。在 Linux 和 MacOS 以及 Windows 发行版中，logs 目录位于 Elasticsearch 安装的根目录下。

这些是JVM遇到致命错误（如段错误）时产生的日志。如果此路径不适合接收日志，请修改jvm.options文件中的-XX:ErrorFile=...条目。

在灾难中，快照可以防止永久性数据丢失。 快照生命周期管理是定期备份集群的最简单方法。更多信息，请参阅创建快照。

某些设置是敏感的，仅依赖文件系统权限来保护其值是不够的。为此，Elasticsearch 提供了一个密钥库和 elasticsearch-keystore 工具来管理密钥库中的设置。

对密钥库的所有修改只有在重新启动 Elasticsearch 后才会生效。

这些设置，就像在 elasticsearch.yml 配置文件中的常规设置一样，需要在集群中的每个节点上指定。目前，所有安全设置都是特定于节点的设置，必须在每个节点上具有相同的值。

就像在 elasticsearch.yml 中的设置值一样，对密钥库内容的更改不会自动应用到正在运行的 Elasticsearch 节点。重新读取设置需要重新启动节点。然而，某些安全设置被标记为 可重新加载。这些设置可以在运行的节点上重新读取并应用。

您可以在节点启动之前定义这些设置， 或者在定义设置后调用节点重新加载安全设置API 以将它们应用于正在运行的节点。

所有安全设置的值，无论是可重新加载的还是不可重新加载的，在所有集群节点上必须相同。在进行所需的安全设置更改后，使用bin/elasticsearch-keystore add命令，调用：

POST _nodes/reload_secure_settings
{
  "secure_settings_password": "keystore-password" 
}

此API解密、重新读取整个密钥库并在每个集群节点上验证所有设置，但仅应用可重新加载的安全设置。其他设置的更改在下次重启之前不会生效。一旦调用返回，重新加载已完成，这意味着所有依赖于这些设置的内部数据结构都已更改。一切看起来都应该像是从一开始就具有新值一样。

在更改多个可重新加载的安全设置时，请在每个集群节点上修改所有设置，然后发出reload_secure_settings调用，而不是在每次修改后重新加载。

有可重新加载的安全设置，包括：

Elasticsearch 包含多个断路器，用于防止操作导致 OutOfMemoryError。每个断路器指定它可以使用的内存限制。此外，还有一个父级断路器，用于指定所有断路器可以使用的总内存量。

除非另有说明，否则可以使用集群更新设置 API 在实时集群上动态更新这些设置。

有关断路器错误的信息，请参阅断路器错误。

父级断路器可以通过以下设置进行配置：

字段数据断路器估计将字段加载到字段数据缓存所需的堆内存。如果加载该字段会导致缓存超过预定义的内存限制，断路器将停止操作并返回错误。

请求断路器允许Elasticsearch防止每个请求的数据结构（例如，用于计算请求期间聚合的内存）超过一定量的内存。

飞行中的请求断路器允许Elasticsearch限制在传输或HTTP级别上所有当前活动的传入请求的内存使用量，使其不超过节点上的特定内存量。内存使用量基于请求本身的内容长度。此断路器还考虑到，内存不仅需要用于表示原始请求，还需要用于表示结构化对象，这反映在默认的开销中。

与之前的基于内存的断路器略有不同，脚本编译断路器限制了在一段时间内内联脚本编译的数量。

有关更多信息，请参阅脚本文档中的“prefer-parameters”部分。

如果集群经常达到给定的 max_compilation_rate，可能是脚本缓存过小，使用 Nodes Stats 检查最近的缓存驱逐数量，script.cache_evictions_history 和编译次数 script.compilations_history。如果最近有大量的缓存驱逐或编译，脚本缓存可能过小，考虑通过设置 script.cache.max_size 来加倍脚本缓存的大小。

编写不当的正则表达式可能会降低集群的稳定性和性能。正则表达式断路器限制了Painless脚本中正则表达式的使用和复杂性。

当执行一个序列查询时，处理该查询的节点需要在内存中保留一些结构，这些结构是实现序列匹配算法所必需的。当需要处理大量数据和/或用户通过设置size查询参数请求大量匹配序列时，这些结构占用的内存可能会超过JVM的可用内存。这会导致OutOfMemory异常，从而使节点崩溃。

为了防止这种情况发生，使用了特殊的断路器， 它在执行序列 查询时限制内存分配。当断路器被触发时，会抛出org.elasticsearch.common.breaker.CircuitBreakingException 并返回一个包含circuit_breaking_exception 的描述性错误消息给用户。

这个 circuit breaker 可以使用以下设置进行配置：

分片分配是将分片副本分配给节点的过程。这可能发生在初始恢复、副本分配、重新平衡、当节点被添加到集群或从集群中移除时，或者当影响分配的集群或索引设置被更新时。

主节点的主要职责之一是决定将哪些分片分配给哪些节点，以及何时在节点之间移动分片以重新平衡集群。

有许多设置可用于控制分片分配过程：

除了这些，还有一些其他的杂项集群级设置。

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disk.watermark.low": "100gb",
    "cluster.routing.allocation.disk.watermark.high": "50gb",
    "cluster.routing.allocation.disk.watermark.flood_stage": "10gb",
    "cluster.info.update.interval": "1m"
  }
}

分片分配感知

edit

您可以使用自定义节点属性作为感知属性，以使Elasticsearch在分配分片时考虑您的物理硬件配置。如果Elasticsearch知道哪些节点位于同一物理服务器、同一机架或同一区域，它可以将主分片及其副本分片分布开来，以最大限度地降低在发生故障时丢失所有分片副本的风险。

当启用分片分配感知时，使用动态 cluster.routing.allocation.awareness.attributes设置，分片只会被分配到设置了指定感知属性的节点上。 如果你使用多个感知属性，Elasticsearch在分配分片时会分别考虑每个属性。

属性值的数量决定了在每个位置分配的分片副本数量。如果每个位置的节点数量不平衡且存在大量副本，副本分片可能会保持未分配状态。

了解更多关于设计弹性集群的信息。

启用分片分配感知

edit

要启用分片分配感知：

1. 使用自定义节点属性指定每个节点的位置。例如，如果您希望 Elasticsearch 在不同的机架之间分配分片，您可能会使用一个名为 rack_id 的感知属性。

   你可以通过两种方式设置自定义属性：

   • 通过编辑 elasticsearch.yml 配置文件：

     node.attr.rack_id: rack_one

   • 在启动节点时使用-E命令行参数：

     ./bin/elasticsearch -Enode.attr.rack_id=rack_one

2. 在每个符合主节点资格的节点的 elasticsearch.yml 配置文件中设置 cluster.routing.allocation.awareness.attributes，以告知 Elasticsearch 在分配分片时考虑一个或多个感知属性。

   cluster.routing.allocation.awareness.attributes: rack_id 

   将多个属性指定为逗号分隔的列表。

   您还可以使用 cluster-update-settings API 来设置或更新 集群的感知属性：

   PUT /_cluster/settings
   {
     "persistent" : {
       "cluster.routing.allocation.awareness.attributes" : "rack_id"
     }
   }

使用此示例配置，如果您启动两个节点并将node.attr.rack_id设置为rack_one，并创建一个包含5个主分片和每个主分片的1个副本的索引，所有主分片和副本将分配在这两个节点之间。

Figure 1. All primaries and replicas allocated across two nodes in the same rack

如果你添加两个节点并将node.attr.rack_id设置为rack_two， Elasticsearch会将分片移动到新节点，确保（如果可能） 同一分片的两个副本不在同一个机架中。

Figure 2. Primaries and replicas allocated across four nodes in two racks, with no two copies of the same shard in the same rack

如果 rack_two 失败并导致其两个节点都宕机，默认情况下 Elasticsearch 会将丢失的分片副本分配到 rack_one 中的节点。为了防止特定分片的多个副本被分配到同一位置，您可以启用强制感知。

强制意识

edit

默认情况下，如果一个位置失败，Elasticsearch 会将分片分散到剩余的位置。如果集群在缺少一个位置时没有足够的资源来托管所有分片，这可能是不希望的。

为了防止在发生整个位置故障时剩余位置过载，请指定应与cluster.routing.allocation.awareness.force.*设置一起存在的属性值。这意味着Elasticsearch将倾向于在发生整个位置故障时保持一些副本未分配，而不是使剩余位置中的节点过载。

例如，如果你有一个名为 zone 的感知属性，并在 zone1 和 zone2 中配置节点，你可以使用强制感知来使 Elasticsearch 在只有一个区域可用时，保留一半的分片副本未分配：

cluster.routing.allocation.awareness.attributes: zone
cluster.routing.allocation.awareness.force.zone.values: zone1,zone2 

指定所有可能的zone属性值。

使用此示例配置，如果您有两个节点，其 node.attr.zone 设置为 zone1，并且一个索引的 number_of_replicas 设置为 1，Elasticsearch 将分配所有主分片，但不分配副本分片。一旦具有不同 node.attr.zone 值的节点加入集群，它将分配副本分片。相比之下，如果您不配置强制感知，Elasticsearch 会将所有主分片和副本分片分配给这两个节点，即使它们位于同一区域。

PUT _cluster/settings
{
  "persistent" : {
    "cluster.routing.allocation.exclude._ip" : "10.0.0.1"
  }
}

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.exclude._ip": "192.168.2.*"
  }
}

可以将整个集群设置为只读模式，使用以下设置：

集群中的分片数量是有限制的，这个限制基于集群中的节点数量。这是为了防止失控的进程创建过多的分片，这可能会损害性能，并且在极端情况下可能会使您的集群不稳定。

如果一个操作，例如创建新索引、恢复索引的快照或打开已关闭的索引，会导致集群中的分片数量超过此限制，则该操作将失败并显示错误，指示分片限制。要解决此问题，可以通过添加节点来扩展集群，或者删除一些索引以使分片数量低于限制。

如果集群已经超过限制，可能由于节点成员变化或设置更改，所有创建或打开索引的操作都将失败。

集群分片限制默认情况下，对于普通（非冻结）索引，每个非冻结数据节点为1000个分片，对于冻结索引，每个冻结数据节点为3000个分片。所有打开索引的主分片和副本分片都计入此限制，包括未分配的分片。例如，一个具有5个主分片和2个副本的打开索引计为15个分片。关闭的索引不计入分片计数。

您可以使用以下设置动态调整集群分片限制：

用户定义的元数据可以使用集群设置 API 进行存储和检索。这可以用于存储关于集群的任意、不常变化的数据，而无需创建索引来存储它。这些数据可以使用任何以 cluster.metadata. 为前缀的键进行存储。例如，要将集群管理员的电子邮件地址存储在键 cluster.metadata.administrator 下，请发出此请求：

PUT /_cluster/settings
{
  "persistent": {
    "cluster.metadata.administrator": "sysadmin@example.com"
  }
}

集群状态维护索引墓碑，以明确表示已删除的索引。集群状态中维护的墓碑数量由以下设置控制：

如果 Elasticsearch 遇到当前集群状态中不存在的索引数据，这些索引将被视为悬空索引。例如，如果你在 Elasticsearch 节点离线时删除了超过 cluster.indices.tombstones.size 个索引，就可能发生这种情况。

您可以使用悬空索引 API来管理这种情况。

控制日志记录的设置可以通过动态更新，使用logger.前缀。例如，要将indices.recovery模块的日志级别提高到DEBUG，请发出此请求：

PUT /_cluster/settings
{
  "persistent": {
    "logger.org.elasticsearch.indices.recovery": "DEBUG"
  }
}

插件可以创建一种称为持久任务的任务。这些任务通常是长时间运行的任务，并且存储在集群状态中，允许在集群完全重启后恢复任务。

每次创建持久任务时，主节点负责将任务分配给集群中的一个节点，然后被分配的节点将接管任务并在本地执行。分配持久任务给节点的过程由以下设置控制：

发现与集群形成受以下设置影响：

发现和集群形成也会受到以下专家级设置的影响，尽管不建议将这些设置从默认值更改。

字段数据缓存包含字段数据和全局序号， 这两者都用于支持对某些字段类型的聚合。 由于这些是堆上数据结构，因此监控缓存的使用情况非常重要。

缓存中的条目构建成本高昂，因此默认行为是将缓存保留在内存中。默认缓存大小是无限的，导致缓存增长直到达到由字段数据断路器设置的限制。此行为可以进行配置。

如果设置了缓存大小限制，缓存将开始清除最近更新最少的条目。此设置可以自动避免断路器限制，但代价是根据需要重建缓存。

如果达到了断路器限制，进一步增加缓存大小的请求将被阻止。在这种情况下，您应该手动清除缓存。

您可以使用节点统计API或cat fielddata API来监控字段数据的内存使用情况以及字段数据断路器。

以下是用于配置内部诊断服务的专家级设置。 该服务的输出目前通过健康API Health API 暴露。不建议将这些设置从默认值更改。

您可以使用以下集群设置来启用或禁用索引管理功能。

对等恢复将数据从主分片同步到一个新的或现有的分片副本。

当 Elasticsearch 发生以下情况时，节点恢复会自动进行：

您可以使用cat recovery API查看正在进行和已完成恢复的列表。

您可以使用以下专家设置来管理对等恢复的资源。

当将 Elasticsearch 作为托管服务运行时，以下设置允许服务为每个节点的磁盘读取、磁盘写入和网络流量指定绝对最大带宽，并允许您根据这些绝对最大值控制每个节点的最大恢复带宽。它们有两个效果：

如果您没有设置 indices.recovery.max_bytes_per_sec，那么最大恢复带宽将根据绝对最大带宽的比例来计算。该计算分别针对读取和写入流量进行。服务使用 node.bandwidth.recovery.disk.read、node.bandwidth.recovery.disk.write 和 node.bandwidth.recovery.network 分别定义磁盘读取、磁盘写入和网络传输的绝对最大带宽，您可以通过调整 node.bandwidth.recovery.factor.read 和 node.bandwidth.recovery.factor.write 来设置用于恢复的绝对最大带宽的比例。如果启用了操作员权限功能，则服务还可以使用这些设置的操作员专用变体来设置默认比例。

如果你设置了indices.recovery.max_bytes_per_sec，那么Elasticsearch将使用它的值作为最大恢复带宽，只要这不超过节点范围的限制。Elasticsearch通过将绝对最大带宽乘以node.bandwidth.recovery.operator.factor.max_overcommit因子来计算节点范围的限制。如果你设置的indices.recovery.max_bytes_per_sec超过了节点范围的限制，那么节点范围的限制将优先。

该服务应通过实验确定绝对最大带宽设置的值，使用类似于恢复的工作负载，其中多个并发工作线程分别按顺序处理512kiB大小的文件块。

索引缓冲区用于存储新索引的文档。当它填满时，缓冲区中的文档会被写入磁盘上的一个段。它在该节点上的所有分片之间分配。

以下设置是静态的，必须在集群中的每个数据节点上进行配置：

本地网关在集群完全重启时存储集群状态和分片数据。

以下静态设置必须在每个主节点上设置，控制新当选的主节点在尝试恢复集群状态和集群数据之前应等待多长时间。

这些设置可以在 elasticsearch.yml 中如下配置：

gateway.expected_data_nodes: 3
gateway.recover_after_time: 600s
gateway.recover_after_data_nodes: 3

您可以使用 Elasticsearch 的应用程序日志来监控您的集群并诊断问题。 如果您将 Elasticsearch 作为服务运行，日志的默认位置会根据您的平台和安装方法而有所不同：

如果你从命令行运行 Elasticsearch，Elasticsearch 会将日志打印到标准输出（stdout）。

Elasticsearch 使用 Log4j 2 进行日志记录。Log4j 2 可以通过 log4j2.properties 文件进行配置。Elasticsearch 暴露了三个属性，${sys:es.logs.base_path}、${sys:es.logs.cluster_name} 和 ${sys:es.logs.node_name}，这些属性可以在配置文件中引用以确定日志文件的位置。属性 ${sys:es.logs.base_path} 将解析为日志目录，${sys:es.logs.cluster_name} 将解析为集群名称（在默认配置中用作日志文件名的前缀），而 ${sys:es.logs.node_name} 将解析为节点名称（如果节点名称已明确设置）。

例如，如果你的日志目录（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。

######## Server JSON ############################
appender.rolling.type = RollingFile 
appender.rolling.name = rolling
appender.rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_server.json 
appender.rolling.layout.type = ECSJsonLayout 
appender.rolling.layout.dataset = elasticsearch.server 
appender.rolling.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}-%d{yyyy-MM-dd}-%i.json.gz 
appender.rolling.policies.type = Policies
appender.rolling.policies.time.type = TimeBasedTriggeringPolicy 
appender.rolling.policies.time.interval = 1 
appender.rolling.policies.time.modulate = true 
appender.rolling.policies.size.type = SizeBasedTriggeringPolicy 
appender.rolling.policies.size.size = 256MB 
appender.rolling.strategy.type = DefaultRolloverStrategy
appender.rolling.strategy.fileIndex = nomax
appender.rolling.strategy.action.type = Delete 
appender.rolling.strategy.action.basepath = ${sys:es.logs.base_path}
appender.rolling.strategy.action.condition.type = IfFileName 
appender.rolling.strategy.action.condition.glob = ${sys:es.logs.cluster_name}-* 
appender.rolling.strategy.action.condition.nested_condition.type = IfAccumulatedFileSize 
appender.rolling.strategy.action.condition.nested_condition.exceeds = 2GB 
################################################

######## Server -  old style pattern ###########
appender.rolling_old.type = RollingFile
appender.rolling_old.name = rolling_old
appender.rolling_old.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_server.log 
appender.rolling_old.layout.type = PatternLayout
appender.rolling_old.layout.pattern = [%d{ISO8601}][%-5p][%-25c{1.}] [%node_name]%marker %m%n
appender.rolling_old.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}-%d{yyyy-MM-dd}-%i.old_log.gz

请注意，您可以在appender.rolling.filePattern中将.gz替换为.zip，以使用zip格式压缩滚动日志。如果您移除.gz扩展名，则日志在滚动时将不会被压缩。

如果您希望保留日志文件指定的时间，可以使用带有删除操作的滚动策略。

appender.rolling.strategy.type = DefaultRolloverStrategy 
appender.rolling.strategy.action.type = Delete 
appender.rolling.strategy.action.basepath = ${sys:es.logs.base_path} 
appender.rolling.strategy.action.condition.type = IfFileName 
appender.rolling.strategy.action.condition.glob = ${sys:es.logs.cluster_name}-* 
appender.rolling.strategy.action.condition.nested_condition.type = IfLastModified 
appender.rolling.strategy.action.condition.nested_condition.age = 7D 

可以加载多个配置文件（在这种情况下它们将被合并），只要它们命名为log4j2.properties并且具有Elasticsearch配置目录作为祖先；这对于公开额外日志记录器的插件很有用。日志记录器部分包含Java包及其对应的日志级别。appender部分包含日志的输出目标。关于如何自定义日志记录以及所有支持的appender的详细信息，可以在Log4j文档中找到。

Log4J 2 日志消息包括一个 级别 字段，它是以下之一（按详细程度递增的顺序）：

默认情况下，Elasticsearch 在其日志中包含所有级别的 INFO、WARN、ERROR 和 FATAL 的消息，但过滤掉 DEBUG 和 TRACE 级别的消息。 这是推荐的配置。不要过滤掉 INFO 或更高日志级别的消息，否则您可能无法理解集群的行为或解决常见问题。除非您是按照本手册中其他地方的指示要求更详细的日志记录，或者您是专家用户，将会阅读 Elasticsearch 源代码以确定日志的含义，否则不要启用 DEBUG 或 TRACE 级别的日志记录。

消息由与 Elasticsearch 源代码中的 Java 包和类层次结构相匹配的日志记录器层次结构记录。每个日志记录器都有一个相应的 动态设置，可用于控制其日志的详细程度。设置的名称是包或类的完全限定名称，前缀为 logger.。

您可以将每个记录器的详细程度设置为日志级别的名称，例如 DEBUG，这意味着来自该记录器的级别直到指定级别的消息都将包含在日志中。您也可以使用值 OFF 来 抑制该记录器的所有消息。

例如，org.elasticsearch.discovery 包包含与发现过程相关的功能，您可以通过 logger.org.elasticsearch.discovery 设置来控制其日志的详细程度。要为此包启用 DEBUG 日志记录，请使用集群更新设置 API 如下：

PUT /_cluster/settings
{
  "persistent": {
    "logger.org.elasticsearch.discovery": "DEBUG"
  }
}

要将此包的日志详细程度重置为其默认级别，请将日志记录设置设置为 null：

PUT /_cluster/settings
{
  "persistent": {
    "logger.org.elasticsearch.discovery": null
  }
}

其他更改日志级别的方法包括：

Elasticsearch 还会将弃用日志写入日志目录。这些日志会在您使用已弃用的 Elasticsearch 功能时记录一条消息。您可以使用弃用日志在升级 Elasticsearch 到新主要版本之前更新您的应用程序。

默认情况下，Elasticsearch 在 1GB 时滚动并压缩弃用日志。默认配置最多保留五个日志文件：四个滚动日志和一个活动日志。

Elasticsearch 在 CRITICAL 级别发出弃用日志消息。这些消息表明使用的弃用功能将在下一个主要版本中被移除。WARN 级别的弃用日志消息表示使用了不太重要的功能，它不会在下一个主要版本中被移除，但可能会在未来被移除。

要停止写入弃用日志消息，请在 log4j2.properties 中将 logger.deprecation.level 设置为 OFF：

logger.deprecation.level = OFF

或者，您可以动态更改日志记录级别：

PUT /_cluster/settings
{
  "persistent": {
    "logger.org.elasticsearch.deprecation": "OFF"
  }
}

请参阅配置日志级别。

如果使用了 X-Opaque-Id 作为 HTTP 头，您可以识别是什么触发了已弃用的功能。 用户 ID 包含在弃用 JSON 日志的 X-Opaque-Id 字段中。

{
  "type": "deprecation",
  "timestamp": "2019-08-30T12:07:07,126+02:00",
  "level": "WARN",
  "component": "o.e.d.r.a.a.i.RestCreateIndexAction",
  "cluster.name": "distribution_run",
  "node.name": "node-0",
  "message": "[types removal] Using include_type_name in create index requests is deprecated. The parameter will be removed in the next major version.",
  "x-opaque-id": "MY_USER_ID",
  "cluster.uuid": "Aq-c-PAeQiK3tfBYtig9Bw",
  "node.id": "D7fUYfnfTLa2D7y-xw6tZg"
}

弃用日志可以被索引到 .logs-deprecation.elasticsearch-default 数据流中， cluster.deprecation_indexing.enabled 设置为 true。

appender.rolling.layout.type = ECSJsonLayout
appender.rolling.layout.dataset = elasticsearch.server

appender.rolling.type = RollingFile
appender.rolling.name = rolling
appender.rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_server.log
appender.rolling.layout.type = PatternLayout
appender.rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c{1.}] [%node_name]%marker %.-10000m%n
appender.rolling.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}-%d{yyyy-MM-dd}-%i.log.gz

任何时候你启动一个Elasticsearch实例，你都是在启动一个节点。一个由连接的节点组成的集合被称为一个集群。如果你运行的是单个Elasticsearch节点，那么你有一个单节点的集群。

集群中的每个节点默认都可以处理HTTP和传输流量。传输层专门用于节点之间的通信；HTTP层由REST客户端使用。

所有节点都知道集群中所有其他节点的信息，并且可以将客户端请求转发到适当的节点。

node.roles: [ master ]

node.roles: [ data, master, voting_only ]

node.roles: [ master, voting_only ]

node.roles: [ data ]

node.roles: [ data_content ]

node.roles: [ data_hot ]

node.roles: [ data_warm ]

node.roles: [ data_cold ]

node.roles: [ data_frozen ]

node.roles: [ ingest ]

node.roles: [ ]

node.roles: [ remote_cluster_client ]

node.roles: [ ml, remote_cluster_client]

node.roles: [ transform, remote_cluster_client ]

path.data:  /var/elasticsearch/data

./bin/elasticsearch -Epath.data=/var/elasticsearch/data

每个Elasticsearch节点都有两种不同的网络接口。客户端通过其HTTP接口发送请求到Elasticsearch的REST API，但节点之间使用传输接口进行通信。传输接口也用于与远程集群的通信。传输接口使用通过长时TCP通道发送的自定义二进制协议。这两个接口都可以配置为使用TLS进行安全通信。

您可以使用network.*设置同时配置这两个接口。如果您有一个更复杂的网络，您可能需要使用http.*和transport.*设置独立配置接口。在可能的情况下，使用适用于两个接口的network.*设置来简化您的配置并减少重复。

默认情况下，Elasticsearch仅绑定到localhost，这意味着它无法远程访问。此配置对于在同一主机上运行的单节点或多节点本地开发集群是足够的。要跨多个主机形成集群，或者使集群可被远程客户端访问，您必须调整一些网络设置，例如network.host。

将Elasticsearch配置为绑定到非本地地址将把一些警告转换为致命异常。如果在配置其网络设置后节点拒绝启动，则必须在继续之前解决记录的异常。

transport.profiles.default.port: 9300-9400
transport.profiles.default.bind_host: 10.0.0.1
transport.profiles.client.port: 9500-9600
transport.profiles.client.bind_host: 192.168.0.1
transport.profiles.dmz.port: 9700-9800
transport.profiles.dmz.bind_host: 172.16.1.2

PUT _cluster/settings
{
   "persistent" : {
      "logger.org.elasticsearch.http.HttpTracer" : "TRACE"
   }
}

PUT _cluster/settings
{
   "persistent" : {
      "http.tracer.include" : "*",
      "http.tracer.exclude" : ""
   }
}

PUT _cluster/settings
{
   "persistent" : {
      "logger.org.elasticsearch.http.HttpTracer" : "TRACE",
      "logger.org.elasticsearch.http.HttpBodyTracer" : "TRACE"
   }
}

[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body [part 1]: H4sIAAAAAAAA/9...
[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body [part 2]: 2oJ93QyYLWWhcD...
[TRACE][o.e.h.HttpBodyTracer     ] [master] [276] response body (gzip compressed, base64-encoded, and split into 2 parts on preceding log lines)

cat httptrace.log | sed -e 's/.*://' | base64 --decode | gzip --decompress

PUT _cluster/settings
{
   "persistent" : {
      "logger.org.elasticsearch.transport.TransportService.tracer" : "TRACE"
   }
}

PUT _cluster/settings
{
   "persistent" : {
      "transport.tracer.include" : "*",
      "transport.tracer.exclude" : "internal:coordination/fault_detection/*"
   }
}

"elasticsearch[instance-0000000004][transport_worker][T#1]" #32 daemon prio=5 os_prio=0 cpu=9645.94ms elapsed=501.63s tid=0x00007fb83b6307f0 nid=0x1c4 runnable  [0x00007fb7b8ffe000]
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.EPoll.wait(java.base@17.0.2/Native Method)
	at sun.nio.ch.EPollSelectorImpl.doSelect(java.base@17.0.2/EPollSelectorImpl.java:118)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@17.0.2/SelectorImpl.java:129)
	- locked <0x00000000c443c518> (a sun.nio.ch.Util$2)
	- locked <0x00000000c38f7700> (a sun.nio.ch.EPollSelectorImpl)
	at sun.nio.ch.SelectorImpl.select(java.base@17.0.2/SelectorImpl.java:146)
	at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at java.lang.Thread.run(java.base@17.0.2/Thread.java:833)

   0.0% [cpu=0.0%, idle=100.0%] (500ms out of 500ms) cpu usage by thread 'elasticsearch[instance-0000000004][transport_worker][T#1]'
     10/10 snapshots sharing following 9 elements
       java.base@17.0.2/sun.nio.ch.EPoll.wait(Native Method)
       java.base@17.0.2/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:118)
       java.base@17.0.2/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:129)
       java.base@17.0.2/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:146)
       io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
       io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
       io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
       io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
       java.base@17.0.2/java.lang.Thread.run(Thread.java:833)

在过滤器上下文中使用的查询结果会被缓存在节点查询缓存中，以便快速查找。每个节点都有一个查询缓存，由所有分片共享。缓存使用LRU（最近最少使用）逐出策略：当缓存满时，最近最少使用的查询结果会被逐出，以便为新数据腾出空间。您无法检查查询缓存的内容。

术语查询和在过滤器上下文之外使用的查询不符合缓存条件。

默认情况下，缓存最多保存10000个查询，占用总堆空间的最多10%。为了确定查询是否有资格进行缓存，Elasticsearch维护了一个查询历史记录来跟踪查询的出现情况。

如果一个段落包含至少10000个文档，并且该段落至少占分片总文档数的3%，则按段落进行缓存。由于缓存是按段落进行的，合并段落可能会使缓存的查询失效。

以下设置是静态的，必须在集群中的每个数据节点上进行配置：

以下专家设置可以设置为管理全局搜索和聚合限制。