ELK 简介

1. ELK背景

1.1 需求背景

  • 业务发展越来越庞大，服务器越来越多
  • 各种访问日志、应用日志、错误日志量越来越多，导致运维人员无法很好的去管理日志
  • 开发人员排查问题，需要到服务器上查日志，不方便
  • 运营人员需要一些数据，需要我们运维到服务器上分析日志

1.2 为何用ELK

 一般我们需要进行日志分析场景：直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大也就是日志量多而复杂的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。 大型系统通常都是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。

 一个完整的集中式日志系统，需要包含以下几个主要特点：

  • 收集－能够采集多种来源的日志数据
  • 传输－能够稳定的把日志数据传输到中央系统
  • 存储－如何存储日志数据
  • 分析－可以支持 UI 分析
  • 警告－能够提供错误报告，监控机制
  • 而ELK则提供了一整套解决方案，并且都是开源软件，之间互相配合使用，完美衔接，高效的满足了很多场合的应用。是目前主流的一种日志系统。

2. ELK简介

 ELK是三个开源软件的缩写，分别为：Elasticsearch、 Logstash以及Kibana , 它们都是开源软件。不过现在还新增了一个Beats，它是一个轻量级的日志收集处理工具(Agent)，Beats占用资源少，适合于在各个服务器上搜集日志后传输给Logstash，官方也推荐此工具，目前由于原本的ELK Stack成员中加入了 Beats 工具所以已改名为Elastic Stack。

Elastic Stack包含：

 Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。详细可参考Elasticsearch权威指南

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

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

 Beats在这里是一个轻量级日志采集器，其实Beats家族有6个成员，早期的ELK架构中使用Logstash收集、解析日志，但是Logstash对内存、cpu、io等资源消耗比较高。相比 Logstash，Beats所占系统的CPU和内存几乎可以忽略不计 ELK Stack （5.0版本之后）→ Elastic Stack == （ELK Stack + Beats）。目前Beats包含六种工具：

  • Packetbeat： 网络数据（收集网络流量数据）
  • Metricbeat： 指标 （收集系统、进程和文件系统级别的 CPU 和内存使用情况等数据）
  • Filebeat： 日志文件（收集文件数据）
  • Winlogbeat： windows事件日志（收集 Windows 事件日志数据）
  • Auditbeat：审计数据 （收集审计日志）
  • Heartbeat：运行时间监控 （收集系统运行时的数据）

ELK 官网 https://www.elastic.co/cn/

2.1 架构图

ELK架构图

2.2 Logstash工作原理

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

logstash原理

Input：输入数据到logstash。一些常用的输入为

  • file：从文件系统的文件中读取，类似于tail -f命令
  • syslog：在514端口上监听系统日志消息，并根据RFC3164标准进行解析
  • redis：从redis service中读取
  • beats：从filebeat中读取
  • Filters：数据中间处理，对数据进行操作。

一些常用的过滤器为

  • grok：解析任意文本数据，Grok 是 Logstash 最重要的插件。它的主要作用就是将文本格式的字符串，转换成为具体的结构化的数据，配合正则表达式使用。内置120多个解析语法。
  • mutate：对字段进行转换。例如对字段进行删除、替换、修改、重命名等。
  • drop：丢弃一部分events不进行处理。
  • clone：拷贝 event，这个过程中也可以添加或移除字段。
  • geoip：添加地理信息(为前台kibana图形化展示使用)
  • Outputs：outputs是logstash处理管道的最末端组件。一个event可以在处理过程中经过多重输出，但是一旦所有的outputs都执行结束，这个event也就完成生命周期。

一些常见的outputs为：

  • elasticsearch：可以高效的保存数据，并且能够方便和简单的进行查询。
  • file：将event数据保存到文件中。
  • graphite：将event数据发送到图形化组件中，一个很流行的开源存储图形化展示的组件。
  • Codecs：codecs 是基于数据流的过滤器，它可以作为input，output的一部分配置。Codecs可以帮助你轻松的分割发送过来已经被序列化的数据。

一些常见的codecs：

  • json：使用json格式对数据进行编码/解码。
  • multiline：将汇多个事件中数据汇总为一个单一的行。比如：java异常信息和堆栈信息。

2.3 ELK 细则

ELK中的三个系统分别扮演不同的角色，组成了一个整体的解决方案。Logstash是一个ETL工具，负责从每台机器抓取日志数据，对数据进行格式转换和处理后，输出到Elasticsearch中存储。Elasticsearch是一个分布式搜索引擎和分析引擎，用于数据存储，可提供实时的数据查询。Kibana是一个数据可视化服务，根据用户的操作从Elasticsearch中查询数据，形成相应的分析结果，以图表的形式展现给用户。 ELK的安装很简单，可以按照"下载->修改配置文件->启动"方法分别部署三个系统，也可以使用docker来快速部署。具体的安装方法这里不详细介绍，下面来看一个常见的部署方案，如下图所示，部署思路是：

  • 在每台生成日志文件的机器上，部署Logstash，作为Shipper的角色，负责从日志文件中提取数据，但是不做任何处理，直接将数据输出到Redis队列(list)中；
  • 需要一台机器部署Logstash，作为Indexer的角色，负责从Redis中取出数据，对数据进行格式化和相关处理后，输出到Elasticsearch中存储；
  • 部署Elasticsearch集群，当然取决于你的数据量了，数据量小的话可以使用单台服务，如果做集群的话，最好是有3个以上节点，同时还需要部署相关的监控插件；
  • 部署Kibana服务，提供Web服务。

 在前期部署阶段，主要工作是Logstash节点和Elasticsearch集群的部署，而在后期使用阶段，主要工作就是Elasticsearch集群的监控和使用Kibana来检索、分析日志数据了，当然也可以直接编写程序来消费Elasticsearch中的数据。

在上面的部署方案中，我们将Logstash分为Shipper和Indexer两种角色来完成不同的工作，中间通过Redis做数据管道，为什么要这样做？为什么不是直接在每台机器上使用Logstash提取数据、处理、存入Elasticsearch？

首先，采用这样的架构部署，有三点优势：第一，降低对日志所在机器的影响，这些机器上一般都部署着反向代理或应用服务，本身负载就很重了，所以尽可能的在这些机器上少做事；第二，如果有很多台机器需要做日志收集，那么让每台机器都向Elasticsearch持续写入数据，必然会对Elasticsearch造成压力，因此需要对数据进行缓冲，同时，这样的缓冲也可以一定程度的保护数据不丢失；第三，将日志数据的格式化与处理放到Indexer中统一做，可以在一处修改代码、部署，避免需要到多台机器上去修改配置。

其次，我们需要做的是将数据放入一个消息队列中进行缓冲，所以Redis只是其中一个选择，也可以是RabbitMQ、Kafka等等，在实际生产中，Redis与Kafka用的比较多。由于Redis集群一般都是通过key来做分片，无法对list类型做集群，在数据量大的时候必然不合适了，而Kafka天生就是分布式的消息队列系统。