计算节点日志轮转配置得当，是防止磁盘被日志写满、保障节点稳定运行的最直接手段，核心思路就是“按大小或时间切分、按策略清理、按目录隔离”。
日志轮转为什么是磁盘的“最后一道防线”
很多运维朋友都遇到过这种场景：某天下午监控告警，说某台计算节点的磁盘使用率超过了90%，登录上去一看，/var/log/messages 或者某个应用的 out.log 已经膨胀到了几十个GB，df -h 显示根分区快要被撑爆了，而这个过程往往就发生在几小时之内。
如果日志没有轮转策略,就相当于让服务进程无限制地往同一个文件里写数据，日志文件一旦变成超大文件，会有两个直接后果，第一是磁盘被写满，导致节点上所有依赖磁盘写入的操作失败，比如数据库落盘、临时文件创建、甚至核心进程直接崩溃，第二是排查问题变难，grep 一个几十GB的文件进行故障定位，效率极低，vi 或 less 打开都会卡顿。
日志轮转就是通过一套既定的规则，在一个日志文件达到特定条件时，把它改名备份，然后让原服务重新创建一个新的空日志文件继续写入。 这个过程不仅能控制单个文件的大小，还能通过设置保留份数来清理最旧的归档日志，从而把磁盘占用稳定在一个可控范围内。
日志轮转怎么设置：先搞懂rotate、compress和dateext的配合
在实际配置中,绝大多数Linux发行版都默认集成了 logrotate 工具，它是目前管理日志轮转的事实标准，配置主文件在 /etc/logrotate.conf，而具体的应用配置则放在 /etc/logrotate.d/ 目录下。
一套合理的日志轮转设置,核心是解决“什么时候切”和“切完留多少”的问题，以下三个参数是必须明确的：
- rotate 份数：指定保留几个归档日志文件。
rotate 7就表示保留最近7天的归档，超过7个旧文件，最老的那个就会被自动删除。 - 按大小触发：使用
size 100M参数，当单个日志文件达到100MB时，立即触发轮转，不等待固定时间周期。 - dateext 加时间戳：使用
dateext参数，归档文件名会带上日期，app.log-20260312，这比默认的app.log.1更容易对照时间定位问题。
还有一个经常被忽略、但对磁盘保护很关键的参数是
compress，它会对归档的日志进行gzip压缩，通常压缩率能达到 90%以上，一个100MB的文本日志，压缩后可能只剩不到10MB，日志量大的计算节点，开启 compress 能显著降低磁盘占用。
服务器日志占满磁盘时，为什么很多团队还在裸奔
行业共识认为,大约有 相当一部分 的中小规模计算集群，日志轮转配置是不完整的，或者根本没有配置，出现这种情况，通常不是因为技术人员不懂 logrotate 的语法，而是因为对“日志增长速度”缺乏准确的预判。
举个例子：一个跑着Java服务的计算节点，如果开启了 info 级别日志，并且业务量在某个时段突然增大，日志文件每小时可能增长1GB，如果只配置了 daily 按天轮转，那么这个文件在24小时内就会膨胀到24GB，在深夜业务低峰时段，磁盘可能还够用，但一旦到了白天高峰期，磁盘会迅速告警。
还有另一种典型场景：应用自身不写系统日志，而是把日志输出到自定义路径，/data/logs/，如果应用框架本身不支持日志切割，运维又没有把这个路径单独交给 logrotate 管理，那么这个目录下的日志就会无限增长。在排查“磁盘神秘被占满”的问题时，检查非标准路径下的日志文件大小，是第一步该做的事。
logrotate和直接写脚本清理相比，哪种方式更可靠
有些团队会写一个简单的crontab脚本,用 find 命令删除7天前的日志文件，这种做法虽然能释放磁盘，但存在一个隐患：删除正在被进程写入的日志文件，不会真正释放磁盘空间。
在Linux系统中,如果一个文件被某个进程打开，即使你用 rm 把它从目录中删除，只要进程没有关闭这个文件句柄，那么这块磁盘空间依然会被占用，直到服务重启，这会导致一个很反直觉的现象：df -h 显示磁盘还是满的，但 du -sh 查看所有目录却找不到那个“消失”的文件。
而 logrotate 的 copytruncate 参数能解决这个问题，它的工作原理是先复制日志文件的现有内容到归档文件，然后立即将原日志文件截断，也就是清空为0字节，服务进程持有的文件句柄依然有效，指向的是被截断后的空文件，因此不需要重启服务也能完成日志切割，同时还能真正释放磁盘空间。
对于不支持 copytruncate
的严格场景，以及对于数据库等对文件写入一致性要求极高的应用，通常采用 create 模式，即先改名旧日志，再新建一个同名日志文件，然后通过信号通知应用重新打开日志文件，这种方式在行业内广泛应用于Nginx、Tomcat的日志处理，可靠性远高于纯手写脚本。
多节点日志集中管理：预算有限情况下为磁盘减负的设计方案
如果你管理着多台计算节点,为每台机器单独配置 logrotate 规则虽然是基本功，但在运维效率和磁盘空间规划上会显得比较被动，业内专家指出，针对日志量较大的生产集群，分阶段规划比首次就搭建很多公司力推的重型采集系统要实际得多。
配置方案不必一开始就引入付费的商业日志平台,针对计算节点磁盘空间有限、又不希望额外购买昂贵存储的情况，可以使用“本地轮转 + 远端rsyslog集中转发”的组合，本地保留一份最少的归档（比如只保留3天的压缩日志），同时通过 rsyslog 的转发规则把完整日志实时同步到一台专用于日志存储的服务器上。
在涉及价格成本的考量时,这个方案的性价比最高：本地节点无需大容量磁盘，存储服务器可以用普通大容量机械硬盘组建，整体采购成本较低，对于身处上海张江等地的互联网企业，自建这套基于rsyslog的集中转发方案，无需支付额外的SaaS日志服务订阅费用，且没有数据出域的安全顾虑。
实际操作：排查节点日志轮转异常的三个必查点
如果当前节点磁盘告警,在设置好轮转之前，先执行以下三个检查，可以快速定位问题：
- 检查
logrotate是否真正被执行：查看/var/log/status文件，这个文件记录了logrotate上次运行的状态，如果找不到对应配置项的记录，说明配置文件可能没有生效，或者由于权限问题被跳过了。 - 检查配置文件的语法：执行
logrotate -d /etc/logrotate.conf，这是调试模式，它会模拟运行整个轮转过程，并打印详细的执行动作和报错信息，注意，使用-d参数时不会真正改动文件，只做演练。 - 手动强制尝试轮转：执行
logrotate -f /etc/logrotate.conf，-f参数会强制触发轮转，即使日志文件还没达到轮转条件，这常用于测试配置是否正确，强制轮转后，立刻查看归档文件是否生成、原日志文件大小是否为0，如果权限不足导致失败，记得检查
/var/log/
syslog或messages的写权限。
在管理数百台计算节点时,建议把 logrotate 配置统一纳入配置管理工具（如Ansible、SaltStack）的分发列表中，确保每台机器的轮转规则一致，避免出现有的节点轮转正常、有的节点磁盘悄悄写满的“破窗效应”。
计算节点日志轮转异常时，如何快速诊断磁盘空间去向
日志轮转虽然能保护磁盘,但轮转本身也可能“失效”，当发现某节点磁盘空间还在持续下降时，直接使用 lsof | grep deleted 命令，可以精准定位那些被进程占用但已经被删除的文件，这个命令的输出会列出进程PID和对应的已删除文件路径，找到PID后，在 /proc/PID/fd/ 目录下可以找到该文件句柄的符号链接，通过查看该链接指向的文件大小，能确认是不是日志文件没有真正释放空间。
如果是这类问题,最稳妥的解决路径是：修改策略、触发一次轮转、然后在业务低峰期重启对应服务进程，让文件句柄正常关闭，如果不方便重启，可以使用 truncate -s 0 /proc/PID/fd/文件描述符 方式强制清空句柄指向的磁盘块，但这操作有风险，需要谨慎评估。
日志轮转策略是否影响节点性能
这主要看两个参数。copytruncate 在复制大文件时会短暂占用较高的I/O带宽，如果节点上的业务本来已经占满了磁盘I/O，在日志轮转的瞬间，磁盘响应时间可能上升，建议将轮转时间设置在业务低峰期，比如每日凌晨3点左右，通过 cron 执行，对于追求极致性能的节点，可以考虑给日志目录挂载单独的分区（/var/log 挂独立盘），这样即使日志写满，也不会拖垮系统根分区，保护效果更好。
日志文件的保留周期如何确定
不是保留的越多越好,保留周期需要结合安全合规要求和磁盘容量综合判断，如果机器只用于短期计算任务，保留7天压缩日志足够；如果是涉及财务、用户行为分析的节点，建议保留30天以上，确定保留周期的思路是：先统计当前日志的日增量，估算出给日志预留的磁盘空间大小，再反推最多能保留多少天的归档，在 /etc/logrotate.d/ 中配置 rotate N 参数时，N的取值必须与磁盘空间上限匹配，而不是随手写的天数。