filebeat+zookeeper+kafka原理图

1.架构图

简版：
位于各个节点上的filebeat将收集到的日志数据output给es存储，通过kibana展示。

规范版：适用于每天50G以上日志量收集。
位于各个节点上的filebeat先将数据/日志传递给Kafka（或者Redis），并将队列中消息或数据间接传递给Logstash，Logstash过滤、分析后将数据传递给Elasticsearch存储。最后由Kibana将日志和数据呈现给用户。因为引入了Kafka（或者Redis）,所以即使远端Logstash server因故障停止运行，数据将会先被存储下来，从而避免数据丢失。

Beats 还不支持输出到消息队列（新版本除外：5.0版本及以上），所以在消息队列前后两端只能是 Logstash 实例。logstash从各个数据源搜集数据，不经过任何处理转换仅转发出到消息队列（kafka、redis、rabbitMQ等），后logstash从消息队列取数据进行转换分析过滤，输出到elasticsearch，并在kibana进行图形化展示

1）什么是Elasticsearch？

是一个高度可扩展的开源全文搜索和分析引擎，它可实现数据的实时全文搜索 搜索、支持分布式

2）什么是 Logstash？

可以通过插件实现日志收集和转发，支持日志过滤，支持普通 log、自定义 json格式的日志解析。

3）什么是 是 kibana ？

主要是通过接口调用 elasticsearch 的数据，并进行前端数据可视化的展现

4）Filebeat隶属于Beats。

轻量，可代替Logstash，规避了Logstash的缺点，目前Beats包含四种工具：

• Packetbeat（搜集网络流量数据）
• Topbeat（搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据）
• Filebeat（搜集文件数据）
• Winlogbeat（搜集 Windows 事件日志数据）

5.filebeat工作原理：

Filebeat由两个主要组件组成：input 和 harvesters。这两个组件协同工作将文件变动发送到指定的输出中。

input插件
https://www.elastic.co/guide/en/beats/filebeat/current/configuration-filebeat-options.html#filebeat-input-types

Filebeat 的工作原理如下：当您启动 Filebeat 时，它会启动一个或多个在您为日志数据指定的位置查找的输入。对于 Filebeat 找到的每个日志，Filebeat 都会启动一个收割机。每个收割机读取新内容的单个日志，并将新日志数据发送到 libbeat，后者聚合事件并将聚合数据发送到您为 Filebeat 配置的输出。

2.组件组成：

• inputs–探测–（探测有哪些文件可采集）
• Harvest–收取–（具体采集文件数据）
• libeat–汇集对外输送–（输出文件数据）
• registry–记录收取进度–（记录采集和输出进度）

输入（inputs）：一个输入负责管理收割机并查找所有可读取的资源。日志类型输入检查每个文件，以查看收割机是否需要启动，是否已经运行，或是否需要忽略该文件。自收割机关闭之后，如果文件大小有更改才会获取新行。

Harvester（收割机）：

• 一个harvester对应一个file，可有多个harvester。
• harvester按行读取文件内容，然后发送给output
• 正在被harvester处理的文件，如果中间被删除了，harvester将会释放资源。
• 不活动的文件在close_inactive到达时间时，harvester关闭句柄后，如果对应文件被删除，则不会再继续处理该文件。
• 只有scan_frequency到达时间时，harvester才会重新启动。

3.zookeeper+kafka工作原理

3.1zookeeper工作原理

角色：

• leader：发起投票和决议，更新系统状态
• learner：1.follower：参与投票，接受与返回客户请求 2.observer：不参与投票，扩展系统，提高读取速度
• client：请求发起方

3.2kafka工作原理（消息中间件）

3.2.1 点对点模式

基于拉取或者轮询的消息传送模式，特点：发送到队列的消息被一个且只有一个消费者处理。

生产者将消息放入消息队列后，由消费者主动的去拉去消息进行消费。

点对点模式优点：消费者拉去消息的频率可以由自己控制，但是消息队列是否有消息需要消费，在消费者端是无感知的，所以在消费者端需要额外的线程去控制。

3.2.2 发布订阅模式

生产者将消息放入消息队列后，队列会将消息推送给订阅过该类消息的消费者（类似于微信公众号）。

由于消费者是被动接收推送，所以无需感知消息队列是否有待消费的消息，由于消费者的机器性能不一样，处理消息的能力也不一样，但消息队列却无法感知消费者的消费速度。

3.2.3 kafka 高吞吐量的分布式发布订阅消息系统

可以处理消费者规模的网站中的所有动作流数据，具有高性能，持久化，多副本备份，横向扩展能力…