访问日志、错误日志、缓存日志、数据库日志，只要服务在跑，日志就在写。平时不太会注意，直到某个凌晨磁盘写满，站点开始报 500，后台传不了图，数据库也写不进去。对运营来说，日志和磁盘属于那种不出问题没感觉、一出问题很耽误事的环节。
先看磁盘和 inode，不只看剩余空间
很多服务器面板会展示磁盘使用率，但 inode 使用率经常被忽略。磁盘空间还有余量，不代表能继续创建新文件；如果小文件太多，inode 先耗尽，同样会出现无法写入的情况。建议同时看两个数字：磁盘使用率和 inode 使用率。
常见的增长来源包括：访问日志、错误日志、应用日志、缓存文件、会话文件、上传的临时文件、数据库 binlog 或慢查询日志。可以按目录大小排序，找出增长最快的几个位置。
查看日志目录的常用思路
- 按目录统计占用：看 /var/log、应用日志目录、缓存目录、临时目录。
- 按文件大小排序：找出单个特别大的日志文件，比如访问日志没有轮转。
- 看增长趋势：对比昨天和今天同一目录的大小，判断是稳定增长还是异常暴涨。
- 看 inode：确认是否被大量小文件占用，比如会话文件、缩略图缓存。
日志轮转配置要能真正生效
日志轮转不是设置了就万事大吉。需要确认轮转周期、保留份数、压缩方式和轮转后是否需要通知服务重新打开日志文件。如果配置写错，可能出现日志文件被重命名后，进程还在往旧文件句柄写，磁盘占用没有释放。
比较稳妥的做法是：给访问日志和错误日志分别设置保留天数，压缩旧日志，限制总保留体积。对增长快的日志，轮转周期可以缩短，但不要只按天，必要时按小时或按大小触发。
轮转后常见的小问题
- 旧日志被删除但进程未重载，磁盘空间没有真正释放。
- 压缩任务和清理任务时间重叠，短时 CPU 和磁盘 IO 升高。
- 保留份数过多，虽然单文件不大，累计起来仍占空间。
- 日志目录权限不对，轮转脚本执行失败但没有告警。
把日志清理和抓取观察放在一起做
访问日志不只是占空间，它也是观察蜘蛛行为的原始材料。清理之前，可以考虑先保留一段时间的压缩归档，方便之后做抓取频次、状态码分布、异常 IP 的复盘。如果日志直接删除，再想查某个时间段的抓取情况就比较被动。
对于蜘蛛池或需要观察 URL 发现的站点，访问日志能反映哪些地址被访问、返回什么状态、是否存在大量 404 或 5xx。定期抽取日志做统计，比等到磁盘告警再处理更从容。
日常自查清单
- 磁盘使用率和 inode 使用率是否低于警戒线，比如 80%。
- 日志目录总大小是否在预期范围内，增长是否平稳。
- 轮转配置是否覆盖访问日志、错误日志、应用日志和数据库日志。
- 轮转后的旧日志是否保留合理天数，压缩是否正常。
- 是否有清理任务，清理后磁盘空间是否实际释放。
- 是否有告警，磁盘或 inode 超过阈值时能通知到人。
- 日志归档是否足够支撑一段时间的抓取复盘。
发现空间不足先做什么
如果已经收到磁盘告警，先不要盲目删除。可以先确认哪个分区、哪个目录增长最快，再判断是日志、缓存、临时文件还是数据库文件。优先清理可再生成的临时文件和过期日志，避免误删数据库文件或上传源文件。
清理之后，检查对应服务是否恢复正常写入，并观察一段时间。如果日志增长很快，说明轮转或清理策略需要调整，而不是每次手动删。
磁盘和 inode 的告警往往来得突然，但增长是渐进的。把日志轮转和清理纳入日常巡检，比故障后救火省事得多。
站点运营不需要每天盯着日志，但需要知道日志写在哪里、保留多久、磁盘还有多少余量。把这几个数字定期看一眼，很多写入类故障可以提前避开。