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

Filebeat---------------------------部分

一、Filebeat 简介

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

1、prospector: 负责找到所有需要进行读取的数据源

2、harvesters：负责读取单个文件的内容，并将内容发送到output中，负责文件的打开和关闭。

1、Logstash
作为数据收集引擎。它支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储到用户指定的位置,一般会发送给 Elasticsearch。

#可以添加的其它组件：
2、Filebeat
轻量级的开源日志文件数据搜集器。通常在需要采集数据的客户端安装 Filebeat，并指定目录与日志格式，Filebeat 就能快速收集数据，并发送给 logstash 进行解析，或是直接发给 Elasticsearch 存储，性能上相比运行于 JVM 上的 logstash 优势明显，是对它的替代。常应用于 EFLK 架构当中。

二、Filebeat的工作方式

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

三、Filebeat工作原理

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

四、Filebeat用途

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

1、为什么要用filebeat来收集日志？

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

2、filebeat结合logstash带来好处

通过 Logstash 具有基于磁盘的自适应缓冲系统，该系统将吸收传入的吞吐量，从而减轻 Elasticsearch 持续写入数据的压力
从其他数据源（例如数据库，S3对象存储或消息传递队列）中提取
将数据发送到多个目的地，例如S3，HDFS（Hadoop分布式文件系统）或写入文件
使用条件数据流逻辑组成更复杂的处理管道
缓存/消息队列（redis、kafka、RabbitMQ等）：可以对高并发日志数据进行流量削峰和缓冲，这样的缓冲可以一定程度的保护数据不丢失，还可以对整个架构进行应用解耦。

Fluentd：是一个流行的开源数据收集器。由于 logstash 太重量级的缺点，Logstash 性能低、资源消耗比较多等问题，随后就有 Fluentd 的出现。相比较 logstash，Fluentd 更易用、资源消耗更少、性能更高，在数据处理上更高效可靠，受到企业欢迎，成为 logstash 的一种替代方案，常应用于 EFK 架构当中。在 Kubernetes 集群中也常使用 EFK 作为日志数据收集的方案。
在 Kubernetes 集群中一般是通过 DaemonSet 来运行 Fluentd，以便它在每个 Kubernetes 工作节点上都可以运行一个 Pod。 它通过获取容器日志文件、过滤和转换日志数据，然后将数据传递到 Elasticsearch 集群，在该集群中对其进行索引和存储。

3、Filebeat和Logstash的区别

	Logstash	Filebeat
内存	大	小
CPU	大	小
插件	多	多
功能	从多种输入端采集并实时解析和转换数据并输出到多种输出端	传输
轻重	相对较重	轻量级二进制文件
过滤能力	强大的过滤能力	有过滤能力但是弱
集群	单节点	单节点
输出到多个接收方	支持	6.0之前支持
二次开发或者扩展开发	难	易
进程	一台服务器只允许一个logstash进程，挂掉之后需要手动拉起

Kafka---------------------------部分

1、Kafka简介

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

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

当前比较常见的 MQ 中间件有 ActiveMQ、RabbitMQ、RocketMQ、Kafka 等。

2、消息队列的好处
1、解耦合

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

2、异步处理

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

3、流量削峰

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

3、Kafka的特性
高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒

可扩展性：kafka集群支持热扩展

持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失

容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）

高并发：支持数千个客户端同时读写

4、Kafka作为存储系统
1、任何允许发布与消费它们分离的消息的消息队列实际上充当了正在进行的消息的存储系统。

2、Kafka的不同之处在于它是一个非常好的存储系统。

3、写入Kafka的数据将写入磁盘并进行复制以实现容错。Kafka允许生产者等待确认，以便在完全复制之前写入不被认为是完整的，并且即使写入的服务器失败也保证写入仍然存在。

4、磁盘结构Kafka很好地使用了规模 - 无论服务器上有50 KB还是50 TB的持久数据，Kafka都会执行相同的操作。

二、Kafka消费模式

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

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

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

1、一对一

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

2、一对多

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

三、Kafka的基础架构

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

1、Kafka架构

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会成为主节点，此时会对齐消息的偏移量。

2、工作流程

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

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

2、Producter将消息发送给leader

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

4、Followers从leader同步消息

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

6、Leader收到所有副本的ACK后，向producter发送ACK

3、分区的原因

1、便在集群中扩展，每个Partition（分区）可以通过调整以适应它所在的机器，而一个topic（消息主题）又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；

2、可以提高并发，因为可以以Partition为单位读写了。

4、分区目的

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

数据会写入到不同的分区，分区的目的是

1、方便扩展：因为一个topic可以有多个partition，所以我们可以通过扩展机器去轻松的应对日益增长的数据量。

2、抗高并发：以partition为读写单位，可以多个消费者同时消费数据，提高了消息的处理效率。

四、Kafka原则

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

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

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

3、如果既没指定partition，又没有设置key，则会轮询选出一个partition。

保证消息不丢失是一个消息队列中间件的基本保证，那producer在向kafka写入消息的时候，怎么保证消息不丢失呢？

那就是通过ACK应答机制！在生产者向队列写入数据的时候可以设置参数来确定是否确认kafka接收到数据，这个参数可设置的值为0、1、all。

Zookeeper---------------------------部分

一、ZooKeeper简介

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

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

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

二、 zookeeper工作机制

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

三、zookeeper特点

1、Zookeeper:一个领导者(Leader)，多个跟随者(Follower）组成的集群。

2、Zookeepe集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。所以zookeeper适合安装奇数台服务器。

3、全局数据一致:每个server保存一份相同的数据副本，client无论连接到哪个Server，数据都是一致的。

4、更新请求顺序执行，来自同一个client的更新请求按其发送顺序依次执行，即先进先出。

5、数据更新原子性，一次数据更新要么成功，要么失败。

6、实时性，在一定时间范围内，client能读到最新数据。

四、Zookeeper数据结构

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

五、zookeeper应用场景

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

1、统一命名服务

1、在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。例如:IP不容易记住，而域名容易记住。

2、统一配置管理

1、分布式环境下，配置文件同步非常常见。一般要求一个集群中，所有节点的配置信息是一致的，比如Kafka集群。对配置文件修改后，希望能够快速同步到各个节点上。

2、配置管理可交由ZooKeeper实现。可将配置信息写入ZooKeeper上的一个Znode。各个客户端服务器监听这个Znode。一旦Znode中的数据被修改，ZooKeeper将通知各个客户端服务器。

3、统一集群管理

1、分布式环境中，实时掌握每个节点的状态是必要的。可根据节点实时状态做出一些调整。

2、ZooKeeper可以实现实时监控节点状态变化。可将节点信息写入ZooKeeper上的一个2Node。监听这个DMode可获取它的实时状态变化。

4、服务器动态上下线

客户端能实时洞察到服务器上下线的变化。

5、软负教均衡

在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求。

六、工作原理

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。

恢复模式：当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，恢复模式不接受客户端请求，
当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。
状态同步保证了leader和Server具有相同的系统状态。

广播模式：一旦Leader已经和多数的Follower进行了状态同步后，他就可以开始广播消息了，
即进入广播状态。这时候当一个Server加入ZooKeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步。待到同步结束，它也参与消息广播。

ZooKeeper的广播状态一直到Leader崩溃了或者Leader失去了大部分的Followers支持。

七、zookeeper选举机制

第一次启动选举机制

1、服务器1启动，发起一次选举。服务器1投自己一票。
此时服务器1票数一票，不够半数以上（3票)，选举无法完成，服务器1状态保持为LOOKING;

2、服务器2启动，再发起一次选举。
服务器1和2分别投自己一票并交换选票信息:
此时服务器1发现服务器2的myid比自己目前投票推举的（服务器1)大，
更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING

3、服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。
此次投票结果:服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，
服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING;

4、服务器4启动，发起一次选举。此时服务器1，2，3已经不是LooKING状态，不会更改选票信息。
交换选票信息结果:服务器3为3票，服务器4为1票。
此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLOWING;

5、服务器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的服务器是。一时刻，3和5服务器出现故障，因此开始进行Leader选举。
选举Leader规则:

EPOCH大的直接胜出
EPOCH相同，事务id大的胜出
事务id相同，服务器id大的胜出

SID:服务器ID。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。
ZXID:事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。
在某一时刻，集群中的每台机器的zxID值不一定完全一致，这和ZooKeeper服务器对于客户端"更新请求"的处理逻辑速度有关。
Bpoch:每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加

搭建ELK+Filebeat+Kafka+Zookeeper----------------------部分

一、ELK+Filebeat+Kafka+Zookeeper架构

每层实现的功能和含义分别介绍如下：

数据采集层
数据采集层位于最左边的业务服务器集群上，
在每个业务服务器上面安装了filebeat做日志收集，然后把采集到的原始日志发送到Kafka+zookeeper集群上。

消息队列层
原始日志发送到Kafka+zookeeper集群上后，会进行集中存储，
此时，filbeat是消息的生产者，存储的消息可以随时被消费。

数据分析层
Logstash作为消费者，会去Kafka+zookeeper集群节点实时拉取原始日志，
然后将获取到的原始日志根据规则进行分析、清洗、过滤，最后将清洗好的日志转发至Elasticsearch集群。

数据持久化存储
Elasticsearch集群在接收到logstash发送过来的数据后，
执行写磁盘，建索引库等操作，最后将结构化的数据存储到Elasticsearch集群上。

数据查询、展示层
Kibana是一个可视化的数据展示平台，当有数据检索请求时，
它从Elasticsearch集群上读取数据，然后进行可视化出图和多维度分析。

二、搭建ELK+Filebeat+Kafka+Zookeeper

|IP | 角色 |所属集群
|–|–|
| 192.168.58.30 | Elasticsearch、Kibana |Elasticsearch集群
| 192.168.58.19 | Elasticsearch |Elasticsearch集群
| 192.168.58.20 | Logstash |数据转发
| 192.168.58.35 | Kafka+zookeeper |Kafka+zookeeper群集
| 192.168.58.13 | Kafka+zookeeper |Kafka+zookeeper群集
| 192.168.58.22 | Kafka+zookeeper |Kafka+zookeeper群集
|192.168.58.10 | filebeat |配置数据采集层

本实验基于ELK已经搭好的情况下
添加链接描述

1、安装zookeeper（zookeeper群集）

解压安装zookeeper软件包
tar zxf apache-zookeeper-3.7.1-bin.tar.gz
 
mv apache-zookeeper-3.7.1-bin /usr/local/zookeeper-3.7.1
 
cd /usr/local/zookeeper-3.7.1/conf/
 
cp zoo_sample.cfg zoo.cfg

1.1、修改配置文件

vim zoo.cfg 
 
12 dataDir=/usr/local/zookeeper-3.7.1/data
13 dataLogDir=/usr/local/zookeeper-3.7.1/logs
15 clientPort=2181
37 server.1=192.168.58.35:3188:3288
38 server.2=192.168.58.13:3188:3288
39 server.3=192.168.58.22:3188:3288
 
 
scp zoo.cfg root@192.168.58.13:/usr/local/zookeeper-3.7.1/conf/
scp zoo.cfg root@192.168.58.22:/usr/local/zookeeper-3.7.1/conf/

1.2、给每个机器指定对应的节点号

pwd
/usr/local/zookeeper-3.7.1
[root@localhost zookeeper-3.7.1]# mkdir data logs
 
[root@localhost zookeeper-3.7.1]# echo "1" > data/myid
[root@localhost zookeeper-3.7.1]# cat data/myid 
1
 

1.3、启动zookeeper
注：启动zookeeper报错

解决方法

cd /usr/local/zookeeper-3.7.1/bin
./zkServer.sh start

1.4、查看zookeeper状态

2、安装kafka

2.1、安装 kafka（Kafka集群）
三台机器都要安装（只展示一台）

tar zxf kafka_2.13-2.7.1.tgz
mv kafka_2.13-2.7.1 /usr/local/kafka

2.2、修改配置文件

cd /usr/local/kafka/config/
vim server.properties
 
（192.168.58.35）
21 broker.id=1
31 listeners=PLAINTEXT://192.168.58.35:9092
123 zookeeper.connect=192.168.58.35:2181,192.168.58.13:2181,192.168.58.22:2181
 
 
（192.168.58.13）
21 broker.id=2
31 listeners=PLAINTEXT://192.168.58.13:9092
123 zookeeper.connect=192.168.58.35:2181,192.168.58.13:2181,192.168.58.22:2181
 
（192.168.58.22）
21 broker.id=3
31 listeners=PLAINTEXT://192.168.58.22:9092
123 zookeeper.connect=192.168.58.35:2181,192.168.58.13:2181,192.168.58.22:2181

192.168.58.35



192.168.58.13


192.168.58.22


2.3、将相关命令加入到系统环境当中
仅展示一台操作

vim /etc/profile
export KAFKA_HOME=/usr/local/kafka
export PATH=$PATH:$KAFKA_HOME/bin
 
source /etc/profile

2.4、启动kafka
三台机器都需要开启，仅展示一台

cd /usr/local/kafka/config/
kafka-server-start.sh -daemon server.properties
netstat -antp | grep 9092

2.5、Kafka 命令行操作解析

创建topic
 
kafka-topics.sh --create --zookeeper 192.168.58.35:2181,192.168.58.13:2181,192.168.58.22: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 192.168.58.35:2181,192.168.58.13:2181,192.168.58.22:2181
 
发布消息
kafka-console-producer.sh --broker-list 192.168.58.35:9092,192.168.58.13:9092,192.168.58.22:9092  --topic test
 
消费消息
kafka-console-consumer.sh --bootstrap-server 192.168.58.35:9092,192.168.58.13:9092,192.168.58.22:9092 --topic test --from-beginning
 
–from-beginning：会把主题中以往所有的数据都读取出来
 
修改分区数
kafka-topics.sh 
--zookeeper 192.168.58.35:2181,192.168.58.13:2181,192.168.58.22:2181 --alter --topic test --partitions 6
 
删除 topic
kafka-topics.sh 
--delete --zookeeper 192.168.58.35:2181,192.168.58.13:2181,192.168.58.22:2181 --topic test
 
 

2.6、创建topic

pwd
/usr/local/kafka/bin
kafka-topics.sh --create --zookeeper \
> 192.168.58.35:2181,192.168.58.13:2181,192.168.58.22:2181 \
> --partitions 3 \
> --replication-factor 2 \
> --topic test
Created topic test.
kafka-topics.sh --describe --zookeeper 192.168.58.13:2181
Topic: test	PartitionCount: 3	ReplicationFactor: 2	Configs: 
	Topic: test	Partition: 0	Leader: 3	Replicas: 3,1	Isr: 3,1
	Topic: test	Partition: 1	Leader: 1	Replicas: 1,2	Isr: 1,2
	Topic: test	Partition: 2	Leader: 2	Replicas: 2,3	Isr: 2,3

2.7、测试topic

发布消息
pwd
/usr/local/kafka/config
 
kafka-console-producer.sh --broker-list 192.168.58.35:9092,192.168.58.13:9092,192.168.58.22:9092 --topic test
 

kafka-console-producer.sh --broker-list 192.168.109.15:9092 --topic test

消费消息

pwd
/usr/local/kafka/config
kafka-console-consumer.sh --bootstrap-server 192.168.58.22:9092 --topic test --from-beginning

3、配置数据采集层filebeat（192.168.58.10）

先下载nginx ,测试用来收集日志



3.1、定制日志格式

log_format   json '{"@timestamp":"$time_iso8601",'
                           '"@version":"1",'
                           '"client":"$remote_addr",'
                           '"url":"$uri",'
                           '"status":"$status",'
                           '"domain":"$host",'
                           '"host":"$server_addr",'
                           '"size":$body_bytes_sent,'
                           '"responsetime":$request_time,'
                           '"referer": "$http_referer",'
                           '"ua": "$http_user_agent"'
               '}';
         access_log  /var/log/nginx/access.log  json;

3.2、上传、解压安装包

cd /opt
tar zxf filebeat-6.5.4-linux-x86_64.tar.gz
mv filebeat-6.5.4-linux-x86_64 /usr/local/filebeat

3.3、修改配置文件filebeat.yml

vim filebeat.yml
 
24   enabled: true
27   paths:
28     - /var/log/access.log
148 output.kafka:
150   hosts: ["192.168.58.35:9092","192.168.58.13:9092","192.168.58.22:9092"]
151   topic: 'nginx-es'

3.4、启动filebeat

./filebeat -c filebeat.yml &
netstat -anpt |grep filebeat

4、组件部署完成之后，开始配置部署

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

kafka-topics.sh --create --zookeeper 192.168.58.35:2181,192.168.58.13:2181,192.168.58.22:2181 --replication-factor 1 --partitions 1 --topic nginx-es

kafka-topics.sh --describe --zookeeper 192.168.58.13:2181

4.2、修改logstash的配置文件（192.168.58.20）

[root@client ~]# cd /etc/logstash/conf.d/
[root@client conf.d]# ls
nginxlog.conf  syslog.conf
 vim nginxlog.conf 
 
input {
    kafka{
        topics => "nginx-es"
        #codec => "json"
        decorate_events => true
        bootstrap_servers => "192.168.58.35:9092,192.168.58.13:9092,192.168.58.22:9092"
    }
}
output {
        elasticsearch {
            hosts => ["192.168.58.30:9200"]
            index => "nginx-%{+YYYY.MM.dd}"
        }
  }

4.3、验证网页
启动服务



4.4、Kibana上创建索引

三、总结

为什么要做日志分析平台？

随着业务量的增长，每天业务服务器将会产生上亿条的日志，单个日志文件达几个GB，这时我们发现用Linux自带工具，cat grep awk 分析越来越力不从心了，而且除了服务器日志，还有程序报错日志，分布在不同的服务器，查阅繁琐。

导致

大量不同种类的日志成为了运维人员的负担，不方便管理。

单个日志文件巨大，无法使用常用的文本工具分析，检索困难。

日志分布在多台不同的服务器上，业务一旦出现故障，需要一台台查看日志。