半夜磁盘告警响起，登上服务器一查，日志目录又吞掉了大半存储空间——这是不少运维人员都碰见过的状况。日志文件不断变大，本身算不上故障，可要是放任不管，它会一点点蚕食存储容量、拖慢问题排查节奏，甚至在业务最吃紧的时候让服务没法写入新数据。日志管理恰恰是日常维护里最容易被放到一边的环节，风平浪静时看不出问题，一旦出事往往就是存储空间亮红灯。
先弄清日志有哪些类型、各自怎么增长
网站运转过程中产生的日志，大体可以分成几类。访问日志记下每一次请求的来源、路径和状态码，数量最多，涨得也最快。错误日志记录程序异常和请求失败，量不算大，但参考价值高。应用日志由业务代码主动写入，内容因系统不同而不同，可能涉及订单、接口调用等关键信息。系统日志则来自操作系统和服务进程，用来观察资源占用和运行状态。各类日志的留存意义不一样，清理时也不该用同一把尺子去量。
保留多久才合适，四个因素说了算
第一看业务需求，电商类网站经常需要按周期核对访问与转化数据，日志留存时间通常会更长一些。第二看故障追溯周期，多数问题在发生后几天内就会暴露，但偶发问题可能几周后才再次出现，留存时间要能覆盖这个窗口。第三看合规要求，部分行业对数据留存有明确规定，需要按相关要求执行，具体情况应以相关官方规定和专业人士意见为准。第四看存储成本，长期保存全量日志的开销并不低，可以通过压缩和抽样来平衡。判断时不必追求最长，而应找到够用且可控的那个平衡点。
一份可以照着做的日志清理清单
动手清理之前，先确认服务运行状态，避免误删正在写入的文件。按日期对日志做归档，把同一天的文件归入同一目录，方便定位。对超过活跃期的日志进行压缩存储，体积通常能明显降下来。对访问日志可以定期抽样保留，既留下趋势又控制住总量。给日志所在分区设置磁盘告警阈值，在写满之前提前介入。清理动作执行前确认已有备份，尤其是错误日志和应用日志，删掉之后无法还原。每一步都建议留下操作记录，方便日后回溯。
用日志轮转取代手工删除
手工删除只能解决一时，更稳妥的办法是启用日志轮转。基本思路是按大小或时间自动切割文件，比如单文件超过设定体积就生成新文件，或者每天零点切分一次。切割后自动压缩历史文件，并且只保留最近若干份，超出部分自动清理。这样单个文件不会无限膨胀，排查时打开速度更快，磁盘占用也保持在可预期的范围内。轮转策略要结合日志写入速度来设定，写入快的服务切分频率可以高一些。
把策略写进维护文档并定期复核
日志管理的核心原则是让日志服务于排查，而不是拖累服务器。保留多久、压缩到什么程度、保留几份历史，这些决定应当写入维护文档，避免换人之后策略丢失。同时建议每隔一段时间复核一次，业务量变化、存储扩容或合规要求调整后，原有策略可能不再适用。it数运在网站维护服务中，通常会把日志策略纳入日常巡检范围，让存储使用保持在可控状态。日志本身不会说话，但一套清晰的保留与清理规则，能让它在需要时真正派上用场。
