生产环境服务器半夜磁盘告警登录上去一看/var/log占了将近 90%再往下一翻某个应用日志已经疯长到 30 多 GB服务早在一个小时前就因为写不进日志开始报错了。这种事故我见过不止一次而且每次排查到最后原因几乎都一样日志文件从来没人管过系统自带的 logrotate 策略要么没配、要么配了但没生效。logrotate 这个命令说白了就是 Linux 系统里专门用来管日志的轮转工具它每天定时把日志按大小或时间切成一段一段该压缩压缩、该删除删除从根上避免日志把磁盘塞满。这篇文章不跟你讲太多理论知识直接按实操来告诉你配置文件怎么写、踩过哪些坑、怎么验证它真的在干活适合刚接手服务器的新手也适合那些一直在用但没深究过的运维老手。1. logrotate 的工作原理与配置文件体系1.1 日志为什么需要轮转先把一个很容易被忽略的事实摆出来在 Linux 里你直接删掉一个正在被进程写入的日志文件磁盘空间其实不会立刻释放。因为那个进程还握着原来的文件句柄删掉文件名只是一层摘牌操作真正的磁盘块还被 inode 占着进程照样往里写。你删了半天df -h一看空间还是满的就是这个道理。所以处理日志不能靠定期删文件这种粗暴思路得用轮转把当前文件改名备份再新建一个空文件让进程继续写等历史备份攒够了数量再统一压缩、清理。logrotate 干的就是这件事。它不直接删正在写的日志而是按你定义的规则把日志切片、归档、压缩、清理一套流程全部自动化。它内置在几乎所有主流发行版里不用额外安装默认的 crontab 作业会每天拉起来一次。理解它之后你就明白为什么日志清理脚本这种民间方案总是有各种问题手写脚本要考虑信号、句柄、权限、并发而 logrotate 把这些边界情况全给你处理好了。1.2 logrotate 的三大件cron、配置、状态文件logrotate 的工作不是自己定时的它靠 cron 拉起来。绝大多数服务器上你会在/etc/cron.daily/logrotate看到一个脚本内容大体是#!/bin/sh /usr/sbin/logrotate /etc/logrotate.conf EXITVALUE$? if [ $EXITVALUE ! 0 ]; then /usr/bin/logger -t logrotate ALERT exited abnormally with [$EXITVALUE] fi exit 0这个脚本的作用是每天执行一次logrotate入口配置文件是/etc/logrotate.conf。如果你用 systemd 的话还可能看到logrotate.timer这类定时器本质是一样的都是定期调一次命令。配置体系分两层主配置文件/etc/logrotate.conf里写全局默认规则然后用一行include /etc/logrotate.d把/etc/logrotate.d目录下的所有片段都加载进来。你在目录里为某个应用放一个独立配置比如nginx、mysql、redislogrotate 读主配置时就会一并处理。这种拆分的最大好处是互不干扰卸载某个软件时直接删掉对应的片段文件就行不会牵连其他日志的轮转策略。第三个关键角色是状态文件路径一般在/var/lib/logrotate/logrotate.status有些老版本是/var/lib/logrotate.status用-s参数可以指定路径。logrotate 每次执行时都会先读这个文件看某个日志文件上一次是在什么时候轮转的判断这次要不要转。你手动跑logrotate -f强制执行的时候状态文件也会被更新。所以当你怀疑日志怎么一直不转的时候第一件事就该打开状态文件看里面的记录时间。1.3 先读懂系统默认配置不同发行版的默认配置略有差异但核心段落大差不差。拿 CentOS 7 的/etc/logrotate.conf举例weekly rotate 4 create dateext compress include /etc/logrotate.d /var/log/wtmp { monthly create 0664 root utmp minsize 1M rotate 1 }逐行解释一下weekly表示默认的轮转周期是一周rotate 4表示默认保留 4 份历史文件create表示轮转后新建一个同名空文件dateext表示切出来的文件名带上日期后缀比如messages-20240315而不是messages.1compress表示对切出来的历史文件做 gzip 压缩。然后include /etc/logrotate.d加载所有子配置最后的/var/log/wtmp是个独立规则块因为 wtmp 这种账号登录记录文件有特殊权限要求所以要单独指定create 0664 root utmp。你会发现全局默认值是兜底用的/etc/logrotate.d里的每个具体配置可以覆盖这些默认值。比如 nginx 的配置里写了daily那 nginx 日志就按天轮转不受全局weekly影响。这个全局兜底加局部覆盖的设计是 logrotate 用起来很顺手的一个原因。2. 核心配置指令从高频到救命2.1 轮转时机频率、大小与 maxsize/minsize 那点事轮转时机是配置里最先要确定的。最基础的是按时间周期daily、weekly、monthly、yearly分别表示一天、一周、一个月、一年轮转一次。注意这里的周期并不是精确的从上次轮转到 24 小时后而是下一次 cron 干活的时候如果状态文件显示已经隔了一个周期就执行。cron.daily 通常每天凌晨执行但具体几点取决于你的系统设置比如 anacron 或者 systemd timer 的调度策略。所以你可能会发现日志轮转并不总是在固定的零点整发生这很正常。按大小触发是另一个维度。这里有三个容易混淆的参数size、maxsize、minsize。size 100M日志文件超过 100M 就轮转。它和 周期 之间的关系在不同 logrotate 版本里处理方式不一样旧版本里size与daily这类周期参数是互斥的写一起可能只生效一个新版本3.8里两者可以并存满足任何一个条件就转。maxsize 100M表示文件最大 100M超过就转即使还没到设置的周期。这个语义比size更明确我建议你在生产配置里优先用maxsize而不是size。minsize 100M表示周期到了并且文件大小超过 100M才转。它是周期条件的附加门槛防止日志量很小的时候也频繁切文件。举个实际例子。一个应用每天产生大约 50M 日志你希望最多 200M 切一次同时希望如果某天流量暴增到 200M 以上也能及时切那配置应该写daily maxsize 200M rotate 14这样平时一天一切赶上业务高峰文件超过 200M 也会立刻切不会把单个文件撑到几 G。而minsize的典型用法是按周轮转但如果一周日志总量不到 1M 就不转避免产生一堆空文件。2.2 保留与压缩rotate、compress、delaycompressrotate N表示最多保留 N 份轮转出来的历史文件。rotate 4就是保留最近 4 份超过之后最老的那份会被删除。注意如果你同时用了dateext保留数量一样生效只是文件名的形式从递增数字变成了日期。rotate 0表示不保留任何历史文件轮转出来的旧日志直接删掉通常不建议除非你有外部日志采集系统本地完全不需要留存。compress开启 gzip 压缩历史文件会变成.gz后缀。压缩率对纯文本日志非常可观动辄 90% 以上。但有一个参数必须跟它配合理解就是delaycompress。这个参数的意思是本轮轮转出来的文件先不急着压缩等下一次轮转的时候再压。为什么需要延迟因为很多应用在日志文件被改名之后不会立刻重新打开新文件还会往旧的句柄里写一会儿。如果你立即压缩可能把正在写入的内容压坏或者压缩包内容不完整。加一行delaycompress就稳妥很多。所以我在给应用日志做配置时的习惯组合是compressdelaycompress宁可磁盘多占一天也不冒丢日志的风险。2.3 文件交接方式create 与 copytruncate 怎么选这是 logrotate 配置里最值得细讲的一个选择因为它直接关系到日志会不会丢、应用要不要重启。create模式是默认逻辑先把当前日志文件改名为轮转文件比如app.log变成app.log.1然后新建一个空的app.log让应用继续往新文件里写。但这里有个隐含前提应用必须能感知到文件被改名了并且主动重新打开新文件。很多应用并不会自动这么做它们的日志文件句柄还是指向被改名后的旧文件日志会继续写进app.log.1。为了让应用重开句柄你得在postrotate脚本里通知它比如向 nginx 发USR1信号或者让 Java 应用自己配置日志框架的滚动策略。所以create模式适合那些有机制配合重新打开日志文件的应用。copytruncate模式走的是完全不同的路线先把当前日志文件复制一份作为轮转文件然后立即把原文件截断成 0 字节。文件名始终没变inode 也没变应用持有的句柄完全不受影响不需要重启、不需要发信号日志写入几乎不中断。代价是复制和截断之间有一瞬间的数据窗口可能漏掉极少量日志文件特别大时复制过程会占一点 IO。但说实话对绝大多数应用场景来说这个代价完全可以接受。怎么选我个人的判断标准很简单如果这个应用我能控制它重开日志句柄就用create 信号通知如果应用是黑盒、不允许随便动或者你用容器部署不方便发信号就用copytruncate。前者的好处是性能和文件完整性更好后者的好处是省心、无侵入。下面我放一个对比表帮你快速决策对比维度createcopytruncate应用是否需要配合重开句柄需要通常靠信号或应用自身滚动不需要进程无感知日志完整度高改名后直接新文件写入复制截断间隙可能丢极少量日志对应用进程的影响无直接伤害但信号通知不当可能触发问题完全无侵入不用碰进程大文件场景改名成本极低复制大文件会占用 IO 和临时磁盘典型适用对象Nginx、rsyslog、系统日志Java 黑盒应用、无法发信号的容器内进程2.4 兜底利器missingok、notifempty、dateext、sharedscripts这几个参数不像前面那些那么显眼但在真实环境里经常是救命级别的。missingok匹配的日志文件不存在时不报错继续处理其他文件。没有这个参数日志文件一旦被误删logrotate 就会对该配置报错甚至中断整轮处理。我建议所有自定义配置里都写上。notifempty日志文件是空文件就不轮转。空日志切来切去纯属浪费还容易产生一堆无意义的压缩包。与之相对的是ifempty强行要求即使空文件也要轮转默认行为其实就是ifempty。notifempty需要显式写。dateext轮转文件名用日期而不是递增数字。这个对排障非常友好你看到app.log-20240315就知道这是哪天的日志而app.log.3还得掰着手指头数。但用dateext有一个隐患同一天内如果多次轮转比如你用-f强制转了一次会产生同名文件。解决办法是配合dateformat加上更细的时间粒度比如dateext dateformat -%Y%m%d-%H%M%S不过要注意dateformat里不能包含路径分隔符而且不同版本的 logrotate 支持的占位符略有差异%s秒级时间戳有的版本支持、有的不支持用%H%M%S最通用。sharedscripts这个参数和postrotate/prerotate配合使用。如果你在配置里用通配符匹配了多个日志文件比如/var/log/nginx/*.log默认情况下每轮转一个文件就会执行一次postrotate脚本。如果脚本只想在所有文件都轮转完之后执行一次加上sharedscripts就能实现。对 nginx 这种场景尤其重要不然转一个文件发一次信号纯粹是多余操作。prerotate和postrotate必须分别和endscript成对出现中间写的就是 shell 命令。顺序是先跑prerotate再执行轮转最后跑postrotate。3. 三个真实场景的完整配置3.1 系统日志 rsyslog 的轮转配置系统日志是所有服务器最基础的一份日志rsyslog 通常已经把轮转规则写在/etc/logrotate.d/syslog里了。不同发行版内容稍有出入CentOS 7 上长这样/var/log/cron /var/log/maillog /var/log/messages /var/log/secure /var/log/spooler { missingok sharedscripts postrotate /bin/kill -HUP cat /var/run/syslogd.pid 2/dev/null 2/dev/null || true endscript }这里的核心是postrotate里的kill -HUP。rsyslog 收到 HUP 信号后会重新打开所有日志文件句柄。因为默认配置是create模式文件名被换了rsyslog 必须重开句柄才能继续写新文件。所以这行信号不是可有可无的少了它messages 日志会闷头写进已经改名的旧文件直到磁盘被塞满都不自知。这段配置还可以帮你理解一件事系统自带的日志轮转脚本为什么这么写背后全是句柄管理的逻辑。3.2 Nginx 访问日志postrotate 里应该发什么信号Nginx 日志的轮转配置在很多教程里都有但见过不少人把postrotate写成了systemctl reload nginx这其实是能用但不够优雅的写法。reload 会重读整个配置文件如果配置有问题可能影响线上服务而且 reload 的开销比单纯重开日志文件要大。Nginx 官方支持的日志重开信号是USR1直接执行/var/log/nginx/access.log /var/log/nginx/error.log { daily rotate 14 compress delaycompress missingok notifempty dateext sharedscripts postrotate [ -f /var/run/nginx.pid ] kill -USR1 cat /var/run/nginx.pid endscript }USR1信号对 Nginx 来说就是重新打开日志文件的专用指令不会重读配置、不会造成 worker 重启代价最小。注意我加了[ -f /var/run/nginx.pid ]判断防止 nginx 没起来的时候脚本报错。再配合sharedscripts所有匹配文件轮转完只发一次信号干净利落。很多发行版打包的 nginx 自带的 logrotate 配置就是这么写的你大可以直接借鉴。3.3 Java 应用日志copytruncate 才是稳妥解Java 应用的日志管理系统和 Nginx 这种原生支持信号的应用完全不一样。大多数 Java 进程用的是 logback、log4j2 这类日志框架日志文件句柄由 JVM 自己持有外部改名文件之后JVM 不会感知也不会自动重开。如果你用create模式轮转 Java 日志大概率会看到日志继续往app.log.1里膨胀新生成的app.log反而一直是空文件。我的推荐方案是直接用copytruncate/opt/awesome-app/logs/app.log { daily maxsize 200M rotate 30 compress delaycompress missingok notifempty copytruncate create 0644 appuser appgroup }等等你说用了copytruncate为什么还写create实际上这两个参数并不是完全互斥的。copytruncate模式下文件被截断但 inode 不变属主属组也不变所以正常情况下不需要create。但有些场景里原文件可能被外部工具改过权限加一行create可以确保截断后新建文件的权限符合预期。如果你确认文件权限没问题create可以不写。这里还要注意一下delaycompressJava 应用在文件被截断之后可能还有一小段输出缓冲在内存里来不及落盘延迟压缩可以把这部分日志保留在未压缩文件中等下次轮转再压。虽然copytruncate本身不改变文件句柄但写日志的时刻和截断时刻的竞争窗口依然存在delaycompress能最大程度减少风险。4. 调试与验证确认配置真正生效配置写完了别急着往生产环境一丢就完事。logrotate 有个特点它平时由 cron 静默执行不报错、不提示你根本不知道它到底有没有按预期跑。所以在改完任何配置之后我都会强制走一遍下面的验证流程。4.1 干跑模式 logrotate -d-d是 debug 模式的缩写也叫 dry run。它不会真的轮转任何文件也不会更新状态文件只是把如果执行轮转会做什么打印出来。这个模式是检查配置语法和逻辑的第一道关卡。logrotate -d /etc/logrotate.conf如果配置里有语法错误比如少了endscript、postrotate配对写错这里会直接报错。输出的内容里重点关注considering log ...和rotating pattern之类的信息它会告诉你每个日志文件当前的轮转条件是否满足、计划执行什么操作。我在改完配置之后几乎一定会先跑一次logrotate -d确认没有报错再上生产。4.2 强制轮转与状态文件核对-f是 force 模式忽略状态文件里的时间记录强制执行一次轮转。这在你修改了轮转周期想让新策略立刻生效时非常有用。但注意别在业务高峰期对核心日志随手-f尤其是create模式会导致应用的日志句柄切换虽然一般不会有问题但能避开还是避开。建议完整操作是logrotate -v -f /etc/logrotate.d/nginx-v是 verbose会打印每个步骤的具体动作。只处理 nginx 这一个配置避免把其他日志也强制转一遍。跑完之后去看状态文件cat /var/lib/logrotate/logrotate.status | grep nginx你会看到 nginx 那行记录的时间已经变成当前时间说明轮转确实发生过了。再回目录里看一眼ls -lh /var/log/nginx/如果看到了access.log-20240315这类带日期的轮转文件说明一切正常。注意-f会更新状态文件所以确认完毕后如果想恢复到正常节奏不用做任何额外操作cron 下次自动执行时会基于这个新状态继续判断。4.3 一套可复制的手动测试流程每次配置新日志轮转我都建议在临时目录里先做一遍完整测试免得直接在生产上搞出乱子。流程大概这样第一步准备测试环境mkdir -p /tmp/logtest touch /tmp/logtest/app.log dd if/dev/zero of/tmp/logtest/app.log bs1M count10这里用dd生成一个 10M 的日志文件模拟真实日志。第二步写一个测试配置文件/etc/logrotate.d/logtest内容故意把轮转条件设得很小方便观察效果/tmp/logtest/app.log { size 5M rotate 3 compress missingok notifempty }因为文件已经超过 5M条件必然满足。第三步先干跑一遍确认没有报错logrotate -d /etc/logrotate.d/logtest第四步强制轮转并查看结果logrotate -v -f /etc/logrotate.d/logtest ls -lh /tmp/logtest/正常的话你会看到app.log变成了新的空文件旁边多出app.log.1以及对应的app.log.1.gz取决于 compress 和 delaycompress 的配置。第五步检查状态文件确认记录已更新cat /var/lib/logrotate/logrotate.status | grep logtest这套流程跑完之后把测试配置从/etc/logrotate.d/logtest删除测试文件清掉生产配置再照着同样的逻辑写好心里就有底了。整个测试下来十分钟都用不了但能帮你把配置里的低级错误全部挡在门外。5. 踩坑实录与排查速查表5.1 日志一直不轮转这是遇到最多的一个问题。配置明明写了daily但日志文件就是死都不切。排查时按顺序查三件事。第一确认 cron 作业在跑。ls -l /etc/cron.daily/logrotate看看脚本还在不在再手动执行一次/usr/sbin/logrotate /etc/logrotate.conf看有没有报错输出。有些服务器上的 cron 服务没启或者被安全策略禁了整个 logrotate 就是瘫痪状态。第二看状态文件的记录时间。cat /var/lib/logrotate/logrotate.status如果显示某个日志文件上次轮转是几十天前而配置是 daily说明条件判断或时间计算出了问题。一个常见诱因是服务器时钟被大改过或者之前有人手动-f过状态文件里的基准时间被刷新了。第三检查配置里有没有周期性参数被覆盖。比如全局写了daily但某个配置块里写了个monthly而你记忆中的规则其实是全局那行。这种情况最好直接logrotate -d看输出里到底按哪个周期在评估。5.2 轮转后权限错乱、应用写不进日志典型的症状是轮转后应用突然报Permission denied看日志文件发现属主变成了root:root而应用进程是以普通用户运行的。根源在于create模式新建文件时默认属主属组是 root。解决方法是在配置里显式指定create 0644 appuser appgroup这里要特别注意appuser和appgroup必须是系统里真实存在的用户和组否则 logrotate 会直接报错。如果你不想每次都被权限问题纠缠也可以用copytruncate模式文件 inode 不变属主属组天然保持原样从机制上就绕开了这个坑。5.3 postrotate 脚本执行异常postrotate 脚本不执行或者执行多次通常都能在sharedscripts这个参数上找到答案。你匹配了多个文件但没加sharedscripts每个文件轮转后都会执行一次脚本。对 rsyslog、nginx 这类服务来说多发几次信号虽然不一定马上出事但没必要。反过来如果有些文件轮转失败脚本也可能跳过导致该重开的句柄没重开。另外一个隐蔽问题是脚本里的路径写错。postrotate 里的命令不会像登录 shell 一样加载完整环境变量如果你直接写了一个用户自定义目录下的脚本路径很可能执行不到。安全做法是写绝对路径并且在脚本开始处把必要的 PATH 也带上postrotate /usr/bin/logger -t logrotate nginx logs rotated endscript5.4 压缩文件损坏压缩出来的.gz文件打开报 CRC 错误十有八九是压缩了正在被写入的日志文件。根源就是没配delaycompress。比如你用copytruncate文件虽然被截断了但应用还可能往同样的 fd 里写东西或者用create但应用没有及时重开句柄日志还在往轮转文件里写此时压缩就会把一个半写入状态的文件给压了。血泪教训凡是你不确定应用句柄切换是否干脆利落的场景一律compressdelaycompress延迟一天压缩也没多大成本但文件完整性就会好很多。5.5 问题速查表症状可能原因解决方向日志一直不轮转cron 没跑 / 状态文件时间被刷新 / 周期条件未触发手动执行 logrotate -d 查看实际判断逻辑磁盘被日志撑满新配的应用没加 logrotate 规则在 /etc/logrotate.d/ 下补齐配置注意 maxsize 硬上限轮转后应用写不进新文件create 默认 root 属主应用权限不足create 0644 appuser appgroup 显式声明属主日志写进轮转的旧文件create 模式但应用没重开句柄改用 copytruncate或 postrotate 里发信号通知应用postrotate 脚本执行多次没有 sharedscripts多个文件各触发一次按需加上 sharedscripts压缩包损坏压缩了正在写入的文件compress delaycompress 组合使用dateext 文件名重复同一天内多次轮转dateformat 加 %H%M%S 或 %s 区分手动 -f 把生产日志转乱了强制执行未考虑业务窗口尽量避开高峰用 -d 先做干跑验证最后说点个人经验logrotate 这个东西吧你说它复杂吗其实配置指令就那么十几个翻一遍 man 手册就全认识了。但它真正考验人的地方全在应用和日志文件的配合关系上。接手一台新服务器我第一件事就是看/etc/logrotate.d/目录里有哪些配置、系统自带的状态文件时间是否正常再有就是把所有日志路径梳理一遍确保没有漏网之鱼。这比装什么监控都管用——日志不爆盘很多半夜的告警压根就不会发生。我自己的习惯是所有自定义配置都放到独立的/etc/logrotate.d/xxx文件里每个文件必须包含missingok和notifempty每次改动之后先-d干跑再-f强制转一次并核对状态文件隔三差五看一眼/var/lib/logrotate/logrotate.status确认所有日志都在按节奏轮转。这套流程走下来日志相关的磁盘事故真的可以绝迹。如果你也遇到过日志文件几百 G 不敢删的尴尬不妨从这套方法入手把 logrotate 这个系统自带的工具真正用起来它会替你省掉大把的运维精力。