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

文章目录

ELK+Filebeat+Kafka+Zookeeper日志分析系统
一、Filebeat
二、Kafka
三、Zookeeper
四、Kafka集群部署
五、Filebeat与logstash配置
六、测试
七、总结

一、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

在这里插入图片描述

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

4.工作流程

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

在这里插入图片描述

先从集群获取分区的leader
Producter将消息发送给leader
Leader将消息写入本地文件
Followers从leader同步消息
Follower将消息写入本地后向leader发送ACK确认消息
Leader收到所有副本的ACK后，向producter发送ACK
//注：消息写入leader后，follower是主动的去leader进行同步的

5.分区

分区的原因
便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；
可以提高并发，因为可以以Partition为单位读写了。

分区目的
producer采用push模式将数据发布到broker，每条消息追加到分区中，顺序写入磁盘，所以保证同一分区内的数据是有序的。

数据会写入到不同的分区，分区的目的是
方便扩展：因为一个topic可以有多个partition，所以我们可以通过扩展机器去轻松的应对日益增长的数据量。
提高并发：以partition为读写单位，可以多个消费者同时消费数据，提高了消息的处理效率。

6.Kafka原则

类似于负载均衡，当我们向某个服务器发送请求的时候，服务端可能会对请求做一个负载，将流量分发到不同的服务器，那在kafka中，如果某个topic有多个partition，producer又怎么知道该将数据发往哪个partition呢？kafka中有几个原则：

partition在写入的时候可以指定需要写入的partition，如果有指定，则写入对应的partition。

如果没有指定partition，但是设置了数据的key，则会根据key的值hash出一个partition。

如果既没指定partition，又没有设置key，则会轮询选出一个partition。
保证消息不丢失是一个消息队列中间件的基本保证，那producer在向kafka写入消息的时候，怎么保证消息不丢失呢？其实上面的写入流程图中有描述出来，那就是通过ACK应答机制！在生产者向队列写入数据的时候可以设置参数来确定是否确认kafka接收到数据，这个参数可设置的值为0、1、all。

0代表producer往集群发送数据不需要等到集群的返回，不确保消息发送成功。安全性最低但是效率最高。

1代表producer往集群发送数据只要leader应答就可以发送下一条，只确保leader发送成功。

all代表producer往集群发送数据需要所有的follower都完成从leader的同步才会发送下一条，确保leader发送成功和所有的副本都完成备份。安全性最高，但是效率最低。

三、Zookeeper

Zookeeper是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。Zookeeper提供了一个类似于Linux文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息，完全不适合存储大量文件或者大文件)，同时提供了对于每个节点的监控与通知机制

1.ZooKeeper简介

**ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，==**它提供了一项基本服务：**分布式锁服务。**分布式应用可以基于它实现更高级的服务，实现诸如同步服务、配置维护和集群管理或者命名的服务。

Zookeeper服务自身组成一个集群，2n+1个（奇数）服务允许n个失效，集群内一半以上机器可用，Zookeeper就可用。

假设 3台机器组成的集群，可以有允许一台失效，如果有2台失效，这个集群就不可用，1<1.5，一般的搭建zookeeper集群时，以奇数台机器来搭建。==目的：==是为了提高容错能允许多损失一台。

2.ZooKeeper工作机制

Zookeeper从设计模式角度来理解:是一个**基于观察者模式设计的分布式服务管理框架它负责存储和管理大家都关心的数据，**然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。也就是说 Zookeeper =文件系统＋通知机制。

在这里插入图片描述

3.ZooKeeper特点

(1)Zookeeper:一个领导者(Leader)，多个跟随者(Follower）组成的集群。
(2)Zookeepe集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。所以zookeeper适合安装奇数台服务器。
(3)全局数据一致:每个server保存一份相同的数据副本，client无论连接到哪个Server，数据都是一致的。
(4)更新请求顺序执行，来自同一个client的更新请求按其发送顺序依次执行，即先进先出。
(5)数据更新原子性，一次数据更新要么成功，要么失败。
(6)**实时性，**在一定时间范围内，client能读到最新数据。

4.Zookeeper数据结构

ZooKeeper数据模型的结构与Linux文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。

在这里插入图片描述

5.ZooKeeper应用场景

提供的服务包括:统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。

统一命名服务
在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。例如:IP不容易记住，而域名容易记住。
统一配置管理
- 分布式环境下，配置文件同步非常常见。一般要求一个集群中，所有节点的配置信息是一致的，比如Kafka集群。对配置文件修改后，希望能够快速同步到各个节点上。
- 配置管理可交由ZooKeeper实现。可将配置信息写入ZooKeeper上的一个Znode。各个客户端服务器监听这个Znode。一旦Znode中的数据被修改，ZooKeeper将通知各个客户端服务器。
统一集群管理
分布式环境中，实时掌握每个节点的状态是必要的。可根据节点实时状态做出一些调整。
ZooKeeper可以实现实时监控节点状态变化。可将节点信息写入ZooKeeper上的一个2Node。监听这个DMode可获取它的实时状态变化。
服务器动态上下线
客户端能实时洞察到服务器上下线的变化。
软负教均衡
在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求。

6.ZooKeeper选举机制

第一次启动选举机制

在这里插入图片描述

服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票)，选举无法完成，服务器1状态保持为LOOKING;
服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息:此时服务器1发现服务器2的myid比自己目前投票推举的（服务器1)大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING
服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果:服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING;
服务器4启动，发起一次选举。此时服务器1，2，3已经不是LooKING状态，不会更改选票信息。交换选票信息结果:服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLOWING;
服务器5启动，与服务器4一样

非第一次启动选举机制

在这里插入图片描述

当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举:
–服务器初始化启动。
–服务器运行期间无法和Leader保持连接。
而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态:
集群中本来就己经存在一个Leader。
对于已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。
集群中确实不存在Leader。
假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、，并且此时SID为3的服务器leader，某一时刻，3和5服务器出现故障，因此开始进行Leader选举。

选举Leader规则:
1.EPOCH大的直接胜出
2.EPOCH相同，事务id大的胜出
3.事务id相同，服务器id大的胜出
**SID:**服务器ID。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。
**ZXID:**事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的zxID值不一定完全一致，这和ZooKeeper服务器对于客户端"更新请求"的处理逻辑速度有关。
**Epoch:**可以理解为当前集群所处的年代或者周期，每个leader就像皇帝，都有自己的年号，所以每次改朝换代，leader变更之后，都会在前一个年代的基础上加l。这样就算I旧的leader崩溃恢复之后，也没有人听他的了，因为follower只听从当前年代的leader的命令。
Zookeeper角色
Zookeeper集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种
Leader
一个Zookeeper集群同一时间只会有一个实际工作的Leader,它会发起并维护与各Follwer及Observer间的心跳。
所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。只要有超过半数节点（不包括observeer节点）写入成功，该写请求就会被提交（类2PC协议）。
Follower
一个Zookeeper集群可能同时存在多个Follower,.它会响应Leader的心跳Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理

四、Kafka集群部署

服务基于ELK部署，具体请参照上篇文章：ELK日志分析系统

1.ZooKeeper部署

tar zxf apache-zookeeper-3.5.7-bin.tar.gz
mv apache-zookeeper-3.5.7-bin /usr/local/zookeeper-3.5.7
cd /usr/local/zookeeper-3.5.7/conf/
cp zoo_sample.cfg zoo.cfg
#修改配置文件
vim zoo.cfg
...
tickTime=2000   #通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒
initLimit=10    #Leader和Follower初始连接时能容忍的最多心跳数（tickTime的数量），这里表示为10*2s
syncLimit=5     #Leader和Follower之间同步通信的超时时间，这里表示如果超过5*2s，Leader认为Follwer死掉，并从服务器列表中删除Follwer
12 dataDir=/usr/local/zookeeper-3.5.7/data ●修改，指定保存Zookeeper中的数据的目录，目录需要单独创建
13 dataLogDir=/usr/local/zookeeper-3.5.7/logs●添加，指定存放日志的目录，目录需要单独创建
clientPort=2181   #客户端连接端口
#添加集群信息
server.1=20.0.0.19:3188:3288
server.2=20.0.0.30:3188:3288
server.3=20.0.0.10:3188:3288

scp zoo.cfg root@192.168.58.13:/usr/local/zookeeper-3.5.7/conf/
scp zoo.cfg root@192.168.58.22:/usr/local/zookeeper-3.5.7/conf/
#创建数据与日志存放目录
mkdir /usr/local/zookeeper-3.5.7/data
mkdir /usr/local/zookeeper-3.5.7/logs
#设置机器节点号
echo 1 > /usr/local/zookeeper-3.5.7/data/myid
echo 2 > /usr/local/zookeeper-3.5.7/data/myid
echo 3 > /usr/local/zookeeper-3.5.7/data/myid   #三台服务器ID号分别设置为1、2、3
#启动服务
cd /usr/local/zookeeper-3.5.7/bin
./zkServer.sh start
./zkServer.sh status

//或配置 Zookeeper 启动脚本
vim /etc/init.d/zookeeper
#!/bin/bash
#chkconfig:2345 20 90
#description:Zookeeper Service Control Script
ZK_HOME=‘/usr/local/zookeeper-3.5.7’
case $1 in
start)

echo -e “\033[32m ---------- zookeeper 启动 ------------ \033[0m”
$ZK_HOME/bin/zkServer.sh start
;;
stop)
echo -e “\033[32m ---------- zookeeper 停止 ------------ \033[0m”
$ZK_HOME/bin/zkServer.sh stop
;;
restart)
echo -e “\033[32m ---------- zookeeper 重启------------ \033[0m”
$ZK_HOME/bin/zkServer.sh restart
;;
status)
echo -e “\033[34m ---------- zookeeper 状态 ------------ \033[0m”
$ZK_HOME/bin/zkServer.sh status
;;
*)
echo “Usage: $0 {start|stop|restart|status}”
esac

// 设置开机自启
chmod +x /etc/init.d/zookeeper
chkconfig --add zookeeper

//分别启动 Zookeeper
service zookeeper start

//查看当前状态
service zookeeper status

解压移动

在这里插入图片描述

修改配置文件

在这里插入图片描述

创建数据与日志存放目录

在这里插入图片描述

设置机器节点号

在这里插入图片描述

加入系统服务

在这里插入图片描述

启动zookeeper，并查看集群状态

在这里插入图片描述

2.Kafka 部署

#上传并解压安装包
tar zxf kafka_2.13-2.8.1.tgz
mv kafka_2.13-2.8.1 /usr/local/kafka

#修改配置文件
cd /usr/local/kafka/config/
vim server.properties
...
● 21行修改服务 
 broker.id=1  
#21行，broker的全局唯一编号，每个broker不能重复，因此要在其他机器上配置 broker.id=1、broker.id=2

 ●31行修改监听地址为本机
listeners=PLAINTEXT://20.0.0.19:9092
 #31行，指定监听的IP和端口，如果修改每个broker的IP需区分开来，也可保持默认配置不用修改
 ============================================================
num.network.threads=3    #42行，broker 处理网络请求的线程数量，一般情况下不需要去修改
num.io.threads=8         #45行，用来处理磁盘IO的线程数量，数值应该大于硬盘数
socket.send.buffer.bytes=102400       #48行，发送套接字的缓冲区大小
socket.receive.buffer.bytes=102400    #51行，接收套接字的缓冲区大小
socket.request.max.bytes=104857600    #54行，请求套接字的缓冲区大小
log.dirs=/usr/local/kafka/logs        #60行，kafka运行日志存放的路径，也是数据存放的路径
num.partitions=1    #65行，topic在当前broker上的默认分区个数，会被topic创建时的指定参数覆盖
num.recovery.threads.per.data.dir=1    #69行，用来恢复和清理data下数据的线程数量
log.retention.hours=168    #103行，segment文件（数据文件）保留的最长时间，单位为小时，默认为7天，超时将被删除
log.segment.bytes=1073741824    #110行，一个segment文件最大的大小，默认为 1G，超出将新建一个新的segment文件
 ================================================================
 ●123行添加zookeeper集群地址，逗号分割
zookeeper.connect=20.0.0.10:2181,20.0.0.19:2181,20.0.0.30:2181
 ●更改环境变量
vim /etc/profile
export KAFKA_HOME=/usr/local/kafka
export PATH=$PATH:$KAFKA_HOME/bin

source /etc/profile
#启动服务
cd /usr/local/kafka/config/
kafka-server-start.sh -daemon server.properties

netstat -antp | grep 9092

或加入系统服务 Zookeeper 启动脚本

vim /etc/init.d/kafka
#!/bin/bash
#chkconfig:2345 22 88
#description:Kafka Service Control Script
KAFKA_HOME=‘/usr/local/kafka’
case $1 in
start)
echo -e “\033[32m---------- Kafka 启动 ------------\033[0m”
${KAFKA_HOME}/bin/kafka-server-start.sh -daemon ${KAFKA_HOME}/config/server.properties
;;
stop)
echo -e “\033[32m---------- Kafka 停止 ------------\033[0m”
${KAFKA_HOME}/bin/kafka-server-stop.sh
;;
restart)
$0 stop
$KaTeX parse error: Undefined control sequence: \0 at position 32: …s) echo -e "\̲0̲33[32m---------…$ (ps -ef | grep kafka | egrep -cv “grep|$ $") i f ["$ count” -eq 0 ];then
echo “kafka is not running”
else
echo “kafka is running”
fi
;;
*)
echo “Usage: $0 {start|stop|restart|status}”
esac

//设置开机自启
chmod +x /etc/init.d/kafka
chkconfig --add kafka

//分别启动 Kafka
service kafka start

上传并解压安装包

在这里插入图片描述

修改配置文件
在这里插入图片描述

在这里插入图片描述

更改环境变量
在这里插入图片描述

启动服务，并查看端口是否连接

在这里插入图片描述

3.kafka命令行操作

下文中命令所提的test为topic名

cd /usr/local/kafka/bin

创建topic

kafka-topics.sh --create --zookeeper 20.0.0.10:2181,20.0.0.19:2181,20.0.0.30:2181 --replication-factor 2 --partitions 3 --topic test

zookeeper：定义 zookeeper 集群服务器地址，如果有多个 IP 地址使用逗号分割，一般使用一个 IP 即可
replication-factor：定义分区副本数，1 代表单副本，建议为 2
partitions：定义分区数
topic：定义 topic 名称

查看当前服务器中的所有 topic

kafka-topics.sh --list --zookeeper 20.0.0.10:2181,20.0.0.19:2181,20.0.0.30:2181

查看某个 topic 的详情

kafka-topics.sh  --describe --zookeeper 20.0.0.10:2181,20.0.0.19:2181,20.0.0.30:2181

发布消息

kafka-console-producer.sh --broker-list 20.0.0.10:2181,20.0.0.19:2181,20.0.0.30:2181 --topic test

消费消息

kafka-console-consumer.sh --bootstrap-server 20.0.0.10:9092,20.0.0.19:9092,20.0.0.30:9092 --topic test --from-beginning

修改分区数

kafka-topics.sh --zookeeper 20.0.0.10:2181,20.0.0.19:2181,20.0.0.30:2181 --alter --topic test --partitions 6

删除 topic

kafka-topics.sh --delete --zookeeper 20.0.0.10:2181,20.0.0.19:2181,20.0.0.30:2181 --topic test

4.创建topic

#创建topic,并制定zookeeper集群，设置3个分片，每个分片有2个副本
cd /usr/local/kafka/bin
kafka-topics.sh --create --zookeeper \
20.0.0.10:2181,20.0.0.19:2181,20.0.0.30:2181 \
--partitions 3 \
--replication-factor 2 \
--topic test

#查看topic详情
kafka-topics.sh --describe --zookeeper 20.0.0.19:2181

在这里插入图片描述

4.5 测试topic
发布消息

kafka-console-producer.sh --broker-list 20.0.0.10:9092,20.0.0.19:9092,20.0.0.30:9092 --topic test

在这里插入图片描述

在另外一台机器消费信息

kafka-console-consumer.sh --bootstrap-server 20.0.0.10:9092 --topic test --from-beginning

在这里插入图片描述

五、Filebeat与logstash配置

1.安装Filebeat

#
安装httpd
systemctl stop firewalld
setenforce 0


#上传并解压filebeat
tar xf filebeat-6.6.0-linux-x86_64.tar.gz
mv filebeat-6.6.0-linux-x86_64 /usr/local/filebeat
#修改配置文件
vim /usr/local/filebeat/filebeat.yml
...
filebeat.prospectors:
- type: log
  enabled: true
  paths:
    - /var/log/httpd/access_log
  tags: ["access"]
  
- type: log
  enabled: true
  paths:
    - /var/log/httpd/error_log
  tags: ["error"]
#添加输出到 Kafka 的配置
output.kafka:
  enabled: true
  hosts: ["20.0.0.10:9092","20.0.0.19:9092","20.0.0.30:9092"]    #指定 Kafka 集群配置
  topic: "httpd"    #指定 Kafka 的 topic
...
#启动服务
cd /usr/local/filebeat/
./filebeat -c filebeat.yml &

netstat -antp|grep filebeat

修改配置文件

在这里插入图片描述

部署 ELK，在 Logstash 组件所在节点上新建一个 Logstash 配置文件

cd /etc/logstash/conf.d/

vim kafka.conf
input {
    kafka {
        bootstrap_servers => "20.0.0.10:9092,20.0.0.19:9092,20.0.0.30:9092"  #kafka集群地址
        topics  => "httpd"     #拉取的kafka的指定topic
        type => "httpd_kafka"  #指定 type 字段
        codec => "json"        #解析json格式的日志数据
		auto_offset_reset => "latest"  #拉取最近数据，earliest为从头开始拉取
		decorate_events => true   #传递给elasticsearch的数据额外增加kafka的属性数据
    }
}

output {
  if "access" in [tags] {
    elasticsearch {
      hosts => ["20.0.0.31:9200"]
      index => "httpd_access-%{+YYYY.MM.dd}"
    }
  }

  if "error" in [tags] {
    elasticsearch {
      hosts => ["20.0.0.31:9200"]
      index => "httpd_error-%{+YYYY.MM.dd}"
    }
  }

  stdout { codec => rubydebug }
}

#启动 logstash
logstash -f kafka.conf

input {
kafka {
bootstrap_servers => “20.0.0.10:9092,20.0.0.19:9092,20.0.0.30:9092”
topics => “httpd”
type => “httpd_kafka”
codec => “json”
auto_offset_reset => “latest”
decorate_events => true
}
}

output {
if “access” in [tags] {
elasticsearch {
hosts => [“20.0.0.11:9200”]
index => “httpd_access-%{+YYYY.MM.dd}”
}
}

if “error” in [tags] {
elasticsearch {
hosts => [“20.0.0.11:9200”]
index => “httpd_error-%{+YYYY.MM.dd}”
}
}

stdout { codec => rubydebug }
}

input {
kafka {
bootstrap_servers => “20.0.0.10:9092,20.0.0.19:9092,20.0.0.30:9092”
topics => “httpd”
decorate_events => true
}
}

output {
elasticsearch {
hosts => [“20.0.0.31:9200”]
index => “httpd-%{+YYYY.MM.dd}”

}

4.浏览器访问 http://192.168.10.13:5601 登录 Kibana，单击“Create Index Pattern”按钮添加索引“filebeat_test-*”，单击 “create” 按钮创建，单击 “Discover” 按钮可查看图表信息及日志信息。

2.kafka创建话题

在kafka上创建一个话题nginx-es

创建
kafka-topics.sh --create --zookeeper 20.0.0.10:2181,20.0.0.19:2181,20.0.0.30:2181 --replication-factor 1 --partitions 1 --topic httpd
查看
kafka-topics.sh --describe --zookeeper 20.0.0.10:2181

3.logstash配置

vim /etc/logstash/conf.d/nginx_log.conf

input {
    kafka {
        topics =>"nginx-es"
        decorate_events => true
        bootstrap_servers => "192.168.48.13:9092,192.168.48.14:9092,192.168.48.16:9092"
    }
}
output {
    elasticsearch {
        hosts => ["192.168.48.3:9200"]
        index =>"nginx-%{+YYYY.MM.dd}"
    }
}

六、测试

6.1 ES验证
访问：192.168.48.3：9100访问nginx日志是否存在

6.2 Kibana验证
访问：192.168.48.3：5601访问Kibana

七、总结

filebeat取代logstash进行日志收集，因为logstash太过消耗系统资源，而filebeat是轻量级服务
filebeat是生产者，将收集的日志发送的kafka

logstash是消费者，将日志进行过滤并发送到ES集群存储，并最终交由kibana展示