Linux日志轮转实战：logrotate配置与优化指南

1. 项目概述：为什么每个Linux运维都绕不开logrotate

要说Linux服务器上最容易被人忽视却又最要命的隐患，日志文件撑爆磁盘绝对排得上号。我刚带团队那会儿，有一次线上告警，某台业务服务器的磁盘使用率直接飙到97%，排查了半天，最后发现罪魁祸首是Nginx的access.log——整整80多个GB，连less打开都卡半天。从那以后，我养成了一个习惯：新服务器上线第一件事，先把logrotate配好。

logrotate这个名字其实很直白，就是“日志轮转”，它是Linux系统里一个专门用来管理日志文件大小和数量的工具。它的核心用途就三件事：把老日志按策略压缩归档、把当前日志按时间或大小切分成新文件、清理过期日志释放磁盘空间。绝大多数发行版都会默认安装，像Ubuntu、CentOS、Debian这些都自带，你甚至不需要额外装任何东西。

对于刚接触Linux的朋友来说，logrotate可能听起来有点陌生，但它其实属于那种“天天在用、只不过你没注意到”的基础设施工具。系统的/var/log/messages、/var/log/syslog、Nginx的access.log、应用的runtime日志，几乎全都是靠它在背后默默打理。而本篇文章要做的，就是把这套日志轮转机制掰开揉碎，从配置语法到实战案例，再到我这些年踩过的坑，一次性讲清楚。

这篇内容适合所有Linux用户和运维工程师，尤其是那些正在被日志膨胀、磁盘告警困扰的人。无论你是刚入门的新手，还是已经写了不少logrotate配置的老手，相信都能从中找到有价值的信息。

2. 日志轮转的核心思路与方案选型

2.1 为什么日志必须轮转，而不是直接删除

很多人会想：日志不用了直接删掉不就完了，为什么还要搞一套轮转机制？这个问题的答案，藏在“日志的多重用途”里。

首先，日志是排查问题的一手资料。线上出了故障，你得从日志里回溯请求链路、找到报错堆栈，但如果日志只有一个文件，它会被新的内容不断覆盖，出事的时候早就不剩什么可查的了。其次，日志在合规审计、安全取证里也是重要依据，很多行业要求日志至少保留6个月以上。第三，如果直接删日志文件，运行中的进程（比如Nginx、Java应用）还会继续往那个已删除的inode里写入数据，磁盘空间不会释放，甚至会造成文件句柄泄漏——这也是新手特别容易踩的坑。

logrotate采用“轮转”而非“删除”的思路，本质上是把日志的生命周期拆成多个阶段：当前正在写的日志、刚切出来的日志（热数据）、压缩归档的日志（温数据）、以及需要清理的旧日志（冷数据），每一阶段都有明确的保留时间和清理策略。这样做既保证了近期的日志可以快速检索，又避免了历史日志无限膨胀，是一种工程上的折中方案。

2.2 主流方案对比：logrotate vs 手动脚本 vs 其他工具

在整个Linux生态里，日志管理不止logrotate一种方案，我归纳了一下，常见的还有这么几类：

从我个人的使用经验来看，logrotate最大的优势在于：它利用了Linux系统自带的cron调度机制，不需要常驻进程，不占额外内存，配置一个文件就能管理同类的所有日志。它的灵活性虽然不如脚本方案，但胜在稳定可靠、标准化程度高。在不需要实时采集的场景下，logrotate是当之无愧的第一选择。

2.3 logrotate的工作流程和原理简析

logrotate本身其实是一个很简单的程序，它的工作原理可以这样理解：系统通过/etc/cron.daily里的定时任务，每天执行一次/etc/cron.daily/logrotate脚本，这个脚本会读取logrotate的配置目录（主要是/etc/logrotate.conf和/etc/logrotate.d/下的配置文件），然后逐条检查每个日志文件的状态，判断是否触发轮转。

判断依据主要有两个维度：一个是时间（例如每天轮转一次），一个是文件大小（例如文件超过100MB就轮转）。哪个条件先满足，就会触发轮转操作。轮转的时候，logrotate会把当前日志文件重命名加编号（比如app.log变成app.log.1），如果设置了压缩选项，还会把app.log.1压缩成app.log.1.gz，然后通知应用重新创建新的空日志文件，或者由logrotate直接创建一个同名的空文件接管写入。

这里有个容易混淆的点：logrotate并不是一个守护进程，它本身不常驻后台。你把它理解成一个“定时触发的批处理工具”更准确，它全靠cron来唤醒，每次运行完就走，不占资源。所以如果哪天你改了logrotate配置却没生效，先别急着怀疑配置语法，很可能是cron调度出了问题。

3. 配置文件结构与核心配置项解析

3.1 配置文件层级：主配置与子配置的分工

logrotate的配置采用“主配置 + 子配置”的层级结构，这个设计非常清晰。主配置文件/etc/logrotate.conf定义全局默认策略，比如默认的轮转周期、是否压缩、日志文件的权限和属主等；而/etc/logrotate.d/目录下的各个子配置文件则针对具体的应用或服务做个性化配置。

举个例子，/etc/logrotate.d/nginx只管Nginx的日志，/etc/logrotate.d/mysql只管MySQL的日志，互不干扰。这样做的好处显而易见：应用通过包管理器安装时，会自带一份logrotate配置放到子目录里，卸载时也会自动清理，不会污染全局设置；同时运维人员排查问题的时候，只需要看对应服务的配置文件就行，不用在几千行的主配置里翻找。这种模模块化管理思路，其实和Ansible、Puppet这类配置管理工具的层级思想是相通的。

3.2 配置指令详解：从daily到postrotate

logrotate的配置指令数量不多，但每个指令都有讲究，我把最常用的几类整理一下。

轮转周期类指令

• daily / weekly / monthly：按天、周、月轮转，这是和cron配合最紧密的指令。注意，如果你设置了hourly，logrotate会读取/etc/cron.hourly下的调度，但这需要额外的脚本支持，不建议常规使用。
• size 100M：按日志文件大小触发轮转，这个指令比较特殊，它优先于时间周期判断——文件只要达到指定大小就会轮转。常和daily配合使用，哪个条件先满足就执行哪个。

文件处理类指令

• rotate 7：保留7个轮转后的旧日志文件，超出数量限制的最老文件会被删除。这个数值直接决定了日志在磁盘上占用多少空间，需要根据业务量和磁盘容量仔细权衡。
• compress / nocompress：是否对轮转后的旧日志进行gzip压缩。压缩能大幅度节省磁盘空间，我实测过一个业务日志压缩率能达到90%以上，但代价是排查旧日志时多一步解压操作。
• delaycompress：和compress配合使用，表示延迟到下一次轮转再压缩。为什么要延迟？因为有些应用在日志轮转之后，仍然会往旧文件里写少量内容（比如还没来得及flush的缓冲数据），等下一次轮转时再压缩，可以确保数据不丢失。
• missingok：日志文件不存在时不要报错，这个指令在管理偶尔才产生日志的服务的场景下特别有用，不会因为一次找不到文件就疯狂往系统日志里刷错误。
• ifempty / notifempty：文件为空时是否也执行轮转，默认是ifempty，但如果日志量很小，建议改成notifempty，避免每天产生一堆空文件。

创建与通知类指令

• create 0640 nginx adm：轮转后创建一个新的空日志文件来接管写入，后面跟权限、属主、属组。这个参数务必保证和应用原先的日志文件权限一致，否则可能出现应用写不进去的故障。
• copytruncate：先复制当前日志文件的内容到旧日志，然后清空当前文件。这个方案不需要应用感知文件切换，适合那些不支持重新打开日志文件的应用。但代价是有数据丢失风险（复制和清空之间存在极短的时间窗口），而且文件句柄不会变化。
• postrotate / endscript：在轮转完成之后执行一段脚本，通常用来给应用发信号，让它重新打开日志文件。比如Nginx需要执行kill -USR1 $(cat /var/run/nginx.pid)，而systemd管理的服务可能需要systemctl reload。

3.3 三种轮转策略的对比与选择

我在实际配置中，最常用的有两种策略组合：一种是daily + rotate N + compress + create，另一种是size 100M + rotate N + copytruncate。这两种策略各有侧重，我做了个对比表：

这里没有绝对的好坏。像Nginx、Apache日志用daily + create最合适，因为这类服务支持信号通知，切换文件无压力；而一些老旧的Java应用、或者用nohup java -jar app.jar > app.log这种简单重定向跑起来的应用，除非用copytruncate，否则信号通知很容易失效，导致日志写到已经被轮转的旧文件里，白白占用磁盘。

3.4 状态文件与调试：dateext和status

logrotate会记录每个日志文件上次轮转的时间，这个记录保存在/var/lib/logrotate/status（某些发行版是/var/lib/logrotate.status）。为什么需要这个状态文件？因为logrotate是每天由cron调用的，它必须知道“上一次是什么时候轮转的”，才能判断今天是否满足daily条件。如果你手动执行logrotate -f强制轮转，也会更新这个状态文件。

另外，dateext这个指令很实用，它让轮转后的日志文件直接用日期命名，比如app.log-20250612，而不是递增的序号app.log.1。这样直观多了，尤其是日志要保留很多天、或者需要追溯某一天问题时，能省不少事。不过要注意，使用dateext后，rotate N的限制依然按文件数量计算，所以你要确保rotate的值不小于日志保留天数，否则日期的文件会被提前清掉。

调试时最常用的命令是logrotate -d（debug模式，只打印执行计划不实际执行）和logrotate -v（verbose模式，打印详细执行过程）。我在调整配置的时候，习惯先-d看计划，再-v看实际执行，配合cat /var/lib/logrotate/status检查状态，基本可以解决90%的疑难杂症。

4. 实战配置：从Nginx到Java应用的完整实现

4.1 最经典的Nginx日志轮转配置

Nginx的日志轮转配置几乎每个Linux运维都会写，但很多人只是从网上抄了一份，并不知道每个参数的含义。我这里给出我日常使用的完整配置，并逐行说明理由：

bash复制cat /etc/logrotate.d/nginx
/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 nginx adm
    sharedscripts
    postrotate
        if [ -f /var/run/nginx.pid ]; then
            kill -USR1 $(cat /var/run/nginx.pid)
        fi
    endscript
}

这套配置的处理逻辑是：每天轮转一次Nginx的access.log和error.log，保留14天，超过14天的压缩归档日志自动删除；轮转后立即将旧日志文件压缩成.gz格式，但在当次轮转时延迟压缩（delaycompress），避免Nginx在信号处理间隙还往旧文件写入少量数据导致丢失；sharedscripts的意思是，所有匹配的日志文件（access.log和error.log）轮转完成后只执行一次postrotate脚本，而不是每个文件都执行一次；postrotate里的kill -USR1是Nginx官方推荐的日志重开信号，它告诉Nginx“旧文件已经切换走了，你重新打开一个新的日志文件来写”。

这里特别提醒：create 0640 nginx adm的属主和权限要和Nginx的worker进程权限保持一致。我见过有人配错属主为root，结果轮转后Nginx直接写不了新日志文件，报Permission denied，线上故障就是这么产生的。

4.2 Java应用日志和copytruncate的使用时机

Java应用（特别是Spring Boot、老式Tomcat）的日志处理，是logrotate配置里最容易翻车的地方。因为Java进程的日志文件句柄在主进程启动时就固定了，除非你在代码里实现了日志重开，否则传统的create方式根本没用——Java还握着旧文件的句柄呢。

解决方案有三种：

第一种，如果你用的是Log4j2或Logback这类支持RollingFile的日志框架，优先在框架层面解决轮转问题，logrotate在这里退居二线，做兜底压缩和清理即可。

第二种，如果你的应用日志是用shell重定向写的（nohup java -jar app.jar >> app.log 2>&1 &），那logrotate必须用copytruncate方案：

bash复制/opt/myapp/logs/app.log {
    daily
    rotate 7
    compress
    copytruncate
    missingok
    notifempty
}

解释一下copytruncate的工作原理：logrotate先把app.log的内容复制到app.log.1（再压缩成app.log.1.gz），然后用truncate -s 0把app.log清空。Java进程从头到尾都握着同一个文件句柄，所以它在清空后会继续往空的app.log里写内容，整个过程应用无感知。

第三种，如果你用的是systemd管理的服务，而且应用框架支持重新打开日志文件，那么postrotate里执行systemctl reload或者发一个定制信号即可。

我个人对copytruncate的建议是：能不用就不用，因为复制大文件有IO开销和“复制期间新日志丢失”的窗口期；但一旦需要用（比如你没法改应用代码），它就是唯一可行的方案。使用的时候把copytruncate的轮转时间安排在日志量相对较小的时段（比如凌晨），可以减少IO峰值。

4.3 使用include与通配符管理多应用日志

当服务器上跑的服务不止一两个时，逐个写配置文件虽然直观，但维护成本上来了。logrotate支持include指令，可以在主配置文件里引入整个目录的配置，这和我前面提到的/etc/logrotate.d/机制是同一个原理。

此外，如果你在同一个目录里有多个日志文件需要统一管理，可以在配置里直接用通配符：

bash复制/var/log/myapp/*.log {
    daily
    rotate 30
    compress
    delaycompress
    create 0640 myapp myapp
    sharedscripts
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

粗体标注的sharedscripts在这里非常关键——它保证多个日志文件在一次轮转周期内只触发一次重载脚本，否则每个文件都触发一次reload，既浪费资源，又有可能导致服务短暂抖动。同理，*.log匹配到10个文件时，如果没有sharedscripts，postrotate会执行10次，这绝对是配置事故。

还有一个容易被忽略的点：配置文件的文件名不要带空格，不要以~结尾，否则logrotate会忽略它。这个坑我踩过，某次从服务器上拷贝配置到本地编辑，文件名带了个~，结果上传回去后一直不生效。

4.4 配置完成后如何验证和手动触发

写完配置不能直接走人，必须验证。我的标准流程如下：

bash复制# 1. 检查语法和计划
logrotate -d /etc/logrotate.conf

# 2. 查看具体某个配置的执行计划（debug模式）
logrotate -d /etc/logrotate.d/nginx

# 3. 强制轮转一次（测试用）
logrotate -f /etc/logrotate.d/nginx

# 4. 查看执行过程详细输出
logrotate -v /etc/logrotate.d/nginx

# 5. 检查状态文件
cat /var/lib/logrotate/status | grep nginx

这里要注意-f参数的潜在风险：强制轮转会无视时间周期，立即执行轮转。如果你在下午手动执行logrotate -f，那Nginx日志会马上被切一次，再等到晚上cron执行日任务时，因为状态文件已经记录了当天轮转过，通常不会再触发。这个行为一般没问题，但如果你的rotate值设得很小，频繁强制轮转可能导致旧日志被提前删掉。

对了，还要检查一下cron任务是否存在：

bash复制ls -l /etc/cron.daily/logrotate
cat /etc/cron.daily/logrotate

正常情况下，这个脚本就是去执行/usr/sbin/logrotate /etc/logrotate.conf。如果你发现这个脚本不存在，说明logrotate虽然装了，但cron调度被人删了——这就能解释为什么你配置半天就是不生效。

5. 常见问题排查与性能调优实录

5.1 日志不轮转的几类典型原因

我在技术支持群里见过最多的问题是：“我明明配了logrotate，为什么日志就是不轮转？”这类问题的排查路径其实很固定，我总结成了一张速查表：

排查时最快的命令组合是logrotate -d -v加tail -f /var/log/messages（或/var/log/syslog），前者看执行计划，后者看运行时是否有报错。logrotate遇到配置错误会把错误信息打到系统日志里，比如error: stat failed多半是文件路径不对，error: permission denied多半是权限问题。

5.2 磁盘空间占用和压缩策略的平衡

日志轮转最核心的诉求就是控制磁盘占用，但控制力度太狠会影响排查便利，太松又会撑爆磁盘。一个我常用的估算公式是：

单日志文件日均最大空间 = 日均日志量 × rotate次数 × 压缩率（未压缩时为1）

举个例子，某个业务日志日均写入500MB，你保留30天，不压缩的话就是15GB；如果用gzip压缩，常规文本日志压缩率大约在10%~20%，也就是1.5GB到3GB。这个数据可以直接指导rotate值的设置。

但这里有个坑——gzip压缩对CPU有一定消耗，尤其是日志量巨大的情况下。如果你在凌晨3点的cron高峰期同时压缩几十个GB的日志，可能造成服务器负载飙升。我的处理策略是：给compresscmd指定nice命令降低压缩进程优先级，或者用compressoptions调整压缩级别。比如：

bash复制compress
compresscmd /usr/bin/nice
compressoptions -n 19 gzip

这行配置的意思是：用nice -n 19来执行gzip压缩，把压缩进程的CPU优先级降到最低，避免影响线上服务。这个方法我实测在Nginx集群和Java应用服务器上效果都很明显，压缩照常进行，但服务响应完全不受影响。

5.3 多服务器环境下logrotate的一致性管理

单台服务器上配置logrotate很容易，但到了几十上百台服务器的集群环境，逐台登录配置就完全不现实了。这时候常用的做法是用Ansible、Puppet或SaltStack等配置管理工具，将logrotate配置文件作为模板统一分发。

我举一个Ansible的playbook片段作为示例：

yaml复制- name: 部署logrotate配置
  ansible.builtin.template:
    src: logrotate_nginx.j2
    dest: /etc/logrotate.d/nginx
    owner: root
    group: root
    mode: '0644'
  notify: reload logrotate

在这个场景下，rotate、daily还是size这些参数可以设计成Ansible变量，不同环境（预发、生产）使用不同取值，这样既保证了配置的一致性，又保留了灵活性。不过需要注意，即使配置文件能自动分发，logrotate本身的调度时间还是受各服务器cron控制，如果你的日志轮转要求精确到小时或分钟，就得考虑Lsyncd这类工具或自研调度器来统一执行logrotate -f了。

老实说，多服务器场景下用logrotate有一种“够用但不够优雅”的感觉。如果日志需要集中检索，最终还是要引入ELK或Loki这类日志采集系统，logrotate退化为一个“防止单机日志无限膨胀”的兜底措施。但从成本和简单可靠的角度来看，它依然是绝大多数场景下性价比最高的选择。

5.4 定制轮转脚本与特殊场景处理

logrotate的postrotate和prerotate两个指令给了运维人员很大的定制空间。prerotate在轮转之前执行，可以用来冻结应用写入（比如暂停队列、发送状态快照），postrotate在轮转之后执行，用来恢复业务或通知应用切换文件。

举一个MySQL慢查询日志的例子：

bash复制/var/log/mysql/mysql-slow.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    create 0640 mysql mysql
    postrotate
        if test -x /usr/bin/mysqladmin; then
            mysqladmin --defaults-file=/etc/mysql/debian.cnf flush-logs
        fi
    endscript
}

这里的关键是mysqladmin flush-logs，它会告诉MySQL关闭当前日志文件并重新打开一个新的。如果不执行这个命令，MySQL进程会继续往已经改名的旧文件里写内容——这又是文件句柄问题。

还有一类特殊日志：应用日志格式虽然统一，但文件数量动态变化（比如每个租户一个日志文件），这时候可以将日志文件放在一个目录下，用目录加通配符的方式：

bash复制/data/logs/tenants/*.log {
    daily
    rotate 7
    compress
    missingok
}

但这种方式有个隐患：如果某个租户被删除，日志文件被清掉，logrotate依然会尝试匹配，missingok可以避免报错，但没法自动清理掉孤立的状态文件条目，时间长了状态文件会膨胀。解决办法是定时清理status文件里已不存在的日志路径，或者定期重启logrotate服务。

6. 经验总结：logrotate进阶优化和团队落地建议

6.1 监控告警和自动化检查：别等磁盘满了才发现

logrotate用得再熟练，也难免有配置失误或者极端情况。我建议把logrotate的运行状态纳入监控体系，每天检查一次。

最简单的做法，是在cron里加一个检查任务，如果logrotate执行失败就发告警：

bash复制#!/bin/bash
# /usr/local/bin/check_logrotate.sh
if ! /usr/sbin/logrotate -d /etc/logrotate.conf > /dev/null 2>&1; then
    echo "logrotate配置检查失败" | mail -s "Logrotate Error" ops@example.com
    exit 1
fi

# 检查日志目录占用
du -sh /var/log/nginx /var/log/myapp | awk '$1 ~ /G/ {print $2 " usage: " $1}'

正常情况下，如果某个日志目录占用超过几个GB，就得人工确认是不是轮转失效了。如果日志目录增长速度极快（比如单个日志一天几十GB），建议用systemd-timer或者cron每6小时检查一次，不要等24小时的daily任务跑完才发现。

6.2 测试环境验证与灰度发布：配置变更也要走流程

logrotate配置文件看似简单，但一个错误的create权限或者一个postrotate脚本漏了endscript，都可能导致服务不可用。所以，我的建议是：所有logrotate配置变更，必须先在一个测试服务器上验证，再批量推送生产。

验证的步骤很简单：

1. 在测试服务器上放一份真实的日志文件（可以从生产环境拷贝一段时间的日志）；
2. 手动执行logrotate -f强制轮转；
3. 检查轮转后的文件目录结构、权限、内容完整性；
4. 确认应用服务没有报错，日志能正常写入新文件；
5. 观察/var/log/messages和状态文件，确保没有异常记录；
6. 在生产服务器上分批次应用，先单台，再全量。

如果在多人协作的团队里，配置文件建议纳入Git仓库管理，提交记录里写清楚变更原因。后续审计和排障时能省很多力气。

6.3 我的实践心得：最值得记住的几条红线

最后说几句掏心窝子的话。logrotate配置本身不难，但细节决定成败，我总结了下面几条红线，希望能帮你少走弯路：

第一，永远不要在生产环境直接使用logrotate -f强行轮转未测试过的配置。哪怕你对语法的掌握再自信，也要先在测试环境跑一遍，因为postrotate脚本里的任何错误都可能带来意想不到的连锁反应。

第二，copytruncate方案虽然方便，但要清醒认识到它的数据丢失窗口，日志量很大的场景谨慎使用。如果应用本身支持日志重开，优先用create方式。

第三，配置文件命名不要用中文、不要带空格、不要用~结尾。保持全英文小写加下划线，是Linux生态里的基本素养，也是避免诡异问题的最佳方式。

第四，别忘了检查cron服务本身是否在运行。很多公司为了安全加固会把cron关掉，这直接导致logrotate停摆。我遇到过一个案例，客户服务器上所有cron任务都失效了半年多，日志把磁盘全部塞满，而他们还在怀疑是logrotate配置写错了。先检查基础服务，再检查应用配置，这个排查顺序永远有效。

第五，如果服务器上同时运行了多个应用，建议把它们的logrotate配置独立成文件，并且在每个文件里都加上sharedscripts参数。否则，随着日志文件数量的增长，postrotate脚本被执行多次的风险会显著上升，而配置里的sharedscripts就像是一个保险，能有效避免这个问题。

7. 拓展思考：logrotate与日志采集系统的协同

7.1 日志采集场景下logrotate如何配合Filebeat或Loki

前文提到，日志量大的场景最终还是会引入集中日志系统。那么logrotate会不会被替代？我的答案是：不会，它在日志采集架构里依然扮演着“文件生命周期管理”的角色。

以Filebeat为例，它的工作原理是监控日志文件的内容变化然后发送到Elasticsearch。当logrotate把app.log重命名为app.log.1并压缩成app.log.1.gz时，Filebeat需要感知到这一变化，才能决定是继续读取还是跳过去。现代版本的Filebeat对logrotate的copytruncate和create两种模式都做了适配，会自动处理文件切换。但压缩后的.gz文件，Filebeat默认不会读取。这就意味着，你的业务日志如果被logrotate压缩得太快，可能会错过仍在缓冲中的数据。

解决思路是：compress和delaycompress配合使用。delaycompress让当前轮转的日志文件先不压缩，等到下一次轮转时再压缩，这样Filebeat有足够的时间读取完app.log.1内容，然后才看到它变成app.log.1.gz。这也是为什么官方配置模板里写delaycompress的原因之一。

而Loki这类轻量级日志采集系统，通过Promtail或Grafana Alloy采集日志，策略也类似。在配置采集器的同时，一定要把logrotate策略同步设计好，避免“日志采集还没读走，文件就被压缩或删除了”的问题。我的建议是：采集引擎的处理延迟要大于日志轮转的间隔，或者直接关闭压缩，让采集完成后再定时清理。

7.2 高并发下日志切割的IO优化

高并发业务下，日志文件的写入压力本身就大，轮转操作又会带来额外的IO开销。这个矛盾在凌晨的集中轮转时段尤其明显。

优化的思路有几种：

第一，错峰轮转。logrotate的daily任务在每台机器上是同一时间触发的（通常早上6:25左右，具体看/etc/crontab里的设置）。可以通过修改cron配置，让不同服务器的轮转时间错开，避免所有服务器同时IO飙升。

第二，使用size触发代替daily触发。高并发场景下，日志文件可能在几小时内就超过100MB，这时候按天轮转已经无法满足控制文件大小的目标。改用size 200M可以让轮转分散到一天中的不同时间，削峰填谷，IO压力更均匀。

第三，将日志文件放到单独的磁盘分区或SSD上，与系统盘隔离。这样即使轮转压缩时占满IO，也不会影响业务进程读取代码和写入其他临时文件。

第四，利用compressoptions降低CPU占用。gzip压缩等级默认是6，如果你对压缩率要求不高，可以用compressoptions -n 1降到最快速度，CPU节省效果显著。

7.3 未来方向：从logrotate到现代日志策略

讲到这里，有人可能会问：既然日志管理如此重要，未来有没有更现代的方案？

我认为logrotate在短期内不会被淘汰，因为它的简单和稳定是很多复杂系统难以替代的。但现代日志策略的演进方向，确实在向“轻量化、实时化、结构化”迈进。比如用Vector或Fluent Bit直接采集并转发日志，在源端完成解析和过滤，减少落盘依赖；或者在容器环境中，让日志直接输出到stdout，由容器运行时负责采集和清理，绕开了传统文件日志的轮转问题。

但即便是容器环境，当你需要挂载持久化卷保存业务日志时，logrotate依然会派上用场——只不过配置方式变了，变成在sidecar容器里跑一个logrotate，或者利用Kubernetes的日志轮转策略。

对我来说，工具永远是为了解决问题而存在的。logrotate的优雅之处，在于它用最小的成本解决了日志膨胀这个大问题，并且留下了足够的扩展空间。你在深入使用它的过程中学到的配置管理、权限设计、cron调度这些底层知识，比工具本身值钱得多。把这些基本功打扎实，以后无论面对什么新工具，都能很快上手。