首页 > 其他分享> > 【Beats】 Filebeat工作原理（十七）

【Beats】 Filebeat工作原理（十七）

2020-06-21 20:02:17 作者：互联网

Filebeat工作方式

　　Filebeat是用于转发和集中日志数据的轻量级传送程序。作为服务器上的代理安装，Filebeat监视您指定的日志文件或位置，收集日志事件，并将它们转发到Elasticsearch或 Logstash进行索引。

　　Filebeat的工作方式如下：启动Filebeat时，它将启动一个或多个输入，这些输入将在为日志数据指定的位置中查找。对于Filebeat所找到的每个日志，Filebeat都会启动收集器。每个收割机都读取单个日志以获取新内容，并将新日志数据发送到libbeat，libbeat将聚集事件并将聚集的数据发送到为Filebeat配置的输出。

Filebeat如何工作

　　Filebeat包含两个主要组件：inputs（输入）和 harvester（收割机）这些组件协同工作以尾部文件并将事件数据发送到指定的输出。

harvester（收割机）　　

　　harvester负责读取单个文件的内容。harvester逐行读取每个文件，然后将内容发送到输出。每个文件启动一个harvester。harvester负责打开和关闭文件，这意味着在harvester运行时文件描述符保持打开状态。如果在收集文件时将其删除或重命名，Filebeat将继续读取该文件。这样做的副作用是磁盘上的空间将保留到收割机关闭为止。默认情况下，Filebeat保持文件打开直到close_inactive到达。

　　关闭收割机有以下后果：

关闭文件处理程序，如果在收割机仍在读取文件时删除了文件，则释放了基础资源。
只有在scan_frequency经过之后，才会再次开始文件的收集。
如果在收割机关闭时移动或删除文件，则文件的收割将不会继续。

inputs（输入）

　　输入负责管理harvester并查找所有可读取的资源。

　　如果输入类型为log，则输入将在驱动器上找到与定义的全局路径匹配的所有文件，并为每个文件启动收集器。每个输入都在其自己的Go例程中运行。

　　Filebeat当前支持类型（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输入检查每个文件看收割机是否需要启动，一个人是否已经在运行，或文件是否可以忽略不计（见ignore_older）。仅当自收割机关闭以来文件的大小已更改时，才会拾取新行。

Filebeat如何保持文件的状态

　　Filebeat保留每个文件的状态，并经常将状态刷新到注册表文件中的磁盘。该状态用于记住harvester正在读取的最后一个偏移量，并确保发送所有日志行。如果无法到达输出（例如Elasticsearch或Logstash），则Filebeat会跟踪发送的最后几行，并在输出再次可用时继续读取文件。在Filebeat运行时，状态信息也保存在内存中，用于每个输入。重新启动Filebeat时，将使用注册表文件中的数据来重建状态，并且Filebeat会在最后一个已知位置继续每个harvester。

　　对于每个输入，Filebeat会保持找到的每个文件的状态。由于可以重命名或移动文件，因此文件名和路径不足以标识文件。对于每个文件，Filebeat都存储唯一的标识符以检测文件是否以前被收获过。

Filebeat如何确保至少一次交付

　　Filebeat保证事件将至少一次传递到配置的输出，并且不会丢失数据。Filebeat之所以能够实现此行为，是因为它在注册表文件中存储了每个事件的传递状态。

　　在定义的输出被阻止并且尚未确认所有事件的情况下，Filebeat将继续尝试发送事件，直到输出确认它已接收到事件为止。

　　如果Filebeat在发送事件的过程中关闭，则它不会在关闭之前等待输出确认所有事件。重新启动Filebeat时，将再次发送发送到输出但在Filebeat关闭之前未确认的所有事件。这样可以确保每个事件至少发送一次，但是最终可能会将重复的事件发送到输出。您可以通过设置shutdown_timeout选项将Filebeat配置为在关闭之前等待特定的时间。