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

一.Filebeat

1.1Filebeat简介

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

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

1.2Filebeat工作方式

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

1.3Filebeat工作原理

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

1.4Filebeat用途

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

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

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

3. Filebeat和Logstash的区别

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

二.Kafka

2.1Kafka简介

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

2.1.1为什么需要消息队列

主要原因是由于在高并发环境下，同步请求来不及处理，请求往往会发生阻塞。比如大量的请求并发访问数据库，导致行锁表锁，最后请求线程会堆积过多，从而触发 too many connection 错误，引发雪崩效应。
我们使用消息队列，通过异步处理请求，从而缓解系统的压力。消息队列常应用于异步处理，流量削峰，应用解耦，消息通讯等场景。
当前比较常见的 MQ 中间件有 ActiveMQ、RabbitMQ、RocketMQ、Kafka 等。

2.1.2消息队列的好处

解耦合
耦合的状态表示当你实现某个功能的时候，是直接接入当前接口，而利用消息队列，可以将相应的消息发送到消息队列，这样的话，如果接口出了问题，将不会影响到当前的功能。

异步处理
异步处理替代了之前的同步处理，异步处理不需要让流程走完就返回结果，可以将消息发送到消息队列中，然后返回结果，剩下让其他业务处理接口从消息队列中拉取消费处理即可。

流量削峰
高流量的时候，使用消息队列作为中间件可以将流量的高峰保存在消息队列中，从而防止了系统的高请求，减轻服务器的请求处理压力。

2.1.3Kafka的特性

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

2.1.4 Kafka作为存储系统

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

2.2Kafka消费模式

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

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

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

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

2.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）上位࿰