ELK+Filebeat+Kafka+Zookeeper日志分析系统

ELK+Filebeat+Kafka+Zookeeper日志分析系统

一、Filebeat

1.Filebeat简介

Filebeat由两个主要组成部分组成：==prospector(探勘者)和 harvesters(矿车)。==这些组件一起工作来读取文件并将事件数据发送到指定的output。

==prospector:==负责找到所有需要进行读取的数据源
harvesters负责读取单个文件的内容，并将内容发送到output中，负责文件的打开和关闭。

2.Filebeat工作方式

启动Filebeat时，它将启动一个或多个输入，这些输入将在为日志数据指定的位置中查找。对于Filebeat所找到的每个日志，Filebeat都会启动收集器。每个收集器都读取单个日志以获取新内容，并将新日志数据发送到libbeat，libbeat将聚集事件，并将聚集的数据发送到为Filebeat配置的输出。

3.Filebeat工作原理

Filebeat可以保持每个文件的状态，并且频繁地把文件状态从注册表里更新到磁盘。这里所说的文件状态是用来记录上一次Harvster读取文件时读取到的位置，以保证能把全部的日志数据都读取出来，然后发送给output。如果在某一时刻，作为output的ElasticSearch或者Logstash变成了不可用，Filebeat将会把最后的文件读取位置保存下来，直到output重新可用的时候，快速地恢复文件数据的读取。在Filebaet运行过程中，每个Prospector的状态信息都会保存在内存里。如果Filebeat出行了重启，完成重启之后，会从注册表文件里恢复重启之前的状态信息，让FIlebeat继续从之前已知的位置开始进行数据读取。

4.Filebeat用途

适用于集群环境下，服务多，且部署在不同机器

• 为什么要用filebeat，而不用logstash收集日志
  因为logstash是jvm跑的，资源消耗比较大，启动一个logstash就需要消耗500M左右的内存（这就是为什么logstash启动特别慢的原因），而filebeat只需要10来M内存资源。常用的ELK日志采集方案中，大部分的做法就是将所有节点的日志内容通过filebeat发送到logstash，logstash根据配置文件进行过滤。然后将过滤之后的文件输送到elasticsearch中，通过kibana去展示。

• filebeat结合logstash带来好处
  通过Logstash，具有基于磁盘的自适应缓冲系统，该系统将吸收传入的吞吐量，从而减轻Elasticsearch持续写入数据的压力
  从其他数据源（例如数据库，s3对象存储或消息传递队列）中提取
  将数据发送到多个目的地，例如S3，HDFS(Hadoop分布式文件系统）或写入文件
  使用条件数据流逻辑组成更复杂的处理管道

• Filebeat和Logstash的区别

  	Logstash	Filebeat
  内存	大	小
  CPU	大	小
  功能	从多种输入端采集并实时解析和转换数据并输出到多种输出端	传输
  过滤能力	强大的过滤能力	有过滤能力但是弱
  轻重	相对较重	轻量级二进制文件
  进程	一台服务器只允许一个logstash进程，挂掉之后需要手动拉起
  原理	Logstash使用管道的方式进行日志的搜集和输出，分为输入input处理filter(不是必须的)输出output，每个阶段都有不同的替代方式	开启进程后会启动一个或多个探测器(prospectors)去检测指定的日志目录或文件，对于探测器找出的每一个日志文件，filebeat启动收割进程(harvester) ，每一个收割进程读取一个日志文件的新内容，并发送这些新的日志数据到处理程序(spooler)，处理程序会集合这些事件，最后filebeat会发送集合的数据到你指定的地点
  集群	单节点	单节点
  输出到多个接收方	支持	6.0之前支持

|二次开发或者扩展开发|难|易 |

​

二、Kafka

Kafka 是一个分布式的基于发布/订阅模式的消息队列（MQ，Message Queue），主要应用于大数据实时处理领域。

1.Kafka简介

Kafka 是最初由 Linkedin 公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于 Zookeeper 协调的分布式消息中间件系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景，比如基于 hadoop 的批处理系统、低延迟的实时系统、Spark/Flink 流式处理引擎，nginx 访问日志，消息服务等等，用 scala 语言编写，
Linkedin 于 2010 年贡献给了 Apache 基金会并成为顶级开源项目。

==Kafka是一种消息队列，主要用来处理大量数据状态下的消息队列，一般用来做日志的处理。==既然是消息队列，那么Kafka也就拥有消息队列的相应的特性了。
可以在系统中起到“削峰填谷”的作用，也可以用于异构、分布式系统中海量数据的异步化处理。

1.1为什么需要消息队列

主要原因是由于在高并发环境下，同步请求来不及处理，请求往往会发生阻塞。比如大量的请求并发访问数据库，导致行锁表锁，最后请求线程会堆积过多，从而触发 too many connection 错误，引发雪崩效应。

我们使用消息队列，通过异步处理请求，从而缓解系统的压力。消息队列常应用于异步处理，流量削峰，应用解耦，消息通讯等场景。
当前比较常见的 MQ 中间件有 ActiveMQ、RabbitMQ、RocketMQ（阿里云–几万并发）、Kafka（几十万） 等。

1.2消息队列的好处

• 解耦合
  耦合的状态表示当你实现某个功能的时候，是直接接入当前接口，而利用消息队列，可以将相应的消息发送到消息队列，这样的话，如果接口出了问题，将不会影响到当前的功能。
• 异步处理
  异步处理替代了之前的同步处理，异步处理不需要让流程走完就返回结果，可以将消息发送到消息队列中，然后返回结果，剩下让其他业务处理接口从消息队列中拉取消费处理即可。
• 流量削峰
  高流量的时候，使用消息队列作为中间件可以将流量的高峰保存在消息队列中，从而防止了系统的高请求，减轻服务器的请求处理压力。
• 可恢复性
  系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
• 缓冲
  有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。

1.3Kafka的特性

高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒
可扩展性：kafka集群支持热扩展
持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
高并发：支持数千个客户端同时读写

1.4 Kafka作为存储系统

任何允许发布与消费它们分离的消息的消息队列实际上充当了正在进行的消息的存储系统。
Kafka的不同之处在于它是一个非常好的存储系统。
写入Kafka的数据将写入磁盘并进行复制以实现容错。Kafka允许生产者等待确认，以便在完全复制之前写入不被认为是完整的，并且即使写入的服务器失败也保证写入仍然存在。
磁盘结构Kafka很好地使用了规模 - 无论服务器上有50 KB还是50 TB的持久数据，Kafka都会执行相同的操作。

2.Kafka消费模式

Kafka的消费模式主要有两种：

• 一种是一对一的消费，也即点对点的通信，即一个发送一个接收。

  消息生产者发布消息到Queue队列中，通知消费者从队列中拉取消息进行消费。消息被消费之后则删除，Queue支持多个消费者，但对于一条消息而言，只有一个消费者可以消费，即一条消息只能被一个消费者消费。

  

• 第二种为一对多的消费，即一个消息发送到消息队列，消费者根据消息队列的订阅拉取消息消费。

  这种模式也称为发布/订阅模式，即利用Topic存储消息，消息生产者将消息发布到Topic中，同时有多个消费者订阅此topic，消费者可以从中消费消息，注意发布到Topic中的消息会被多个消费者消费，消费者消费数据之后，数据不会被清除，Kafka会默认保留一段时间，然后再删除。

3.Kafka的基础架构

Kafka像其他Mq一样，也有自己的基础架构，主要存在生产者Producer、Kafka集群Broker、消费者Consumer、注册消息Zookeeper

1. Producer：Producer即生产者，消息的产生者，是消息的入口。
2. Broker：Broker是kafka实例，每个服务器上有一个或多个kafka的实例，我们姑且认为每个broker对应一台服务器。每个kafka集群内的broker都有一个不重复的编号.
3. **Topic：消息的主题,**可以理解为消息的分类，kafka的数据就保存在topic。在每个broker上都可以创建多个topic。
4. Partition: **Topic的分区，**每个topic可以有多个分区，分区的作用是做负载，提高kafka的吞吐量。同一个topic在不同的分区的数据是不重复的，partition的表现形式就是一个一个的文件夹！
5. Replication:每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。
6. Message：每一条发送的消息主体。
7. Consumer： 消费者，即消息的消费方，是消息的出口。
8. Consumer Group：我们可以将多个消费组组成一个消费者组，在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据，这也是为了提高kafka的吞吐量！
9. Zookeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。
10. Leader：每个分区多个副本的主角色，生产者发送数据的对象，以及消费者消费数据的对象都是Leader。
11. Follower：每个分区多个副本的从角色，实时的从Leader中同步数据，保持和Leader数据的同步，Leader发生故障的时候，某个Follower会成为新的Leader。
    上述一个Topic会产生多个分区Partition，分区中分为Leader和Follower，消息一般发送到Leader，Follower通过数据的同步与Leader保持同步，消费的话也是在Leader中发生消费，如果多个消费者，则分别消费Leader和各个Follower中的消息，当Leader发生故障的时候，某个Follower会成为主节点，此时会对齐消息的偏移量。

4.工作流程

producer就是生产者，是数据的入口。Producer在写入数据的时候永远的找leader，不会直接将数据写入follower

1. 先从集群获取分区的leader

2. Producter将消息发送给leader

3. Leader将消息写入本地文件

4. Followers从leader同步消息

5. Follower将消息写入本地后向leader发送ACK确认消息

6. Leader收到所有副本的ACK后，