Filebeat的使用

前言

logstash自己就能够具备文件数据采集的功能了，为何还须要在前面加一层filebeat？理由以下：
logstash是使用Java编写，插件是使用JRuby编写，对机器的资源要求会比较高，在logstash中作数据的逻辑过滤已经很吃服务器性能了(即logstash 具备filter功能，能过滤分析日志)。为了分摊当前服务器cpu资源，因此将使用GO编写的轻量级的filebeat做为单独组件，放在待收集日志的服务器上使用。

简单概述

　　最近在了解ELK作日志采集相关的内容，这篇文章主要讲解经过filebeat来实现日志的收集。日志采集的工具备不少种，如fluentd, flume, logstash,betas等等。首先要知道为何要使用filebeat呢？由于logstash是jvm跑的，资源消耗比较大，启动一个logstash就须要消耗500M左右的内存，而filebeat只须要10来M内存资源。经常使用的ELK日志采集方案中，大部分的作法就是将全部节点的日志内容经过filebeat送到kafka消息队列，而后使用logstash集群读取消息队列内容，根据配置文件进行过滤。而后将过滤以后的文件输送到elasticsearch中，经过kibana去展现。

官网下载地址：https://www.elastic.co/cn/downloads/beats/filebeat

官网配置说明：https://www.elastic.co/guide/en/beats/filebeat/current/configuring-howto-filebeat.html

 

工做原理：

Filebeat能够保持每一个文件的状态，而且频繁地把文件状态从注册表里更新到磁盘。这里所说的文件状态是用来记录上一次Harvster读取文件时读取到的位置，以保证能把所有的日志数据都读取出来，而后发送给output。若是在某一时刻，做为output的ElasticSearch或者Logstash变成了不可用，Filebeat将会把最后的文件读取位置保存下来，直到output从新可用的时候，快速地恢复文件数据的读取。在Filebaet运行过程当中，每一个Prospector的状态信息都会保存在内存里。若是Filebeat出行了重启，完成重启以后，会从注册表文件里恢复重启以前的状态信息，让FIlebeat继续从以前已知的位置开始进行数据读取。

Prospector会为每个找到的文件保持状态信息。由于文件能够进行重命名或者是更改路径，因此文件名和路径不足以用来识别文件。对于Filebeat来讲，都是经过实现存储的惟一标识符来判断文件是否以前已经被采集过。

若是在你的使用场景中，天天会产生大量的新文件，你将会发现Filebeat的注册表文件会变得很是大。这个时候，你能够参考（ the section called “Registry file is too large? edit），来解决这个问题。

 

Filebeat由两个主要组件组成：prospector 和harvester。这些组件一块儿工做来读取文件（tail file）并将事件数据发送到您指定的输出
启动Filebeat时，它会启动一个或多个查找器，查看您为日志文件指定的本地路径。 对于prospector 所在的每一个日志文件，prospector 启动harvester。 每一个harvester都会为新内容读取单个日志文件，并将新日志数据发送到libbeat，后者将聚合事件并将聚合数据发送到您为Filebeat配置的输出。

 

harvester(收割机)

harvester :负责读取单个文件的内容。读取每一个文件，并将内容发送到 the output
每一个文件启动一个harvester, harvester 负责打开和关闭文件，这意味着在运行时文件描述符保持打开状态
若是文件在读取时被删除或重命名，Filebeat将继续读取文件。
这有反作用，即在harvester关闭以前，磁盘上的空间被保留。默认状况下，Filebeat将文件保持打开状态，直到达到close_inactive状态

关闭harvester会产生如下结果：
1）若是在harvester仍在读取文件时文件被删除，则关闭文件句柄，释放底层资源。
2）文件的采集只会在scan_frequency事后从新开始。
3）若是在harvester关闭的状况下移动或移除文件，则不会继续处理文件。

要控制收割机什么时候关闭，请使用close_ *配置选项

prospector(采矿者)

prospector 负责管理harvester并找到全部要读取的文件来源。
若是输入类型为日志，则查找器将查找路径匹配的全部文件，并为每一个文件启动一个harvester。
每一个prospector都在本身的Go协程中运行。

如下示例将Filebeat配置为从与指定的匹配的全部日志文件中收集行：

filebeat.prospectors:
- type: log paths: - /var/log/*.log - /var/path2/*.log 

Filebeat目前支持两种prospector类型：log和stdin。
每一个prospector类型能够定义屡次。
日志prospector检查每一个文件以查看harvester是否须要启动，是否已经运行，
或者该文件是否能够被忽略（请参阅ignore_older）。
只有在harvester关闭后文件的大小发生了变化，才会读取到新行。

注：Filebeat prospector只能读取本地文件， 没有功能能够链接到远程主机来读取存储的文件或日志。

Filebeat如何保持文件的状态？

Filebeat 保存每一个文件的状态并常常将状态刷新到磁盘上的注册文件中。
该状态用于记住harvester正在读取的最后偏移量，并确保发送全部日志行。
若是输出（例如Elasticsearch或Logstash）没法访问，Filebeat会跟踪最后发送的行，并在输出再次可用时继续读取文件。
在Filebeat运行时，每一个prospector内存中也会保存的文件状态信息，
当从新启动Filebeat时，将使用注册文件的数据来重建文件状态，Filebeat将每一个harvester在从保存的最后偏移量继续读取。

每一个prospector为它找到的每一个文件保留一个状态。
因为文件能够被重命名或移动，所以文件名和路径不足以识别文件。
对于每一个文件，Filebeat存储惟一标识符以检测文件是否先前已采集过。

若是您的使用案例涉及天天建立大量新文件，您可能会发现注册文件增加过大。请参阅注册表文件太大？编辑有关您能够设置以解决此问题的配置选项的详细信息。

Filebeat如何确保至少一次交付

Filebeat保证事件至少会被传送到配置的输出一次，而且不会丢失数据。 Filebeat可以实现此行为，由于它将每一个事件的传递状态存储在注册文件中。

在输出阻塞或未确认全部事件的状况下，Filebeat将继续尝试发送事件，直到接收端确认已收到。

若是Filebeat在发送事件的过程当中关闭，它不会等待输出确认全部收到事件。
发送到输出但在Filebeat关闭前未确认的任何事件在从新启动Filebeat时会再次发送。
这能够确保每一个事件至少发送一次，但最终会将重复事件发送到输出。
也能够经过设置shutdown_timeout选项来配置Filebeat以在关闭以前等待特定时间。

注意：
Filebeat的至少一次交付保证包括日志轮换和删除旧文件的限制。若是将日志文件写入磁盘而且写入速度超过Filebeat能够处理的速度，或者在输出不可用时删除了文件，则可能会丢失数据。
在Linux上，Filebeat也可能因inode重用而跳过行。有关inode重用问题的更多详细信息，请参阅filebeat常见问题解答。

 

示例：Filebeat --> Kafka

filebeat.prospectors:
- type: log
  paths:
    - /home/hottopic/logs/b612/8086/b612.json
    - /home/hottopic/logs/b612/8088/b612.json
  json.keys_under_root: true
  json.overwrite_keys: true
processors:
- drop_fields:
    fields: ["offset","prospector", "tags","beat.name", "beat.version"]
output:
  kafka:
    enabled: true
    hosts: ["172.17.65.210:9092", "172.17.65.211:9092"]
    topic: adsdk
    compression: gzip
    required_acks: 1
    max_message_bytes: 1000000
max_procs: 1