Filebeat（基于6.5版本）

概述

filebeat的由来

Logstash是ELK（ElasticSearch、Logstash、Kibana）组件中的一个。这三个组件往往是配合使用的：ES负责数据的存储和索引，Logstash负责数据采集和过滤转换，Kibana则负责图形界面处理；之后，这三个组件又先后被收购于Elastic.co公司名下

因为logstash是jvm跑的，资源消耗比较大，所以后来作者又用go写了一个功能较少但是资源消耗也小的轻量级logstash-forwarder。因为es公司本身还收购了另一个开源项目packetbeat，而这个项目专门就是用go语言的，所以es公司干脆把logstash-forwarder的开发工作也合并到同一个团队，于是新的项目就叫filebeat了。

logstash 和filebeat都具有日志收集功能，filebeat更轻量，占用资源更少。filebeat可以发送到logstash，进一步进行日志清洗和过滤。

filebeat介绍

harvesters采集器：

一个采集器的职责是一行行的读取一个文件的内容，并且发送内容到output。（A harvester is responsible for reading the content of a single file. The harvester reads each file, line by line, and sends the content to the output.）

 

Inputs：

input的职责是管理采集器并且发现所有的资源去读取他们（An input is responsible for managing the harvesters and finding all sources to read from.）

当启动时，有1个或多个input去指定位置，为每一个文件启动一个收集器，收集器读取文件内容发送到libbeat，然后聚合event发送到output（When you start Filebeat, it starts one or more inputs that look in the locations you’ve specified for log data. For each log that Filebeat locates, Filebeat starts a harvester. Each harvester reads a single log for new content and sends the new log data to libbeat, which aggregates the events and sends the aggregated data to the output that you’ve configured for Filebeat.）

总结：一个filebeat client可以有多个input，当程序启动时，会根据文件目前的读取状态来判断是需要启动harvester，harvester负责文件的打开和关闭，读取文件。

 

具体实现

功能图：

流程图：

input

1. 如何识别一个文件？

当文件重命名和移动时，依然可以读取这个文件。

对于每个input的文件，filebeat通过每个文件的元信息来识别文件，因为文件名和路径可能会改变，不会通过文件名等标识一个文件，filebeat保存文件的唯一标识符来识别一个文件，在Linux系统中，通过inode （存储文件的元信息）来进行识别。

文件句柄如何关闭？

为了实现的这种功能，当没有close_*配置时，会一直保存这个这个文件的hander，磁盘上的空间会保留。

 

Close_* 达到这些情况时，关闭hander。

close_inactive 以最后一次读取的日志时间为起点（即lastoffset），如果超过这个时间日志没有更新，则会关闭句柄。开始时间不是文件的修改时间。如果文件有更新，则在下一次scan时会再次被收集。

close_renamed 被重命名时，关闭句柄。默认是不会关闭的。

Close_removed 被删除时，关闭句柄

Close_eof 读完一个文件就关闭。用于读取存量不会更新的文件。

Close_timeout 一个收割机的生命周期时间

 

clean_* 删除文件的注册表文件信息

Clean_inactive 删除注册表文件。会在非活动期过后删除文件状态，对于每天生成大量新文件的非常有用。

Clean_removed 文件删除时删除文件状态。

 

如果句柄没有关闭，会执行下面三个参数重试：

backoff Filebeat检测到某个文件到了EOF之后，每次等待多久再去检测文件是否有更新，默认为1s。

Max_backoff Filebeat检测到某个文件到了EOF之后，等待检测文件更新的最大时间，默认是10秒。

Backoff_factor 定义到达max_backoff的速度，默认因子是2，到达max_backoff后，变成每次等待max_backoff那么长的时间才backoff一次，直到文件有更新才会重置为backoff。

 

注意：在Linux文件系统上，Filebeat使用inode和设备来识别文件。从磁盘中删除文件时，可将inode分配给新文件。在涉及文件旋转的使用情况下，如果旧文件被删除并且之后立即创建新文件，则新文件可能与删除的文件具有完全相同的inode。在这种情况下，Filebeat假定新文件与旧文件相同，并尝试在旧位置继续读取，这是不正确的。

2、如何去读取一个文件？

filebeat会在每个event发送成功后，刷新每个文件的状态到磁盘的注册文件中（Registry file），这个状态用来记录harverster读取的最后一个offset,

在filebeat运行时，状态信息也会为每个input保存在内存中。

为了确保所有日志的每一行都能被发送，当filebeat重启时，注册表中的文件被用来重建每个文件的状态，让每个harverster知道上次最后的位置。

 

input端其他的重要功能和配置

exclude_lines 在输入中排除符合正则表达式列表的那些行。

include_lines 包含输入中符合正则表达式列表的那些行（默认包含所有行）

harvester_buffer_size 每个harvester监控文件时，使用的buffer的大小

max_bytes 每条日志最大的大小，对于此值会被截断不发送。

exclude_files 忽略掉符合正则表达式列表的文件

ignore_older 可以指定Filebeat忽略指定时间段以外修改的日志内容

Scan_frequency input扫描的时间间隔

Tail_files 设置该值时，注册表中没有文件状态会从最后一行读取文件。

Harvester_limit 最大的harverster值，如果同时多个文件，会打开失败，Linux对同时打开文件的多少有限制。

fields 向输出的每一条日志添加额外的信息

processors：You can use processors to filter and enhance data before sending it to the configured output

Each processor receives an event, applies a defined action to the event, and returns the event. If you define a list of processors, they are executed in the order they are defined in the Filebeat configuration file.

event -> processor 1 -> event1 -> processor 2 -> event2 ...

格式：

processors:

- <processor_name>:

    when:

      <condition>

    <parameters>

 

- <processor_name>:

    when:

      <condition>

    <parameters>

 

...

 

Queue

Harverster收割完的event会在这里排队，通过output配置发送出去。

Memory queue

The queue is responsible for buffering and combining events into batches that can be consumed by the outputs. The outputs will use bulk operations to send a batch of events in one transaction.

This sample configuration forwards events to the output if 512 events are available or the oldest available event has been waiting for 5s in the queue:

queue.mem:

  events: 4096

  flush.min_events: 512

  flush.timeout: 5s

Events：

Number of events the queue can store.（input类型对于log来说，一行数据是一个event，default:4096）

flush.min_events:

flush.timeout:

 

File spool queue

注意：此功能在测试阶段，之后可能会更改。

概述：写到本地磁盘，并且有一个write buffer，先写到buffer里，再写到磁盘上，spool的底层是一个个page，相当于划分一个个块。spool的大写以及page的大小可以配置，buffer的大小和buffer flush的规则也可以配置，具体配置如下：

This sample configuration creates a spool of 512MiB, with 16KiB pages. The write buffer is flushed if 10MiB of contents, or 1024 events have been written. If the oldest available event has been waiting for 5s in the write buffer, the buffer will be flushed as well:

queue.spool:

  file:

    path: "${path.data}/spool.dat"

    size: 512MiB

    page_size: 16KiB

  write:

    buffer_size: 10MiB

    flush.timeout: 5s

    flush.events: 1024

output

如何进行发送？

filebeat聚合event传送给output，会至少传送一次，不会有数据丢失。因为他会把每个event的传送状态保存到注册表文件中，当没有收到output方的ack时，会重试直到收到。

event可能会重复发送，当一批event发送出去没有收到output方的ack就shut down时，当再次启动会重复发送这些event。

数据丢失。当日志写入磁盘并且旋转的速度大于filebeat处理的速度，或者在output不可用时删除了这个文件，会造成数据的丢失。

配置一：required_acks

The ACK reliability level required from broker. 0=no response, 1=wait for local commit, -1=wait for all replicas to commit. The default is 1.

Note: If set to 0, no ACKs are returned by Kafka. Messages might be lost silently on error.

配置二：

Compression

Must be one of none, snappy, lz4 and gzip. The default is gzip.

compression_level

 

module

Filebeat 内置有多种模块（auditd、Apache、NGINX、System、MySQL 等等），可针对常见格式的日志大大简化收集、解析和可视化过程，只需一条命令即可。（https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-nginx.html）

 

配置

inputs配置

参数	含义	样例	默认值
paths		/var/log/*.log
recursive_glob.enabled		/foo, /foo/*, /foo/*/*, and so on	This feature is enabled by default
exclude_lines
include_lines
harvester_buffer_size	The size in bytes of the buffer that each harvester uses when fetching a file.		The default is 16384.
max_bytesedit	一个日志最大值，超过会被截取，在进行多行日志读取时很有用		The default is 10MB (10485760).
exclude_files
ignore_older
close_inactive	以最后一次读取的日志时间为起点，如果超过这个时间日志没有更新，则会关闭句柄。开始时间不是文件的修改时间。如果文件有更新，则在下一次scan时会再次被收集。		5m
close_renamed	被重命名时，关闭句柄。默认是不会关闭的。
Close_removed	被删除时，关闭句柄		This option is enabled by default
Close_eof	读完一个文件就关闭。用于读取存量不会更新的文件。
Close_timeout	一个收割机的生命周期时间
Clean_inactive	删除注册表文件。会在非活动期过后删除文件状态，对于每天生成大量新文件的非常有用。
Clean_removed	文件删除时删除文件状态。
Scan_frequency
Tail_files	设置该值时，注册表中没有文件状态会从最后一行读取文件。
symlinks
backoff
Max_backoff
Backoff_factor
Harvester_limit
tag
fields
Fields_under_root
processors
pipeline	The Ingest Node pipeline ID to set for the events generated by this input.

output配置

注意：

1 This output works with all Kafka versions in between 0.11 and 2.0.0. Older versions might work as well, but are not supported.

Hosts

Version

username

password

Topic

topics

Partition:Must be one of random, round_robin, or hash. By default the hash partitioner is used.

Compression

Must be one of none, snappy, lz4 and gzip. The default is gzip.

compression_level

max_message_bytes

每条信息最大的长度，多余的被删除

required_acks

The ACK reliability level required from broker. 0=no response, 1=wait for local commit, -1=wait for all replicas to commit. The default is 1.

Note: If set to 0, no ACKs are returned by Kafka. Messages might be lost silently on error.

Flume

概述

Reliability（可靠性）

Event在每个Agent的Channel上进行缓存，随后Event将会传递到流中的下一个Agent或终端存储库，只有在存储在下一个代理的通道或终端存储库中后Event才会从Channel中删除。这一步骤实现了单节点架构的可靠性。

Recoverability（可恢复性）

Event在Channel中进行缓存，提供了从失败中恢复的机制。Flume支持由本地文件系统支持的File Channel。Flume还有一个内存Channel，它将事件简单地存储在内存队列中，这个速度更快，但是当Agent死亡时,仍然留在内存通道中的任何Event都不能被恢复。

Zookeeper based Configuration

可以把配置信息放到zookeeper中统一进行维护（This is an experimental feature）

Consolidation

应用中通常有大量的节点同时采集写入到存储层，这时可以使用flume Collector进行日志收集，即flume集群，合并成单个通道，输送到目的地。多个节点的flume Collector支持高可用。

 

 

Flume Interceptors

过滤器

Source

Spooling Directory Source

读取一个目录中的文件，读取完成后打上完成标签。

Taildir Source

检测一个目录文件变化，输出新增文件。

writePosInterval 每个一段时间把标识写入到文件，为了启动时按照文件中的pos往后读取。

 

 

flume与filebeat比较

1. 重启时。filebeat不会造成数据丢失；flume虽然有断点续传功能，但是在channel中的数据会丢失；
2. 数据重复。filebeat和flume都会有。flume有些没有写入到pos文件中的数据也会重复发送。
3. 目录中文件回滚时。filebeat会自动处理，flume不能自动处理，处理起来比较麻烦。
4. 资源的占用。flume运行在jvm上，会占用较多的资源；filebeat对操作系统而言，是一个二进制文件，占用资源较少。
5. 系统的配置。flume可以与zookeeper结合，由zookeeper统一维护配置信息；fliebeat不能。
6. 数据完整性。flume对于每个event进行事务性处理，只有当收到sink的ack时，才会删除channel中的event；filebeat也可以做到。
7. 版本更新力度。flume最新1.8，filebeat6.5
8. flume可以配置flume Collector集群统一收集每个flume agent的日志，flume Collector具有failover模式。filebeat支持写入到logstash中。