如何设置Filebeat日志轮转

要保证日志系统稳定可靠，日志轮转设置是绕不开的一环。很多人在配置Filebeat时，容易把两类日志的轮转混为一谈，结果要么日志撑爆磁盘，要么采集任务出错。今天这篇，就把Filebeat日志轮转的几种玩法彻底讲清楚。

一 概念与总体思路

先说说几个核心概念。Filebeat涉及两类日志，它们的轮转方式完全不同，必须分开处理：

• Filebeat自身日志：由Filebeat进程自己写入，通常位于/var/log/filebeat/。这类日志的轮转，优先使用Filebeat内置的logging.files配置；如果走systemd，也可以由journald接管，再通过logrotate切割journal日志。
• 被采集的业务日志：由应用写入，Filebeat负责读取。轮转方式通常是操作系统logrotate或应用自身的策略。Filebeat这边要做的，是通过filestream输入正确识别轮转后的文件，避免重复采集或丢失数据。

这两类日志的轮转策略，说白了就是一句话：自己的事自己管，别人的事别瞎掺和。

二 轮转 Filebeat 自身日志

内置文件日志轮转（推荐）

直接在filebeat.yml的logging段开启并配置，这是最省事的方案。关键参数就那么几个：

• logging.to_files: true —— 开启文件日志输出
• logging.files.path —— 日志目录，比如/var/log/filebeat
• logging.files.name —— 日志文件名，比如filebeat
• logging.files.rotateeverybytes —— 单个文件大小上限，默认10MB
• logging.files.keepfiles —— 保留历史文件数，比如7
• logging.files.permissions —— 文件权限，比如0644

举个例子：

logging.to_files: true
logging.files:
  path: /var/log/filebeat
  name: filebeat
  rotateeverybytes: 10485760 # 10MB
  keepfiles: 7
  permissions: 0644

配置好之后，当文件达到大小阈值，Filebeat会自动滚动生成新文件，旧文件按序号保留，达到keepfiles数量后自动清理——完全不需要操心。

使用 systemd + logrotate（可选）

如果坚持用systemd跑，又想用logrotate来切割，也不是不行。在/etc/logrotate.d/filebeat里配一个规则：

/var/log/filebeat/*.log {
    daily
    missingok
    rotate 7
    compress
    notifempty
    create 0640 root root
}

注意，这种方式依赖systemd的StandardOutput/StandardError指向文件。如果已经用了内置的logging.files，就没必要再折腾logrotate了。

三 轮转被采集的业务日志

使用 logrotate 切割应用日志

业务日志的轮转，通常交给操作系统自带的logrotate来处理。在/etc/logrotate.d/下给每个业务应用创建配置文件，比如：

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 app app
    sharedscripts
    postrotate
        # 如果应用支持USR1信号重开日志（比如nginx），可以在这里发信号
        # kill -USR1 $(cat /var/run/myapp.pid 2>/dev/null) || true
    endscript
}

这里有几个要点：切割策略（按大小、时间还是保留份数）要和业务吞吐量匹配；切割后要确保应用能继续写入新文件，要么发信号通知，要么让应用自动重新打开文件描述符。

Filebeat 侧正确读取轮转文件

Filebeat这边，用的是filestream输入。配置好paths和file_identity，就能避免重复或漏读。举个例子：

filebeat.inputs:
- type: filestream
  id: app-logs
  paths:
    - /var/log/myapp/*.log
  # 默认基于inode+device识别文件，多数本地轮转场景无需额外配置

大部分场景下，默认配置就够了。不过有几个特殊情况需要注意：

• 网络共享或云盘环境下，inode可能会变，这时可以改用path方式识别文件，配合inode_marker使用，但要仔细评估重复风险。
• 要避免采集已经轮转归档的旧文件，可以用exclude_files排除匹配模式，比如*.gz、*.zip。

四 验证与常见问题

验证 Filebeat 自身日志轮转

先看配置是否生效：ls -lh /var/log/filebeat/，看看有没有出现按序号或时间命名的多个文件。再检查Filebeat运行状态：systemctl status filebeat，确认日志持续写入。

验证业务日志轮转

可以手动触发一次轮转试试：logrotate -f /etc/logrotate.d/myapp。然后观察新日志是否继续写入，Filebeat是否有重复或报错。同时，去Filebeat自己的日志里看看有没有文件打开、关闭或轮转相关的提示。

常见问题与处理

• 重复采集：多数是file_identity识别异常，或者没有排除归档文件。核对一下filestream配置和exclude_files。
• 丢失事件：轮转期间应用没有正确重开文件，或者缓冲区没有刷新。确保应用支持信号重开，或者切割后短暂等待再清理旧文件。
• 权限问题：被采集日志或Filebeat自身日志目录权限不足，导致无法读取或写入。检查create权限和属主属组是否正确。

归根结底，日志轮转的关键在于匹配——Filebeat的配置要和业务日志的轮转策略一致，再加上正确的file_identity识别，基本就能跑得稳了。