。

但在规模较大的场景中#xff0c;此方法效率低下#xff0c;面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。

需要集中化…为什么用到ELK

grep、awk

就可以获得自己想要的信息。

但在规模较大的场景中此方法效率低下面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。

需要集中化的日志管理所有服务器上的日志收集汇总。

常见解决思路是建立集中式日志收集系统将所有节点上的日志统一收集管理访问。

一般大型系统是一个分布式部署的架构不同的服务模块部署在不同的服务器上问题出现时大部分情况需要根据问题暴露的关键信息定位到具体的服务器和服务模块构建一套集中式日志系统可以提高定位问题的效率。

收集能够采集多种来源的日志数据传输能够稳定的把日志数据传输到中央系统存储如何存储日志数据分析可以支持

分析警告能够提供错误报告监控机制

ELK提供了一整套解决方案并且都是开源软件之间互相配合使用完美衔接高效的满足了很多场合的应用。

目前主流的一种日志系统。

ELK简介

它们都是开源软件。

新增了一个FileBeat它是一个轻量级的日志收集处理工具(Agent)Filebeat占用资源少适合于在各个服务器上搜集日志后传输给Logstash官方也推荐此工具。

Elasticsearch是个开源分布式搜索引擎提供搜集、分析、存储数据三大功能。

它的特点有分布式零配置自动发现索引自动分片索引副本机制restful风格接口多数据源自动搜索负载等。

Logstash

主要是用来日志的搜集、分析、过滤日志的工具支持大量的数据获取方式。

一般工作方式为c/s架构client端安装在需要收集日志的主机上server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。

Kibana

Packetbeat搜集网络流量数据Topbeat搜集系统、进程和文件系统级别的

CPU

和内存使用情况等数据Filebeat搜集文件数据Winlogbeat搜集

Windows

ElasticsearchElasticsearch官方分布式搜索和分析引擎

ElasticElasticsearch

这是最简单的一种ELK架构方式。

优点是搭建简单易于上手。

缺点是Logstash耗资源较大运行占用CPU和内存高。

另外没有消息队列缓存存在数据丢失隐患。

此架构由Logstash分布于各个节点上搜集相关日志、数据并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。

Elasticsearch将数据以分片的形式压缩存储并提供多种API供用户查询操作。

用户亦可以更直观的通过配置Kibana

架构图二

Agent先将数据/日志传递给Kafka或者Redis并将队列中消息或数据间接传递给LogstashLogstash过滤、分析后将数据传递给Elasticsearch存储。

最后由Kibana将日志和数据呈现给用户。

因为引入了Kafka或者Redis,所以即使远端Logstash

server因故障停止运行数据将会先被存储下来从而避免数据丢失。

架构图三

此种架构将收集端logstash替换为beats更灵活消耗资源更少扩展性更强。

同时可配置Logstash

和Elasticsearch

harvesters。

这两个组件协同工作将文件变动发送到指定的输出中。

Harvester收割机负责读取单个文件内容。

每个文件会启动一个Harvester每个Harvester会逐行读取各个文件并将文件内容发送到制定输出中。

Harvester负责打开和关闭文件意味在Harvester运行的时候文件描述符处于打开状态如果文件在收集中被重命名或者被删除Filebeat会继续读取此文件。

所以在Harvester关闭之前磁盘不会被释放。

默认情况filebeat会保持文件打开的状态直到达到close_inactive如果此选项开启filebeat会在指定时间内将不再更新的文件句柄关闭时间从harvester读取最后一行的时间开始计时。

若文件句柄被关闭后文件发生变化则会启动一个新的harvester。

关闭文件句柄的时间不取决于文件的修改时间若此参数配置不当则可能发生日志不实时的情况由scan_frequency参数决定默认10s。

Harvester使用内部时间戳来记录文件最后被收集的时间。

例如设置5m则在Harvester读取文件的最后一行之后开始倒计时5分钟若5分钟内文件无变化则关闭文件句柄。

默认5m。

Prospector勘测者负责管理Harvester并找到所有读取源。

input_type:

Prospector会找到/apps/logs/*目录下的所有info.log文件并为每个文件启动一个Harvester。

Prospector会检查每个文件看Harvester是否已经启动是否需要启动或者文件是否可以忽略。

若Harvester关闭只有在文件大小发生变化的时候Prospector才会执行检查。

只能检测本地的文件。

Filebeat如何记录文件状态

将文件状态记录在文件中默认在/var/lib/filebeat/registry。

此状态可以记住Harvester收集文件的偏移量。

若连接不上输出设备如ES等filebeat会记录发送前的最后一行并再可以连接的时候继续发送。

Filebeat在运行的时候Prospector状态会被记录在内存中。

Filebeat重启的时候利用registry记录的状态来进行重建用来还原到重启之前的状态。

每个Prospector会为每个找到的文件记录一个状态对于每个文件Filebeat存储唯一标识符以检测文件是否先前被收集。

Filebeat之所以能保证事件至少被传递到配置的输出一次没有数据丢失是因为filebeat将每个事件的传递状态保存在文件中。

在未得到输出方确认时filebeat会尝试一直发送直到得到回应。

若filebeat在传输过程中被关闭则不会再关闭之前确认所有时事件。

任何在filebeat关闭之前为确认的时间都会在filebeat重启之后重新发送。

这可确保至少发送一次但有可能会重复。

可通过设置shutdown_timeout

Logstash工作原理

outputs。

是一个接收处理转发日志的工具。

支持系统日志webserver日志错误日志应用日志总之包括所有可以抛出来的日志类型。

-f命令

syslog在514端口上监听系统日志消息并根据RFC3164标准进行解析

redis从redis

最重要的插件。

它的主要作用就是将文本格式的字符串转换成为具体的结构化的数据配合正则表达式使用。

内置120多个解析语法。

官方提供的grok表达式https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns

grok在线调试https://grokdebug.herokuapp.com/

mutate对字段进行转换。

例如对字段进行删除、替换、修改、重命名等。

clone拷贝

Outputsoutputs是logstash处理管道的最末端组件。

一个event可以在处理过程中经过多重输出但是一旦所有的outputs都执行结束这个event也就完成生命周期。

elasticsearch可以高效的保存数据并且能够方便和简单的进行查询。

graphite将event数据发送到图形化组件中一个很流行的开源存储图形化展示的组件。

Codecscodecs

是基于数据流的过滤器它可以作为inputoutput的一部分配置。

Codecs可以帮助你轻松的分割发送过来已经被序列化的数据。

multiline将汇多个事件中数据汇总为一个单一的行。

比如java异常信息和堆栈信息。