日志收集===》ELK、EFK、zookeeper+kafka

1.架构图

简版:
位于各个节点上的filebeat将收集到的日志数据output给es存储,通过kibana展示。
在这里插入图片描述

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

2.单个服务介绍

1.Elasticsearch是个开源分布式搜索引擎,提供搜集、分析、存储数据三大功能。它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful风格接口,多数据源,自动搜索负载等。

2.Logstash 主要是用来日志的搜集、分析、过滤日志的工具,支持大量的数据获取方式。一般工作方式为c/s架构,client端安装在需要收集日志的主机上,server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。缺点:Logstash耗资源较大,运行占用CPU和内存高。另外没有消息队列缓存,存在数据丢失隐患。

3.Kibana 也是一个开源和免费的工具,Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面,可以帮助汇总、分析和搜索重要数据日志。

4.Filebeat隶属于Beats。轻量,可代替Logstash,规避了Logstash的缺点,目前Beats包含四种工具:

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

5.filebeat工作原理:Filebeat由两个主要组件组成:prospectors 和 harvesters。这两个组件协同工作将文件变动发送到指定的输出中。
在这里插入图片描述

组件组成:

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

Prospector(勘测者):负责管理Harvester并找到所有读取源。

Prospector会找到配置文件paths指定目录下的所有info.log文件,并为每个文件启动一个Harvester。Prospector会检查每个文件,看Harvester是否已经启动,是否需要启动,或者文件是否可以忽略。若Harvester关闭,只有在文件大小发生变化的时候Prospector才会执行检查。只能检测本地的文件。

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 高吞吐量的分布式发布订阅消息系统

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

在这里插入图片描述

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值