当前位置：首页 > news >正文

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

news 2026/7/6 12:36:44

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时立即轮转，而不是傻等固定时间。