Elasticsearch7.14.0安装，配置密码认证及创建用户

此时我们执行文件运行

解决方案：创建一个es用户组以及用户，然后使用es用户启动elasticsearch

elasticsearh从7.0开始默认安装了java运行环境，以便在没有安装java运行环境的机器上运行。

通过阅读elasticsearch-env文件大概35行可以知道

如果配置了环境变量ES_JAVA_HOM，则elasticsearh启动时会使用ES_JAVA_HOM作为java路径。

如果配置了环境变量JAVA_HOM，则elasticsearh启动时会使用JAVA_HOM作为java路径。

如果没有配置Java环境，则elasticsearh启动时会使用自带的jdk来运行

解决方案：

一、安装符合条件的jdk并配置JAVA_HOME。

二、安装符合条件的jdk并配置ES_JAVA_HOME

三、使用elasticsearch自带的jdk配置ES_JAVA_HOME,不需要配置PATH

添加一行

将用户切换回es后再次执行

做到这一步，elasticsearch总算是运行起来了

title: elasticsearch高级配置

date: 2020-10-16 09:00:39

categories: elk

tags:

- 配置

- elasticsearch

大多数设置可以使用 集群更新API 来更改

Elasticsearch提供了三个主要的配置文件，我们所有的配置都通过这个三个文件：

您应该很少需要更改Java虚拟机（JVM）选项。如果这样做，最可能的更改是设置堆大小。

<font color="501818"> 10. 堆转储路径 </font>

默认情况，配置jvm存储堆栈溢出到data文件夹里，如果该目录不支持则需要修改。

<font color="501818"> 11. GC记录 </font>

默认情况下，Elasticsearch启用GC日志。这些配置在 jvm.options默认位置和默认位置与Elasticsearch日志相 同。默认配置每64 MB轮换一次日志，最多可占用2 GB的磁盘空间。

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

在投入生产之前，必须考虑以下设置：

<font color="501818"> 1.路径设置 </font>

主要是数据和日志路径

对于数据，可以有多个路径如：

data中生成目录形式：elasticsearch/nodes/0/indices/uuid/shard/

<font color="501818"> 2. 群集名称 </font>

这是节点加入集群的唯一方法，默认的是elasticsearch

<font color="501818"> 3. 节点名称 </font>

节点名称有助于区别不同类型(可以使用环境变量如 node.name: ${HOSTNAME} )

<font color="501818"> 4. 网络主机 network.host </font>

一般设置本机ip ，一旦设置为非回环地址，即默认视为生产模式，就需要注意系统配置

一旦配置了类似的网络设置network.host，Elasticsearch就会假定您正在转向生产并将上述警告升级为异常。这些异常将阻止您的Elasticsearch节点启动。这是一项重要的安全措施，可确保您不会因服务器配置错误而丢失数据。

<font color="501818"> 5. 发现设置 </font>

①：如果不指定port，则会使用transport.tcp.port

②：如果是多个ip的主机，则会访问所有解析到的ip

discovery.zen.minimum_master_nodes

最好为 （master_eligible_nodes / 2）+ 1 3个节点的情况设置2个

<font color="501818"> 1. 资源限制： </font>

要将打开文件句柄（ulimit -n）的数量设置为65,536 /etc/security/limits.conf

<font color="501818"> 2. Disable swapping </font>

交换对性能，节点稳定性非常不利，应该不惜一切代价避免。它可能导致垃圾收集持续数分钟而不是毫秒，并且可能导致节点响应缓慢甚至断开与群集的连接。在d性分布式系统中，让 *** 作系统终止节点更有效。

三种方案：

<font color="501818"> 3. Increase file descriptors </font>

<font color="501818"> 4. Ensure sufficient virtual memory </font>

<font color="501818"> 5. Ensure sufficient threads </font>

<font color="501818"> 6. JVM DNS cache settings </font>

<font color="501818"> 7. Temporary directory not mounted with noexec </font>

<font color="501818"> 8. 临时目录 </font>

Generate a private key and X.509 certificate.

生成节点证书

<font color="blue"> 结论： </font>开源基础版，无法使用安全功能

目前主要通过插件的形式来控制：

常用的插件主要包括：elasticsearch-http-basic，search-guard，shield

配置名 默认值 说明

http.basic.enabled true 开关，开启会接管全部HTTP连接

http.basic.user "admin" 账号

http.basic.password "admin_pw" 密码

http.basic.ipwhitelist ["localhost", "127.0.0.1"]白名单内的ip访问不需要通过账号和密码，支持ip和主机名，不支持ip区间或正则

http.basic.trusted_proxy_chains[]信任代理列表

http.basic.logfalse把无授权的访问事件添加到ES的日志

http.basic.xforward""记载代理路径的header字段名

第二步：shutdown你要升级的节点

第三步：升级重启该节点，并确认该节点重新加入到了集群中

第四步：重复2-3步，升级重启其它要升级的节点。

第五步：重启启动集群的shard均衡

1、内存优化

在bin/elasticsearch.in.sh中进行配置

修改配置项为尽量大的内存：

ES_MIN_MEM=8g

ES_MAX_MEM=8g

两者最好改成一样的，否则容易引发长时间GC（stop-the-world）

elasticsearch默认使用的GC是CMS GC

如果你的内存大小超过6G，CMS是不给力的，容易出现stop-the-world

建议使用G1 GC

注释掉：

JAVA_OPTS=”$JAVA_OPTS -XX:+UseParNewGC”

JAVA_OPTS=”$JAVA_OPTS -XX:+UseConcMarkSweepGC”

JAVA_OPTS=”$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75″

JAVA_OPTS=”$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly”

修改为：

JAVA_OPTS=”$JAVA_OPTS -XX:+UseG1GC”

JAVA_OPTS=”$JAVA_OPTS -XX:MaxGCPauseMillis=200″

如果G1 GC优点是减少stop-the-world在几率，但是CPU占有率高。

需要更优化的性能，你可以参考

http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html

2、合理配置主节点和数据节点

配置文件：conf/elasticsearch.yaml

node.master: true

node.data: true

3、设置合理的刷新时间

建立的索引，不会立马查到，这是为什么elasticsearch为near-real-time的原因

需要配置index.refresh_interval参数，默认是1s。

你可以像

http://zhaoyanblog.com/archives/299.html

文件中一样，调用接口配置

也可以直接写到conf/elasticsearch.yaml文件中

index.refresh_interval：1s

这样所有新建的索引都使用这个刷新频率。

小贴士1：规划索引、分片 以及集群增长情况

ES使得创建大量索引和超大量分片非常地容易，但更重要的是理解每个索引和分片都是一笔开销。如果拥有太多的索引或分片，单单是管理负荷就会影响到ES集群的性能，潜在地也会影响到可用性方面。这里我们专注于管理负荷，但运行大量的索引/分片依然会非常显著地影响到索引和检索性能。

我们发现影响管理负荷的最大因素是集群状态数据的大小，因为它包含了集群中每个索引的所有mapping数据。我们曾经一度有单个集群拥有超过900MB的集群状态数据。该集群虽然在运行但并不可用。

让我们通过一些数据来了解到底发生了什么 。。。。。。

假如有一个索引包含50k的mapping数据（我们当时是有700个字段）。如果每小时生成一个索引，那么每天将增加24 x 50k的集群状态数据，或者1.2MB。如果需要在系统中保留一年的数据，那么集群状态数据将高达438MB（以及8670个索引，43800个分片）。如果与每天一个索引（18.25MB，365个索引，1825个分片）作比较，会看到每小时的索引策略将会是一个完全不同的境况。

幸运的是，一旦系统中有一些真实数据的话，实际上非常容易做这些预测。我们应当能够看到集群必须处理多少状态数据和多少索引/分片。在上到生产环境之前真的应该演练一下，以便防止凌晨3:00收到集群挂掉的电话告警。

小贴士3: 内存设置

Linux把它的物理RAM分成多个内存块，称之为分页。内存交换（swapping）是这样一个过程，它把内存分页复制到预先设定的叫做交换区的硬盘空间上，以此释放内存分页。物理内存和交换区加起来的大小就是虚拟内存的可用额度。

内存交换有个缺点，跟内存比起来硬盘非常慢。内存的读写速度以纳秒来计算，而硬盘是以毫秒来计算，所以访问硬盘比访问内存要慢几万倍。交换次数越多，进程就越慢，所以应该不惜一切代价避免内存交换的发生。

ES的mlockall属性允许ES节点不交换内存。（注意只有Linux/Unix系统可设置。）这个属性可以在yaml文件中设置：

bootstrap.mlockall: true

在5.x版本中，已经改成了bootstrap.memory_lock: true.

mlockall默认设置成false，即ES节点允许内存交换。一旦把这个值加到属性文件中，需要重启ES节点才可生效。可通过以下方式来确定该值是否设置正确：

curl http://localhost:9200/_nodes/process?pretty

如果你正在设置这个属性，请使用-DXmx选项或ES_HEAP_SIZE属性来确保ES节点分配了足够的内存。

Elasticsearch默认使用服务发现(Zen discovery)作为集群节点间发现和通信的机制。Azure、EC2和GCE也有使用其他的发现机制。服务发现由discovery.zen.*开头的一系列属性控制。

在0.x和1.x版本中同时支持单播和多播，且默认是多播。所以要在这些版本的ES中使用单播，需要设置属性discovery.zen.ping.multicast.enabled为false。

从2.0开始往后服务发现就仅支持单播了。

首先需要使用属性discovery.zen.ping.unicast.hosts指定一组通信主机。方便起见，在集群中的所有主机上为该属性设置相同的值，使用集群节点的名称来定义主机列表。

属性discovery.zen.minimum_master_nodes决定了有资格作为master的节点的最小数量，即一个应当“看见”集群范围内运作的节点。如果集群中有2个以上节点，建议设置该值为大于1。一种计算方法是，假设集群中的节点数量为N，那么该属性应该设置为N/2+1。

初步判断该设置可以有效防止脑裂问题

小贴士5：当心DELETE _all

必须要了解的一点是，ES的DELETE API允许用户仅仅通过一个请求来删除索引，支持使用通配符，甚至可以使用_all作为索引名来代表所有索引。例如:

curl -XDELETE ‘ http://localhost:9200/*/ ’

这个特性非常有用，但也非常危险，特别是在生产环境中。在我们的所有集群中，已通过设置action.destructive_requires_name:true来禁用了它。

这项配置在1.0版本中开始引用，并取代了0.90版本中使用的配置属性disable_delete_all_indices。

小贴士6：使用Doc Values

2.0及以上版本默认开启Doc Values特性，但在更早的ES版本中必须显式地设置。当进行大规模的排序和聚合 *** 作时，Doc Values相比普通属性有着明显的优势。本质上是将ES转换成一个列式存储，从而使ES的许多分析类特性在性能上远超预期。

为了一探究竟，我们可以在ES里比较一下Doc Values和普通属性。

当使用一个普通属性去排序或聚合时，该属性会被加载到属性数据缓存中。一个属性首次被缓存时，ES必须分配足够大的堆空间，以便能保存每一个值，然后使用每个文档的值逐步填充。这个过程可能会耗费一些时间，因为可能需要从磁盘读取他们的值。一旦这个过程完成，这些数据的任何相关 *** 作都将使用这份缓存数据，并且会很快。如果尝试填充太多的属性到缓存，一些属性将被回收，随后再次使用到这些属性时将会强制它们重新被加载到缓存，且同样有启动开销。为了更加高效，人们会想到最小化或淘汰，这意味着我们的属性数量将受限于此种方式下的缓存大小。

相比之下，Doc Values属性使用基于硬盘的数据结构，且能被内存映射到进程空间，因此不影响堆使用，同时提供实质上与属性数据缓存一样的性能。当这些属性首次从硬盘读取数据时仍然会有较小的启动开销，但这会由 *** 作系统缓存去处理，所以只有真正需要的数据会被实际读取。

Doc Values因此最小化了堆的使用（因为垃圾收集），并发挥了 *** 作系统文件缓存的优势，从而可进一步最小化磁盘读 *** 作的压力。

---