ElasticSearch 集群（搭建 分片配置 原理 ELK搭建 路由原理 脑裂 集群扩容）

集群

1.1 搭建集群

Elasticsearch如果做集群的话Master节点至少三台服务器或者三个Master实例加入相同集群，三个Master节点最多只能故障一台Master节点，如果故障两个Master节点，Elasticsearch将无法组成集群.会报错，Kibana也无法启动，因为Kibana无法获取集群中的节点信息。

由于，我们使用只有一台虚拟机，所以我们在虚拟机中安装三个ES实例，搭建伪集群，而ES启动比较耗内存，所以先设置虚拟机的内存3G和CPU个数4个

1.1.1 整体步骤

步骤如下：

• 拷贝opt目录下的elasticsearch-7.4.0安装包3个，分别命名：

  elasticsearch-7.4.0-itcast1

  elasticsearch-7.4.0-itcast2

  elasticsearch-7.4.0-itcast3

• 然后修改elasticsearch.yml文件件。

• 然后启动启动itcast1、itcast2、itcast3三个节点。

• 打开浏览器输⼊：http://192.168.149.135:9200/_cat/health?v ,如果返回的node.total是3，代表集 群搭建成功

在此，需要我们特别注意的是，像本文这样单服务器多节点（ 3 个节点）的情况，仅供测试使用，集群环境如下：

cluster name	node name	IP Addr	http端口 / 通信端口
itcast-es	itcast1	192.168.149.135	9201 / 9700
itcast-es	itcast2	192.168.149.135	9202 / 9800
itcast-es	itcast3	192.168.149.135	9203 / 9900

1.1.2 拷贝副本

拷贝opt目录下的elasticsearch-7.4.0安装包3个，打开虚拟机到opt目录

执行 拷贝三份

cd /opt
cp -r  elasticsearch-7.4.0   elasticsearch-7.4.0-itcast1
cp -r  elasticsearch-7.4.0   elasticsearch-7.4.0-itcast2
cp -r  elasticsearch-7.4.0   elasticsearch-7.4.0-itcast3

1.1. 3 修改elasticsearch.yml配置文件

1)、创建日志目录

cd /opt
mkdir logs
mkdir  data
# 授权给itheima用户
chown -R itheima:itheima ./logs
chown -R itheima:itheima ./data

chown -R itheima:itheima ./elasticsearch-7.4.0-itcast1
chown -R itheima:itheima ./elasticsearch-7.4.0-itcast2
chown -R itheima:itheima ./elasticsearch-7.4.0-itcast3

打开elasticsearch.yml配置，分别配置下面三个节点的配置文件

vim /opt/elasticsearch-7.4.0-itcast1/config/elasticsearch.yml 
vim /opt/elasticsearch-7.4.0-itcast2/config/elasticsearch.yml 
vim /opt/elasticsearch-7.4.0-itcast3/config/elasticsearch.yml 

2)、下面是elasticsearch-7.4.0-itcast1配置文件

cluster.name: itcast-es
node.name: itcast-1 
node.master: true
node.data: true
node.max_local_storage_nodes: 3 
network.host: 0.0.0.0
http.port: 9201
transport.tcp.port: 9700
discovery.seed_hosts: ["localhost:9700","localhost:9800","localhost:9900"]
cluster.initial_master_nodes: ["itcast-1", "itcast-2","itcast-3"]
path.data: /opt/data
path.logs: /opt/logs

#集群名称
cluster.name: itcast-es
#节点名称
node.name: itcast-1 
#是不是有资格主节点
node.master: true
#是否存储数据
node.data: true
#最大集群节点数
node.max_local_storage_nodes: 3 
#ip地址
network.host: 0.0.0.0
#端口
http.port: 9201
#内部节点之间沟通端口
transport.tcp.port: 9700
#es7.x 之后新增的配置，节点发现
discovery.seed_hosts: ["localhost:9700","localhost:9800","localhost:9900"]
#es7.x 之后新增的配置，初始化一个新的集群时需要此配置来选举master
cluster.initial_master_nodes: ["itcast-1", "itcast-2","itcast-3"] 
#数据和存储路径
path.data: /opt/data
path.logs: /opt/logs

3)、下面是elasticsearch-7.4.0-itcast2配置文件

cluster.name: itcast-es
node.name: itcast-2 
node.master: true
node.data: true
node.max_local_storage_nodes: 3 
network.host: 0.0.0.0
http.port: 9202
transport.tcp.port: 9800
discovery.seed_hosts: ["localhost:9700","localhost:9800","localhost:9900"]
cluster.initial_master_nodes: ["itcast-1", "itcast-2","itcast-3"]
path.data: /opt/data
path.logs: /opt/logs

#集群名称
cluster.name: itcast-es
#节点名称
node.name: itcast-2 
#是不是有资格主节点
node.master: true
#是否存储数据
node.data: true
#最大集群节点数
node.max_local_storage_nodes: 3 
#ip地址
network.host: 0.0.0.0
#端口
http.port: 9202
#内部节点之间沟通端口
transport.tcp.port: 9800
#es7.x 之后新增的配置，节点发现
discovery.seed_hosts: ["localhost:9700","localhost:9800","localhost:9900"]
#es7.x 之后新增的配置，初始化一个新的集群时需要此配置来选举master
cluster.initial_master_nodes: ["itcast-1", "itcast-2","itcast-3"] 
#数据和存储路径
path.data: /opt/data
path.logs: /opt/logs

4)、下面是elasticsearch-7.4.0-itcast3 配置文件

cluster.name: itcast-es
node.name: itcast-3 
node.master: true
node.data: true
node.max_local_storage_nodes: 3 
network.host: 0.0.0.0
http.port: 9203
transport.tcp.port: 9900
discovery.seed_hosts: ["localhost:9700","localhost:9800","localhost:9900"]
cluster.initial_master_nodes: ["itcast-1", "itcast-2","itcast-3"] 
path.data: /opt/data
path.logs: /opt/logs

#集群名称
cluster.name: itcast-es
#节点名称
node.name: itcast-3 
#是不是有资格主节点
node.master: true
#是否存储数据
node.data: true
#最大集群节点数
node.max_local_storage_nodes: 3 
#ip地址
network.host: 0.0.0.0
#端口
http.port: 9203
#内部节点之间沟通端口
transport.tcp.port: 9900
#es7.x 之后新增的配置，节点发现
discovery.seed_hosts: ["localhost:9700","localhost:9800","localhost:9900"]
#es7.x 之后新增的配置，初始化一个新的集群时需要此配置来选举master
cluster.initial_master_nodes: ["itcast-1", "itcast-2","itcast-3"] 
#数据和存储路径
path.data: /opt/data
path.logs: /opt/logs

1.1.4 执行授权

在root用户下执行
chown -R itheima:itheima /opt/elasticsearch-7.4.0-itcast1
chown -R itheima:itheima /opt/elasticsearch-7.4.0-itcast2
chown -R itheima:itheima /opt/elasticsearch-7.4.0-itcast3
如果有的日志文件授权失败，可使用(也是在root下执行)
cd /opt/elasticsearch-7.4.0-itcast1/logs
chown -R itheima:itheima ./* 
cd /opt/elasticsearch-7.4.0-itcast2/logs
chown -R itheima:itheima ./* 
cd /opt/elasticsearch-7.4.0-itcast3/logs
chown -R itheima:itheima ./* 

1.1.5 启动三个节点

启动之前，设置ES的JVM占用内存参数，防止内存不足错误

vim /opt/elasticsearch-7.4.0-itcast1/bin/elasticsearch

可以发现，ES启动时加载/config/jvm.options文件

vim /opt/elasticsearch-7.4.0-itcast1/config/jvm.options

默认情况下，ES启动JVM最小内存1G，最大内存1G

-xms:最小内存
-xmx:最大内存

修改为256m

启动成功访问节点一：

可以从日志中看到：master not discovered yet。还没有发现主节点

访问集群状态信息 http://192.168.149.135:9201/_cat/health?v 不成功

启动成功访问节点二:

可以从日志中看到：master not discovered yet。还没有发现主节点master node changed.已经选举出主节点itcast-2

访问集群状态信息 http://192.168.149.135:9201/_cat/health?v 成功

健康状况结果解释：

cluster 集群名称
status 集群状态 
	green代表健康；
	yellow代表分配了所有主分片，但至少缺少一个副本，此时集群数据仍旧完整；
	red 代表部分主分片不可用，可能已经丢失数据。
node.total代表在线的节点总数量
node.data代表在线的数据节点的数量
shards 存活的分片数量
pri 存活的主分片数量 正常情况下 shards的数量是pri的两倍。
relo迁移中的分片数量，正常情况为 0
init 初始化中的分片数量 正常情况为 0
unassign未分配的分片 正常情况为 0
pending_tasks准备中的任务，任务指迁移分片等 正常情况为 0
max_task_wait_time任务最长等待时间
active_shards_percent正常分片百分比 正常情况为 100%

启动成功访问节点三

访问集群状态信息 http://192.168.149.135:9201/_cat/health?v 成功

1.2 使用Kibana配置和管理集群

1.2.1 集群配置

因为之前我们在单机演示的时候也使用到了Kibana，我们先复制出来一个Kibana，然后修改它的集群配置

cd /opt/
cp -r kibana-7.4.0-linux-x86_64   kibana-7.4.0-linux-x86_64-cluster
# 由于 kibana 中文件众多，此处会等待大约1分钟的时间

修改Kibana的集群配置

vim  kibana-7.4.0-linux-x86_64-cluster/config/kibana.yml
加入下面的配置
elasticsearch.hosts: ["http://localhost:9201","http://localhost:9202","http://localhost:9203"]

启动Kibana

sh kibana --allow-root

1.2.2 管理集群

1、打开Kibana，点开 Stack Monitoring 集群监控


2、点击【Nodes】查看节点详细信息

在上图可以看到，第一个红框处显示【Green】，绿色，表示集群处理健康状态

第二个红框是我们集群的三个节点，注意，itcast-3旁边是星星，表示是主节点

1.1-集群介绍

• 集群和分布式：

​ 集群：多个人做一样的事。

​ 分布式：多个人做不一样的事

• 集群解决的问题：

​ 让系统高可用

​ 分担请求压力

• 分布式解决的问题：

​ 分担存储和计算的压力，提速

​ 解耦

• 集群和分布式架构往往是并存的

1.2-ES集群相关概念

es 集群:

•ElasticSearch 天然支持分布式

•ElasticSearch 的设计隐藏了分布式本身的复杂性

ES集群相关概念:

•集群（cluster）：一组拥有共同的 cluster name 的 节点。

•节点（node) ：集群中的一个 Elasticearch 实例

•索引（index) ：es存储数据的地方。相当于关系数据库中的database概念

•分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中

•主分片（Primary shard）：相对于副本分片的定义。

•副本分片（Replica shard）每个主分片可以有一个或者多个副本，数据和主分片一样。

1.3-kibina管理集群

vim  kibana-7.4.0-linux-x86_64-cluster/config/kibana.yml

kibana.yml

#支持中文
i18n.locale: "zh-CN"
#5602避免与之前的冲突
server.port: 5602
server.host: "0.0.0.0"
server.name: "kibana-itcast-cluster"
elasticsearch.hosts: ["http://localhost:9201","http://localhost:9202","http://localhost:9203"]
elasticsearch.requestTimeout: 99999

2.1 ElasticSearch集群介绍

• 主节点（或候选主节点）

主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作， 主节点负荷相对较
轻， 客户端请求可以直接发往任何节点， 由对应节点负责分发和返回处理结果。
一个节点启动之后， 采用 Zen Discovery机制去寻找集群中的其他节点， 并与之建立连接， 集群
会从候选主节点中选举出一个主节点， 并且一个集群只能选举一个主节点， 在某些情况下， 由于
网络通信丢包等问题， 一个集群可能会出现多个主节点， 称为“脑裂现象”， 脑裂会存在丢失数据
的可能， 因为主节点拥有最高权限， 它决定了什么时候可以创建索引， 分片如何移动等， 如果存
在多个主节点， 就会产生冲突， 容易产生数据丢失。要尽量避免这个问题， 可以通过
discovery.zen.minimum_master_nodes 来设置最少可工作的候选主节点个数。 建议设置为（候
选主节点/2） + 1 比如三个候选主节点，该配置项为 （3/2）+1 ,来保证集群中有半数以上的候选主
节点， 没有足够的master候选节点， 就不会进行master节点选举，减少脑裂的可能。
主节点的参数设置：

node.master = true 
node.data = false 

• 数据节点

数据节点负责数据的存储和CRUD等具体操作，数据节点对机器配置要求比较高、，首先需要有足
够的磁盘空间来存储数据，其次数据操作对系统CPU、Memory和IO的性能消耗都很大。通常随着
集群的扩大，需要增加更多的数据节点来提高可用性。
数据节点的参数设置：

node.master = false 
node.data = true 

• 客户端节点

客户端节点不做候选主节点， 也不做数据节点的节点，只负责请求的分发、汇总等等，增加客户端
节点类型更多是为了负载均衡的处理。

node.master = false 
node.data = false 

• 提取节点（预处理节点）

能执行预处理管道，有自己独立的任务要执行， 在索引数据之前可以先对数据做预处理操作， 不负责数据存储也不负责集群相关的事务。
参数设置：

node.ingest = true

• 协调节点

协调节点，是一种角色，而不是真实的Elasticsearch的节点，不能通过配置项来指定哪个节点为协调节点。集群中的任何节点，都可以充当协调节点的角色。当一个节点A收到用户的查询请求后，会把查询子句分发到其它的节点，然后合并各个节点返回的查询结果，最后返回一个完整的数据集给用户。在这个过程中，节点A扮演的就是协调节点的角色。

ES的一次请求非常类似于Map-Reduce操作。在ES中对应的也是两个阶段，称之为scatter-gather。客户端发出一个请求到集群的任意一个节点，这个节点就是所谓的协调节点，它会把请求转发给含有相关数据的节点(scatter阶段)，这些数据节点会在本地执行请求然后把结果返回给协调节点。协调节点将这些结果汇总(reduce)成一个单一的全局结果集(gather阶段) 。

• 部落节点

在多个集群之间充当联合客户端， 它是一个特殊的客户端 ， 可以连接多个集群，在所有连接的集群上执行搜索和其他操作。 部落节点从所有连接的集群中检索集群状态并将其合并成全局集群状态。 掌握这一信息，就可以对所有集群中的节点执行读写操作，就好像它们是本地的。 请注意，部落节点需要能够连接到每个配置的集群中的每个单个节点。

2.2 ElasticSearch集群原理

2.2.1 集群分布式原理

ES集群可以根据节点数， 动态调整分片与副本数， 做到整个集群有效均衡负载。
单节点状态下：

两个节点状态下， 副本数为1：

三个节点状态下， 副本数为1：

三个节点状态下， 副本数为2：

2.2.2 分片处理机制

设置分片大小的时候， 需预先做好容量规划， 如果节点数过多， 分片数过小， 那么新的节点将无法分片， 不能做到水平扩展， 并且单个分片数据量太大， 导致数据重新分配耗时过大。

假设一个集群中有一个主节点、两个数据节点。orders索引的分片分布情况如下所示

PUT orders 
{ 
"settings":{ 
"number_of_shards":2, ## 主分片 
"number_of_replicas":2 ## 副分片 
} 
}

整个集群中存在P0和P1两个主分片， P0对应的两个R0副本分片， P1对应的是两个R1副本分片。

2.2.3 新建索引处理流程

1. 写入的请求会进入主节点， 如果是NODE2副本接收到写请求， 会将它转发至主节点。
2. 主节点接收到请求后， 根据documentId做取模运算（外部没有传递documentId，则会采用内部自增ID），
   如果取模结果为P0，则会将写请求转发至NODE3处理。
3. NODE3节点写请求处理完成之后， 采用异步方式， 将数据同步至NODE1和NODE2节点。

2.2.4 读取索引处理流程

1. 读取的请求进入MASTER节点， 会根据取模结果， 将请求转发至不同的节点。
2. 如果取模结果为R0，内部还会有负载均衡处理机制，如果上一次的读取请求是在NODE1的R0， 那么当前请求会转发至NODE2的R0， 保障每个节点都能够均衡的处理请求数据。
3. 读取的请求如果是直接落至副本节点， 副本节点会做判断， 若有数据则返回，没有的话会转发至其他节点处理。

2.5 ElasticSearch集群分片测试

修改kibana的配置文件，指向创建的集群节点：

elasticsearch.hosts: 
["http://192.168.116.140:9200","http://192.168.116.140:9201","http://192.168.116.140:9202"] 

重启kibana服务， 进入控制台：
http://192.168.116.140:5601/app/home#/
再次创建索引（副本数量范围内）：

PUT orders 
{ 
"settings": { 
"index": { 
"number_of_shards": 2, 
"number_of_replicas": 2 
} 
} 
}

可以看到， 这次结果是正常：

集群并非可以随意增加副本数量， 创建索引（超出副本数量范围）：

PUT orders 
{ 
"settings": { 
"index": { 
"number_of_shards": 2, 
"number_of_replicas": 5 
} 
} 
}

可以看到出现了yellow警告错误：

3. ELK部署应用与工作机制

3.1 ELK日志分析平台介绍

ELK是三个开源软件的缩写，分别表示：Elasticsearch , Logstash和Kibana。Elasticsearch和Kibana我们上面做过讲解。 Logstash 主要是用来日志的搜集、分析、过滤日志的工具，适用大数据量场景，
一般采用c/s模式，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作， 再一并发往Elasticsearch上做数据分析。
一个完整的集中式日志系统，需要包含以下几个主要特点：

• 收集－能够采集多种来源的日志数据
• 传输－能够稳定的把日志数据传输到中央系统
• 存储－如何存储日志数据
• 分析－可以支持 UI 分析
• 警告－能够提供错误报告，监控机制

ELK提供了一整套解决方案，并且都是开源软件，之间互相配合使用，完美衔接，高效的满足了很多场合的应用，是目前主流的一种日志分析平台。

3.2 ELK部署架构模式

3.2.1 简单架构

这是最简单的一种ELK部署架构方式， 由Logstash分布于各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。 优点是搭建简单， 易于上手， 缺点是Logstash耗资源较大， 依赖性强， 没有消息队列缓存， 存在数据丢失隐患

3.2.2 消息队列架构

该队列架构引入了KAFKA消息队列， 解决了各采集节点上Logstash资源耗费过大， 数据丢失的问题，各终端节点上的Logstash Agent 先将数据/日志传递给Kafka， 消息队列再将数据传递给Logstash，Logstash过滤、分析后将数据传递给Elasticsearch存储， 由Kibana将日志和数据呈现给用户。

3.2.3 BEATS架构

该架构的终端节点采用Beats工具收集发送数据， 更灵活，消耗资源更少，扩展性更强。同时可配置Logstash 和Elasticsearch 集群用于支持大集群系统的运维日志数据监控和查询， 官方也推荐采用此工具， 本章我们采用此架构模式进行配置讲解（如果在生产环境中， 可以再增加kafka消息队列， 实现了beats+消息队列的部署架构 ）。
Beats工具包含四种：
1、Packetbeat（搜集网络流量数据）
2、Topbeat（搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据）
3、Filebeat（搜集文件数据）
4、Winlogbeat（搜集 Windows 事件日志数据）

3.3 ELK工作机制

3.3.1 Filebeat工作机制

Filebeat由两个主要组件组成：prospectors（勘测者） 和 harvesters（收割机）。这两个组件协同工作将文件变动发送到指定的输出中。

Harvester（收割机）：负责读取单个文件内容。每个文件会启动一个Harvester，每个Harvester会逐行读取各个文件，并将文件内容发送到制定输出中。Harvester负责打开和关闭文件，意味在Harvester运行的时候，文件描述符处于打开状态，如果文件在收集中被重命名或者被删除，Filebeat会继续读取
此文件。所以在Harvester关闭之前，磁盘不会被释放。默认情况filebeat会保持文件打开的状态，直到达到close_inactive
filebeat会在指定时间内将不再更新的文件句柄关闭，时间从harvester读取最后一行的时间开始计时。若文件句柄被关闭后，文件发生变化，则会启动一个新的harvester。关闭文件句柄的时间不取决于文件的修改时间，若此参数配置不当，则可能发生日志不实时的情况，由scan_frequency参数决定，默认10s。Harvester使用内部时间戳来记录文件最后被收集的时间。例如：设置5m，则在Harvester读取文件的最后一行之后，开始倒计时5分钟，若5分钟内文件无变化，则关闭文件句柄。默认5m】。
Prospector（勘测者）：负责管理Harvester并找到所有读取源。

filebeat.prospectors: 
- input_type: log 
  paths: 
    - /apps/logs/*/info.log 

Prospector会找到/apps/logs/*目录下的所有info.log文件，并为每个文件启动一个Harvester。
Prospector会检查每个文件，看Harvester是否已经启动，是否需要启动，或者文件是否可以忽略。若Harvester关闭，只有在文件大小发生变化的时候Prospector才会执行检查。只能检测本地的文件。

Filebeat如何记录发送状态：
将文件状态记录在文件中（默认在/var/lib/filebeat/registry）。此状态可以记住Harvester收集文件的偏移量。若连接不上输出设备，如ES等，filebeat会记录发送前的最后一行，并再可以连接的时候继续发送。
Filebeat在运行的时候，Prospector状态会被记录在内存中。Filebeat重启的时候，利用registry记录的状态来进行重建，用来还原到重启之前的状态。每个Prospector会为每个找到的文件记录一个状态，对于每个文件，Filebeat存储唯一标识符以检测文件是否先前被收集。

Filebeat如何保证数据发送成功：
Filebeat之所以能保证事件至少被传递到配置的输出一次，没有数据丢失，是因为filebeat将每个事件的传递状态保存在文件中。在未得到输出方确认时，filebeat会尝试一直发送，直到得到回应。若filebeat在传输过程中被关闭，则不会再关闭之前确认所有时事件。任何在filebeat关闭之前未确认的事件，都会在filebeat重启之后重新发送。这可确保至少发送一次，但有可能会重复。可通过设置shutdown_timeout 参数来设置关闭之前的等待事件回应的时间（默认禁用）。

3.3.2 Logstash工作机制

Logstash事件处理有三个阶段：inputs → filters → outputs。是一个接收，处理，转发日志的工具。支持系统日志，webserver日志，错误日志，应用日志等。

Input：输入数据到logstash。
支持的输入类型：
file：从文件系统的文件中读取，类似于tail -f命令
syslog：在514端口上监听系统日志消息，并根据RFC3164标准进行解析
redis：从redis service中读取
beats：从filebeat中读取

Filters：数据中间处理，对数据进行操作。
一些常用的过滤器为：
grok：解析任意文本数据，Grok 是 Logstash 最重要的插件。它的主要作用就是将文本格式的字符串，
转换成为具体的结构化的数据，配合正则表达式使用。内置120多个解析语法。

官方提供的grok表达式
mutate：对字段进行转换。例如对字段进行删除、替换、修改、重命名等。
drop：丢弃一部分events不进行处理。
clone：拷贝 event，这个过程中也可以添加或移除字段。
geoip：添加地理信息(为前台kibana图形化展示使用)

Outputs：outputs是logstash处理管道的最末端组件。
一个event可以在处理过程中经过多重输出，但是一旦所有的outputs都执行结束，这个event也就完成生命周期。
常见的outputs为：
elasticsearch：可以高效的保存数据，并且能够方便和简单的进行查询。
file：将event数据保存到文件中。
graphite：将event数据发送到图形化组件中，一个很流行的开源存储图形化展示的组件。

Codecs：codecs 是基于数据流的过滤器，它可以作为input，output的一部分配置。
Codecs可以帮助你轻松的分割发送过来已经被序列化的数据。
常见的codecs：
json：使用json格式对数据进行编码/解码。
multiline：将多个事件中数据汇总为一个单一的行。比如：java异常信息和堆栈信息。

3.4 Logstash安装配置

在192.168.116.141机器节点上进行安装：

1. 下载解压
   下载：

cd /usr/local 
wget https://artifacts.elastic.co/downloads/logstash/logstash-7.10.2-linux-x86_64.tar.gz 

解压：

tar -xvf logstash-7.10.2-linux-x86_64.tar.gz

2. 创建数据存储与日志记录目录

[root@localhost logstash-7.10.2]# mkdir -p /usr/local/logstash-7.10.2/data 
[root@localhost logstash-7.10.2]# mkdir -p /usr/local/logstash-7.10.2/logs

3. 修改配置文件：

vi /usr/local/logstash-7.10.2/config/logstash.yml

配置内容：

# 数据存储路径 
path.data: /usr/local/logstash-7.10.2/data 
# 监听主机地址 
http.host: "192.168.116.141" 
# 日志存储路径 
path.logs: /usr/local/logstash-7.10.2/logs 
#启动监控插件 
xpack.monitoring.enabled: true 
#Elastic集群地址 
xpack.monitoring.elasticsearch.hosts: 
["http://192.168.116.140:9200","http://192.168.116.140:9201","http://192.168.116.140:9202"] 

4. 创建监听配置文件：

vi /usr/local/logstash-7.10.2/config/logstash.conf

配置

input { 
  beats { 
    # 监听端口 
    port => 5044 
  } 
}
output { 

  stdout { 
  # 输出编码插件 
  codec => rubydebug 
}

  elasticsearch { 
  # 集群地址 
  hosts => 
["http://192.168.116.140:9200","http://192.168.116.140:9201","http://192.168.116.140:9202"] 
   } 
}

5. 启动服务：
   以root用户身份执行：

## 后台启动方式 
nohup /usr/local/logstash-7.10.2/bin/logstash -f /usr/local/logstash- 
7.10.2/config/logstash.conf & 
##
./logstash -f ../config/logstash.conf

成功启动后会显示以下日志：

[2020-10-15T06:57:40,640][INFO ][logstash.agent ] Successfully 
started Logstash API endpoint {:port=>9600}

访问地址： http://192.168.116.141:9600/, 可以看到返回信息：

3.5 Filebeat安装配置

在192.168.116.141机器节点上操作：

1. 下载解压
   与ElasticSearch版本一致， 下载7.10.2版本。

cd /usr/local 
wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.10.2-linux-x86_64.tar.gz 

解压：

tar -xvf filebeat-7.10.2-linux-x86_64.tar.gz

2. 修改配置文件

vi /usr/local/filebeat-7.10.2/filebeat.yml 

修改内容：

# 需要收集发送的日志文件 
filebeat.inputs: 
- type: log 
enabled: true 
paths: 
- /var/log/messages 
# 如果需要添加多个日志，只需要添加 
- type: log 
enabled: true 
paths: 
- /var/log/test.log 
# filebeat 配置模块， 可以加载多个配置 
filebeat.config.modules: 
path: ${path.config}/modules.d/*.yml 
reload.enabled: false 
# 索引分片数量设置 
setup.template.settings: 
index.number_of_shards: 2 
# kibana 信息配置 
setup.kibana: 
host: "192.168.116.140:5601" 
# logstash 信息配置 （注意只能开启一项output设置， 如果采用logstash, 将 
output.elasticsearch关闭） 
output.logstash: 
hosts: ["192.168.116.141:5044"] 
# 附加metadata元数据信息 
processors: 
- add_host_metadata: ~ 
- add_cloud_metadata: ~ 

3. 启动服务

## 后台启动 
nohup /usr/local/filebeat-7.10.2/filebeat -e -c /usr/local/filebeat- 
7.10.2/filebeat.yml & 
##
./filebeat -e -c filebeat.yml

启动成功后显示日志：

2020-12-15T07:09:33.922-0400 WARN beater/filebeat.go:367 Filebeat is 
unable to load the Ingest Node pipelines for the configured modules because 
the Elasticsearch output is not configured/enabled. If you have already 
loaded the Ingest Node pipelines or are using Logstash pipelines, you can 
ignore this warning. 
2020-12-15T07:09:33.922-0400 INFO crawler/crawler.go:72 Loading 
Inputs: 1 
2020-12-15T07:09:33.923-0400 INFO log/input.go:148 Configured 
paths: [/var/log/messages] 
2020-12-15T07:09:33.923-0400 INFO input/input.go:114 Starting 
input of type: log; ID: 14056778875720462600 
2020-12-15T07:09:33.924-0400 INFO crawler/crawler.go:106 Loading and 
starting Inputs completed. Enabled inputs: 1 
2020-12-15T07:09:33.924-0400 INFO cfgfile/reload.go:150 Config 
reloader started

我们监听的是/var/log/messages系统日志信息， 当日志发生变化后， filebeat会通过logstash上
报到Elasticsearch中。 我们可以查看下集群的全部索引信息：
http://192.168.116.140:9200/_cat/indices?v

可以看到， 已经生成了名为logstash-2021.07.20-000001索引。

3.6 Kibana配置与查看数据

1. 进入Kibana后台， 进行配置：
   http://192.168.116.140:5601
   
   进入【Management】–> 在Index Pattern中输入"logstash-*" --> 点击【next step】, 选 择"@timestamp",
   
   点击【 Create index pattern 】进行创建。
   
2. 查看数据
   进入【Discover】, 可以查看到收集的数据：
   
   如果没有显示， 可以重新调整Time Range时间范围。

4.5-JavaAPI 访问集群

PUT cluster_test
{
  "mappings": {
    "properties": {
      "name":{
        "type": "text"
      }
    }
  }
}

GET cluster_test
GET cluster_test/_search

POST /cluster_test/_doc/1
{
  "name":"张三"
}

测试类

 
    @Resource(name="clusterClient")
    RestHighLevelClient clusterClient;
 
 /**
     * 测试集群
     * @throws IOException
     */
    @Test
    public void testCluster() throws IOException {


        //设置查询的索引、文档
        GetRequest indexRequest=new GetRequest("cluster_test","1");

        GetResponse response = clusterClient.get(indexRequest, RequestOptions.DEFAULT);
        System.out.println(response.getSourceAsString());

    }

ElasticSearchConfig

private String host1;

private int port1;

private String host2;

private int port2;

private String host3;

private int port3;

//get/set ...

@Bean("clusterClient")
    public RestHighLevelClient clusterClient(){
        return new RestHighLevelClient(RestClient.builder(
                new HttpHost(host1,port1,"http"),
                new HttpHost(host2,port2,"http"),
                new HttpHost(host3,port3,"http")
        ));
    }

application.yml

elasticsearch:
   host: 192.168.140.130
   port: 9200
   host1: 192.168.140.130
   port1: 9201
   host2: 192.168.140.130
   port2: 9202
   host3: 192.168.140.130
   port3: 9203

4.6-分片配置

•在创建索引时，如果不指定分片配置，则默认主分片1，副本分片1。

•在创建索引时，可以通过settings设置分片



分片配置

#分片配置
#"number_of_shards": 3, 主分片数量
#"number_of_replicas": 1  主分片备份数量，每一个主分片有一个备份
# 3个主分片+3个副分片=6个分片
PUT cluster_test1
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  }, 
  "mappings": {
    "properties": {
      "name":{
        "type": "text"
      }
    }
  }
}

1.三个节点正常运行（0、1、2分片标号）

2.itcast-3 挂掉


分片与自平衡

•当节点挂掉后，挂掉的节点分片会自平衡到其他节点中

注意：分片数量一旦确定好，不能修改。

索引分片推荐配置方案：

1.每个分片推荐大小10-30GB

2.分片数量推荐 = 节点数量 * 1~3倍

思考：比如有1000GB数据，应该有多少个分片？多少个节点

1.每个分片20GB 则可以分为40个分片

2.分片数量推荐 = 节点数量 * 1~3倍 --> 40/2=20 即20个节点

4.7-路由原理

路由原理

•文档存入对应的分片，ES计算分片编号的过程，称为路由。

•Elasticsearch 是怎么知道一个文档应该存放到哪个分片中呢？

•查询时，根据文档id查询文档， Elasticsearch 又该去哪个分片中查询数据呢？

•路由算法 ：shard_index = hash(id) % number_of_primary_shards

查询id为5的文档：假如hash(5)=17 ，根据算法17%3=2

4.8-脑裂

ElasticSearch 集群正常状态：

• 一个正常es集群中只有一个主节点（Master），主节点负责管理整个集群。如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。

•集群的所有节点都会选择同一个节点作为主节点。

脑裂现象：

•脑裂问题的出现就是因为从节点在选择主节点上出现分歧导致一个集群出现多个主节点从而使集群分裂，使得集群处于异常状态。

脑裂产生的原因：

1.网络原因：网络延迟

​ •一般es集群会在内网部署，也可能在外网部署，比如阿里云。

​ •内网一般不会出现此问题，外网的网络出现问题的可能性大些。

2.节点负载

​ •主节点的角色既为master又为data。数据访问量较大时，可能会导致Master节点停止响应（假死状态）。

3. JVM内存回收

•当Master节点设置的JVM内存较小时，引发JVM的大规模内存回收，造成ES进程失去响应。

避免脑裂：

1.网络原因：discovery.zen.ping.timeout 超时时间配置大一点。默认是3S

2.节点负载：角色分离策略

​ •候选主节点配置为

​ •node.master: true

​ •node.data: false

​ •数据节点配置为

​ •node.master: false

​ •node.data: true

3.JVM内存回收：修改 config/jvm.options 文件的 -Xms 和 -Xmx 为服务器的内存一半。