目录
ELK日志分析-简介
1.实验环境
2.Elasticsearch的部署
下载安装
配置
3.图形插件安装
1.容器方法
2.直接安装
4.优化
1.节点
2.集群
3.节点优化
ELK日志分析-简介
Elasticsearch是与名为Logstash的数据收集和日志解析引擎以及名为Kibana的分析和可视化平台一起开发的。这三个产品被设计成一个集成解决方案,称为“Elastic Stack”(以前称为“ELK stack”)。
ElasticSearch:是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于RESTful web接口。Elasticsearch是用Java开发的,并作为Apache许可条款下的开放源码发布,是当前流行的企业级搜索引擎。设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便。
Logstash:是一个具有实时渠道能力的数据收集引擎,主要用于日志的收集与解析,并将其存入 ElasticSearch中。与ElasticSearch有很高的适配性。
Kibana:是一款基于 Apache 开源协议,使用 Javascript 语言编写,为 Elasticsearch提供分析和可视化的 Web 平台。它可以在 Elasticsearch 的索引中查找,交互数据,并生成各种维度的表图。
1.实验环境三台纯净的rhel7.6
2.Elasticsearch的部署 下载安装下载中心 - Elastic 中文社区https://elasticsearch.cn/download/这里下载了7.6.1
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.6.1-x86_64.rpm yum install elasticsearch-7.6.1-x86_64.rpm -y systemctl daemon-reload配置
编辑yml文件,重启服务报错
17 cluster.name: my-es 集群名 23 node.name: server1 主机名本地解析 43 bootstrap.memory_lock: true 锁定内存 生产环境 http.port: 9200 55 network.host: 0.0.0.0 68 discovery.seed_hosts: ["server1", "server2","server3"] 72 cluster.initial_master_nodes: ["server1", "server2","server3"] 初始化的master取值
查看日志分析
cat /var/log/elasticsearch/my-es.log
[1]: memory locking requested for elasticsearch process but memory is not locked
根据日志提示修改
vim /etc/security/limits.conf
内存足够将swap分区禁掉
[root@server1 elasticsearch]# vim /etc/fstab [root@server1 elasticsearch]# mount -a
Disable swapping | Elasticsearch Guide [7.6] | Elastichttps://www.elastic.co/guide/en/elasticsearch/reference/7.6/setup-configuration-memory.html编辑systemd件,找到路径
systemctl status elasticsearch.service
vim /usr/lib/systemd/system/elasticsearch.service
LimitMEMLOCK=infinity加进去
cat /usr/lib/systemd/system/elasticsearch.service
左下角的并发数和进程数限制写进 /etc/security/limits.conf
vim /etc/security/limits.conf
开启服务
systemctl daemon-reload systemctl restart elasticsearch.service
再次查看日志
查看端口
netstat -antlp
测试
单机集群部署成功
其他两台机器同样部署
server1 scp elasticsearch-7.6.1-x86_64.rpm server2:/root server2 yum install elasticsearch-7.6.1-x86_64.rpm -y server1 scp /etc/elasticsearch/elasticsearch.yml server2:/etc/elasticsearch/elasticsearch.yml scp /etc/security/limits.conf server2:/etc/security/limits.conf scp /etc/fstab server2:/etc/fstab scp /usr/lib/systemd/system/elasticsearch.service server2:/usr/lib/systemd/system/elasticsearch.service 修改yml文件对应主机名即可
测试
3.图形插件安装使用podman拉取cerbro
podman pull docker.io/lmenezes/cerebro podman images podman run -d --name cerbro -p 9000:9000 docker.io/lmenezes/cerebro
浏览器进入
http://172.25.7.250:9000
需要输入密码
http://172.25.7.1:9200
cat api看master 为server2
安装 heald 浏览插件
1.容器方法podman pull docker.io/mobz/elasticsearch-head:5 podman run -d --name head -p 9100:9100 docker.io/mobz/elasticsearch-head:5 podman history docker.io/mobz/elasticsearch-head:5 可以看到端口是9100
访问http://172.25.7.250:9100无法连接
修改配置文件
vim /etc/elasticsearch/elasticsearch.yml systemctl daemon-reload systemctl restart elasticsearch.service
连接server1
无法索引
2.直接安装rpm -ivh nodejs-9.11.2-1nodesource.x86_64.rpm
解压准备好的master
yum install unzip -y unzip elasticsearch-head-master.zip
cd elasticsearch-head-master/ cnpm install换源安装 失败 yum install bzip2 -y cnpm install 成功 cnpm run start & 打入后台运行
http://172.25.7.1:9100
建立索引
4.优化 1.节点Master: 主要负责集群中索引的创建、删除以及数据的Rebalance等 *** 作。Master不负责数据的索引和检索,所以负载较轻。当Master节点失联或者挂掉的时候,ES集群会自动从其他Master节点选举出一个Leader。
Data Node: 主要负责集群中数据的索引和检索,一般压力比较大。
Coordinating Node: 原来的Client node的,主要功能是来分发请求和合并结果的。所有节点默认就是Coordinating node,且不能关闭该属性。
ngest Node: 专门对索引的文档做预处理
2.集群Cluster:集群,包含多个节点,每个节点属于哪个集群是通过一个配置(集群名称,默认是elasticsearch)来决定的
Node:节点(简单理解为集群中的一个服务器),集群中的一个节点,节点也有一个名称(默认是随机分配的),节点名称很重要(在执行运维管理 *** 作的时候),默认节点会去加入一个名称为“elasticsearch”的集群,如果直接启动一堆节点,那么它们会自动组成一个elasticsearch集群,当然一个节点也可以组成一个elasticsearch集群。
Index:索引(简单理解就是一个数据库),包含一堆有相似结构的文档数据,比如可以有一个客户索引,商品分类索引,订单索引,索引有一个名称。一个index包含很多document,一个index就代表了一类类似的或者相同的document。比如说建立一个product index,商品索引,里面可能就存放了所有的商品数据,所有的商品document。
3.节点优化在生产环境下,如果不修改elasticsearch节点的角色信息,在高数据量,高并发的场景下集群容易出现脑裂等问题。默认情况下,elasticsearch集群中每个节点都有成为主节点的资格,也都存储数据,还可以提供查询服务。
节点角色是由以下属性控制:
• node.master: false|true
• node.data: true|false
• node.ingest: true|false
• search.remote.connect: true|false
默认情况下这些属性的值都是true
node.master:这个属性表示节点是否具有成为主节点的资格
注意:此属性的值为true,并不意味着这个节点就是主节点。因为真正的主节点,是由多个具有主节点资格的节点进行选举产生的。
node.data:这个属性表示节点是否存储数据。
node.ingest: 是否对文档进行预处理。
search.remote.connect:是否禁用跨集群查询
四种组合
默认: pass掉
• node.master: true
• node.data: true
• node.ingest: true
• search.remote.connect: true
这种组合表示这个节点即有成为主节点的资格,又存储数据。
如果某个节点被选举成为了真正的主节点,那么他还要存储数据,这样对于这个节点的压力就比较大了。
测试环境下这样做没问题,但实际工作中不建议这样设置。
data节点
• node.master: false
• node.data: true
• node.ingest: false
• search.remote.connect: false
这种组合表示这个节点没有成为主节点的资格,也就不参与选举,只会存储数据。
这个节点称为data(数据)节点。在集群中需要单独设置几个这样的节点负责存储数据。后期提供存储和查询服
master节点
第三种组合:(master node)
• node.master: true
• node.data: false
• node.ingest: false
• search.remote.connect: false
这种组合表示这个节点不会存储数据,有成为主节点的资格,可以参与选举,有可能成为真正的主节点。
这个节点我们称为master节点。
(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节点,对索引的文档做处理。
对已知的三个节点进行优化,server1不存储,预处理,可以选举为master
如果有数据要删除,我在面板上删除了
在server1上删除
cd /usr/share/elasticsearch/bin systemctl stop elasticsearch.service 必要时工具也要停掉 ./elasticsearch-node repurpose
vim /etc/elasticsearch/elasticsearch.yml
重启服务
server2和server3
配置可以存储,不可以预处理
node.master: true node.data: true node.ingest: false node.ml: false
重启服务
刷新server成为master
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)