logrotate实战避坑与高级配置指南

1. 为什么你需要掌握logrotate

作为系统管理员，你一定遇到过这样的场景：服务器运行几个月后，突然发现磁盘空间告急，一查发现是某个应用的日志文件已经膨胀到几十GB。更糟的是，直接删除日志文件可能导致应用异常，因为很多程序会持续向已打开的文件描述符写入数据。

这就是logrotate的价值所在。这个Linux系统自带的日志管理工具，能够帮你自动完成日志的轮转、压缩和清理。但说实话，很多运维同学对它的理解仅限于基本配置，遇到复杂场景就抓瞎。我见过太多人因为配置不当，要么日志根本没轮转，要么轮转后应用还在往旧文件写数据，甚至出现日志丢失的情况。

logrotate的核心优势在于它与系统深度集成，通过cron自动运行，支持各种灵活的轮转策略。但要想真正用好它，必须理解其工作原理和那些容易踩坑的高级参数。接下来，我会结合多年实战经验，带你深入logrotate的配置细节，避开那些教科书上不会告诉你的"坑"。

2. 基础配置与常见误区

2.1 配置文件结构与基本参数

logrotate的主配置文件通常位于/etc/logrotate.conf，而各个应用的配置则放在/etc/logrotate.d/目录下。一个典型的配置段长这样：

/var/log/nginx/access.log { daily rotate 7 compress delaycompress missingok notifempty create 0640 www-data www-data sharedscripts postrotate /usr/bin/systemctl reload nginx >/dev/null 2>&1 || true endscript }

这里有几个新手常犯的错误：

1. 权限设置不当：create参数指定的用户/组必须对日志目录有写入权限，否则轮转后会因创建新文件失败导致日志丢失。我曾经就遇到过因为误设create为root:root而Nginx无法写入新日志的情况。
2. 压缩时机混淆：compress表示立即压缩，delaycompress则是延迟到下次轮转再压缩。如果同时启用两者，后者会覆盖前者。
3. 脚本执行顺序：postrotate脚本是在日志轮转后执行，而prerotate是在轮转前。搞反顺序会导致应用无法正确重载日志文件。

2.2 计划任务这个"隐藏BOSS"

很多人不知道的是，logrotate默认通过/etc/cron.daily/logrotate脚本每天运行一次。这意味着：

• 即使你设置了size参数，如果文件在两次运行间隔内没达到阈值，就不会触发轮转
• 配置了hourly轮转但没有添加cron任务，设置根本不会生效

我曾经为某个高流量服务配置了size=100M，但日志增长到300MB还没轮转，就是因为没调整cron频率。解决方法很简单：

# 创建每小时运行的任务 sudo cp /etc/cron.daily/logrotate /etc/cron.hourly/

或者更精确地控制执行时间：

# 在/etc/crontab中添加 */30 * * * * root /usr/sbin/logrotate /etc/logrotate.conf

3. 高级参数实战技巧

3.1 大小与周期的优先级规则

logrotate的轮转条件主要有两种：时间周期（daily/weekly/monthly）和文件大小（size）。它们的组合使用容易让人困惑：

• 单独使用周期参数：严格按时间触发，不考虑文件大小
• 单独使用size参数：需配合高频cron任务，否则可能错过轮转
• 同时使用两者：行为取决于minsize/maxsize的选择

这里有个实际案例：某次我需要保留最近7天日志，但单日日志可能超过磁盘容量。最终配置方案：

/var/log/app/*.log { daily rotate 7 maxsize 1G compress dateext dateformat -%Y%m%d sharedscripts postrotate # 通知应用重载日志 endscript }

maxsize=1G确保日志达到1GB立即轮转，不受daily限制；同时rotate 7保证最多保留7个归档。

3.2 时间格式的精确控制

dateext参数允许在归档文件名中添加时间戳，而dateformat可以自定义格式。但要注意：

1. 只支持%Y(年)、%m(月)、%d(日)、%H(时)、%s(秒)五种格式
2. 使用dateext时，rotate参数计算的是除当前日志外的归档文件数
3. 时间格式错误会导致轮转失败

我曾经需要按小时归档日志，这样配置：

dateext dateformat -%Y%m%d%H hourly

结果发现归档文件堆积，因为hourly需要配合cron.hourly才能生效，单纯改配置没用。

3.3 sharedscripts的妙用与陷阱

当监控多个日志文件时：

/var/log/cluster/*.log { sharedscripts postrotate /usr/bin/killall -HUP app_server endscript }

sharedscripts确保所有文件轮转完成后只执行一次postrotate，而不是每个文件轮转都执行。但这里有三个坑：

1. 如果某个日志轮转失败，整个postrotate都不会执行
2. 脚本执行时环境变量可能与预期不同
3. 脚本执行超时会导致logrotate报错

建议在关键脚本中添加错误处理和日志记录：

postrotate echo "[$(date)] Rotating logs" >> /var/log/logrotate.log /usr/bin/killall -HUP app_server || echo "HUP failed" >> /var/log/logrotate.log endscript

4. 生产环境经典问题排查

4.1 为什么轮转后日志还在增长

这是最常见的问题之一，现象是轮转后旧日志文件大小仍在增加。根本原因是应用没有重载日志文件描述符。解决方案有三：

1. 使用copytruncate参数（不推荐，可能丢失数据）
2. 配置正确的postrotate脚本（如kill -HUP）
3. 让应用支持日志文件热重载（最佳实践）

对于Nginx这样的服务，reload命令就足够了。但对于自定义应用，可能需要特殊处理。我曾经遇到一个Java应用，需要这样配置：

postrotate # 通过PID文件找到进程 if [ -f /var/run/app.pid ]; then kill -USR1 $(cat /var/run/app.pid) fi endscript

4.2 参数不生效的排查步骤

当你的配置似乎没起作用时，按这个顺序检查：

1. 手动测试：logrotate -d /etc/logrotate.conf调试模式查看输出
2. 检查状态文件：/var/lib/logrotate/status记录上次轮转时间
3. 验证cron：grep logrotate /etc/crontab /etc/cron.*/*
4. 查看日志：journalctl -u cron或/var/log/syslog
5. 文件权限：确保logrotate有权限读取配置和写入日志目录

一个真实的debug案例：某次配置了size=100M但无效，最终发现是status文件中记录的上次轮转时间比文件修改时间新，导致logrotate认为不需要处理。

4.3 多磁盘环境的特殊处理

当日志和归档需要放在不同分区时，必须注意：

1. olddir指定的目录必须与日志同文件系统（硬链接限制）
2. 可以改用复制+删除的方式：

olddir /mnt/archive/logs nocreate copy

这会带来性能开销，但对大日志文件更可靠。我曾经通过这种方式将归档日志自动转移到NFS共享存储。

5. 性能优化与安全加固

5.1 大规模日志的优化技巧

当处理GB级日志文件时，需考虑：

1. 压缩消耗CPU：在非高峰时段执行压缩

   compresscmd /usr/bin/pigz # 使用多线程压缩

2. 并行处理：对多个独立日志使用su user group并行运行
3. IO调度：通过ionice降低优先级

   lastaction /usr/bin/ionice -c 3 /usr/bin/rsync -a /var/log/archive /backup/ endscript

5.2 安全最佳实践

1. 权限最小化：

   create 0640 appuser appgroup

2. 敏感日志过滤：

   prerotate /usr/bin/sed -i '/password/d' $1 endscript

3. 日志完整性保护：

   lastaction /usr/bin/chattr +a /var/log/audit.log endscript

5.3 监控与告警配置

完善的日志轮转需要监控：

1. 检测轮转失败：

   mail admin@example.com

2. 添加Prometheus监控：

   postrotate echo "logrotate_completed{log=\"$1\"} 1" > /var/lib/node_exporter/logrotate.prom endscript

3. 日志分析集成：

   lastaction /usr/bin/find /var/log/archive -name "*.gz" -mtime +30 -exec aws s3 cp {} s3://backup/ \; endscript

6. 替代方案与进阶思路

虽然logrotate能满足大部分需求，但在某些场景下可能需要替代方案：

1. 基于inotify的实时轮转：如使用inotifywait监控日志大小
2. 容器化环境方案：采用sidecar容器处理日志轮转
3. 分布式日志系统：直接输出到Fluentd/Logstash等管道

一个Kubernetes环境的优雅解决方案：

/var/log/pods/*/*.log { size 100M rotate 5 compress missingok delaycompress nocreate nocopytruncate postrotate # 通过API通知Pod重建日志文件 endscript }

经过多年实践，我认为logrotate在传统服务器环境中仍是日志管理的首选方案。它的稳定性经过时间检验，只是需要深入理解那些"隐藏规则"。记住，任何自动化工具都需要配合监控和定期检查，毕竟日志的价值往往在系统出问题时才真正体现。