一、问题描述：生产环境日志凭空消失

上个月我在维护一套日志采集系统，用的是Filebeat来收集业务服务器的Nginx访问日志。某天突然发现，用户报障说某个功能的数据对不上，排查下来发现日志文件明明存在，但Filebeat上报到Elasticsearch的行数少了大概十几行。更奇怪的是，查看Filebeat的日志没有报错，也没有明显的异常。这种“无故丢日志”的情况最让人头疼，因为你不知道它什么时候丢，为什么丢。为了弄明白背后的原因，我重新梳理了Filebeat读取文件的整个流程，最后发现问题的根子出在文件指针（offset）和inode的关联上。

二、基础知识回顾：Filebeat是怎么读取日志的

要搞清楚怎么丢的，先得知道Filebeat正常情况怎么读文件。Filebeat内部有两类组件在干活：一个是Harvester（收割机），另一个是Spooler（缓存发送器）。Harvester负责打开每个日志文件，像水龙头一样持续读取新写入的内容，每读到一个新行就把数据扔到内存里的一个队列中；Spooler则定期把队列里的数据打包发往输出端（比如Elasticsearch或Logstash）。

2.1 文件指针与inode概念

Harvester在读文件的时候，会记录它已经读到的位置，这个位置叫offset（文件指针），精确到字节。每次读完一行，offset就向前移动。同时，为了应对日志文件被改名、删除或者重建的情况，Filebeat不能光靠文件名来跟踪文件，因为文件名可以变来变去。它真正用来唯一标识一个文件的，是操作系统的inode（索引节点）和设备号（device number）。inode是每个文件在文件系统里的身份证，文件改名、移动都不会改变inode的值——除非你真正新建了一个文件（先删除再创建），才会生成新的inode。

举个例子：你有一个日志文件 /var/log/app.log，它的inode是123456。如果用mv app.log app.log.bak重命名，inode还是123456；但如果用echo new > app.log覆盖（先删后创建），新文件的inode会是新的。Filebeat的registry文件（记录读取进度的数据库）里保存的就是(设备号, inode, 文件偏移量)这样的三元组，而不是文件名。

2.2 为什么Filebeat要这么设计

因为日志文件会频繁地被日志轮转工具（如logrotate）处理。常见的轮转方式有两种：

  • create模式：logrotate把老日志重命名为app.log.1，然后创建一个新的空文件app.log。这样老文件的inode不变，新文件的inode不一样。
  • copytruncate模式：先复制老文件再清空原文件（truncate）。这种情况下文件名和inode都不变，只是内容被截断成0。

如果Filebeat只靠文件名跟踪，当文件被重命名后，它拿着老文件名去打开，发现文件不存在了，或者打开了一个新文件，就会导致进度丢失。而通过inode跟踪，它能够认出经过重命名但inode不变的文件（比如原来的老文件），保证不会漏读。

三、丢失日志的深层原因：harvester文件指针与inode的关联是如何出错的

3.1 典型丢日志场景：logrotate create模式下的“旧文件残留”

我们用一个最真实的场景来演示。假设Nginx的访问日志通过logrotate每天轮转，配置如下（简化版）：

/var/log/nginx/access.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 640 nginx adm  # 轮转后创建新文件
    sharedscripts
    postrotate
        /usr/sbin/nginx -s reopen
    endscript
}

这个配置的含义是：每天凌晨0点，logrotate把当前的access.log重命名为access.log.1，然后创建一个全新的空文件access.log（inode变了），最后通知Nginx重新打开日志文件（确保后续日志写进新文件）。这时候，Filebeat的harvester会发生什么事情呢？

  1. 第一阶段（轮转前）：Filebeat的harvester A正在读取access.log（inode=100），offset已经走到文件末尾，等待新数据。
  2. 轮转发生：logrotate把文件重命名为access.log.1，此时access.log.1的inode仍然是100（因为只是改了文件名）。同时新文件access.log被创建出来，它的inode是101，内容为空。
  3. 第二阶段（轮转后）：
    • harvester A通过inode跟踪发现老文件变成了access.log.1，它会尝试打开这个文件继续读取（因为inode没变）。如果这时候还有日志写入老文件（比如Nginx关闭旧连接前的最后几行），harvester A能读到，没问题。
    • 新文件access.log（inode=101）对于Filebeat来说是一个全新的文件，Filebeat会启动一个新的harvester B来读取它。
  4. 问题出在哪里？ 如果logrotate配置中使用了postrotate通知Nginx reopen，Nginx在收到信号后会立即关闭旧文件描述符，打开新文件。但Windows或某些特殊场景下，从logrotate重命名到Nginx reopen之间可能存在毫秒级的时间差。如果在这段时间内，Nginx还没来得及切换写句柄，那么最后几行日志可能仍然写到了旧的access.log.1（inode=100）里。这些数据被harvester A读走了。但是！如果logrotate配置了delaycompress加上compress，稍后logrotate会压缩access.log.1。压缩通常意味着把access.log.1删掉（或者改名再压缩），这个操作就触发了文件删除。一旦文件被删除，它的inode会被回收。如果这个时候harvester A还没有把offset写入registry（比如因为内存里的数据还没flush），那么当Filebeat下次重启或扫描时，这个inode已经不存在了，registry里记录的进度就变成了一个“幽灵条目”。更糟糕的是，如果harvester A因为某种原因一直没关闭这个文件句柄（比如设置了close_inactive为非常大的值），文件被删除后，它可能还在尝试读取，但文件内容已经被清空，读取到的行数为0，而offset停在最后的位置。下次重新扫描时，这个偏移量无法用于新文件，导致那些“被延迟读取”的最后几行永远丢失。

听起来有点绕？我们用代码来模拟这个过程。

3.2 模拟实验：用Python模拟日志轮转并观察Filebeat的行为

为了更直观地看到问题，我写了一个Python脚本，模拟一个日志文件被轮转并且数据丢失的场景。注意，这只是一个演示，实际Filebeat的行为依赖它的版本和配置。

# 模拟文件轮转 + Filebeat的harvester行为
# 技术栈：Python 3.8+

import os
import time
import io
import uuid

# 模拟一个日志文件，初始inode和内容
log_file_path = "/tmp/test_app.log"

# 第一步：创建一个日志文件并写入一些行
def create_log_file(path, lines):
    with open(path, "w") as f:
        for i, line in enumerate(lines):
            f.write(f"Line {i}: {line}\n")
    print(f"创建文件 {path}, inode={os.stat(path).st_ino}")

# 模拟Filebeat的harvester：它记录当前文件的inode和偏移量
class SimulatedHarvester:
    def __init__(self, file_path):
        self.file_path = file_path
        self.inode = os.stat(file_path).st_ino     # 记录初始inode
        self.offset = 0                           # 文件指针
        self.file_obj = open(file_path, "r")
        print(f"Harvester启动: 文件={file_path}, inode={self.inode}")
    
    def read_lines(self):
        # 尝试读取新行，更新offset
        self.file_obj.seek(self.offset)
        lines = self.file_obj.readlines()
        if lines:
            for line in lines:
                print(f"  读取: {line.strip()}")
            # 更新offset：要使用tell()获取当前位置，但注意readlines会读取到末尾
            self.offset = self.file_obj.tell()
            print(f"  新offset={self.offset}")
        else:
            print("  没有新行")
        return lines
    
    def check_file_renamed(self):
        # 检查当前打开的文件inode是否与路径上的inode一致
        # 如果被重命名，路径上的inode可能变了，但打开的文件inode不变
        try:
            current_stat = os.stat(self.file_path)  # 获取当前路径的inode
        except FileNotFoundError:
            # 文件被删除或移动了
            print(f"WARNING: 文件 {self.file_path} 已不存在")
            return True
        # 如果当前路径的inode不等于我们打开时的inode，说明是另一个文件
        current_inode = current_stat.st_ino
        return current_inode != self.inode
    
    def close(self):
        self.file_obj.close()
        print(f"Harvester关闭: 文件={self.file_path}, inode={self.inode}")

# 模拟logrotate create模式
# Step1: 创建初始日志
original_lines = [
    "2023-01-01 00:00:01 INFO start",
    "2023-01-01 00:00:02 INFO request1",
    "2023-01-01 00:00:03 INFO request2",
]
create_log_file(log_file_path, original_lines)

# Step2: 启动一个harvester，读取到文件末尾
harvester = SimulatedHarvester(log_file_path)
time.sleep(0.1)
harvester.read_lines()  # 读取所有行，offset移动到末尾
print(f"第1次读取后，offset={harvester.offset}")

# Step3: 模拟logrotate重命名+创建新文件
os.rename(log_file_path, log_file_path + ".bak")  # 重命名为.bak
print(f"文件被重命名为 {log_file_path}.bak")
# 注意：此时旧文件的inode没变，但路径变了；新文件名(log_file_path)不存在了
# 接下来创建新文件（模拟create模式）
new_lines = [
    "2023-01-01 00:00:04 INFO request3",
    "2023-01-01 00:00:05 INFO request4",
]
create_log_file(log_file_path, new_lines)  # 新文件inode不一样
print(f"新文件 {log_file_path} 创建完成，inode={os.stat(log_file_path).st_ino}")

# Step4: 模拟havester继续读取旧文件（它仍持有旧inode的文件句柄）
# 但此时旧文件已经被重命名为.bak，如果写入还在继续（比如Nginx还没切换）
# 这里我们模拟写入一些额外数据到.bak文件中，就好像Nginx在reopen之前写了最后几行
with open(log_file_path + ".bak", "a") as bak_file:
    bak_file.write("2023-01-01 00:00:06 INFO last_request\n")   # 这一行可能丢失！

print("模拟写入一条到.bak文件")
time.sleep(0.1)
harvester.read_lines()  # 如果能读到这条新行，就ok；如果harvester误以为这是新文件...
# 实际上harvester还持有.bak的句柄，应该能读到
# 但是，如果后续.bak被压缩或删除，而harvester还没记录offset...
print("--- 模拟轮转完成 ---")
harvester.close()

# 如果我们在harvester关闭后，删除.bak，而Filebeat的registry还没来得及写进去，就会丢失offset。
# 真实Filebeat会在关闭harvester时写registry，但若close_inactive太长或非正常退出就有风险

这个例子展示了：harvester通过inode跟踪可以正确读取到重命名后的文件。但如果后续文件被删除，且harvester的offset没有及时持久化，那些“最后写入”的行就会丢失。在真实生产中，丢失的往往是轮转间隙的那几行。

3.3 示例：close_inactive设置不合理导致harvester卡住

另一个常见元凶是close_inactive配置。它的含义是：如果文件在指定时间内没有新写入，harvester就关闭这个文件句柄，释放资源。默认是5分钟。很多人把它调得很大，比如1小时，认为这样能减少反复打开文件的开销。但这样做有两个风险：

  • 如果日志文件被轮转删除，harvester还开着句柄不释放，操作系统可以回收inode，但Filebeat的registry里还保留着这个inode的记录。下次重启时，它会发现这个inode已经不存在，于是放弃，导致这段区间内可能还有未读的数据（尤其是如果文件被truncate后，新数据写到了同一个inode，但offset已经是旧值）。
  • 如果使用了copytruncate模式，文件被truncate后，内容清空，但inode不变。如果harvester的offset还在文件末尾，它读到文件为空，就会一直停在原地，新写入的内容实际上被追加到了offset之后，但harvester还没读，接着它可能因为超时而关闭，下次重新打开时从0开始读，造成重复读取或者丢失（取决于配置里的clean_removed等选项）。

给出一个实际配置示例：

# filebeat.yml 配置片段
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/nginx/access.log
  close_inactive: 5m          # 默认5分钟无写入就关闭
  close_renamed: false        # 默认false，文件被重命名后仍然尝试读取
  clean_removed: true         # 当文件被删除时，清理registry记录
  ignore_older: 12h           # 忽略12小时之前的文件
  harvester_buffer_size: 16384

如果close_renamed: false（默认），当一个文件被重命名后，Filebeat还会尝试继续读取它。这本身没问题。但如果重命名后，这个文件被系统删除了（比如logrotate压缩后删掉），而clean_removed: true，Filebeat会检测到文件消失，然后清理registry，这样就彻底放弃了对这个inode的跟踪。然而，在文件被删除之前，如果harvester还没有把最新offset写进registry，这些偏移信息就丢失了。

3.4 解决方案：调整配置避免丢失

根据场景选择合适的参数：

  • 使用close_renamed: true：当文件被重命名后，立即关闭harvester，不再读取旧文件。这样，新文件会单独被harvester读取，不会出现“夹心”问题。但要看是否你的业务需要收集重命名后旧文件继续写入的数据。对于Nginx的logrotate create模式，推荐设为true，因为重命名后Nginx会立即reopen写入新文件，旧文件不会再增加内容。
  • 缩小close_inactive：不要设置太大，默认5分钟足够了。如果日志量很小，可以考虑减少到1分钟，确保harvester及时关闭，registry及时更新。
  • 配合scan_frequency：Filebeat每隔一定时间（默认10秒）扫描文件列表，尽早发现新文件。
  • 使用harvester_limit：限制同时打开的harvester数量，避免文件过多时性能问题。
  • 在logrotate中使用copytruncate模式：可以避免inode变化，Filebeat只需跟踪同一个inode，offset会一直有效。但缺点是复制后清空原文件可能会导致短暂的空档（如果清空后马上有写入，偏移量会被重置？）。实际上，copytruncate会先复制，然后truncate，Filebeat会检测到文件变小（被截断），然后从0开始重新读取。这样会重复读取一部分数据，但不会丢失。如果对重复数据不敏感（比如ID去重），可以使用copytruncate。

四、技术优缺点与应用场景

4.1 优点

  • inode跟踪机制：鲁棒地应对文件重命名、删除等操作，不需要依赖文件名。
  • offset持久化：通过registry文件（使用boltdb）记录每个inode的读取进度，重启后能继续。
  • 灵活的关闭策略：允许根据文件写入频率调整资源占用。

4.2 缺点

  • 性能开销：每个文件一个harvester进程，大量小文件时内存和文件句柄占用较高。
  • registry文件损坏风险：突发断电或磁盘故障可能导致registry损坏，丢失进度，造成重复或丢失。
  • 对共享文件系统支持有限：如果多个Filebeat实例读取同一个NFS文件，inode在不同机器上可能不同（因为NFS client看到的是伪inode），容易重复读取。
  • 配置复杂：需要根据日志轮转策略精心调整close_*和clean_*参数，否则容易出问题。

4.3 应用场景

  • 单机日志采集：最常用，配合logrotate create或copytruncate模式。
  • 容器日志: 在Docker或Kubernetes中，每个容器日志文件实际上是通过软链接指向stdout/stderr，inode跟踪也有效。
  • 实时日志分析：对数据实时性要求高的场景，Filebeat可以做到秒级延迟。

五、注意事项

  1. 不要盲目关闭文件老化：ignore_older不要设置过小，否则日志文件若因写入暂停被误判为旧文件而跳过。
  2. 监控Filebeat内部指标：通过filebeat --metrics或/filebeat/metrics监控filebeat.harvester.closed、filebeat.harvester.running等指标，观察是否有异常关闭或卡住。
  3. 定期检查registry文件大小：如果registry文件过大（超过100MB），会影响启动速度，可以配置registry.flush和registry.cleanup_interval。
  4. 使用Filebeat的--strict.perms模式测试：在调试阶段可以开启logging.level: debug，观察Filebeat如何处理文件轮转。
  5. 阅读官方文档关于close_*的区别：close_inactive是超时关闭；close_renamed是重命名后关闭；close_eof是读到结尾关闭（不推荐）。要区分清楚。

六、文章总结

丢失日志总是让人抓狂，但背后往往是一个系统性的问题。Filebeat的harvester通过inode和offset来跟踪文件，这套机制本身很健壮，但在与logrotate等工具配合时，由于文件生命周期和写入时序的微妙差异，就容易出现“夹缝中丢行”的情况。常见的元凶包括：logrotate的create模式导致新老文件inode不一致、harvester关闭不及时导致offset未持久化、close_inactive设置过长等。解决思路是理解每个配置项的真实含义，根据日志轮转方式合理设置close_renamed、close_inactive，并且在关键场景下考虑使用copytruncate模式来避免inode变化。排查时，可以打开Filebeat的调试日志，观察每个文件的状态变化，配合strace或procfs追踪系统调用，往往能快速定位。只要把文件指针和inode的关系彻底弄明白，就能从根本上杜绝这类神秘消失。