ELK原理简介

为什么用到ELK&＃xff1a;

一般我们需要进行日志分析场景&＃xff1a;直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大的场景中&＃xff0c;此方法效率低下&＃xff0c;面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理&＃xff0c;所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统&＃xff0c;将所有节点上的日志统一收集&＃xff0c;管理&＃xff0c;访问。

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

一个完整的集中式日志系统&＃xff0c;需要包含以下几个主要特点&＃xff1a;

• 收集&＃xff0d;能够采集多种来源的日志数据
• 传输&＃xff0d;能够稳定的把日志数据传输到中央系统
• 存储&＃xff0d;如何存储日志数据
• 分析&＃xff0d;可以支持 UI 分析
• 警告&＃xff0d;能够提供错误报告&＃xff0c;监控机制

ELK提供了一整套解决方案&＃xff0c;并且都是开源软件&＃xff0c;之间互相配合使用&＃xff0c;完美衔接&＃xff0c;高效的满足了很多场合的应用。目前主流的一种日志系统。

ELK简介&＃xff1a;

ELK是三个开源软件的缩写&＃xff0c;分别表示&＃xff1a;Elasticsearch , Logstash, Kibana , 它们都是开源软件。新增了一个FileBeat&＃xff0c;它是一个轻量级的日志收集处理工具(Agent)&＃xff0c;Filebeat占用资源少&＃xff0c;适合于在各个服务器上搜集日志后传输给Logstash&＃xff0c;官方也推荐此工具。

Elasticsearch是个开源分布式搜索引擎&＃xff0c;提供搜集、分析、存储数据三大功能。它的特点有&＃xff1a;分布式&＃xff0c;零配置&＃xff0c;自动发现&＃xff0c;索引自动分片&＃xff0c;索引副本机制&＃xff0c;restful风格接口&＃xff0c;多数据源&＃xff0c;自动搜索负载等。

Logstash 主要是用来日志的搜集、分析、过滤日志的工具&＃xff0c;支持大量的数据获取方式。一般工作方式为c/s架构&＃xff0c;client端安装在需要收集日志的主机上&＃xff0c;server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。

Kibana 也是一个开源和免费的工具&＃xff0c;Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面&＃xff0c;可以帮助汇总、分析和搜索重要数据日志。

Filebeat隶属于Beats。目前Beats包含四种工具&＃xff1a;

1. 1. Packetbeat&＃xff08;搜集网络流量数据&＃xff09;
   2. Topbeat&＃xff08;搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据&＃xff09;
   3. Filebeat&＃xff08;搜集文件数据&＃xff09;
   4. Winlogbeat&＃xff08;搜集 Windows 事件日志数据&＃xff09;

官方文档&＃xff1a;

Filebeat&＃xff1a;

https://www.elastic.co/cn/products/beats/filebeat
https://www.elastic.co/guide/en/beats/filebeat/5.6/index.html

Logstash&＃xff1a;
https://www.elastic.co/cn/products/logstash
https://www.elastic.co/guide/en/logstash/5.6/index.html

Kibana:

https://www.elastic.co/cn/products/kibana

https://www.elastic.co/guide/en/kibana/5.5/index.html

Elasticsearch&＃xff1a;
https://www.elastic.co/cn/products/elasticsearch
https://www.elastic.co/guide/en/elasticsearch/reference/5.6/index.html

elasticsearch中文社区&＃xff1a;
https://elasticsearch.cn/

ELK架构图&＃xff1a;

架构图一&＃xff1a;

这是最简单的一种ELK架构方式。优点是搭建简单&＃xff0c;易于上手。缺点是Logstash耗资源较大&＃xff0c;运行占用CPU和内存高。另外没有消息队列缓存&＃xff0c;存在数据丢失隐患。

此架构由Logstash分布于各个节点上搜集相关日志、数据&＃xff0c;并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩存储并提供多种API供用户查询&＃xff0c;操作。用户亦可以更直观的通过配置Kibana Web方便的对日志查询&＃xff0c;并根据数据生成报表。

架构图二&＃xff1a;

此种架构引入了消息队列机制&＃xff0c;位于各个节点上的Logstash Agent先将数据/日志传递给Kafka&＃xff08;或者Redis&＃xff09;&＃xff0c;并将队列中消息或数据间接传递给Logstash&＃xff0c;Logstash过滤、分析后将数据传递给Elasticsearch存储。最后由Kibana将日志和数据呈现给用户。因为引入了Kafka&＃xff08;或者Redis&＃xff09;,所以即使远端Logstash server因故障停止运行&＃xff0c;数据将会先被存储下来&＃xff0c;从而避免数据丢失。

架构图三&＃xff1a;

此种架构将收集端logstash替换为beats&＃xff0c;更灵活&＃xff0c;消耗资源更少&＃xff0c;扩展性更强。同时可配置Logstash 和Elasticsearch 集群用于支持大集群系统的运维日志数据监控和查询。

Filebeat工作原理&＃xff1a;

Filebeat由两个主要组件组成&＃xff1a;prospectors 和 harvesters。这两个组件协同工作将文件变动发送到指定的输出中。

Harvester&＃xff08;收割机&＃xff09;&＃xff1a;负责读取单个文件内容。每个文件会启动一个Harvester&＃xff0c;每个Harvester会逐行读取各个文件&＃xff0c;并将文件内容发送到制定输出中。Harvester负责打开和关闭文件&＃xff0c;意味在Harvester运行的时候&＃xff0c;文件描述符处于打开状态&＃xff0c;如果文件在收集中被重命名或者被删除&＃xff0c;Filebeat会继续读取此文件。所以在Harvester关闭之前&＃xff0c;磁盘不会被释放。默认情况filebeat会保持文件打开的状态&＃xff0c;直到达到close_inactive&＃xff08;如果此选项开启&＃xff0c;filebeat会在指定时间内将不再更新的文件句柄关闭&＃xff0c;时间从harvester读取最后一行的时间开始计时。若文件句柄被关闭后&＃xff0c;文件发生变化&＃xff0c;则会启动一个新的harvester。关闭文件句柄的时间不取决于文件的修改时间&＃xff0c;若此参数配置不当&＃xff0c;则可能发生日志不实时的情况&＃xff0c;由scan_frequency参数决定&＃xff0c;默认10s。Harvester使用内部时间戳来记录文件最后被收集的时间。例如&＃xff1a;设置5m&＃xff0c;则在Harvester读取文件的最后一行之后&＃xff0c;开始倒计时5分钟&＃xff0c;若5分钟内文件无变化&＃xff0c;则关闭文件句柄。默认5m&＃xff09;。

Prospector&＃xff08;勘测者&＃xff09;&＃xff1a;负责管理Harvester并找到所有读取源。

Prospector会找到/apps/logs/*目录下的所有info.log文件&＃xff0c;并为每个文件启动一个Harvester。Prospector会检查每个文件&＃xff0c;看Harvester是否已经启动&＃xff0c;是否需要启动&＃xff0c;或者文件是否可以忽略。若Harvester关闭&＃xff0c;只有在文件大小发生变化的时候Prospector才会执行检查。只能检测本地的文件。

Filebeat如何记录文件状态&＃xff1a;

将文件状态记录在文件中&＃xff08;默认在/var/lib/filebeat/registry&＃xff09;。此状态可以记住Harvester收集文件的偏移量。若连接不上输出设备&＃xff0c;如ES等&＃xff0c;filebeat会记录发送前的最后一行&＃xff0c;并再可以连接的时候继续发送。Filebeat在运行的时候&＃xff0c;Prospector状态会被记录在内存中。Filebeat重启的时候&＃xff0c;利用registry记录的状态来进行重建&＃xff0c;用来还原到重启之前的状态。每个Prospector会为每个找到的文件记录一个状态&＃xff0c;对于每个文件&＃xff0c;Filebeat存储唯一标识符以检测文件是否先前被收集。

Filebeat如何保证事件至少被输出一次&＃xff1a;

Filebeat之所以能保证事件至少被传递到配置的输出一次&＃xff0c;没有数据丢失&＃xff0c;是因为filebeat将每个事件的传递状态保存在文件中。在未得到输出方确认时&＃xff0c;filebeat会尝试一直发送&＃xff0c;直到得到回应。若filebeat在传输过程中被关闭&＃xff0c;则不会再关闭之前确认所有时事件。任何在filebeat关闭之前为确认的时间&＃xff0c;都会在filebeat重启之后重新发送。这可确保至少发送一次&＃xff0c;但有可能会重复。可通过设置shutdown_timeout 参数来设置关闭之前的等待事件回应的时间&＃xff08;默认禁用&＃xff09;。

Logstash工作原理&＃xff1a;

Logstash事件处理有三个阶段&＃xff1a;inputs → filters → outputs。是一个接收&＃xff0c;处理&＃xff0c;转发日志的工具。支持系统日志&＃xff0c;webserver日志&＃xff0c;错误日志&＃xff0c;应用日志&＃xff0c;总之包括所有可以抛出来的日志类型。

Input&＃xff1a;输入数据到logstash。

一些常用的输入为&＃xff1a;

file&＃xff1a;从文件系统的文件中读取&＃xff0c;类似于tial -f命令

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

redis&＃xff1a;从redis service中读取

beats&＃xff1a;从filebeat中读取

Filters&＃xff1a;数据中间处理&＃xff0c;对数据进行操作。

一些常用的过滤器为&＃xff1a;

grok&＃xff1a;解析任意文本数据&＃xff0c;Grok 是 Logstash 最重要的插件。它的主要作用就是将文本格式的字符串&＃xff0c;转换成为具体的结构化的数据&＃xff0c;配合正则表达式使用。内置120多个解析语法。

官方提供的grok表达式&＃xff1a;https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns
grok在线调试&＃xff1a;https://grokdebug.herokuapp.com/

mutate&＃xff1a;对字段进行转换。例如对字段进行删除、替换、修改、重命名等。

drop&＃xff1a;丢弃一部分events不进行处理。

clone&＃xff1a;拷贝 event&＃xff0c;这个过程中也可以添加或移除字段。

geoip&＃xff1a;添加地理信息(为前台kibana图形化展示使用)

Outputs&＃xff1a;outputs是logstash处理管道的最末端组件。一个event可以在处理过程中经过多重输出&＃xff0c;但是一旦所有的outputs都执行结束&＃xff0c;这个event也就完成生命周期。

一些常见的outputs为&＃xff1a;

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

file&＃xff1a;将event数据保存到文件中。

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

Codecs&＃xff1a;codecs 是基于数据流的过滤器&＃xff0c;它可以作为input&＃xff0c;output的一部分配置。Codecs可以帮助你轻松的分割发送过来已经被序列化的数据。

一些常见的codecs&＃xff1a;

json&＃xff1a;使用json格式对数据进行编码/解码。

multiline&＃xff1a;将汇多个事件中数据汇总为一个单一的行。比如&＃xff1a;java异常信息和堆栈信息。