Filebeat日志轮转策略设置
一 核心思路
- 区分两类日志：一类是 Filebeat 自身的运行日志（filebeat.log），另一类是 Filebeat 采集的应用日志（如 /var/log/*.log）。前者建议用系统级 logrotate 管理；后者由 Filebeat 的 Harvester 持续跟踪，无需额外轮转配置。若你使用 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 是让进程重新打开日志文件的首选方式，避免重启导致采集短暂中断。
- 若 PID 文件路径不同，请按实际环境调整（常见还有 /run/filebeat.pid）。
- 测试与生效
- 手动测试：sudo logrotate -f /etc/logrotate.d/filebeat
- 查看轮转记录：/var/log/logrotate.log
- 确保服务运行：sudo systemctl status filebeat
- 常见变体
- 仅保留 7 天：rotate 7
- 按小时轮转：hourly（需系统 cron 支持）
- 不压缩：去掉 compress；延迟压缩：使用 delaycompress。
三 轮转 Filebeat 采集的应用日志
- 原则：被采集的日志文件由 Filebeat 持续 inode 跟踪，应用侧按时间/大小轮转即可（如 logrotate 或应用自带轮转）。为避免 Filebeat 继续读已轮转的旧文件，建议：
- 使用 copytruncate（复制后清空原文件），或
- 轮转后让 Filebeat 重新加载配置（如上节的 reload），或
- 确保轮转后的新文件使用与旧文件一致的 inode（多数 rename 方式会变更 inode，Filebeat 会感知为新文件继续采集）。
- 示例（应用日志的 logrotate，配合 Filebeat 使用）
/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 导致短暂无新数据写入。