Filebeat 浅析（一）

发表于 更新于 分类于 阅读次数： 本文字数： 1.6k 阅读时长 ≈ 3 分钟

简介

Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.

这是elastic对于filebeat的官方描述，翻译过来就是filebeat是一个轻量级的用来采集和转发日志数据的组件。将采集的日志封装成event转发给下游的组件，例如elasticsearch、logstash或者kafka。

架构设计

artich

Inputs

该组件的作用就如同名称一样，是用来定义输入源的，简单理解就是定义了你需要采集的数据源是哪些，对于我们最常使用的日志来说就是告诉filebeat需要监听哪些日志文件，当然其inputs类型并不是只有log一种，其支持以下类型：

  • Azure Event Hub
  • Cloud Foundry
  • Container
  • Docker
  • Google Pub/Sub
  • HTTP Endpoint
  • HTTP JSON
  • Kafka
  • Log
  • MQTT
  • NetFlow
  • Office 365 Management Activity API
  • Redis
  • S3
  • Stdin
  • Syslog
  • TCP
  • UDP

当然最常有的是其中的log类型，使用其来采集我们的应用日志，然后可以对我们的日志信息进行实时/离线统计、分析。

Harvester

该组件严格意义上来说也是属于inputs的，但是由于其重要性，这里才单独拿出来说，该组件的功能其实很简单–监听需要采集的输入源，将其监听到的所有变更向下进行转发。转发到哪呢，这就会引出下一个组件，Spooler。

Spooler

spooler其实是一个集合，里面包括很多小组件：porcessor、Internal queue等。

Processor

该组件是对harvester发过来的event进行二次处理转化为另一个类型的event。可以把其简单理解为一个filtering的过程，从中将一些不满足你的需求的event过滤调，只将符合条件的event向下传递，进入internal queue。

Internal Queue

该组件就是filebeat用来存储harvester转发的data event的内部“队列”，其默认实现是一个内存队列，如果对数据完整性要求高可以选择使用磁盘来存储相关队列信息。同时internal queue还会对event进行一次合并（batch）操作，目的是为了减少outputs组件的发送压力。

Outputs

该组件就是用来消费internal queue队列中的event的，每次其会从internal queue中取出一个batch的数据，经过编解码、压缩等一系列操作后将其存储到下游系统中。目前filebeat支持的outputs包含：

  • Elasticsearch Service
  • Elasticsearch
  • Logstash
  • Kafka
  • Redis
  • File
  • Console

其他组件

除了上述的几个主要组件之外，filebeat还包括很多其他组件，比如：modules、monitor等。这里暂不进行介绍。可以自己去看Filebeat的官方文档。

总结

filebeat的大致流程就是使用inputs组件中定义的type类型的harvester来监听采集相应inputs中产生的事件（event），并将其转发到spooler中，spooler在经过一系列的processor处理后将events合并为一个batch最终存入到queue中，等待outputs来消费，outputs将从queue中拉取到的batch存入对于的下游系统中。