ELK详解

系统概要

我们常说的ELK日志收集系统，完整的应该称为：ELK Stack是软件集合Elasticsearch、Logstash、Kibana的简称，它们都是开源软件,目前称为：Elastic Stack，其是ELK Stack 在 5.0 版本加入 Beats 套件后的新称呼。新增得FileBeat，它是一个轻量级的日志收集处理工具(Agent)，Filebeat占用资源少，适合于在各个服务器上搜集日志后传输给Logstash。


官方地址：https://www.elastic.co/guide/cn/index.html
中文文档地址：https://elkguide.elasticsearch.cn/

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

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

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

4>Filebeat隶属于Beats，其作为原logstash-forwarder的替代来完成。Filebeat轻量级的日志传输工具，可以读取系统、nignx、apache等logs文件，监控日志文件，传输数据到Elasticsearch或者Logstash，最后在Kibana中实现可视化。目前Beats包含四种工具：

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

Filebeat一个典型的应用场景：1. Filebeat从nignx读取日志文件，将过滤后的数据传给Logstash。2. Logstash收集到Filebeat传来的数据后格式化输出到 Elasticsearch。3. 最后再由Kibana 访问Elasticsearch提供的比较友好的 Web 界面进行汇总、分析、搜索。

Elastic Stack 目前已成为机器数据分析，或者说实时日志处理领域，开源界的第一选择，和传统的日志处理方案相比，Elastic Stack 具有如下几个优点：
1）处理方式灵活。Elasticsearch 是实时全文索引，不需要像 storm 那样预先编程才能使用；
2）配置简易上手。Elasticsearch 全部采用 JSON 接口，Logstash 是 Ruby DSL 设计，都是目前业界最通用的配置语法设计；
3）检索性能高效。虽然每次查询都是实时计算，但是优秀的设计和实现基本可以达到全天数据查询的秒级响应；
4）集群线性扩展。不管是 Elasticsearch 集群还是 Logstash 集群都是可以线性扩展的；
5）前端操作炫丽。Kibana 界面上，只需要点击鼠标，就可以完成搜索、聚合功能，生成炫丽的仪表板。

附：相关其他文档地址：
Filebeat：
https://www.elastic.co/cn/products/beats/filebeat
https://www.elastic.co/guide/en/beats/filebeat/5.6/index.html

Logstash：
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：
https://www.elastic.co/cn/products/elasticsearch
https://www.elastic.co/guide/en/elasticsearch/reference/5.6/index.html

elasticsearch中文社区：https://elasticsearch.cn/

架构及原理

1）软件安装不同版本，可实现不同功能，即具备不同的架构：

1.1>Demo版: 可
如上图所示，Logstash实例与Elasticsearch实例直接相连，本架构实现容易较简单。我们的程序App将日志写入Log，然后Logstash将Log读出，进行过滤，写入Elasticsearch。最后浏览器访问Kibana，提供一个可视化输出。
本架构主要弊端有2个：
1>在大并发情况下，日志传输峰值比较大。如果直接写入ES,ES的HTTP API处理能力有限，在日志写入频繁的情况下可能会超时、丢失，所以需要一个缓冲中间件。
2>Logstash将Log读出、过滤、输出都是在应用服务器上进行的，这势必会造成服务器上占用系统资源较高，性能不佳，需要进行拆分。

1.2>初级版:

本版中，架构中加入一个缓冲中间件。且对Logstash拆分为Shipper和Indexer；Shipper来进行日志收集，Indexer从缓冲中间件接收日志，过滤输出到Elasticsearch。关于缓冲中间件，推荐使用redis或kafka，相关实践经验表明后者更加优秀，而 Redis 来做消息队列，因Redis无法保证消息的可靠性，这点Kafka可以做到，Kafka的吞吐量和集群模式都比Redis更优秀，Redis受限于机器内存，当内存达到最大时，数据就会被丢弃。如果通过加大内存解决，需要考虑，在Redis中内存越大，触发持久化的操作阻塞主线程的时间越长。相比之下，Kafka的数据是堆积在硬盘中，不存在这个问题，故采用kafka做缓冲中间件更好。

遗留问题：
1>Logstash Shipper是jvm跑的，非常占用JAVA内存！ 。据相关资料显示，8线程8GB内存下，Logstash常驻内存660M（JAVA）。因此，这么一个巨无霸部署在应用服务器端就不大合适了，我们需要一个更加轻量级的日志采集组件。
2>上述架构如果部署成集群，所有业务放在一个大集群中相互影响。一个业务系统出问题了，就会拖垮整个日志系统。因此，需要进行业务隔离！

1.3>中级版:

如上图所示，本版中引入了组件Filebeat。其前身是Logstash的作者用golang写的一个功能较少但是资源消耗也小的轻量级的Logstash-forwarder。后加入Elasticsearch后，以logstash-forwarder为基础，研发了一个新项目就，也就是今天的Filebeat。相比于Logstash，Filebeat更轻量，占用资源更少，所占系统的 CPU 和内存几乎可以忽略不计，因其实际就只是一个二进制文件。

上述架构中，Elasticsearch根据业务分成了3个集群，他们之间相互独立。避免出现，一个业务拖垮了Elasticsearch集群，整个日志系统就一起宕机的情况。图中所示的Tribe Node组件，中文翻译为：部落结点，它是一个特殊的客户端，可连接多个集群，在所有连接的集群上执行搜索和其他操作。本处主要负责将请求路由到正确的后端ES集群上。
遗留问题：
本架构中没有对日志进行冷热分离。因假如需要对一个礼拜内的日志，查询的最多。以7天作为界限，区分冷热数据，可以大大的优化查询速度。

1.4>高级版:

本次版本中，我们对数据进行冷热分离。每个业务准备两个Elasticsearch集群，可以理解为冷热集群。7天以内的数据，存入热集群，以SSD存储索引。超过7天，就进入冷集群，以SATA存储索引。这么一改动，性能又得到提升。
遗留问题：
敏感数据没有进行处理，就直接写入日志了。关于这点，其实现在JAVA这边，现成的日志组件，比如log4j都有提供这种日志过滤功能，可以将敏感信息进行脱敏后，再记录日志。

2）组件架构及原理

2.1>整体架构：


2.2>ELK架构体系

架构图一：
图上所示架构，搭建简单，易于上手；但Logstash耗资源较大，运行占用CPU和内存高。另外没有消息队列缓存，存在数据丢失隐患。

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

架构图二：

上图所示架构，软件部署简单，使用filebeats作为收集端，相比logstash更灵活，消耗资源更少，扩展性更强。同时可配置Logstash 和Elasticsearch 集群用于支持大集群系统的运维日志数据监控和查询。

架构图三：

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

2.3>Filebeat工作原理:
Filebeat由两个主要组件组成：prospectors 和 harvesters。这两个组件协同工作将文件变动发送到指定的输出中。

Prospector（勘测者）： 负责管理Harvester并找到所有读取源。Prospector会找到/apps/logs/*目录下的所有info.log文件，并为每个文件启动一个Harvester。Prospector会检查每个文件，看Harvester是否已经启动，是否需要启动，或者文件是否可以忽略。若Harvester关闭，只有在文件大小发生变化的时候Prospector才会执行检查。只能检测本地的文件。

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

Filebeat如何记录文件状态：

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

Filebeat如何保证事件至少被输出一次：

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

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

部署实践

参考：亿级 ELK 日志平台构建实践https://blog.51cto.com/13527416/2117141
elk+kafka+rsyslog+hadoop-hdfs+zookeeper搭建https://www.2cto.com/os/201604/503601.html

……未完待整理