日志分析系统ELK之Elasticsearch
Elasticsearch
-
- 什么是ELK
- Elasticsearch
-
- Elasticsearch基础模块
- elasticsearch应用场景
- Elasticsearch单节点部署
- Elasticsearch集群的部署
-
- 集群简介
- elasticsearch节点角色
- 集群部署
- 可视化工具cerebro
- 可视化工具elasticsearch-head插件
- 索引、分片和副本
- Elasticsearch节点优化
-
- 第一种组合：（默认）
- 第二种组合：（Data node）
- 第三种组合：（master node）
- 第四种组合：（Coordinating Node）
- 第五种组合：（Ingest Node）
- 建议
什么是ELK
一般我们需要进行日志分析场景：直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。
一般大型系统是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。
ELK提供了一整套解决方案，并且都是开源软件，之间互相配合使用，完美衔接，高效的满足了很多场合的应用。目前主流的一种日志系统。
ELK是三个开源软件的缩写，分别表示：Elasticsearch , Logstash, Kibana , 它们都是开源软件。
Elasticsearch
官方文档：https://www.elastic.co/guide/en/elasticsearch/reference/6.0/getting-started.html
Elasticsearch 是一个开源的分布式搜索分析引擎，建立在一个全文搜索引擎库 Apache Lucene基础之上。，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。（主要是存储日志）
Elasticsearch 不仅仅是 Lucene，并且也不仅仅只是一个全文搜索引擎：
- 一个分布式的实时文档存储，每个字段 可以被索引与搜索
- 一个分布式实时分析搜索引擎
- 能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据
Elasticsearch基础模块
- cluster：管理集群状态，维护集群层面的配置信息。
- alloction：封装了分片分配相关的功能和策略。
- discovery：发现集群中的节点，以及选举主节点。
- gateway：对收到master广播下来的集群状态数据的持久化存储。
- indices：管理全局级的索引设置。
- http：允许通过JSON over HTTP的方式访问ES的API。
- transport：用于集群内节点之间的内部通信。
- engine：封装了对Lucene的操作及translog的调用。
elasticsearch应用场景
- 信息检索
- 日志分析
- 业务数据分析
- 数据库加速
- 运维指标监控
Elasticsearch单节点部署
需要下载的软件包可以去官网下载，本次演示下载的是7.6.1版本
官网地址：
https://elasticsearch.cn/download/
安装软件包
进入目录编辑yaml配置文件
需要更改的地方如下图所示（没有锁定内存），设置集群名称为my-es，节点名称为server1
任何主机都可以访问，http端口为9200，发现的主机有server1、server2，初始化节点为server1
启动服务成功（占用内存较大）
elasticsearch服务浏览器访问成功！
Elasticsearch集群的部署
集群简介
集群是一个或多个节点（服务器）的集合，它们共同保存整个数据并提供跨所有节点的联合索引和搜索功能。集群由唯一名称标识，默认情况下为“elasticsearch”(我设置的是my-es)。
节点是单个服务器，它是集群的一部分，存储数据，并参与集群的索引和搜索功能。就像集群一样，节点由名称标识，默认情况下，该名称是在启动时分配给节点的随机通用唯一标识符 (UUID)。如果不想要默认值，可以定义任何想要的节点名称。此名称对于管理目的很重要，希望识别网络中的哪些服务器对应于 Elasticsearch 集群中的哪些节点。
可以将节点配置为通过集群名称加入特定集群。默认情况下，每个节点都被设置为加入一个名为elasticsearch的集群，这意味着如果在网络上启动多个节点并且——假设它们可以相互发现——它们都将自动形成并加入一个名为elasticsearch的集群。
elasticsearch节点角色
-
Master：
主要负责集群中索引的创建、删除以及数据的Rebalance等操作。Master不负责数据的索引和检索，所以负载较轻。当Master节点失联或者挂掉的时候，ES集群会自动从其他Master节点选举出一个Leader。 -
Data Node：
主要负责集群中数据的索引和检索，一般压力比较大。 -
Coordinating Node：
原来的Client node的，主要功能是来分发请求和合并结果的。所有节点默认就是Coordinating node，且不能关闭该属性。 -
Ingest Node：
专门对索引的文档做预处理
集群部署
集群节点，最好部署三台，我这里只部署了两台
server1 192.128.122.11
server2 192.168.122.12
server1已经配好，在另外一台虚拟机也同样安装Elasticsearch，编辑配置文件
成功启动服务
浏览器访问成功！
限制内存（选做）：
直接运行内存较大，如果内存不太够，可以锁定内存
[root@server1 elasticsearch]# pwd
/etc/elasticsearch
[root@server1 elasticsearch]# vim elasticsearch.yml
开启锁存
修改系统的资源限制文件
[root@server1 elasticsearch]# vim /etc/security/limits.conf
elasticsearch soft memlock unlimited
elasticsearch hard memlock unlimited
elasticsearch - nofile 65536
elasticsearch - nproc 4096
修改systemd启动文件
[root@server1 elasticsearch]# systemctl status elasticsearch.service
[root@server1 elasticsearch]# vim /usr/lib/systemd/system/elasticsearch.service
LimitMEMLOCK=infinity
进入配置目录，修改Xmx和Xms
-Xmx用来设置你的应用程序(不是JVM)能够使用的最大内存数，如果你的程序要花很大内存的话，那就需要修改缺省的设置，比如配置tomcat的时候，如果流量啊程序啊都很大的话就需要加大这个值了，但是不要超过你的机器的内存。
-Xms用来设置程序初始化的时候内存栈的大小，增加这个值的话你的程序的启动性能会得到提高。不过同样有前面的限制，以及受到-Xmx的限制。
Xmx设置不超过物理RAM的50％，以确保有足够的物理RAM留给内核文件系统缓存。但不要超过32G。
[root@server1 elasticsearch]# pwd
/etc/elasticsearch
[root@server1 elasticsearch]# vim jvm.options
如果你的电脑性能还可以，内存也够用，可以关闭swap分区，用起来会更流畅
[root@server1 elasticsearch]# swapoff -a
[root@server1 elasticsearch]# vim /etc/fstab
[root@server1 elasticsearch]# systemctl daemon-reload
重新启动服务
[root@server1 elasticsearch]# systemctl restart elasticsearch.service
[root@server1 elasticsearch]# systemctl status elasticsearch.service
web访问成功
可视化工具cerebro
使用curl等客户端工具即可通过Restful API对Elasticsearch进行操作，但也有一些客户端工具提供对于ElasticSearch更加友好的可视化操作支持，比如cerebro。
直接在真机使用docker镜像使用会很方便（真机rhel8的系统，自带docker，但不叫docker，叫podman），在真机器拉取镜像并导入
使用下面的命令运行该服务
podman run -d --name cerebro -p 9000:9000 lmenezes/cerebro
在浏览器端直接访问本地9000端口成功
输入节点地址，输入server1的
进入可以看到server1目前是master端，如果server1此时挂掉，那么master就会转移，这里两台的不建议尝试
点击node可以查看节点状态
可视化工具elasticsearch-head插件
下载elasticsearch-head插件，head插件本质上是一个nodejs的工程，因此需要安装node。
#下载node
[root@server1 ~]# wget https://mirrors.tuna.tsinghua.edu.cn/nodesource/rpm_9.x/el/7/x86_64/nodejs-9.11.2-1nodesource.x86_64.rpm
[root@server1 ~]# rpm -ivh nodejs-9.11.2-1nodesource.x86_64.rpm
[root@server1 ~]# yum install -y unzip bzip2
#下载head插件
[root@server1 ~]# wget https://github.com/mobz/elasticsearch-head/archive/master.zip
[root@server1 ~]# unzip master.zip
[root@server1 ~]# cd elasticsearch-head-master/
[root@server1 elasticsearch-head-master]# ls
crx Gruntfile.js package.json _site
Dockerfile grunt_fileSets.js plugin-descriptor.properties src
Dockerfile-alpine index.html proxy test
elasticsearch-head.sublime-project LICENCE README.textile
#由于npm慢，所以更换为cnpm源
[root@server1 elasticsearch-head-master]# npm install -g cnpm --registry=https://registry.npm.taobao.org
[root@server1 elasticsearch-head-master]# cnpm -v #查看版本
#npm（node package manager）：nodejs的包管理器，用于node插件管理（包括安装、卸载、管理依赖等）
#cnpm：是一个完整 npmjs.org 镜像，可以用此代替官方版本(只读)，同步频率目前为 10分钟 一次以保证尽量与官方服务同步。”
[root@server1 elasticsearch-head-master]# cnpm install
[root@server1 elasticsearch-head-master]# cnpm run start & #后台运行head工具
[root@server1 elasticsearch-head-master]# cd /etc/elasticsearch/
[root@server1 elasticsearch]# vim elasticsearch.yml #修改主配置文件，如下图
http.cors.enabled: true
http.cors.allow-origin: "*"
[root@server1 elasticsearch]# systemctl restart elasticsearch.service
允许跨域，*表示支持所有域名
重启服务
网页访问9100端口，监控http://192.168.122.11:9200的elasticsearch（默认是localhost:9200，浏览器用的是真机的所以不能这么写），可以看到集群的两个节点。*代表master节点
索引、分片和副本
索引：
索引是具有某些相似特征的文档的集合。例如，您可以有一个用于客户数据的索引、另一个用于产品目录的索引以及另一个用于订单数据的索引。索引由名称（必须全部小写）标识，在对其中的文档执行索引、搜索、更新和删除操作时，该名称用于引用索引。
在单个集群中，您可以定义任意数量的索引。
分片：
索引可能会存储大量数据，这些数据可能会超出单个节点的硬件限制。例如，占用 1TB 磁盘空间的 10 亿个文档的单个索引可能不适合单个节点的磁盘，或者可能太慢而无法单独处理来自单个节点的搜索请求。
为了解决这个问题，Elasticsearch 提供了将索引细分为多个称为分片的功能。创建索引时，可以简单地定义所需的分片数量。每个分片本身就是一个功能齐全且独立的“索引”，可以托管在集群中的任何节点上。
分片很重要，主要有两个原因：
1、它允许水平拆分/缩放内容量
2、它允许跨分片（可能在多个节点上）分布和并行化操作，从而提高性能/吞吐量
分片的分布机制以及它的文档如何聚合回搜索请求完全由 Elasticsearch 管理，并且对用户是透明的。
副本：
在随时可能出现故障的网络/云环境中，如果分片/节点不知何故脱机或因任何原因消失，则具有故障转移机制非常有用并强烈建议使用。为此，Elasticsearch 允许将索引分片的一个或多个副本制作成所谓的副本分片，或简称为副本。
复制之所以重要，主要有两个原因：
1、它在分片/节点发生故障时提供高可用性。出于这个原因，重要的是要注意副本分片永远不会与复制它的原始/主分片在同一节点上分配。
2、它允许扩展搜索量/吞吐量，因为搜索可以在所有副本上并行执行。
总而言之，每个索引都可以拆分为多个分片。索引也可以复制零次（意味着没有副本）或多次。复制后，每个索引将具有主分片（从中复制的原始分片）和副本分片（主分片的副本）。可以在创建索引时为每个索引定义分片和副本的数量。创建索引后，可以随时动态更改副本数，但事后无法更改分片数。
创建索引
查看ES状态，灰色标识没有副本；黄色代表没有主分片丢失
Elasticsearch节点优化
在生产环境下，如果不修改elasticsearch节点的角色信息，在高数据量，高并发的场景下集群容易出现脑裂（比如多个节点争当master）等问题。
默认情况下，elasticsearch集群中每个节点都有成为主节点的资格，也都存储数据，还可以提供查询服务。
节点角色是由以下属性控制，默认情况下这些属性的值都是true：
node.master: false|true
node.data: true|false
node.ingest: true|false
search.remote.connect: true|false
node.master：这个属性表示节点是否具有成为主节点的资格。
#注意：此属性的值为true，并不意味着这个节点就是主节点。因为真正的主节点，是由多个具有主节点资格的节点进行选举产生的。
#在当前master当掉（其实是假死）的情况下，其他节点选举成为master就会产生脑裂现象。
node.data：这个属性表示节点是否存储数据。
node.ingest: 是否对文档进行预处理。
search.remote.connect：是否禁用跨集群查询。
第一种组合：（默认）
node.master: true
node.data: true
node.ingest: true
search.remote.connect: true
这种组合表示这个节点既有成为主节点的资格，又存储数据。
如果某个节点被选举成为了真正的主节点，那么他还要存储数据，这样对于这个节点的压力就比较大了。
测试环境下这样做没问题，但实际工作中不建议这样设置。
第二种组合：（Data node）
node.master: false
node.data: true
node.ingest: false
search.remote.connect: false
这种组合表示这个节点没有成为主节点的资格，也就不参与选举，只会存储数据。
这个节点称为data(数据)节点。在集群中需要单独设置几个这样的节点负责存储数据。后期提供存储和查询服务。
第三种组合：（master node）
node.master: true
node.data: false
node.ingest: false
search.remote.connect: false
这种组合表示这个节点不会存储数据，有成为主节点的资格，可以参与选举，有可能成为真正的主节点。
这个节点我们称为master节点。
编辑主编配置文件/etc/elasticsearch/elasticsearch.yml，添加node.data: false语句，表示该主机不存放数据
第四种组合：（Coordinating Node）
node.master: false
node.data: false
node.ingest: false
search.remote.connect: false
这种组合表示这个节点即不会成为主节点，也不会存储数据，
这个节点的意义是作为一个协调节点，主要是针对海量请求的时候可以进行负载均衡。
第五种组合：（Ingest Node）
node.master: false
node.data: false
node.ingest: true
search.remote.connect: false
这种组合表示这个节点既不会成为主节点，也不会存储数据，
这个节点的意义是ingest节点，对索引的文档做预处理。
建议
生产集群中可以对这些节点的职责进行划分：
建议集群中设置3台以上的节点作为master节点，只负责成为主节点，维护整个集群的状态。
再根据数据量设置一批data节点，这些节点只负责存储数据，后期提供建立索引和查询索引的服务，这样的话如果用户请求比较频繁，这些节点的压力也会比较大。
所以在集群中建议再设置一批协调节点，这些节点只负责处理用户请求，实现请求转发，负载均衡等功能。
- 节点需求
master节点：普通服务器即可(CPU、内存 消耗一般)
data节点：主要消耗磁盘、内存。
path.data: data1,data2,data3这样的配置可能会导致数据写入不均匀，建议只指定一个数据路径，磁盘可以使用raid0阵列，而不需要成本高的ssd。
Coordinating节点：对cpu、memory要求较高。
调整后的ES集群状态
