ELK架构概览

1. ELK架构简介

1.1 核心组成

• ELK是一套开源免费且功能强大的日志分析管理系统，由Elasticsearch、Logstash、Kibana三部分组成，简称ELK。
• ELK可以将系统日志、网站日志、应用系统日志等各种日志进行收集、过滤、清洗，然后进行集中存放并可用于检索、分析。
• 这三款软件都是开源软件，通常是配合使用，且归于Elastic.co公司名下，所以被简称为ELK Stack。

1.2 Elasticsearch简介

• Elasticsearch是一个实时的分布式搜索和分析引擎，可用于全文搜索，结构化搜索以及分析，采用Java语言编写。

1）主要特点

• 实时搜索，实时分析
• 分布式架构、实时文件存储，并将每一个字段都编入索引
• 文档导向，所有的对象全部是文档
• 高可用性，易扩展，支持集群（Cluster）、分片和复制（Shared、Replicas）
• 接口友好，支持JSON

2）典型的集群架构图

1.3 Logstash简介

Logstash是一款轻量级的、开源的日志收集处理框架，它可以方便的把分散的、多样化的日志收集起来，并进行自定义过滤分析处理，然后传输到指定的位置（某服务器或者文件）。Logstash采用JRuby语言编写。

1）Logstash的特点

• input：数据搜集
• filter：数据加工，如过滤、改写等
• output：数据输出

2）Logstash的内部运行逻辑图

• Shipper：主要用来搜集日志数据，负责监控本地日志文件的变化，及时把日志文件的最新内容收集起来，然后经过加工、过滤，输入到Broker
• Broker：相当于日志Hub，用来连接多个Shipper和多个Indexer
• Indexer：从Broker读取文本，经过加工、过滤，输入到指定的介质中（可以是文件、网络、Elasticsearch等）

Redis服务器是logstash官方推荐的broker，这个broker起数据缓存的作用，通过这个缓存器可以提高Logstash Shipper发送日志到Logstash indexer的速度，同时避免了由于突然断电导致的数据丢失。可以实现broker功能的软件还有许多，如kafka等。

在实际应用中LogStash自身并没有什么角色，只是根据不同的功能、不同的配置给出不同的称呼而已，无论是Shipper还是Indexer，始终只做前面说的三件事。

1.4 Kibana简介

Kibana是一个开源的数据分析可视化平台。

使用Kibana可以为Logstash和Elasticsearch提供的日志数据进行高效搜索、可视化总和多维度分析，还可以与Elasticsearch搜索引擎中的数据进行交互。

它基于浏览器的界面操作可以快速创建动态仪表板，实时监控Elasticsearch的数据状态与更新。

1.5 ELK的工作流程

1）工作流程

1. 一般都是在需要搜索日志的所有服务器上部署Logstash，作为Logstash shipper用于监控并收集、过滤日志，
2. 接着将过滤后的日志发送给Broker，
3. 然后Logstash Indexer将存放在Broker中的数据再写入Elasticsearch，Elasticsearch对这些数据创建索引，
4. 最后由Kibana对其进行各种分析并以图表的形式展示。

 2）工作图示

有些时候，如果搜集的日志量较大，为了保证日志搜集的性能和数据的完整性，Logstash shipper和logstash indexer之间的缓冲器（Broker）也经常用kafka来实现。

2. ZooKeeper基础入门

2.1 ZooKeeper简介

1）分布式协调技术

分布式协调技术主要是用来解决分布式环境当中多个进程之间的同步控制，让它们有序的去访问某种共享资源，防止造成资源竞争（脑裂）。

2）分布式系统

分布式系统就是在不同地域分布的多个服务器，共同组成一个应用系统来提供服务。

在分布式系统中最重要的是进程的调度，需要一个协调器，来让它们有序的来访问这个资源；这个协调器就是分布式系统中的“锁”。分布式环境下的锁叫做分布式锁；分布式锁就是分布式协调技术实现的核心内容。

某个进程在使用资源时，会先去获得这把锁，该进程获得锁以后会对资源保持独占，此时其它进程就无法访问该资源。这个进程用完该资源后会将该锁释放掉，以便让其他教程来获得锁。这样就可以保证分布式系统中多个进程能够有序的访问该共享资源。

3）ZooKeeper

ZooKeeper就是一种为分布式应用所设计的高可用、高性能的开源协调服务。

它提供了一套分布式锁服务，同时也提供了数据的维护和管理机制，如：同一命名服务、状态同步服务、集群管理、分布式消息队列、分布式应用配置项的管理等。

2.2 ZooKeeper的应用

1）单点故障

在分布式锁服务中，最典型的应用场景就是通过对集群进行Master角色的选举，来解决分布式系统中单点故障问题。

单点故障就是在一个主从的的分布式系统中，主节点负责任务调度，从节点负责任务的处理，而当主节点发生故障时，整个应用系统也就瘫痪了，这种故障件求称之为单点故障

2）传统方式解决单点故障

采用一个备用节点定期向主节点发送ping包，主节点收到ping包以后向备用节点发送回复Ack信息，当备节点收到回复的时候就会任务当前主节点运行正常，让它继续提供服务；当主节点故障时，没用节点就无法收到回复信息了，此时，备用节点就认为主节点宕机，然后接替它成为新的主节点继续提供服务。

3）传统方式解决单点故障的缺陷

当主节点并没有出现故障，只是在向从节点回复Ack响应的时候网络发生了故障，这样备用节点就无法收到回复，那么他就会认为主节点出现了故障， 然后备用节点将会接管主节点的服务并成为新的主节点。此时，分布式系统中就出现了两个主节点（双Master节点）的情况（脑裂），双Master节点的出现，会导致分布式系统的服务发生混乱。这样这个分布式系统将不可用。

为了解决传统方式决绝单点故障的缺陷，就引入了ZooKeeper来解决这种问题。

2.3 ZooKeeper的工作原理

1）Master启动

分布式系统中引入ZooKeeper之后，就可以配置多个主节点，以配置两个节点为例，Master A和Master B都启动后，它们都会向ZooKeeper中注册节点信息。

假设Master A锁注册的节点信息是master00001，Master B注册的节点信息是master00002，注册完成之后会进行选举，选举有多种算法。以编号最小作为选举算法为例，编号最小的节点将在选举中获胜并获得锁成为主节点，也就是Master A将会获得锁并成为主节点，然后Master B将被阻塞成为一个备用节点。那么通过这种方式ZooKeeper就完成了对两个Master进程的调度，完成了主、备节点的分配和协作。

2）Master故障

如果Master A发生了故障，这时它在ZooKeeper所注册的节点信息会被自动删除，而ZooKeeper会自动感知节点的变化，发现Master A故障后，会再次发出选举，这时Master B将在选举中获胜，替代Master A成为新的主节点，这样就完成了主、被节点的重新选举。

3）Master恢复

如果主节点恢复了，它会再次向ZooKeeper注册自身的节点信息，但是这时它注册的节点信息将会变成master00003，而不是原来的信息。ZooKeeper会感知节点的变化再次发动选举，这时Master B会在选举中再次获胜继续担任主节点，Master A会担任备用节点。

ZooKeeper就是通过这样的协调、调度机制如此反复的对集群进行管理和状态同步的。

2.4 ZooKeeper集群架构

1）ZooKeeper集群图示

ZooKeeper一般是通过集群架构来提供服务的

2）ZooKeeper的角色

ZooKeeper集群主要角色有Server和Client，其中Server又分为Leader、Follower、Observer三个角色

• Leader：领导者角色，主要负责投票的发起和决议，以及更新系统状态
• Follower：跟随者角色，用于接收客户端的请求并返回结果给客户端，在选举过程中参与投票
• Observer：观察者角色，用户接收客户端的请求，并将写请求转发给Leader，同时同步Leader状态，但不参与投票；Observer的目的是扩展系统，提高伸缩性。
• Client：客户端角色，用于向ZooKeeper发起请求。

3）ZooKeeper数据存储机制

ZooKeeper集群中每个Server在内存中存储了一份数据，在ZooKeeper启动时，将从实例中选举一个Server作为Leader，Leader负责处理数据更新等操作，当大多数Server在内存中成功修改数据，才认为数据修改成功。

4）ZooKeeper写的流程

客户端Client首先和一个Server或者Observer通信，发起写请求，然后Server将写请求转发给Leader，Leader再将写请求转发给其他Server，其他Server在接收到写请求后写入数据并响应Leader，Leader在接收到大多数写成功回应后，认为数据写成功，最后响应Client，完成一次写操作过程。

3. Kafka基础入门

3.1 kafka基本概念

Kafka是一种高吞吐量的分布式发布/订阅消息系统。

kafka是Apache旗下的一个开源系统，它可以实时处理大量数据以满足各种需求场景：如基于hadoop平台的数据分析、低时延的实时系统、storm/spark流式处理引擎等。

3.2 kafka角色术语

Broker：Kafka集群包含一个或多个服务器，每个服务器被称为broker。

Topic：每条发布到Kafka集群的消息都有一个分类，这个类别被称为Topic（主题）。

Producer：指消息的生产者，负责发布消息到Kafka broker。

Consumer：指消息的消费者，从Kafka broker拉取数据，并消费这些已发布的消息。

Partition：Partition是物理上的概念，每个Topic包含一个或多个Partition，每个partition都是一个有序的队列；partition中的每条消息都会被分配一个有序的id（称为offset）。

Consumer Group：消费者组，可以给每个Consumer指定消费者组，若不指定消费者组，则属于默认的group。

Message：消息，通信的基本单位，每个producer可以向一个topic发布一些消息。

3.3 kafka拓扑架构

典型的Kafka集群包含若干Producer，若干broker，若干Consumer Group，以及一个Zookeeper集群。

Kafka通过ZooKeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。

Produce使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。

3.4 Topic与Partition

Kafka中的topic是以partition的形式存放的，每个topic都可以设置它的partition数量

Partition的数量决定了组成topic的log的数量，推荐partition的数量大于同时运行的consumer的数量，这样消息数据就可以均匀的分布在各个broker中。

Topic设置多个Partition的缘由：

应该kafka是基于文件存储的，通过配置多个partition可以将消息内容分散存储到多个broker上，这样可以避免文件尺寸达到单机磁盘的上限。

同时，将topic切分成任意多个partitions，可以保证消息存储、消息消费的效率，因为越多的partitions可以容纳更多的consumer，可以有效的提升kafka的吞吐率。

所以，将Topic切分成多个partitions的好处是可以将大量的消息分成多批数据同时写到不同节点上，将写请求负担负载到各个集群节点。

3.5 kafka消息发送机制

3.6 kafka消息消费机制

3.7 kafka消息存储机制

4. filebeat基础入门

4.1 filebeat简介

4.2 filebeat架构运行原理

5. ELK常见应用架构

5.1 简单的ELK架构

5.2 典型ELK架构

5.3 ELK集群架构