了解filebeat的采集原理，将会帮助我们更好的在不同的应用场景对filebeat的配置进行调整。

filebeat由两个非常重要的组件组成：

• inputs
• harvesters

inputs 输入，就是数据读取的源头
harvesters 采集器。在英文上面常见的意思是收割机，为了更好的和软件结合起来，我觉得称之为采集器更为合适

这两大组件构成了filebeat的核心，这两大组件一起对文件进行采集然后输出到特定的输出组件，下图是filebeat的一个工作流程图：

filebeat.png

首先输入组件通过正则表达式配置需要读取的文件，配置完毕之后，filebeat会启动采集器来对文件进行采集，下面我们会详细讨论下具体的采集器的工作流程

filebeat的工作流程

详细流程图如下：

filebeat工作流程.png

有了流程图，我们来分析几种常见的日志打印策略会不会有什么问题？

1. 按文件时间以及大小进行日志滚动

情况一

当达到日志滚动条件的时候，先对原来日志文件进行重命名，然后创建一个新文件，如下表：

对应的logback.xml的配置如下：

<appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>D:/Java/logstash-logs-file-for-test/logs/mylog.txt</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
        <!-- rollover daily -->
        <fileNamePattern>D:/Java/logstash-logs-file-for-test/logs/mylog-%d{yyyy-MM-dd}.%i.txt</fileNamePattern>
        <maxFileSize>5kb</maxFileSize>
    </rollingPolicy>
    <encoder charset="UTF-8">
        <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{80}- %msg%n</pattern>
    </encoder>
</appender>

分析：

根据官方的描述：

By default, the harvester stays open and keeps reading the file because the file handler does not depend on the file name

也就是采集器不是根据文件名来对文件进行采集的，在linux中，官方是这样描述的：

On Linux file systems, Filebeat uses the inode and device to identify files.

至于windows系统则没有找到相关的信息，不过从其描述来看也不是根据文件名称来进行记录的，而是根据文件的内部属性来进行记录，因此。这里重命名之后不会对采集造成影响，也不会进行重复采集。

结论：
根据上面的分析，这种情况的采集是没有问题的。

情况二
当日志文件达到条件之后直接创建新的文件来进行复写，例如开始是：
foo-0.log
当foo-0.log达到归档条件之后，直接创建新的文件来继续写日志，也就是
foo-1.log

logback.xml的配置如下：

<appender name="SizeAndTimeBasedFNATP" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
        <level>TRACE</level>
    </filter>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>D:/Java/logstash-logs-file-for-test/logs/log-%d{yyyy-MM-dd}-%i.log</fileNamePattern>
        <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
            <maxFileSize>5kb</maxFileSize>
        </timeBasedFileNamingAndTriggeringPolicy>
        <maxHistory>10</maxHistory>
    </rollingPolicy>

    <encoder charset="UTF-8">
        <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{80}- %msg%n</pattern>
    </encoder>
</appender>

分析：
在这种情况下，只要输入组件配置的扫描文件路径能够确保新的文件能够被扫描到是没有问题的。

结论：
根据上面的分析，这种情况的采集也是没有问题的

2. 日志文件循环复写

情况一

所谓日志文件循环复写就是说日志文件重复使用，例如按照大小归档的日志

当写foo.log-5达到一定大小的时候，去清空日志文件foo.log-1然后使用foo.log-1继续写日志，这就是日志文件循环复写的情况。

说明： 在logback中没有这样的配置，但是可以自己写RollingPolicy去实现

分析：

在filebeat中减行会导致文件从头读取，下面是抓取filebeat日志的一个信息

log/harvester.go:241 File was truncated. Begin reading file from offset 0

结论：
根据上面的分析，我们知当文件被全部清空的时候会从头读取。因此只要不是清空文件的一部分内容就不会导致文件重复读取的情况，因此这种场景也是没有问题的

情况二

logback.xml的配置如下：

<appender name="FixedWindowRolling" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>D:/Java/logstash-logs-file-for-test/logs/mylogFixedWindowRolling.log</file>

    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
        <fileNamePattern>D:/Java/logstash-logs-file-for-test/logs/mylogFixedWindowRolling.%i.log</fileNamePattern>
        <minIndex>1</minIndex>
        <maxIndex>3</maxIndex>
    </rollingPolicy>

    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
        <maxFileSize>100kb</maxFileSize>
    </triggeringPolicy>
    <encoder>
        <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
    </encoder>
</appender>

循环条件是4个文件，当写满第4个文件的时候会删除掉最旧的文件，然后重命名创建新文件继续复写

分析：
在这种情况下，只要保证filebeat在一轮循环之前不被关闭即可。也就是被删除之前，如果都已经滚动了好几轮（很多文件已经被删但是未被采集），但是filebeat还未启动就会造成数据丢失

结论：
通过分析我们得知，只要filebeat正常启动情况下是不会导致数据丢失的。