ELK原理以及一些处理难点分析
1.ELK是Elasticsearch、Logstash、Kibana的简称,这三者是核心套件,但并非全部。后文的四种基本架构中将逐一介绍应用到的其它套件。
- Elasticsearch是实时全文搜索和分析引擎,提供搜集、分析、存储数据三大功能;是一套开放REST和JAVA API等结构提供高效搜索功能,可扩展的分布式系统。它构建于Apache Lucene搜索引擎库之上。
- Logstash是一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志,包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志,这些来源包括 syslog、消息传递(例如 RabbitMQ)和JMX,它能够以多种方式输出数据,包括电子邮件、websockets和Elasticsearch。
- Kibana是一个基于Web的图形界面,用于搜索、分析和可视化存储在 Elasticsearch指标中的日志数据。它利用Elasticsearch的REST接口来检索数据,不仅允许用户创建他们自己的数据的定制仪表板视图,
- 还允许他们以特殊的方式查询和过滤数据。
2.这是最简单的一种ELK架构方式。优点是搭建简单,易于上手。缺点是Logstash耗资源较大,运行占用CPU和内存高。另外没有消息队列缓存,存在数据丢失隐患。建议供学习者和小规模集群使用。
此架构首先由Logstash分布于各个节点上搜集相关日志、数据,并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩存储并提供多种API供用户查询,操作。用户亦可以更直观的通过配置Kibana Web Portal方便的对日志查询,并根据数据生成报表
![](https://img2018.cnblogs.com/blog/1298587/201909/1298587-20190918093448030-1519729494.png)
3.难点以及处理方法
1、ElasticSearch 分布式集群,在企业真实环境中防火墙需要关闭吗?
在实际工作中,ElasticSearch集群只开放对应的端口,不会直接关闭防火墙。
2、将公司的核心流量数据导入ELK平台的过程中,使用Logstash采集数据,那么Logstash能承受多大的数据压力呢?
一个logstash节点,每秒钟能收集个一两万条日志数据(普通的页面浏览日志),如果单条日志比较大,或者在logstash中filter逻辑复杂,处理能力会再小一点。另外需要补充说明:一条普通日志大概6~8K的大小,转换成流量的话大致是105000KB/S。
3、在ELK的项目中,公司的日志如何动态产生?动态日志又改如何采集?
如果日志只输出到一个文件,比如access.log,那么Logstash直需要监控这个日志文件即可。
如果日志名称按照时间或者大小滚动,那么在Logstash配置文件名的时候使用通配符即可。
4、比如我每天的日志有1g或者10g或者100g,ELK系统架构中,应该需要多少台es,需要多少redis 需要多少logstash等。
可以根据数据量的大小以及每个组件数据处理能力合理规划。
filebeat:每秒钟收集能力大致在3W条左右
redis:每秒钟读取或者写入数据能力在10W条左右
logstash:每秒钟处理能力在1~2w左右
ELasticSearch:处理能力可以很容易水平扩展,单台服务器测试的指标大致在1.5W左右 配置:2核CPU、 16G内存
上述指标是指普通的access访问日志,每条日志大小大致在6~8KB如果单条日志过大或者过小,则指标会有上下浮动。
5、现在我的es集群每次full gc之后, 年老代占用的内存都会上升, 然后full gc会越来越频繁. 基本5天之后集群就得重启了,有没办法不重启强制清理年老代内存。
可以通过参数进行配置,参数配置:
index.cache.field.max_size: 100000
index.cache.field.expire: 60m
index.cache.field.type: soft
如果发现这个效果不明显,可以尝试修改一下JVM内存中年轻代和老年代的占比,把年轻代的内存调大一点,这样可以减少年轻代GC的次数,就不会有很多数据进入到老年代中。
6.logstash正在给es发送数据,无任何外部操作情况下,突然es没了~!:
(。于是翻看我的过往操作,没有发现可以导致类似结果的命令,es的日志在当时的时间点下并没有报告任何信息。后来想到了syslog的功能,于是查看syslog的日志,在/var/log/messages(确认一下路径)中按时间查找到es故障那会儿,找到了报错故障。简单说就是内存严重不足,linux系统先后杀死了我的两个服务:mysqld和es。这两个可都是后台处理数据的呀,如此重要确也能被如此只能的OOM Killer机制选中并杀掉!