Filebeat日志轮转策略如何设置

日志轮转，这大概是所有运维同学都绕不开的日常话题。Filebeat 作为轻量级日志采集器，它的日志管理同样需要讲究章法。做不好，磁盘很快就被打满，采集也会莫名其妙中断。从实践经验来看，核心只有一句话：分清边界，谁的孩子谁抱走。

核心思路

首先要区分两类日志：一类是 Filebeat 自身的运行日志（filebeat.log），另一类是它采集的那些应用日志（比如 /var/log/*.log）。

对于前者，直接用系统级的 logrotate 来管理，这是最成熟、最稳妥的方案。对于后者，Filebeat 的 Harvester 会通过 inode 持续跟踪文件变化，你完全不需要在 Filebeat 内部做任何轮转配置——应用侧该轮转就轮转，Filebeat 自然能感知到。当然，如果你特别依赖 Filebeat 的 file 输出插件写入本地文件，也可以单独给它配置基于大小的滚动策略，但这属于特例。

轮转 Filebeat 自身日志：logrotate 推荐做法

具体怎么配置呢？我们直接创建一个 /etc/logrotate.d/filebeat 文件，内容如下：

/var/log/filebeat/*.log {
  daily
  rotate 7
  missingok
  notifempty
  compress
  delaycompress
  create 0640 root root
  sharedscripts
  postrotate
    # 优先使用 kill -USR1 触发重新打开日志文件（不中断进程）
    if [ -f /var/run/filebeat/filebeat.pid ]; then
      kill -USR1 $(cat /var/run/filebeat/filebeat.pid) 2>/dev/null || true
    else
      # 兼容 systemd 场景：也可用 systemctl reload
      systemctl reload filebeat >/dev/null 2>&1 || true
    fi
  endscript
}

这里需要划几个重点：

避免重启导致采集中断，首选 kill -USR1。这个信号会通知 Filebeat 重新打开日志文件，进程本身不受影响，采集任务也不会断开。如果 PID 文件不在默认路径（比如 /run/filebeat.pid），记得根据实际环境调整路径。

配置完成后，用 sudo logrotate -f /etc/logrotate.d/filebeat 手动触发一次测试。轮转的结果会记录在 /var/log/logrotate.log 里，务必去确认一下是否执行成功。同时检查 sudo systemctl status filebeat 确保服务正常运行。

一些常见变体也值得一提：保留周期可以用 rotate 7 控制；如果业务日志量极大想按小时轮转，设 hourly 即可（需要系统 cron 支持）；不想压缩就去掉 compress，用 delaycompress 则可以实现“第二天再压缩”，兼顾灵活性。

轮转 Filebeat 采集的应用日志

被采集的日志文件，Filebeat 通过 inode 持续跟踪。应用侧的轮转策略（时间或大小触发）照常执行就好，Filebeat 会自动适应。但要注意一个常见陷阱：轮转后，Filebeat 可能继续读旧文件而不是新文件。解决方法有三种：

• 使用 copytruncate 模式（先复制原文件，再清空原文件），inode 不变，Filebeat 继续正常工作。
• 轮转后让 Filebeat 重新加载配置（比如用上面的 reload 或 USR1 信号）。
• 如果轮转采用 rename 方式（inode 会变更），Filebeat 会自动感知到新文件并继续采集，但前提是应用侧能及时生成新文件。

下面是一个配合 Filebeat 使用的应用日志 logrotate 配置示例：

/var/log/myapp/*.log {
  daily
  rotate 30
  missingok
  notifempty
  compress
  delaycompress
  copytruncate
  create 0644 root root
}

采用 copytruncate 的好处是不需要重启应用或发信号，运维成本非常低。如果你一定要用 rename+信号的方式，请务必确保 Filebeat 能收到通知（reload 或 USR1），否则会出现“旧文件一直开着、新文件一直没人读”的尴尬局面。

使用 Filebeat 输出到文件时的内置滚动

如果 Filebeat 的输出目标写到本地文件（output.file），你可以利用内置的滚动参数来约束：

output.file:
  enabled: true
  path: "/var/log/filebeat"
  filename: "filebeat.log"
  rotate_every_kb: 104857600 # 100MB
  keep_files: 10
  permissions: 0644

这属于按大小进行滚动，适合本地调试或者特殊归档需求。生产环境中更常见的做法，是将日志直接发送到 Elasticsearch、Logstash 或 Kafka 这类集中式存储，避免在本地做复杂的文件管理。

验证与排错

改完了，怎么确认一切正常？几个常用检查点：

• 查看轮转是否生效：ls -lh /var/log/filebeat/，观察是否有 .gz 压缩文件出现，以及文件数量是否符合 rotate 设定。
• 检查 Filebeat 是否持续采集：tail -f /var/log/filebeat/filebeat 或执行 filebeat test output。
• 查看 logrotate 自身的日志：tail -f /var/log/logrotate.log，确认配置是否被触发、是否有报错。
• 如果采集出现中断，优先排查：日志路径的权限是否正确、是否成功触发了 USR1/reload、以及 copytruncate 是否导致了短暂的无新数据写入窗口。

总而言之，日志轮转的核心不在于代码有多复杂，而在于理解谁负责轮转、谁负责跟踪、轮转后怎么保证采集不中断。把这几条线理清楚了，后面基本不会出大问题。