Filebeat如何进行日志文件轮转

Filebeat日志轮转实践

说到日志轮转，不少朋友可能会感到困惑：到底该管哪些文件？其实，这里需要明确区分两类性质完全不同的日志，处理策略也截然不同。

一 核心概念与适用场景

首先，必须分清你面对的是哪一类日志：

• Filebeat自身日志：这是Filebeat进程自己输出的运行状态和错误信息。对于这类日志，通常建议交给系统的 logrotate 工具来管理，当然，你也可以在 filebeat.yml 的 logging.files 配置段里，直接设置保留策略。
• 被采集的业务日志：这才是重头戏，指的是你的应用程序或操作系统产生的那些日志文件。它们通常由应用自身或系统工具（比如 logrotate）按照时间或大小进行切割轮转。Filebeat的聪明之处在于，它依靠文件的 inode 和文件名来跟踪读取进度。因此，你只需要配合 ignore_older、close_inactive、clean_inactive 这几个关键参数，就能让它优雅地处理文件的轮转与清理。

二 轮转Filebeat自身日志的两种方式

对于Filebeat自己的日志，主要有两种管理思路，各有利弊。

方式A 使用 logrotate（推荐）

这是更通用、更符合系统管理习惯的做法。你需要在 /etc/logrotate.d/ 目录下创建一个配置文件，比如 /etc/logrotate.d/filebeat。注意，日志文件的实际路径可能因安装方式而异，常见的有 /var/log/filebeat/filebeat 或 /var/log/filebeat/filebeat.log。

一个典型的配置示例如下：

/var/log/filebeat/*.log {
    daily
    missingok
    rotate 7
    compress
    notifempty
    create 0640 root root
    sharedscripts
    postrotate
        # 优先使用 kill -HUP，若PID文件不存在则忽略
        kill -HUP $(cat /var/run/filebeat/filebeat.pid 2>/dev/null) 2>/dev/null || true
    endscript
}

这里有几个关键点需要解释：

• 配置中的 kill -HUP 命令至关重要。它的作用是通知Filebeat进程重新打开日志文件描述符。如果没有这一步，Filebeat可能会继续向已经被轮转、重命名的旧日志文件里写入内容。
• 如果你的Filebeat是通过systemd管理并以 -e（前台）模式运行的，那么用 systemctl restart filebeat 重启服务也能达到相同效果，只是会带来一次短暂的数据采集中断。

配置好后，别忘了验证：

• 手动触发测试：执行 sudo logrotate -f /etc/logrotate.d/filebeat，强制进行一次轮转。
• 查看结果：用 ls -l /var/log/filebeat/ 看看是否生成了类似 filebeat.log.1.gz 这样的压缩归档文件。
• 确认调度：通常 logrotate 由每日的cron任务自动执行，可以通过 cat /etc/cron.daily/logrotate 来确认。

方式B 使用 Filebeat 内置日志保留

如果你希望配置更集中，不想依赖外部工具，Filebeat也提供了内置的日志管理功能。注意，这仅影响Filebeat自身的日志。

你可以在 filebeat.yml 中这样配置：

logging:
  to_files: true
  files:
    path: /var/log/filebeat
    name: filebeat
    keepfiles: 7
    level: info

修改配置后，重启Filebeat服务即可生效：sudo systemctl restart filebeat。这种方式简单直接，Filebeat会自己按照 keepfiles 设置的数量来保留旧日志文件，无需处理信号或依赖其他工具。

三 采集端对业务日志轮转的推荐配置

这才是Filebeat日志采集工作的核心场景。你的应用日志在不断轮转，Filebeat如何做到既不漏数据也不重复采？关键在于合理的配置。

识别策略

• 跟踪机制：保持Filebeat默认的基于文件inode的跟踪方式，这是避免漏采或重复采集的基石。
• 参数调优：合理设置以下几个参数，能让整个流程更顺畅：
  • ignore_older：直接忽略超过指定时长（例如168小时）的历史文件，减轻扫描负担。
  • close_inactive：如果一个文件在指定时间（例如5分钟）内没有新内容写入，Filebeat会先关闭它的句柄。这非常有用，因为文件轮转后，及时释放句柄才能让系统清理旧文件。
  • clean_inactive：超过指定时间（例如24小时）未更新的被跟踪文件，将从Filebeat的注册表中清理掉。这是防止句柄泄漏的最后一道保险。

示例（filebeat.yml 片段）

将上述策略落实到配置文件中，大概是这个样子：

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/*.log
  ignore_older: 168h
  close_inactive: 5m
  clean_inactive: 24h

output.elasticsearch:
  hosts: ["localhost:9200"]

提示

这里有个常见的理解误区：如果应用程序是按大小切割日志（比如每写满100MB就轮转一次），你需要在Filebeat这边做特殊配置吗？答案是：通常不需要。只要确保轮转产生的新日志文件，其路径在Filebeat的监控范围内，并且Filebeat进程有权限读取它，剩下的交给基于inode的跟踪机制就好了。

四 常见问题与排查

理论归理论，实践中总会遇到些“小状况”。下面这几个场景，相信不少人都碰到过。

• 轮转后，日志仍向旧文件写入
  • 根因：最可能的原因是，日志文件轮转后，没有人通知Filebeat去重新打开文件描述符。
  • 处理：检查你的 logrotate 配置，确保 postrotate 脚本里包含了向Filebeat发送 HUP 信号的命令，或者设置了重启服务。同时，务必确认脚本中引用的PID文件路径正确且Filebeat有权限读取。
• 因误删或移动文件导致重复采集
  • 处理：尽量避免在Filebeat还在跟踪读取时，直接移动或删除日志文件。如果必须这样做，稳妥的办法是先停止Filebeat服务，完成轮转操作后再启动。或者，通过精确设置 ignore_older 和 clean_inactive 参数，来缩小可能受影响的“时间窗口”。
• 权限问题
  • 处理：这是一个经典的“坑”。请双重确认：Filebeat进程用户对要采集的日志目录和文件有读取权限；如果配置了内部队列或日志输出，它对相关目录有写入权限。另外，logrotate 配置中的 create 指令所设置的文件模式和属主，也要和运行用户匹配（例如 0640 root root 或 0640 root adm）。
• 验证与观测
  • 当你对配置有疑问时，可以手动触发轮转来验证：sudo logrotate -f /etc/logrotate.d/filebeat。
  • 同时观察Filebeat自身的日志（tail -f /var/log/filebeat/filebeat）和系统日志（journalctl -u filebeat -f），看看有无报错。
  • 最后，别忘了确认自动轮转的调度是否生效：cat /etc/cron.daily/logrotate。