2-2-1 零基础入门ElasticSearch——重要的配置

 Elasticsearch路径配置主要包括以下两个；通常这两个路径都在$ES_HOME环境变量下，但是$ES_HOME在升级时有被删除的风险，因此在生产环境一定要将其配置到其他目录下。

1. data：存放索引和数据流的文件夹
2. logs：存放记录集群健康情况和操作的日志文件

接下来，将讲解一下这两个路径的配置方式（在不同的操作系统下，路径分隔符会不一样，这里只以windows操作系统为例）。

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

        一个节点可以在 path.data 下配置多个路径，如下所示；当配置多个路径后，es节点会将数据存在多个路径下（保证一个分片的数据存在一个路径下，且不保证均衡）；

        多路径配置存在一些问题，如多个路径中任何一个路径达到高硬盘使用水位线，当前节点都不会再被分配分片，即时其他的路径下还有足够的空间。因此在7.13版本下，多路径配置就已经是过时的配置，而且在更高的版本中，会被移除。

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

        可以使用到硬件虚拟化层实现将多个路径虚拟化成一个路径，实现多路径配置。

        如果对于已经使用了多路径配置的节点，可以使用为每一个路径启动一个对应节点的方式，完成多路径配置迁移。

        迁移的主要流程如下：

1. 对数据进行快照，防止出现问题
2. 使用 allocation filter 实现在当前集群中，移除当前节点，重新分配分片数据，可以使用 cat allocation API 来跟踪数据迁移进度，如果存在分片没有被迁移，可以通过 cluster allocation explain API 查看原因
3. 遵循 rolling restart process 原则，下线当前节点
4. 监控集群状态，确保集群状态是 yellow 或 green 来保证至少由一个所有分片的备份被分配到集群中至少一个节点上
5. 如果合适的话，对第2步中，使用 allocation filter 来排除的节点名称的操作做回复，也就是取消分片分配排除节点配置
6. 通过删除下线节点的 datas 路径下的内容来丢弃这些数据
7. 使用硬件虚拟化层对多个路径虚拟出一个路径，并保证这个虚拟出来的路径拥有足够的空间来存储即将分配过来的数据
8. 重新配置这个节点的数据路径为这个虚拟路径；如果需要，可以建立多个节点来分别持有各个路径。

9. 遵循 rolling restart process 原则，启动节点

10. 最后确保集群状态是 green

        集群中，拥有相同的 cluster.name 配置的节点会加入同一个集群，默认的集群名称是 elasticsearch，另外配置集群名称时，应该用名称区分用途，比如不同环境下，名称中应该区分出来。

cluster:
  name: logging-prod

        使用 node.name 配置一个有意义的名称用来区分Elasticsearch中的每一个实例。该实例名称会在很多API中返回，默认的节点名称是机器的主机名

node:
  name: prod-data-2

        默认情况，Elasticsearch只会绑定到合适的地址，例如：127.0.0.1 和 [::1]。这种情况，在开发环境或者测试环境中，对于一个服务器的几个节点是没有问题的，但是，一个可 resilient production cluster（可回复的生产集群） 必须包含其他服务器上的节点。在 network settings （网络配置）中有配置配置，但是通常只需要配置 network.host

network:
  host: 192.168.1.10

        当配置了network.host之后，Elasticsearch会认为这个节点是生产环境的节点，因此在启动时，会做从警告到异常的一系列系统检测，详情可以查看 development and production modes（开发和生产模式）https://www.elastic.co/guide/en/elasticsearch/reference/current/system-config.html#dev-vs-prod

        在上线前，有两个配置需要配置，用来让集群内部的节点能够互相发现和选举。

        默认情况下，Elasticsearch会在本机的9300-9305这些端口上去发现集群内的节点，从而达到无需任何配置的情况下，就能够组建集群。

        当需要从其他服务器上发现节点时，就需要通过 discover.seed_hosts 来配置种子主机，这些种子主机也是备选主节点，这些种子主机需要是存活的，且互相之间可以交流，由此来推动发现程序。

        种子主机的配置是一个数组，数组内支持：

1. 主机:端口
2. 主机，此情况下，端口默认是9300
3. 域名，此情况下，会通过DNS解析，得到对应的主机
4. [IP6]:port，此情况相下，IP6地址必须使用中括号括起来

        另外，主机的配置还支持 alternative hosts provider（可选的主机提供者）来实现获取动态地址。

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 来指定候选主节点，首次选举时，就能知道节点票数。

在集群首次形成后，应该移除每个节点的cluster.initial_master_nodes配置；在重启一个集群或者在新增一个节点到集群中时，不要使用该配置。

cluster:
  initial_master_nodes: 
   - master-node-a
   - master-node-b
   - master-node-c

        这里初始主节点中，应该使用和节点名称 node.name 完全一致的名称

        默认情况下，Elasticsearch会根据节点的角色和总内存空间来设置JVM堆内存。推荐在生产环境使用默认的配置。

        如果要自己配置，使用 Xms 和 Xmx 来分别配置最小和最大堆内存，这两个值一定要相等。

        堆内存设置应该基于服务器的内存大小来设置，有以下几点参考：

1. Xms 和 Xmx 不要超过服务器内存大小的 50% ，Elasticsearch需要的内存除了堆内存外，还有其他的用处。例如使用堆内存以外的缓存来实现搞笑的网络连接和依赖于操作系统文件缓存用于访问文件。JVM本身也需要一些内存。所以，Elasticsearch会使用超出堆内存配置外更多的内存。（对于使用容器，如Docker来部署，总内存大小就是对于容器可见的总内存大小）
2. 设置 Xms 和 Xmx 不超过 （threshold for compressed ordinary object pointers）压缩普通对象指针阀值 ，对于大多数系统来说，阀值在 26GB 都是安全的，有些系统可以达到 30GB。为了验证 Xms 和 Xmx 设置低于这个值，可以在Elasticsearch日志中发现如下日志：

heap size [1.9gb], compressed ordinary object pointers [true]

        Elasticsearch可用内存越大，可用于其内部缓存的空间就越大，同时留给操作系统文件系统缓存的空间就越小，垃圾回收暂停时间也就越长。

        Xms 和 Xmx 的配置方式是在 $ES_HOME 的 config 文件夹下的 jvm.options.d 文件夹下的 .options 文件中进行配置，以下是配置示例：

-Xms2g
-Xmx2g

        出于测试目的，也可以指定 ES_JAVA_OPTS 环境变量，该环境变量会覆盖JVM配置，但是在生产环境下，并不建议这样配置。

ES_JAVA_OPTS="-Xms2g -Xmx2g" ./bin/elasticsearch

如果是在Windows中，将Elasticsearch作为服务来运行的，可以通过服务管理来设置堆内存大小，参见 Installing Elasticsearch as a Service on Windows（Windows中将Elasticsearch安装成服务）

        默认情况下，当出现内存溢出异常时，JVM堆信息会转存到默认的 data 目录。对于 RPM 和 Debian 包中，data 目录在 /var/lib/elasticsearch 中，对于 Linux and MaxOS 和 Windows 中，data 目录在 Elasticsearch 安装目录下。

        当默认的目录不适于存储JVM堆信息时，可以通过修改 jvm.options 文件中 -XX:HeapDumpPath=... 键值对的值，该值的配置说明如下：

• 如果配置的值是目录，JVM会基于当前实运行的PID来生成转存文件
• 如果配置的值是固定的文件名称，当需要转存堆信息时，该文件必须是不存在的，否则转存会失败。

        默认情况下，Elasticsearch开启了垃圾收集（GC）日志。这些配置在 jvm.options 中，日志输出目录和Elasticsearch日志默认输出目录相同。默认的配置是日志文件以 64MB 轮写，最多消耗 2GB 的空间。

        可以通过命令行配置一些命令，参见 JEP 158: Unified JVM Logging。在不改变 jvm.options 的情况下，Elasticsearch的配置都会额外添加在你自己的配置之上，如果要禁用Elasticsearch的默认的配置，可以通过参数  -Xlog:disable 来禁用，然后在命令行上进行自己的配置，禁用后，所有的JVM日志都会被禁用，因此记得开启需要的配置。

        有以下示例，通过在 在 $ES_HOME 的 config 文件夹下的 jvm.options.d 文件夹下创建 gc.options 来修改GC日志的输出目录

# 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,pid,tags:filecount=32,filesize=64m

        在Docker容器中，通过 ES_JAVA_OPTS 来指定GC调试日志输出

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中一些长时间没有访问的临时文件，但是这些文件又是Elasticsearch运行时所必须的文件，就会造成问题。

        如果是使用 .deb 或 .rpm 安装的，使用  systemd 运行，Elasticsearch使用的临时目录会被周期性删除锁排除在外。

        如果是使用 .tar.gz 安装，推荐额外创建专用的临时文件夹，这个文件夹要求不会被删除，同时其访问和操作权限必须是只有运行Elasticsearch的用户才拥有的。然后在启动Elasticsearch之前，通过 $ES_TMPDIR 环境变量来指向这个临时创建的目录。

        默认情况下，Elasticsearch对JVM致命错误会记录到默认的日志目录，对于 RPM 和 Debian 包管理，日志目录在 /var/log/elasticsearch ，对于 Linux and MacOS and Windows ，日志目录在Elasticsearch安装目录。

        可以 jvm.options 文件中修改属性 -XX:ErrorFile=... 的值来设置到合适的位置。

        出现问题时，快照可以保证数据不丢失。Snapshot lifecycle management（快照生命周期管理），可以参见 Create a snapshot（创建一个快照）来实现

        本文主要介绍了Elasticsearch一些基础但是非常重要的配置，这些配置将帮助构建一个基础的集群，也会帮助实现集群的容灾性，同时，在节点出现问题时，可以到专门的日志中去查看问题原因等。