凌晨磁盘告警响起，运维登录服务器查看，日志目录按日期分得整整齐齐，表面看管理规范，磁盘却已接近写满。这类现象背后有个常见误区：日志切分只处理了文件如何组织，并未处理容量如何受控。按天分文件夹，只是把日志拆成一个个独立文件；若每日写入量本身很大，或者旧文件从未被真正删除，磁盘依旧会被占满。此时不宜急着删文件，而应按顺序核查保留策略，找出容量失控的真正原因。
首先要核查的是单日日志量与实际写入来源。查看最近几天的日志文件大小，算出平均单日增量，再与业务量对照。若单日体积明显超出预期，需区分两种情形：一是业务确实增长，访问量、任务量上升带来正常增量；二是程序存在异常重复输出，例如循环中反复打印同一段内容、错误被捕获后逐层记录、调试日志未关闭。正常增量应调整容量或保留周期，异常输出则须回到代码层面修复，否则清理再多也只是暂时缓解。核查时可抽取一个日志文件，观察重复行占比与日志级别分布，判断错误日志和调试日志是否混在一起大量写入。
其次要核查保留天数、压缩开关与清理任务是否真正执行。不少系统配置了保留七天或三十天，但配置写入不等于策略生效。需确认三件事：保留策略是写在应用配置里，还是交给日志组件或系统任务处理；历史文件是否开启压缩，未压缩的文本日志占用空间往往是压缩后的数倍；清理任务有无实际运行记录，是否因权限不足、路径写错、任务被禁用而静默失败。清理任务失败通常不会主动报错，需要查看任务日志，或直接对比目录中最早文件的日期，看是否真的只保留了设定天数。
第三是建立一份可执行的检查清单。单日体积估算：连续观察三到五天，取平均值并预留业务高峰余量。保留周期：根据排查需求和磁盘容量反推合理天数，而非照搬默认值。压缩比：确认压缩是否开启，估算压缩后能节省多少空间。清理失败告警：为清理任务增加执行结果记录，超过预期时间没有清理动作时主动提醒。这四项落实后，日志容量才真正可控。
最后需要说明，日志保留不只是技术问题。部分业务场景对操作记录有留存要求，保留周期过短可能影响问题追溯，具体天数应以实际业务需要和相关规定为准。切分、压缩、清理三者配合，再加上对写入来源的持续观察，才能让日志既够用又不至于写满磁盘。
