es集群搭建
3个ES节点：均为master和data节点，ES版本7.10.1
1个kibana节点：kibana版本7.10.1
环境：es7要求jdk最低版本为11，不过es7已内置jdk，不需要我们额外安装11版本的jdk，但es6版本需要安装最低版本8的jdk。
第一步：下载elasticsearch和kibana的7.10.1版本的压缩包，并解压到相应目录
Es目录结构
Kibana目录结构
第二步：es为了安全不允许使用root用户启动，因此需要创建用户elasticsearch，并给予es和kibana安装目录的所有权。
第三步：修改es配置elasticsearch.yml
位置：在解压目录下的config文件夹中
# 集群名称
cluster.name: escluster
#节点名称
node.name: es1
# 该节点是否为master节点
node.master: true
# 该节点是否为数据节点
node.data: true
# 数据目录(需检查是否存在该目录且有权限访问)
path.data: /data/elasticsearch/data
# 日志目录(需检查是否存在该目录且有权限访问)
path.logs: /data/elasticsearch/logs
# 对外暴露的http请求端口
http.port: 9200
# 集群节点之间通信用的TCP端口
transport.tcp.port: 9300
# 这将指定用于监听请求的网络接口。一个节点可以绑定多个接口，例如有两块网卡，一个本地站点地址，一个本地地址
network.bind_host: 192.168.1.1
# 发布地址，一个单一地址，用于通知集群中的其他节点，以便其他的节点能够和它通信。当前，一个 elasticsearch 节点可能被绑定到多个地址，但是仅仅有一个发布地址
network.publish_host: 192.168.1.1
# bind_host和publish_host一起设置
network.host: 192.168.1.1
# 一个集群中最小主节点个数（防止脑裂，一般为n/2 + 1，n为集群节点个数）（7.10.1版本已取消？）
discovery.zen.minimum_master_nodes: 2
# 新节点启动时能被发现的节点列表（新增节点需要添加自身）
discovery.zen.ping.unicast.hosts: ["172.16.0.8:9300","172.16.0.6:9300","172.16.0.22:9300"]
# 集群初始话指定主节点（节点名）,7版本必须设置
cluster.initial_master_nodes: es1
# 字段发现其他节点的超时时间
discovery.zen.ping_timeout: 3000s
# 锁住物理内存，不使用swap内存
bootstrap.memory_lock: true
第四步：jvm配置调优
解压目录下conf目录下的jvm.options文件，修改-Xms1g和-Xmx1g，一般设置为物理内存的一半，但是不应超过32G，最大设置为31G即可。
第五步：内存优化
① /etc/sysctl.conf添加以下内容，sysctl -p生效：
fs.file-max=655360 # 系统最大打卡文件描述符数
vm.max_map_count=655360 # 限制一个进程拥有虚拟内存区域的大小② 修改/etc/security/limits.conf
soft nofile 65536
hard nofile 65536
soft nproc 65536
hard nproc 65536
soft memlock unlimited
# (nofile)最大开打开文件描述符
# (nproc)最大用户进程数
# (memlock)最大锁定内存地址空间③ 修改/etc/security/limits.d/90-nproc.conf，将1024修改为65536
soft nproc 1024 # 修改前
soft nproc 65536 # 修改后
max file descriptors [65535] for elasticsearch process is too low -> elasticsearch用户拥有的可创建文件描述的权限太低，至少需要65536，参考博客：
第六步：复制es文件夹并修改部分参数
将压缩后的ES进行复制，复制到另外两个节点，修改elasticsearch中的参数：
node.name: es2
path.data: /data/elasticsearch/data
path.logs: /data/elasticsearch/logs
第七步：启动3台ES节点
执行bin目录下的elasticsearch文件，注意启动前，三台机器都需要进行第四步和第五步的操作。
3台ES节点启动后，会自动选举出一个master节点，这3台es节点一起组成一个es集群，master节点宕机后，另外两个节点
第八步：修改kibana配置文件kibana.yml
配置文件目录再安装目录的config文件夹下：
# kibana对外暴露端口
server.port:: 5601
# 默认localhost，指定后端服务器的主机
server.host: "192.168.119.128"
# es主节点ip+端口，与ES进行通信用
elasticsearch.hosts: ["http://192.168.119.128:9200"]
# es集群名称
server.name: "my-es"
# 开启中文
i18n.locale: "zh-CN"
第九步：启动kibana并验证
执行bin目录下的kibana文件，页面上输入192.168.119.128:5601地址（kibana地址+端口）即可看到es集群状态，若ES集群状态为green则为健康。
注意事项：
故障恢复
① 主数分离：该非高可用版集群适用于开发和测试环境，3个节点组成集群，节点均为数据节点，均会存储数据。生产环境，master节点和data节点应该分离，使用不同的节点。
② 自动选举：3个节点中会选举一个master主节点，该master节点宕机后，另外两个节点会选举出一个新的master节点
③ 防止脑裂：yml配置文件中的discovery.zen.minimum_master_nodes，推荐设置为n/2+1，n为集群中设置为master的节点数，故3个master节点时推荐设置为2。如果两个节点宕机，则不满足最小节点限制，不会重新选举。
④ 副本冗余：为保证数据的完整性，es提供了副本机制，合理的设置分片和副本的数量可以一定程度地保证宕机时的数据完整性。
示例：3个数据节点，主分片设置为5，副本设置为1。1个节点宕机后，另外两个节点还拥有完整的数据。2个节点宕机后最后一个节点没有完整的数据，无法正常地提供服务。若需要2个节点宕机仍正常提供服务，则可以设置副片数量为2。
分片和副本
① 分片数量越多，对查询速度会有提升，但是当分片数量到一定数量后，对主分片的维护的时间开销变大，反而会降低索引的查询速度。一般来说，主分片数量需要设置少于2倍的节点数。
② 副本的增加提高了维护分片的成本，也会导致一个索引占用的空间增加，也进一步增加了存储的压力，一般来说，副本数量应尽量设置不超过3个。
③ 索引的主分片设置后就不允许修改，一个索引的大小增加后，分片的大小必然也会随之增加，当分片的大小增加到一定程度后，对该分片的维护成本变高，查询速度也会变慢。官方推荐一个分片的大小最好在20G~50G之间，所以当一个索引的大小到达一定程度后，我们需要将新的数据导入到新的索引中，这时会用到rollover
rollover：设置该索引数据量超过一定大小后，es将会新建一个索引，并将数据导入到新的索引中。
es冷热数据分离目的是为了节省成本，冷热数据分离和多级缓存是非常类似的，一句话概括就是把更高频访问的数据，放在性能搞好的硬件上，但区别就是多级缓存是不考虑数据持久化的。
性能越快的硬件往往空间越少，以至于其只能把最高频使用的数据放进去，如CPU的L1、L2、L3三级缓存。性能递减，容量递增。上升到整个计算机层面，CPU到内存再到磁盘，也是速度递减，容量递增。本质上讲，就是把最常用的东西放在最近的位置。
数据层：Data tiers
① hot tier：处理时间序列数据（例如日志或指标）的索引负载，并保存您最近、最常访问的数据。
热层中的节点需要快速读取和写入，这需要更多的硬件资源和更快的存储 (SSD)。为了弹性，热层中的索引应配置为使用一个或多个副本。热层是必须的。作为数据流一部分的新索引会自动分配给热层。
② warm tier：保存访问频率较低且很少需要更新的时间序列数据。
一旦查询的频率低于热层中最近索引的数据，时间序列数据就可以移动到热层。暖层通常保存最近几周的数据，仍然允许更新，但可能不频繁。热层中的节点通常不需要像热层中的节点那样快，为了弹性，应将暖层中的索引配置为使用一个或多个副本。
③ cold tier：保存不经常访问且通常不更新的时间序列数据。
一旦数据不再被更新，它就可以从暖层移动到冷层，并在不经常被查询的情况下停留在那里。冷层仍然是响应式查询层，但冷层中的数据不会正常更新。随着数据转换到冷层，它可以被压缩和缩小。对于弹性，冷层可以使用完全安装的 可搜索快照索引，从而消除对副本的需求。
④ frozen tier：保存很少访问且从不更新的时间序列数据，保存在可搜索的快照中。
一旦数据不再被查询或很少被查询，它可能会从冷层移动到冻结层，并在其余生中停留。冻结层使用部分安装的索引来存储和加载来自快照存储库的数据。这降低了本地存储和运营成本，同时仍然让您搜索冻结的数据。因为 Elasticsearch 有时必须从快照存储库中获取冻结数据，所以在冻结层上的搜索通常比在冷层上慢。
⑤ content tier：处理产品目录等内容的索引和查询负载。
内容层节点通常针对查询性能进行优化——它们优先考虑处理能力而不是 IO 吞吐量，因此它们可以处理复杂的搜索和聚合并快速返回结果。虽然它们还负责索引，但内容数据的摄取率通常不如日志和指标等时间序列数据那么高。从弹性的角度来看，该层中的索引应配置为使用一个或多个副本。内容层是必需的。不属于数据流的系统索引和其他索引会自动分配给内容层。
当文档直接索引到特定 index 时，会永久保留在 content tier 节点上。
当文档索引到数据流时，数据最初驻留在 hot tier 节点上。
节点角色：node.roles
① data_hot：热数据节点在进入 Elasticsearch 时存储时间序列数据。热层对于读取和写入都必须快速，并且需要更多的硬件资源（例如 SSD 驱动器）
② data_warm：暖数据节点存储不再定期更新但仍在查询的索引。查询量的频率通常低于索引处于热层时的频率。此层中的节点通常可以使用性能较低的硬件。
③ data_cold：冷数据节点存储访问频率较低的只读索引。该层使用性能较低的硬件，并且可以利用可搜索的快照索引来最小化所需的资源。
④ data_frozen：冻结层专门存储部分安装的索引。我们建议您在冻结层中使用专用节点。
⑤ data_content：内容数据节点容纳用户创建的内容。它们支持 CRUD、搜索和聚合等操作
参考：https://blog.csdn.net/wlei0618/article/details/125275346
