Fluent Bit持久化配置：保障数据可靠传输的关键

#作者：程宏斌

在 Fluentd中，如果你配置了使用buffer插件，设置buffer_path指向持久化存储的位置。这些内容确保了在故障或重启后，Fluentd可以继续从上次处理的位置恢复数据处理。不做持久化意味着 Fluentd的状态不会在容器或进程重启后保留，它会从头开始重新采集日志文件。

不做持久化的潜在问题

不做持久化的Fluentd配置可能导致一系列潜在问题，具体包括：

数据丢失：
故障风险：如果Fluentd进程意外崩溃或重启，所有未发送的日志数据将会丢失。这在高流量环境中尤为严重，可能导致重要日志信息的缺失。

数据重复：
输出重试：在输出目标（如数据库或消息队列）出现故障时，Fluentd可能会重新尝试发送数据。没有持久化的情况下，可能导致已发送数据的重复处理，从而造成数据冗余。

故障恢复复杂性：
缺乏恢复机制：如果没有持久化存储，恢复数据的过程将更加复杂。一旦发生故障，无法从最后的处理状态恢复，导致数据处理中断。

监控和故障分析受限：
缺乏历史数据：没有持久化的日志记录，会使得在发生问题时缺乏必要的历史数据进行排查和分析，影响故障诊断的效率。

系统负担增加：
内存消耗：在没有持久化的情况下，Fluentd需要将所有数据保存在内存中，可能导致内存资源消耗过高，从而影响系统的稳定性。

后续数据处理难度：
数据整合挑战：如果数据在发送到不同的目标之前没有持久化，后续的分析和整合工作将变得困难，可能导致数据孤岛。
通过以上分析，可以看出不做持久化的Fluentd配置可能会带来多方面的问题，影响系统的可靠性、数据的完整性以及业务的连续性。因此，在生产环境中，建议采用适当的持久化策略来增强Fluentd的可靠性。

配置持久化

configmap配置
需要在source里面配置红色内容

     <source>
      @type tail
      path /var/log/test.log
      **pos_file /var/log/td-agent/test.log.pos**
      tag test.log
      <parse>
        @type json
        time_key time
        time_format %Y-%m-%dT%H:%M:%S.%NZ
      </parse>
    </source>

DaemonSet配置
          volumeMounts:
          - name: fluentd-config-volume
            mountPath: /opt/bitnami/fluentd/conf/fluentd.conf
            subPath: fluent.conf
          - name: varlog
            mountPath: /var/log
          **- name: pos
            mountPath: /var/log/td-agent**
      volumes:
      - name: fluentd-config-volume
        configMap:
          name: fluentd-config
      - name: varlog
        hostPath:
          path: /home/chb/test
     ** - name: pos
        hostPath:
          path: /var/log/td-agent**
      imagePullSecrets:
        - name: default-secret
      tolerations:
      - operator: Exists

添加上面** **部分。

实现的效果

首先配置持久化，会在本地配置持久化挂载的地方生产一个pos文件：
Fluentd 配置的 pos 文件（position file）用于记录 Fluentd 读取日志文件的位置，确保在 Fluentd 重启或系统故障时，能够从上一次读取的位置继续读取，避免重复消费日志数据或遗漏日志。

pos_file 的作用

记录文件读取进度：pos文件会记录Fluentd已读取到的文件的偏移量或行号，当 Fluentd 重启或发生异常时，能够从记录的偏移量继续读取数据，而不需要从头读取整个日志文件。

避免重复消费：如果 Fluentd不使用 pos_file，在重启或异常恢复后，可能会重新读取已处理过的数据，从而导致重复消费。例如，读取日志文件时，如果 Fluentd 停止并重新启动，没有 pos_file 的话会从文件头开始读取，导致重复发送相同的日志数据。
防止数据丢失：pos_file也能确保Fluentd不会遗漏日志数据。即使 Fluentd 重启或出现问题，它能够精确地从断点恢复读取，不会跳过任何数据。
支持多文件跟踪：如果日志文件发生轮转（rotation），pos_file 还能够帮助 Fluentd 追踪多个日志文件，确保不会遗漏或重复读取数据。

配置输出到kafka，如果不配置pos_file持久化的话，在重启或异常恢复后，可能会重新读取已处理过的数据，从而导致重复消费。而且在故障重启过程中写入的日志内容，直接输出会丢失。
配置了pos_file持久化在fluentd重启之后会从pos文件获取到之前读取的偏移量，从获取的位置自动往后读取，不会从头开始采集读取或丢失数据。

pos 文件的内容通常由多个字段组成，格式如下：

<filepath> <position> <inode>

filepath：日志文件的完整路径。
position：文件中的读取偏移量。Fluentd 会记录读取到日志文件的最后一个字节的位置，确保下次读取从这个位置开始。
inode：文件的inode号，表示该文件在文件系统中的唯一标识符。即使文件名发生改变，inode 号不变时，Fluentd仍然能够追踪到该文件。

工作原理

inode：如果日志文件发生了轮转（例如，生成了新的日志文件或日志文件被压缩存档），Fluentd 会通过 inode 来识别是新的文件还是旧文件。因此，即使文件名改变，Fluentd 仍能通过 inode 继续追踪日志源。
position：每当 Fluentd 从日志文件中读取一行数据后，它会更新 pos_file 中的偏移量。这样，即使 Fluentd 进程在之后崩溃或重启，它也能从上次记录的位置继续读取文件，而不会重复读取之前的数据。
filepath：虽然 inode 号是核心，但文件路径也用于确保文件正确定位。如果文件被移动到新的目录或文件名发生变化（且 inode 改变），Fluentd 会将其视为新文件。

pos_file 更新的场景

Fluentd 正常运行时：每当 Fluentd 读取日志文件中的数据时，pos_file 会定期更新，记录当前读取到的偏移量。
日志文件轮转：如果日志文件被轮转（如 logrotate 操作），Fluentd 会检测到文件的 inode 变化，并在 pos_file 中更新相应的日志文件信息。
Fluentd 重启：当 Fluentd 重启时，它会从 pos_file 读取上次的偏移量，从该位置继续读取日志文件。

总结

inode 确保 Fluentd 能正确追踪日志文件，即使文件被重命名或轮转。
position 确保 Fluentd 不会重复读取已经处理过的日志数据。
filepath 提供文件的绝对路径，帮助 Fluentd 定位日志源。
通过 pos_file，Fluentd 能够准确、高效地从日志文件中恢复数据读取，避免重复消费或数据丢失。

故障恢复

注：配置pos文件会记录文件偏移量、日志文件路径、文件的inode号等信息，所以必须保证文件的一致性。
如果一个fluentd故障，可以重新启动一个fluentd进程，通过pos文件恢复到故障前最后一次读取的位置，接着继续往后读取日志。
恢复演示：
首先给node打标签，让fluentd进程调度到指定node上

然后正常采集日志

把之前node标签去除（pod自动删除），然后往日志文件里追加内容

复制pos文件到想要调度的node上

然后换个node打同样的标签，让fluentd调度到其他node上。

再写两条数据

启动pod之后，会自动根据pos文件记录（之前读取到key=15）的偏移量继续往后读取日志（故障期间写入的日志也会读取出来）