1. logrotate子配置文件基础解析
在Linux系统中，日志文件的管理是个技术活。想象一下，如果放任日志文件无限制增长，用不了多久你的磁盘就会被撑爆。这时候logrotate就像个贴心的管家，帮你把日志文件整理得井井有条。
/etc/logrotate.d/这个目录特别有意思，它就像是主配置文件的"小助手"。主配置文件/etc/logrotate.conf定义了全局规则，而/etc/logrotate.d/下的子配置文件则负责各个服务的个性化需求。这种模块化的设计让日志管理既保持了统一性，又能灵活应对不同服务的特殊要求。
我见过不少新手直接把所有配置都塞进主配置文件，结果文件越改越乱。其实正确的做法是：通用配置放主文件，服务专用配置放子文件。比如Nginx的日志轮转规则就应该是/etc/logrotate.d/nginx，这样即使Nginx升级也不会影响其他服务的日志配置。
2. 常见服务的子配置实战
2.1 Nginx日志配置详解
先来看个Nginx的典型配置，这是我多年运维经验总结出来的黄金方案：
/var/log/nginx/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 www-data adm sharedscripts postrotate [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid` endscript }这个配置有几个精妙之处：
- rotate 14表示保留两周的日志，这个时间长度既能满足排查问题需求，又不会占用太多空间
- delaycompress配合compress使用，可以避免压缩正在写入的日志文件
- postrotate里的USR1信号会让Nginx优雅地重新打开日志文件
我曾经遇到过配置写完不生效的情况，后来发现是权限问题。注意create参数指定的www-data用户和adm组必须和Nginx运行用户一致，否则会导致日志写入失败。
2.2 Syslog的定制方案
系统日志的管理更需要谨慎，这里分享一个经过实战检验的配置：
/var/log/syslog /var/log/mail.info /var/log/mail.warn /var/log/mail.err /var/log/daemon.log /var/log/kern.log /var/log/auth.log /var/log/user.log /var/log/lpr.log /var/log/cron.log /var/log/debug /var/log/messages { rotate 7 daily missingok notifempty delaycompress compress postrotate /usr/lib/rsyslog/rsyslog-rotate endscript }这个配置的特点是：
- 同时管理多个系统日志文件
- 采用daily轮转但只保留7天，因为系统日志量通常很大
- 使用rsyslog自带的旋转脚本，比直接发信号更可靠
2.3 Zabbix监控日志配置
对于监控系统Zabbix，日志配置需要特别关注：
/var/log/zabbix/zabbix_server.log /var/log/zabbix/zabbix_agentd.log { weekly rotate 12 compress delaycompress missingok notifempty create 0664 zabbix zabbix sharedscripts postrotate systemctl restart zabbix-agent >/dev/null 2>&1 || true endscript }这里有个坑要注意：Zabbix服务重启可能会影响监控数据收集，所以实际生产环境中我会改用HUP信号而不是直接restart。
3. 高级配置技巧
3.1 create与copytruncate的抉择
这两个参数的选择经常让人纠结，我用实际案例说明它们的区别：
create模式工作流程：
- 重命名当前日志文件（如access.log变为access.log.1）
- 创建新的access.log文件
- 通知服务重新打开日志
copytruncate模式工作流程：
- 复制当前日志文件为access.log.1
- 清空原access.log文件
create模式更优雅但需要服务支持重新打开日志，适合Nginx、Apache等现代服务。copytruncate简单粗暴，适合那些不支持重载日志的老旧程序。
我曾经在MySQL上踩过坑：使用copytruncate导致丢失了几秒钟的日志。所以现在我的原则是：能用create就不用copytruncate。
3.2 自定义cron调度
默认logrotate是通过/etc/cron.daily执行的，但有些服务需要更频繁的轮转。比如高流量的Web服务，我们可以创建自定义任务：
# /etc/cron.hourly/logrotate-nginx #!/bin/sh /usr/sbin/logrotate /etc/logrotate.d/nginx-hourly对应的nginx-hourly配置：
/var/log/nginx/*.log { size 100M rotate 24 compress missingok notifempty create sharedscripts postrotate [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid` endscript }这种配置会在日志达到100MB时立即轮转，而不是傻等固定时间。
4. 排错与调试技巧
4.1 调试模式实战
当配置不按预期工作时，debug模式是你的好朋友：
logrotate -d /etc/logrotate.d/nginx这个命令会详细显示logrotate的决策过程，但不会真正执行操作。我曾经用它发现了一个奇葩问题：日志文件大小写不匹配导致配置不生效。
4.2 常见问题解决方案
问题1：日志轮转后服务不再写入新日志 解决方法：检查postrotate脚本是否执行成功，确认文件权限是否正确
问题2：轮转太频繁 解决方法：调整size参数或时间间隔，避免minsize和maxsize冲突
问题3：磁盘空间不足 解决方法：增加rotate数量或调整compress参数，必要时使用olddir指定其他分区
问题4：轮转后日志丢失 解决方法：检查是否误用copytruncate，确认inode变化情况
记得有次凌晨三点被叫起来处理日志问题，最后发现是磁盘inode用尽。现在我会在配置里加上：
su root root确保轮转时有足够权限。
5. 最佳实践总结
经过多年摸爬滚打，我总结出这些黄金法则：
- 保持配置简洁：一个服务一个文件，便于管理
- 重要日志多保留：安全日志保留半年，应用日志保留两周
- 监控日志轮转：通过logrotate的状态文件/var/lib/logrotate.status监控执行情况
- 定期检查：设置每月检查一次日志配置，特别是服务升级后
- 性能考量：压缩虽然省空间但会增加CPU负载，根据服务器情况权衡
最后分享一个我常用的多维度检查清单：
- 权限检查（服务用户能否写入新日志）
- 信号检查（postrotate脚本是否正确）
- 空间检查（rotate数量是否合理）
- 时间检查（cron是否正常执行）
