企业ELK日志搜索引擎— Elastic Stack 实战手册

本文涉及的产品
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
简介: 通过每个应用服务器上部署 filebeat,上传到 kafka;由 kafka 分发消息到 logstash; Logstatsh 写入日志到 Elasticsearch 集群;

970X90.png

· 更多精彩内容,请下载阅读全本《Elastic Stack实战手册》

· 加入创作人行列,一起交流碰撞,参与技术圈年度盛事吧

创作人:朱祝元
审稿人:朱永生

技术架构

1.png

  • 物理部署:

1master;5 Data;1 Logstash+kibana;3 kafka 3 主 3 从交叉部署

  • 应用框架:

项目采用 springboot 作为基础框架开发分布式应用;

  • 实施方案:

通过每个应用服务器上部署 filebeat,上传到 kafka;由 kafka 分发消息到 logstash; Logstatsh 写入日志到 Elasticsearch 集群;

  • 应用目标:

收集 50 台机器的日志,可以及时发现日志中的错误日志以及日志对应的上下文。

日志解决方案的演进

阶段一、项目上线一切刚开始

每个程序员通过 ssh 将数据 copy 到堡垒机。然后把数据从堡垒机下载到本地处理数据,分析日志;

遇到的问题

  1. 下载日志到本地,文件太大难以处理:每个日志文件大概 500M,这种体量,Windows 上任何文本工具打开都很吃力,还要下载多个文件,下载速率也有很大影响;
  2. 远程服务器上查找,服务器关联多:同一个服务部署的有多个节点,那么找一个需要的日志就要多个服务器都执行类似于下面的命令来查找蛛丝马迹:
more INFO-2020-12-17.0.log |grep -C 5 'scanRecord'

如果遇到关联的服务日志查询,还会让事情的复杂度变的更高。

阶段二、测试环境建立ELK环境

实践过程:

刚开始的时候 1 master+ 3 data;有一个普遍的认知就是,单个 Elasticsearch data 节点的每个分片数据大小:30GB-50GB。因为我们的系统是 4 核 8G 的配置,因此我们采用了下限,也就是每个 Shard 30G。这样子运行了 3 个月。

采用策略:

按天产生 index,一些 IP,APP 应用名等不需要分词查询的字段都禁用了 index (这样可以节省磁盘),只保留一周的日志回溯,3 天的日志 alive 查询,4 天的日志 close。一周以上的 index 直接 delete ,晚上 12点 定时执行 forcemerge。

遇到瓶颈,系统扩容:

因为随着系统票件量的提升,日志数据逐步增加。慢慢就会感到系统查询非常慢,磁盘空间慢慢的无法做到保留一周日志回溯,立马进行了系统扩容。

扩容后:

系统会自动进行索引分片重分配,会把分片均匀的分布到所有的节点上。比如刚开始 3 台 data 节点 6 个分片,平均每个机器会有 2 个分片,那么系统扩容一倍后,会变成 6 个 data 节点,那么这 6 个分片,会自动平均分布到 6 个 data 节点上。每个节点有一个 shard。

扩容步骤

修改配置文件

主要修改所有 Elasticsearch 节点的elasticsearch.yml中的 IP 地址,如果一个机器上部署多个节点,记得将端口号加上。

一个机器上部署三个节点实例

discovery.zen.ping.unicast.hosts:["192.168.207.43:9300","192.168.207.43:9301","192.168.207.43:9302"]

配合的属性:

http.port: 9202
transport.tcp.port: 9302

分批启动ES

  • 启动顺序:先启动 master 节点,再启动其他类型的节点。
  • 启动命令:nohup ./bin/elasticsearch > nohup.out 2>&1 &

心路旅程

1、资源并不是充裕的。可以使用 Stack Monitoring 上的磁盘监控功能,随时监控磁盘的剩余空间。

2.png

并且,可以在数据可靠性要求允许的情况下,在索引生命周期管理中,把冷数据的index.number_of_replicas设置为 0。

3.png

2、最佳的 Kafka 分发效率。如果使用了 Kafka,注意 Kafka 的 Partition 与 Topic 的配置关系,通常来说 Logstash 中 Worker 的数量应该等于或大于 Kafka Partition 的数量,以便于达到最优的分发效率

3、SSD 的取舍。数据量过大。磁盘 IO 也真的能成为瓶颈,对比集群没有数据和集群数据量达到磁盘容量的50%的时候,写入的速率差别很大。业务需求需要实时查询的场景能上 SSD 就上SSD。

创作人简介:
朱祝元,从事 JAVA 企业级应用开发十余年,获得 pmp,acp 项目管理认证。有扎实
的企业级开发经验,以及分布式应用开发架构经验,参与了千万级的复杂项目数据场景
业务处理。
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
19天前
|
存储 监控 数据可视化
日志分析对决:揭示 ELK 与 GrayLog 的优势和差异
日志分析对决:揭示 ELK 与 GrayLog 的优势和差异
37 0
|
28天前
|
存储 Prometheus 监控
Prometheus vs. ELK Stack:容器监控与日志管理工具的较量
随着容器化技术的广泛应用,容器监控与日志管理成为了关键任务。本文将对两种常用工具进行比较与选择,分别是Prometheus和ELK Stack。Prometheus是一款开源的监控系统,专注于时序数据的收集和告警。而ELK Stack则是一套完整的日志管理解决方案,由Elasticsearch、Logstash和Kibana三个组件组成。通过比较它们的特点、优势和适用场景,读者可以更好地了解如何选择适合自己需求的工具。
|
1月前
|
Go 数据处理 Docker
elk stack部署自动化日志收集分析平台
elk stack部署自动化日志收集分析平台
49 0
|
1月前
|
存储 监控 安全
ELK7.x日志系统搭建 1. elk基础搭建
ELK7.x日志系统搭建 1. elk基础搭建
51 0
|
1月前
|
消息中间件 数据可视化 关系型数据库
ELK7.x日志系统搭建 4. 结合kafka集群完成日志系统
ELK7.x日志系统搭建 4. 结合kafka集群完成日志系统
32 0
|
23天前
|
运维 Ubuntu Linux
【Linux操作系统】探秘Linux奥秘:日志管理的解密与实战
【Linux操作系统】探秘Linux奥秘:日志管理的解密与实战
27 0
|
29天前
|
Prometheus 监控 Cloud Native
Prometheus VS ELK Stack:容器监控与日志管理工具的比较与选择
在容器化时代,有效的容器监控与日志管理工具对于确保应用程序的可靠性和可维护性至关重要。本文将比较两个主流工具,Prometheus和ELK Stack,探讨它们在容器监控和日志管理方面的特点、优势和适用场景,帮助读者做出明智的选择。
|
1月前
|
存储 Java
jvm性能调优实战 - 23 模拟Young GC的发生及分析GC日志
jvm性能调优实战 - 23 模拟Young GC的发生及分析GC日志
31 0
|
2月前
|
SQL 数据采集 数据挖掘
nginx+flume网络流量日志实时数据分析实战
nginx+flume网络流量日志实时数据分析实战
73 0
|
2月前
|
SQL 大数据 HIVE
每天一道大厂SQL题【Day09】充值日志SQL实战
每天一道大厂SQL题【Day09】充值日志SQL实战
21 0

相关产品

  • 检索分析服务 Elasticsearch版