凌晨两点手机连着震了三下。我迷迷糊糊划开屏幕看到监控面板上某业务服务A所在主机的磁盘使用率已经冲到98%再过半小时就得写满。这种告警一年多少要碰上几回但这次有点反常——前天才刚做过一次大清理磁盘明明还剩60%空间怎么一夜之间又满了爬起来登录服务器df -h一看/var/log 目录像被什么东西一口气灌满了。顺着du -sh /var/log/*查下去一个熟悉的 app.log 文件已经膨胀到 80 多G还在以肉眼可见的速度增长。这是一次极其典型的日志增长吞掉磁盘的事故也是我处理过的案例里最值得写下来复盘的一次。整个过程涉及文件句柄、日志轮转机制、inode 耗尽、journald 独立治理等多个环节每走一步都踩到了常规文档里不会写清楚的坑。这篇就按照我当时完整排查到收尾的顺序把定位思路、logrotate 配置细节、后续监控改进全部掰开讲一遍希望能帮同样被日志打爆磁盘的人少走一点弯路。1. 磁盘告警那晚从 100% 占用到定位日志元凶1.1 告警现场与第一波排查命令进了服务器之后我没有直接去看日志目录而是先做了一套标准的三连排查这个顺序很重要能帮你快速判断是文件占空间还是被删除文件未释放空间。# 第一看磁盘整体情况 df -h # 第二看哪些目录占了大头 du -sh /var/log/* 2/dev/null | sort -rh | head -20 # 第三看有没有已经被删除但仍旧被进程占用的文件 lsof | grep deleted | head -30第一眼df -h显示/根分区已经满到 98%/var 挂载点同样告急。du -sh /var/log/*的结果里app.log 独占 80G 多简直像个小水库。第三项lsof | grep deleted没有输出说明不是删了没释放的经典问题磁盘空间确实是被这个文件真实占据了。我当时的第一反应是直接删掉 app.log 先止损。幸好手停了一下因为直接rm是有隐患的——如果那个应用进程还在持续写入这个文件删除之后空间并不会立刻释放只有句柄关闭后空间才能回来而且文件会变成幽灵文件后续日志轮转也没法正常工作。正确做法是先确认哪个进程在写再决定怎么处理。1.2 为什么日志会在一夜之间吃掉半个磁盘八十多G一个文件光靠正常业务日志很难堆到这种量级。我先看了写入进程确认是服务的主进程在持续往 app.log 里追加数据。然后我用tail -n 200 app.log扫了一眼日志内容发现几乎全是同一类报错刷屏每隔几百毫秒就喷几条堆栈信息每条一两KB。算一笔账假设平均每秒写入 30 条、每条 1.5KB一天就是 30 × 1.5KB × 86400 秒约等于 3.8GB 左右。但如果应用本身遇到某种故障循环比如连接池反复重试、某个下游接口持续超时日志频率可以翻几倍——每秒写个几十条甚至上百条都很正常80G 一晚上完全可能。这里要引出第一个容易被忽略的为什么为什么排障的时候日志会突然这么猛排查后发现是服务在凌晨被流量波动触发了一个异常分支某个模块进入了死循环式重试每次重试都带着完整参数和堆栈打日志。代码里没有做频率限制也没有熔断降级日志就变成了无底洞。单纯把日志文件删掉或者清空外部流量还在涌入问题根源没解决日志会立刻再次膨胀。所以我的处理分两步第一步暂停这个异常模块的流量或者重启进程让日志喷涌先停下来止损第二步才是把现有大文件归档、清理、配置轮转恢复和预防。这个案例充分说明了一个核心原则日志治理的第一优先级是控制日志产生速率而不是控制日志存储空间。没有这个认知你做再多轮转配置也只是把爆炸时间点往后推。2. 日志轮转的底层逻辑rotate、compression 与延迟删除2.1 logrotate 的触发链路止损之后磁盘虽然腾出来了但我知道不把轮转机制补齐这种事迟早还会重演。Linux 生态里处理日志轮转的标准工具就是 logrotate绝大多数发行版都默认安装了它。它的工作机制并不复杂系统每天或每周定时触发一次 logrotate 主流程主流程读取/etc/logrotate.conf和各应用放在/etc/logrotate.d/下的碎片配置然后按每个配置里声明的规则对日志文件执行重命名、压缩、删除旧文件等动作。一条日志文件从产生到被轮转掉完整生命周期大致是这样应用把日志写入 app.loglogrotate 到点被触发把 app.log 重命名成 app.log.1应用继续写入一个新建的 app.log或者继续写被重命名的文件取决于轮转模式下一个周期到了app.log.1 变成 app.log.2新的 app.log 又重命名成 app.log.1设置保留 N 份那么第 N1 份会被自动删除或者压缩之后删除。这里的核心参数是rotate N、daily/weekly/size、compress、delaycompress和copytruncate。我见过不少配置文档大多只是在写参数是什么但真正决定轮转行为成败的恰恰是这些参数之间的组合关系尤其copytruncate和create的选择搞错了会引出完全不同的坑。2.2 copytruncate 与 create 的权衡logrotate 有几种工作模式最常见的是create和copytruncate。create模式是重命名加重建。logrotate 先把 app.log 重命名为 app.log.1然后在原位置新建一个空的 app.log接着信号通知应用重新打开日志文件。这套逻辑干净利落文件句柄指向新文件不会丢数据。但前提是应用必须能响应信号并重新打开文件。很多应用没有做这个处理结果就是文件被重命名了进程仍然握着旧文件句柄继续往 app.log.1 里写新的 app.log 反而是个空壳。日志越轮转越乱排查问题的时候你都不知道数据到底在哪个文件里。copytruncate模式就粗暴不少。它先把 app.log 复制一份成 app.log.1然后通过truncate把原 app.log 截断为 0应用之前持有的文件句柄不失效继续往同一个 inode 里写但这个 inode 指向的文件已经被清空了所以不会出现数据写到旧文件的问题。代价也很明显复制和截断之间存在一个时间窗口。如果日志写入非常频繁这个窗口内的日志会丢失虽然通常只有毫秒级或者几十毫秒级的量但对日志完整性要求极高的场景需要评估这个损失。另外copytruncate在复制大文件时会占用大量 I/O一个 80G 的文件去复制CPU 和磁盘的瞬时压力都非常大这一点在生产环境里必须提前考虑。我当时那套场景进程是一个自己封装的 Java 服务虽然理论上它响应了 USR1 信号就能重新打开文件但由于进程是通过一个脚本启动的信号转发链路没打通用create模式反而容易出岔子。稳妥起见我选择了copytruncate。如果你要问我经验除非你能确认应用会响应信号并重开日志文件否则生产环境优先用copytruncate日志丢掉的那一点点窗口数据比你整个日志体系混乱要划算得多。3. 让轮转配置落地一份可以直接抄作业的配置3.1 配置逐行拆解下面这份配置是我在多个环境里验证过的写法适用于大多数单进程写单个日志文件的服务无论是 Java、Go、Python 还是 Node 都通用。你只需要把/data/logs/app/app.log替换成你实际路径。# /etc/logrotate.d/app /data/logs/app/app.log { daily rotate 7 maxsize 500M missingok notifempty compress delaycompress copytruncate dateext dateformat .%Y%m%d-%H%M%S extension .log su root root }逐个解释一下因为照着抄是小事理解了随时能改才是关键。daily表示每天轮转一次。配合后面的maxsize实际规则是每天至少轮转一次但如果文件提前达到 500M立即触发轮转。这个组合非常适合日志量不稳定、可能突然暴涨的服务。rotate 7表示保留最近 7 份轮转文件。加上昨天的原始文件一共 8 份配合压缩策略磁盘占用基本可控。missingok是指文件不存在时不要报错退出避免日志服务没启动时长目录屁用没有却天天报警。notifempty是文件为空时不轮转。防止某些低频服务在日志没有任何内容时也频繁触发轮转。compress开启压缩默认使用 gzip。80G 文本日志压缩完可能只有几G效果立竿见影。delaycompress会推迟一份再压缩。它的意义在于很多服务可能会在轮转后继续往 app.log.1 写入一点尾部内容比如旧句柄的残留数据延迟一天压缩能把这些零碎内容也收进去避免丢失最后那几百毫秒的日志。这个参数配合copytruncate尤其重要可以弥补复制截断窗口期的数据损失。copytruncate前面讲过这是保障进程不需要重启的关键参数。dateext给轮转文件加上日期后缀而不是默认的.1、.2。这样文件名看起来是 app.log.20250516-023000.log查找某一天的日志非常直观而且避免了文件重命名时同名覆盖的风险。su root root是指定 logrotate 以 root 身份执行文件操作。如果你的日志目录属主是别的用户请改成su 用户名 用户组否则会出现权限不足的诡异问题。3.2 手动强制执行与验证闭环配置写完后不要干等第二天先手动执行一次验证语法和权限是否正常。这个动作叫试运行很多第一次用 logrotate 的人会漏掉# 先看配置语法是否正确 logrotate -d /etc/logrotate.d/app # 再强制执行一次-f 强制忽略 daily 等时间条件 logrotate -vf /etc/logrotate.d/app-d是 debug 模式会打印出 logrotate 准备执行的动作但不会真实执行。确认无报错后再加-v -f强制执行。执行完立刻去看日志目录ls -l /data/logs/app/看到类似这样的输出就说明轮转闭环成功-rw-r--r-- 1 root root 500M May 16 02:30 app.log -rw-r--r-- 1 root root 480M May 15 02:30 app.log.20250515-023000.log -rw-r--r-- 1 root root 460M May 14 02:30 app.log.20250514-023000.log.gzapp.log已经是新建的 0 字节文件应用进程还在正常运行没有重启app.log.20250515-023000.log还没被压缩昨天的delaycompress 生效更早的已经变成.gz。这就对了。这里我想额外分享一个经验配置完轮转之后一定要用日志量最大的一天来验证压缩效果和保留策略。我曾经在另一个项目上配置了rotate 3当时日志每天才 200M觉得三个文件绰绰有余。结果一个月后业务翻了几倍日志量涨到每天 1G 多三个压缩文件加原始文件都快把 /var 撑爆了被迫紧急调整保留份数。所以配置数字不是拍脑袋定的你可以这样估算占用保留文件总大小 当前原始日志大小 × (1 1/压缩比 × rotate 份数)如果原始日志每天 500M、gzip 压缩比大约 10:1、rotate 7那么磁盘占用大约是 500M 7 × 50M 850M 左右在可控范围内。日志量大的服务可以把rotate调小、把maxsize调低甚至把daily改成按小时轮转核心原则是总占用不能超过你预期的水位。4. 轮转之外的隐性坑inode、journald 与多副本日志4.1 inode 耗尽比磁盘满更隐蔽配置好轮转之后我以为事情告一段落但正好借着这次机会把同一台服务器上另一类隐患也查了一遍其中一个就是 inode 耗尽问题。磁盘空间满和 inode 满经常被混为一谈但它们其实是两回事。磁盘满意味着数据块不够了inode 满意味着文件系统里索引节点耗尽了即使磁盘还剩很多空间你也无法新建任何文件。很多文件系统默认每 16KB 左右的容量才分配一个 inode如果上面全是几十字节的小文件很容易把 inode 池耗光。排查方法很简单df -i如果 IUse% 接近 100%你就知道问题不在空间而在文件数量。有次我在另一个环境就撞上过这种情况临时目录里堆积了上千万个未清理的 socket 文件磁盘使用率才 20%但没有任何进程能创建新文件了服务全部卡死。场景不同本质完全一样。回到日志场景为什么 logrotate 也会制造 inode 压力因为轮转本身就是不断创建新文件的过程每个日志文件都要占一个 inode。如果rotate设置得很大且轮转频率很高几天之内就会生成大量小日志文件。加上如果不配置dateext而是用默认编号、某些服务还在同一个目录下按 PID 或者按时间戳拆多个日志文件inode 消耗就会更加失控。所以建议运维同学把df -i也加到日常巡检脚本里这个指标和磁盘使用率一样重要却几乎没人看。4.2 journald 日志的独立治理排查那台服务器的时候我还顺手发现 systemd 日志目录/var/log/journal/也占了几个G的空间。很多部署在 systemd 下的服务如果没配置 stdout 日志重定向日志会直接进 journald而不是写到你业务配置的文件里。这意味着你会同时有两套日志体系业务日志归 logrotate 管journald 的日志走它自己的配额策略互不干扰但空间占用是叠加的。journald 默认的配额策略曾经有版本差异某些版本在系统盘大的时候会允许 journal 目录一直涨到跟系统盘容量挂钩的比例这个值如果没限制几十个G也不是不可能。限制方式是在/etc/systemd/journald.conf里显式加规则[Journal] SystemMaxUse2G SystemMaxFileSize200M MaxRetentionSec14d其中SystemMaxUse2G是所有 journal 文件加起来最多 2GSystemMaxFileSize200M限制单个日志文件大小MaxRetentionSec14d表示只保留 14 天的日志。改完配置后记得重启服务systemctl restart systemd-journald有同学会担心重启 journald 会不会影响正在跑的业务一般来说不会journald 重启后旧的日志文件还在只是它会按新的配额策略开始清理超龄和超量的日志。这是我强烈建议你在每台 systemd 主机上都加的一段配置尤其是根分区不大的机器经常遇到业务日志还没占多少空间journal 反而把 /var 吃满了这种事。4.3 不要忽略同一应用的多写者问题最后还有一个非常隐蔽的坑是我在调整完 logrotate 之后继续观察时才想到的如果同一个日志文件同时被多个进程写入轮转的copytruncate模型就会产生撕裂问题。什么叫多写者比如某个应用通过 supervisor 之类工具被拉起了多个 worker 进程它们都往同一个 app.log 追加日志。另外有些部署形态里会有日志采集 Agent 同时读取这个文件并转发到远端。这种情况下 logrotate 复制文件、截断原文件时其他进程可能正拿着旧的文件句柄或者正在读取某个偏移位置日志数据就可能在轮转时被切得七零八落甚至出现轮转后某几个进程还在往旧 inode 里写几个小时的现象。解决思路无非几种一是从源头统一写日志路径确保一个进程一个日志文件不要乱共享二是如果必须共享考虑采集层用更完善的文件追踪方案而不是依赖copytruncate轮转三是日志量允许的话让应用自己按大小主动切割日志文件logrotate 只负责压缩和清理归档文件业务层切割永远比外部工具周期触发更及时。这个多写者问题平时不太显眼但它发生的时候排障体验非常痛苦。你按时间线查日志发现中间有将近一个小时的记录出现在昨天轮转走的压缩包里而今天的文件里却有一段空白你会误以为业务出了故障。实际上就是文件句柄和轮转之间的错位造成的。所以从第一天设计日志采集方案的时候就要把谁在写、谁在读、谁来切这三件事想清楚不要都让 logrotate 兜底。5. 事后复盘监控阈值与告警分级的调整5.1 从磁盘满到趋势预测的告警设计问题解决后我做的第一件事是回顾那晚为什么会被动挨打。凌晨两点收到告警意味着这个状态已经持续了好几个小时如果早点发现趋势处理成本会低得多。原来的监控策略是磁盘使用率超过 90% 才触发告警但这本质上是一个事态发生后的告警等它响起来你能操作的时间窗口已经很窄了。我把告警策略调整成了三级级别触发条件响应动作预警磁盘使用率 24 小时环比增长超过 10%检查是否有异常文件增长次要告警磁盘使用率超过 75%计划性清理、扩容评估紧急告警磁盘使用率超过 90%立即处理在实际操作里我还加了两个非常有用的监控维度。第一实时监控/var/log下最大的三个文件的增长速度而不是只盯分区使用率。这个指标能直接暴露哪份日志在异常膨胀为排障省掉一半时间。第二给日志目录的文件总数设置告警基线一旦 inode 数异常飙升就提醒防止触发 inode 耗尽的次生灾害。5.2 快速恢复与长尾优化的平衡回归到事故处理本身还有一个思路值得做既然日志量的暴涨几乎总是和业务异常强相关那么在轮转机制之外还应该加一道日志写入限流的保险。这个思路说起来也不复杂很多语言都提供了日志库限流能力。比如 Java 的 logback 可以配置SizeAndTimeBasedRollingPolicyPython 的 logging 可以做 handler 级别的缓冲和丢弃策略。限流的目标不是丢掉所有日志而是在异常流量爆发时保证日志系统自身的稳定性同时保留足够多的关键上下文用于排障。我当时的做法是在服务里加了一个单日日志熔断配置如果某个 logger 在 1 分钟内写入了超过设定条数的日志后续日志进入采样模式只保留前 N 条和堆栈摘要其余丢弃或计数。这个策略上线后那台服务器的磁盘使用率曲线从「偶尔冲高、经常告警」变成了「持续平缓」效果非常明显。最后再回到配置本身的一个小细节。maxsize 500M这个值需要结合你服务的实际日志量调整如果日志每天稳定在 100M 左右设成 500M 就是空摆设每天轮转一次足够如果日志经常在几分钟内冲到几Gmaxsize反而是第一道防线触发得越早越安全。我在另一个约 60 个节点的集群里统一定成了maxsize 200M、rotate 3、daily加上压缩后每台机器的日志总占用都控制在 1G 以内配合上面的三级告警已经连续跑了大半年没有出过一起日志撑爆磁盘的故障。这次的整个处理链路从凌晨被告警叫醒到定位 app.log 膨胀再到 logrotate 配置、journald 治理、inode 排查、监控阈值重构每一步其实都是对一个核心问题的反复确认日志系统的每一层都要有明确的容量边界和处置策略不能只依赖某一个工具“自动就好”。把边界画清楚之后日志就不再是随时引爆的雷而只是一个普通的、可管理的数据流。
凌晨两点手机连着震了三下。我迷迷糊糊划开屏幕看到监控面板上某业务服务A所在主机的磁盘使用率已经冲到98%再过半小时就得写满。这种告警一年多少要碰上几回但这次有点反常——前天才刚做过一次大清理磁盘明明还剩60%空间怎么一夜之间又满了爬起来登录服务器df -h一看/var/log 目录像被什么东西一口气灌满了。顺着du -sh /var/log/*查下去一个熟悉的 app.log 文件已经膨胀到 80 多G还在以肉眼可见的速度增长。这是一次极其典型的日志增长吞掉磁盘的事故也是我处理过的案例里最值得写下来复盘的一次。整个过程涉及文件句柄、日志轮转机制、inode 耗尽、journald 独立治理等多个环节每走一步都踩到了常规文档里不会写清楚的坑。这篇就按照我当时完整排查到收尾的顺序把定位思路、logrotate 配置细节、后续监控改进全部掰开讲一遍希望能帮同样被日志打爆磁盘的人少走一点弯路。1. 磁盘告警那晚从 100% 占用到定位日志元凶1.1 告警现场与第一波排查命令进了服务器之后我没有直接去看日志目录而是先做了一套标准的三连排查这个顺序很重要能帮你快速判断是文件占空间还是被删除文件未释放空间。# 第一看磁盘整体情况 df -h # 第二看哪些目录占了大头 du -sh /var/log/* 2/dev/null | sort -rh | head -20 # 第三看有没有已经被删除但仍旧被进程占用的文件 lsof | grep deleted | head -30第一眼df -h显示/根分区已经满到 98%/var 挂载点同样告急。du -sh /var/log/*的结果里app.log 独占 80G 多简直像个小水库。第三项lsof | grep deleted没有输出说明不是删了没释放的经典问题磁盘空间确实是被这个文件真实占据了。我当时的第一反应是直接删掉 app.log 先止损。幸好手停了一下因为直接rm是有隐患的——如果那个应用进程还在持续写入这个文件删除之后空间并不会立刻释放只有句柄关闭后空间才能回来而且文件会变成幽灵文件后续日志轮转也没法正常工作。正确做法是先确认哪个进程在写再决定怎么处理。1.2 为什么日志会在一夜之间吃掉半个磁盘八十多G一个文件光靠正常业务日志很难堆到这种量级。我先看了写入进程确认是服务的主进程在持续往 app.log 里追加数据。然后我用tail -n 200 app.log扫了一眼日志内容发现几乎全是同一类报错刷屏每隔几百毫秒就喷几条堆栈信息每条一两KB。算一笔账假设平均每秒写入 30 条、每条 1.5KB一天就是 30 × 1.5KB × 86400 秒约等于 3.8GB 左右。但如果应用本身遇到某种故障循环比如连接池反复重试、某个下游接口持续超时日志频率可以翻几倍——每秒写个几十条甚至上百条都很正常80G 一晚上完全可能。这里要引出第一个容易被忽略的为什么为什么排障的时候日志会突然这么猛排查后发现是服务在凌晨被流量波动触发了一个异常分支某个模块进入了死循环式重试每次重试都带着完整参数和堆栈打日志。代码里没有做频率限制也没有熔断降级日志就变成了无底洞。单纯把日志文件删掉或者清空外部流量还在涌入问题根源没解决日志会立刻再次膨胀。所以我的处理分两步第一步暂停这个异常模块的流量或者重启进程让日志喷涌先停下来止损第二步才是把现有大文件归档、清理、配置轮转恢复和预防。这个案例充分说明了一个核心原则日志治理的第一优先级是控制日志产生速率而不是控制日志存储空间。没有这个认知你做再多轮转配置也只是把爆炸时间点往后推。2. 日志轮转的底层逻辑rotate、compression 与延迟删除2.1 logrotate 的触发链路止损之后磁盘虽然腾出来了但我知道不把轮转机制补齐这种事迟早还会重演。Linux 生态里处理日志轮转的标准工具就是 logrotate绝大多数发行版都默认安装了它。它的工作机制并不复杂系统每天或每周定时触发一次 logrotate 主流程主流程读取/etc/logrotate.conf和各应用放在/etc/logrotate.d/下的碎片配置然后按每个配置里声明的规则对日志文件执行重命名、压缩、删除旧文件等动作。一条日志文件从产生到被轮转掉完整生命周期大致是这样应用把日志写入 app.loglogrotate 到点被触发把 app.log 重命名成 app.log.1应用继续写入一个新建的 app.log或者继续写被重命名的文件取决于轮转模式下一个周期到了app.log.1 变成 app.log.2新的 app.log 又重命名成 app.log.1设置保留 N 份那么第 N1 份会被自动删除或者压缩之后删除。这里的核心参数是rotate N、daily/weekly/size、compress、delaycompress和copytruncate。我见过不少配置文档大多只是在写参数是什么但真正决定轮转行为成败的恰恰是这些参数之间的组合关系尤其copytruncate和create的选择搞错了会引出完全不同的坑。2.2 copytruncate 与 create 的权衡logrotate 有几种工作模式最常见的是create和copytruncate。create模式是重命名加重建。logrotate 先把 app.log 重命名为 app.log.1然后在原位置新建一个空的 app.log接着信号通知应用重新打开日志文件。这套逻辑干净利落文件句柄指向新文件不会丢数据。但前提是应用必须能响应信号并重新打开文件。很多应用没有做这个处理结果就是文件被重命名了进程仍然握着旧文件句柄继续往 app.log.1 里写新的 app.log 反而是个空壳。日志越轮转越乱排查问题的时候你都不知道数据到底在哪个文件里。copytruncate模式就粗暴不少。它先把 app.log 复制一份成 app.log.1然后通过truncate把原 app.log 截断为 0应用之前持有的文件句柄不失效继续往同一个 inode 里写但这个 inode 指向的文件已经被清空了所以不会出现数据写到旧文件的问题。代价也很明显复制和截断之间存在一个时间窗口。如果日志写入非常频繁这个窗口内的日志会丢失虽然通常只有毫秒级或者几十毫秒级的量但对日志完整性要求极高的场景需要评估这个损失。另外copytruncate在复制大文件时会占用大量 I/O一个 80G 的文件去复制CPU 和磁盘的瞬时压力都非常大这一点在生产环境里必须提前考虑。我当时那套场景进程是一个自己封装的 Java 服务虽然理论上它响应了 USR1 信号就能重新打开文件但由于进程是通过一个脚本启动的信号转发链路没打通用create模式反而容易出岔子。稳妥起见我选择了copytruncate。如果你要问我经验除非你能确认应用会响应信号并重开日志文件否则生产环境优先用copytruncate日志丢掉的那一点点窗口数据比你整个日志体系混乱要划算得多。3. 让轮转配置落地一份可以直接抄作业的配置3.1 配置逐行拆解下面这份配置是我在多个环境里验证过的写法适用于大多数单进程写单个日志文件的服务无论是 Java、Go、Python 还是 Node 都通用。你只需要把/data/logs/app/app.log替换成你实际路径。# /etc/logrotate.d/app /data/logs/app/app.log { daily rotate 7 maxsize 500M missingok notifempty compress delaycompress copytruncate dateext dateformat .%Y%m%d-%H%M%S extension .log su root root }逐个解释一下因为照着抄是小事理解了随时能改才是关键。daily表示每天轮转一次。配合后面的maxsize实际规则是每天至少轮转一次但如果文件提前达到 500M立即触发轮转。这个组合非常适合日志量不稳定、可能突然暴涨的服务。rotate 7表示保留最近 7 份轮转文件。加上昨天的原始文件一共 8 份配合压缩策略磁盘占用基本可控。missingok是指文件不存在时不要报错退出避免日志服务没启动时长目录屁用没有却天天报警。notifempty是文件为空时不轮转。防止某些低频服务在日志没有任何内容时也频繁触发轮转。compress开启压缩默认使用 gzip。80G 文本日志压缩完可能只有几G效果立竿见影。delaycompress会推迟一份再压缩。它的意义在于很多服务可能会在轮转后继续往 app.log.1 写入一点尾部内容比如旧句柄的残留数据延迟一天压缩能把这些零碎内容也收进去避免丢失最后那几百毫秒的日志。这个参数配合copytruncate尤其重要可以弥补复制截断窗口期的数据损失。copytruncate前面讲过这是保障进程不需要重启的关键参数。dateext给轮转文件加上日期后缀而不是默认的.1、.2。这样文件名看起来是 app.log.20250516-023000.log查找某一天的日志非常直观而且避免了文件重命名时同名覆盖的风险。su root root是指定 logrotate 以 root 身份执行文件操作。如果你的日志目录属主是别的用户请改成su 用户名 用户组否则会出现权限不足的诡异问题。3.2 手动强制执行与验证闭环配置写完后不要干等第二天先手动执行一次验证语法和权限是否正常。这个动作叫试运行很多第一次用 logrotate 的人会漏掉# 先看配置语法是否正确 logrotate -d /etc/logrotate.d/app # 再强制执行一次-f 强制忽略 daily 等时间条件 logrotate -vf /etc/logrotate.d/app-d是 debug 模式会打印出 logrotate 准备执行的动作但不会真实执行。确认无报错后再加-v -f强制执行。执行完立刻去看日志目录ls -l /data/logs/app/看到类似这样的输出就说明轮转闭环成功-rw-r--r-- 1 root root 500M May 16 02:30 app.log -rw-r--r-- 1 root root 480M May 15 02:30 app.log.20250515-023000.log -rw-r--r-- 1 root root 460M May 14 02:30 app.log.20250514-023000.log.gzapp.log已经是新建的 0 字节文件应用进程还在正常运行没有重启app.log.20250515-023000.log还没被压缩昨天的delaycompress 生效更早的已经变成.gz。这就对了。这里我想额外分享一个经验配置完轮转之后一定要用日志量最大的一天来验证压缩效果和保留策略。我曾经在另一个项目上配置了rotate 3当时日志每天才 200M觉得三个文件绰绰有余。结果一个月后业务翻了几倍日志量涨到每天 1G 多三个压缩文件加原始文件都快把 /var 撑爆了被迫紧急调整保留份数。所以配置数字不是拍脑袋定的你可以这样估算占用保留文件总大小 当前原始日志大小 × (1 1/压缩比 × rotate 份数)如果原始日志每天 500M、gzip 压缩比大约 10:1、rotate 7那么磁盘占用大约是 500M 7 × 50M 850M 左右在可控范围内。日志量大的服务可以把rotate调小、把maxsize调低甚至把daily改成按小时轮转核心原则是总占用不能超过你预期的水位。4. 轮转之外的隐性坑inode、journald 与多副本日志4.1 inode 耗尽比磁盘满更隐蔽配置好轮转之后我以为事情告一段落但正好借着这次机会把同一台服务器上另一类隐患也查了一遍其中一个就是 inode 耗尽问题。磁盘空间满和 inode 满经常被混为一谈但它们其实是两回事。磁盘满意味着数据块不够了inode 满意味着文件系统里索引节点耗尽了即使磁盘还剩很多空间你也无法新建任何文件。很多文件系统默认每 16KB 左右的容量才分配一个 inode如果上面全是几十字节的小文件很容易把 inode 池耗光。排查方法很简单df -i如果 IUse% 接近 100%你就知道问题不在空间而在文件数量。有次我在另一个环境就撞上过这种情况临时目录里堆积了上千万个未清理的 socket 文件磁盘使用率才 20%但没有任何进程能创建新文件了服务全部卡死。场景不同本质完全一样。回到日志场景为什么 logrotate 也会制造 inode 压力因为轮转本身就是不断创建新文件的过程每个日志文件都要占一个 inode。如果rotate设置得很大且轮转频率很高几天之内就会生成大量小日志文件。加上如果不配置dateext而是用默认编号、某些服务还在同一个目录下按 PID 或者按时间戳拆多个日志文件inode 消耗就会更加失控。所以建议运维同学把df -i也加到日常巡检脚本里这个指标和磁盘使用率一样重要却几乎没人看。4.2 journald 日志的独立治理排查那台服务器的时候我还顺手发现 systemd 日志目录/var/log/journal/也占了几个G的空间。很多部署在 systemd 下的服务如果没配置 stdout 日志重定向日志会直接进 journald而不是写到你业务配置的文件里。这意味着你会同时有两套日志体系业务日志归 logrotate 管journald 的日志走它自己的配额策略互不干扰但空间占用是叠加的。journald 默认的配额策略曾经有版本差异某些版本在系统盘大的时候会允许 journal 目录一直涨到跟系统盘容量挂钩的比例这个值如果没限制几十个G也不是不可能。限制方式是在/etc/systemd/journald.conf里显式加规则[Journal] SystemMaxUse2G SystemMaxFileSize200M MaxRetentionSec14d其中SystemMaxUse2G是所有 journal 文件加起来最多 2GSystemMaxFileSize200M限制单个日志文件大小MaxRetentionSec14d表示只保留 14 天的日志。改完配置后记得重启服务systemctl restart systemd-journald有同学会担心重启 journald 会不会影响正在跑的业务一般来说不会journald 重启后旧的日志文件还在只是它会按新的配额策略开始清理超龄和超量的日志。这是我强烈建议你在每台 systemd 主机上都加的一段配置尤其是根分区不大的机器经常遇到业务日志还没占多少空间journal 反而把 /var 吃满了这种事。4.3 不要忽略同一应用的多写者问题最后还有一个非常隐蔽的坑是我在调整完 logrotate 之后继续观察时才想到的如果同一个日志文件同时被多个进程写入轮转的copytruncate模型就会产生撕裂问题。什么叫多写者比如某个应用通过 supervisor 之类工具被拉起了多个 worker 进程它们都往同一个 app.log 追加日志。另外有些部署形态里会有日志采集 Agent 同时读取这个文件并转发到远端。这种情况下 logrotate 复制文件、截断原文件时其他进程可能正拿着旧的文件句柄或者正在读取某个偏移位置日志数据就可能在轮转时被切得七零八落甚至出现轮转后某几个进程还在往旧 inode 里写几个小时的现象。解决思路无非几种一是从源头统一写日志路径确保一个进程一个日志文件不要乱共享二是如果必须共享考虑采集层用更完善的文件追踪方案而不是依赖copytruncate轮转三是日志量允许的话让应用自己按大小主动切割日志文件logrotate 只负责压缩和清理归档文件业务层切割永远比外部工具周期触发更及时。这个多写者问题平时不太显眼但它发生的时候排障体验非常痛苦。你按时间线查日志发现中间有将近一个小时的记录出现在昨天轮转走的压缩包里而今天的文件里却有一段空白你会误以为业务出了故障。实际上就是文件句柄和轮转之间的错位造成的。所以从第一天设计日志采集方案的时候就要把谁在写、谁在读、谁来切这三件事想清楚不要都让 logrotate 兜底。5. 事后复盘监控阈值与告警分级的调整5.1 从磁盘满到趋势预测的告警设计问题解决后我做的第一件事是回顾那晚为什么会被动挨打。凌晨两点收到告警意味着这个状态已经持续了好几个小时如果早点发现趋势处理成本会低得多。原来的监控策略是磁盘使用率超过 90% 才触发告警但这本质上是一个事态发生后的告警等它响起来你能操作的时间窗口已经很窄了。我把告警策略调整成了三级级别触发条件响应动作预警磁盘使用率 24 小时环比增长超过 10%检查是否有异常文件增长次要告警磁盘使用率超过 75%计划性清理、扩容评估紧急告警磁盘使用率超过 90%立即处理在实际操作里我还加了两个非常有用的监控维度。第一实时监控/var/log下最大的三个文件的增长速度而不是只盯分区使用率。这个指标能直接暴露哪份日志在异常膨胀为排障省掉一半时间。第二给日志目录的文件总数设置告警基线一旦 inode 数异常飙升就提醒防止触发 inode 耗尽的次生灾害。5.2 快速恢复与长尾优化的平衡回归到事故处理本身还有一个思路值得做既然日志量的暴涨几乎总是和业务异常强相关那么在轮转机制之外还应该加一道日志写入限流的保险。这个思路说起来也不复杂很多语言都提供了日志库限流能力。比如 Java 的 logback 可以配置SizeAndTimeBasedRollingPolicyPython 的 logging 可以做 handler 级别的缓冲和丢弃策略。限流的目标不是丢掉所有日志而是在异常流量爆发时保证日志系统自身的稳定性同时保留足够多的关键上下文用于排障。我当时的做法是在服务里加了一个单日日志熔断配置如果某个 logger 在 1 分钟内写入了超过设定条数的日志后续日志进入采样模式只保留前 N 条和堆栈摘要其余丢弃或计数。这个策略上线后那台服务器的磁盘使用率曲线从「偶尔冲高、经常告警」变成了「持续平缓」效果非常明显。最后再回到配置本身的一个小细节。maxsize 500M这个值需要结合你服务的实际日志量调整如果日志每天稳定在 100M 左右设成 500M 就是空摆设每天轮转一次足够如果日志经常在几分钟内冲到几Gmaxsize反而是第一道防线触发得越早越安全。我在另一个约 60 个节点的集群里统一定成了maxsize 200M、rotate 3、daily加上压缩后每台机器的日志总占用都控制在 1G 以内配合上面的三级告警已经连续跑了大半年没有出过一起日志撑爆磁盘的故障。这次的整个处理链路从凌晨被告警叫醒到定位 app.log 膨胀再到 logrotate 配置、journald 治理、inode 排查、监控阈值重构每一步其实都是对一个核心问题的反复确认日志系统的每一层都要有明确的容量边界和处置策略不能只依赖某一个工具“自动就好”。把边界画清楚之后日志就不再是随时引爆的雷而只是一个普通的、可管理的数据流。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
