Linux日志系统-03:logrotate子配置文件实战与最佳实践

📅 2026/7/6 12:21:39
Linux日志系统-03:logrotate子配置文件实战与最佳实践
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 21 || 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是否正常执行