早上打开监控，磁盘使用率从六成跳到百分之九十八，告警短信一条接一条。这种时候最忌讳上来就删日志。日志暴涨和单纯磁盘写满不同，写满往往能看出是哪个目录、哪批文件在增长，而日志暴涨是持续写入把空间迅速吃光，删掉一批很快又满，如果没找到写入源头，重启和清理都只是把问题往后推几个小时。更麻烦的是，日志本身是排查线索，动手太急容易把现场一起清掉。
第一步先确认暴涨的是哪类日志。访问日志记录外部请求，错误日志记录程序异常，应用日志包含业务运行信息，系统日志则涉及系统服务和内核消息。这四类日志的增长原因完全不同：访问日志暴涨多半与请求量有关，错误日志暴涨往往意味着某个环节在反复报错，应用日志暴涨可能是循环打印或调试输出没关，系统日志暴涨则要留意服务异常重启和定时任务。先按目录和文件名把增长最快的几个文件列出来，看它们的修改时间和体积变化，再决定往哪个方向查。
第二步按时间线比对。把磁盘增长的起始时间标出来，和访问量曲线、错误数量曲线放在一起看。如果请求量同步上涨，重点查请求来源、接口分布和是否存在异常抓取；如果请求量平稳但错误数陡增，重点查程序是否进入重试循环、定时任务是否重复触发、某个外部依赖是否持续超时。一个实用的判断方法是看日志内容的重复度：大量完全相同的行，通常指向循环输出；内容各异且集中在某几个路径，更像是外部请求异常。
第三步检查日志轮转与保留策略。常见失效点包括轮转配置没有覆盖新加的服务、按大小轮转的阈值设得过大、保留份数过多、压缩任务失败、日志被多个进程同时写入导致轮转不生效，以及容器环境下日志写到了宿主机而没纳入统一管理。逐项核对配置文件与实际文件状态，确认轮转是否真的执行过，而不是只写了规则。
临时处置上，可以先限制写入速率、临时调低日志级别、把增长最快的日志切分转移，为排查争取时间，但每一步都要记录，避免丢失关键线索。长期预防则要把日志容量纳入托管规划：按业务量估算每日日志体积，设定磁盘水位告警，明确轮转周期和保留天数，对错误日志设置频率提醒。it数运在服务器管理中通常先确认日志分类和增长时间线，再动清理动作，把容量规划和轮转检查作为日常项，而不是等告警来了才处理。
顺序可以记成一句话：先分类，再对时间线，然后查轮转，最后才清理。按这个顺序走，既能尽快定位来源，也不会把有用的现场一起删掉。
