目录
ELK是三个开源软件的缩写,分别是Elasticsearch、Logstash、Kibana,后来又新加了一个FileBeat。
Elasticsearch是个开源分布式搜索引擎,提供搜集、分析、存储数据等功能。它的特点有:分布式、零配置、自动发现、索引自动分片、索引副本机制、Restful风格接口、多数据源、自动搜索负载等,详细介绍可查看这篇文章:
ES知识记录_承缘丶的博客-CSDN博客ES知识记录https://blog.csdn.net/qq_30168227/article/details/124569725 Logstash主要是用来日志的搜集、分析、过滤日志的工具,支持多种多样的数据获取方式。一般工作方式为c/s架构,Client端安装在需要收集日志的服务器上,Server端负责将收到的各节点日志进行过滤、修改等操作,再一并发往Elasticsearch上去。
Kibana可以为Logstash和ElasticSearch在收集、存储的日志基础上进行分析时友好的Web界面,可以帮助汇总、分析和搜索重要数据日志。
Filebeat隶属于Beats。是一个轻量级的日志收集处理工具(Agent),Filebeat占用资源少,适合于在各个服务器上搜集日志后传输给Logstash,官方也推荐此工具。目前Beats包含四种工具:Packetbeat(搜集网络流量数据)、Topbeat(搜集系统、进程和文件系统级别的CPU和内存使用情况等数据)、Filebeat(搜集文件数据)、Winlogbeat(搜集Windows事件日志数据)。
在需要收集日志的所有服务上部署Logstash,作为Logstash Agent(logstash shipper)用于监控并过滤收集日志,将过滤后的内容发送到Redis(消息队列缓存,避免数据丢失隐患),然后Logstash Indexer将日志收集在一起再交给ElasticSearch即全文搜索服务,可以用ElasticSearch进行自定义搜索,可以通过Kibana来结合自定义搜索进行页面展示。
Filebeat由两个主要组件组成:Prospectors和Harvesters。这两个组件协同工作将文件变动发送到指定的输出中。
Harvester(收割机):负责读取单个文件内容。每个文件会启动一个Harvester,每个Harvester会逐行读取各个文件,并将文件内容发送到制定输出中。Harvester负责打开和关闭文件,意味在Harvester运行的时候,文件描述符处于打开状态,如果文件在收集中被重命名或者被删除,Filebeat会继续读取此文件。所以在Harvester关闭之前,磁盘不会被释放。默认情况Filebeat会保持文件打开的状态,直到达到Close_inactive(如果此选项开启,Filebeat会在指定时间内将不再更新的文件句柄关闭,时间从Harvester读取最后一行的时间开始计时。若文件句柄被关闭后,文件发生变化,则会启动一个新的Harvester。关闭文件句柄的时间不取决于文件的修改时间,若此参数配置不当,则可能发生日志不实时的情况,这个参数由Scan_frequency参数决定的,默认是10s。Harvester使用内部时间戳来记录文件最后被收集的时间。例如:设置5m,则在Harvester读取文件的最后一行之后,开始倒计时5分钟,若5分钟内文件无变化,则关闭文件句柄)。
- filebeat.prospectors:
-
- - input_type: log
-
- paths:
-
- - /apps/logs/*/info.log
Prospector(勘测者):负责管理Harvester并找到所有读取源。Prospector会找到/apps/logs/* 目录下的所有info.log文件,并为每个文件启动一个Harvester。Prospector会检查每个文件,看Harvester是否已经启动,是否需要启动,或者文件是否可以忽略。若Harvester关闭,只有在文件大小发生变化的时候Prospector才会执行检查,它只能检测本地的文件。
Logstash事件处理有三个阶段:Inputs → Filters → Outputs。是一个接收、处理、转发日志的工具。支持系统日志、Webserver日志、应用日志等,几乎包含了可以抛出来的所有日志类型。
一些常用的输入为:
File:从文件系统的文件中读取,类似于tial -f命令
Syslog:在514端口上监听系统日志消息,并根据RFC3164标准进行解析
Redis:从redis service中读取
Beats:从filebeat中读取
一些常用的过滤器为:
Grok:解析任意文本数据,Grok 是 Logstash 最重要的插件。它的主要作用就是将文本格式的字符串,转换成为具体的结构化的数据,配合正则表达式使用。
官方提供的grok表达式:logstash-patterns-core/patterns at main · logstash-plugins/logstash-patterns-core · GitHub
Grok在线调试:Grok Debugger
Mutate:对字段进行转换。例如对字段进行删除、替换、修改、重命名等。
Drop:丢弃一部分Events不进行处理。
Clone:拷贝Event,这个过程中也可以添加或移除字段。
Geoip:添加地理信息(为前台kibana图形化展示使用)
一些常见的Outputs为:
Elasticsearch:可以高效的保存数据,并且能够方便和简单的进行查询。
File:将Event数据保存到文件中。
Graphite:将Event数据发送到图形化组件中,踏实一个当前较流行的开源存储图形化展示的组件。
一些常见的Codecs:
Json:使用json格式对数据进行编码/解码。
Multiline:将汇多个事件中数据汇总为一个单一的行。比如:java异常信息和堆栈信息。
这是最简单的一种ELK架构方式。优点是搭建简单,易于上手。缺点是Logstash耗资源较大,运行占用服务器CPU和内存较高。另外其没有消息队列缓存,存在数据丢失隐患。
此架构由Logstash分布于各个节点上搜集相关日志、数据,并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩存储并提供多种API供用户查询等操作。用户还可以通过配置Kibana Web方便地对日志进行查询、生成报表等。
此种架构引入了消息队列机制,位于各个节点上的Logstash Agent先将数据、日志传递给Kafka(或者Redis),并将队列中消息或数据间接传递给Logstash,Logstash过滤、分析后将数据传递给Elasticsearch存储。最后由Kibana将日志等数据呈现给用户。因为引入了Kafka(Redis),所以即使远端Logstash Server因宕机,数据也将会先被存储下来,从而避免了数据丢失。
此种架构将收集端Logstash替换为Beats,更灵活且消耗资源更少、扩展性更强。同时可配置Logstash和Elasticsearch集群用于支持大集群系统的运维日志数据监控和查询。