為什么日誌會成為“隐形占用”
站点跑起来之後，訪問日誌、错誤日誌、抓取日誌每天都在增長。一個流量不大的站点，access.log 一年也可能攒到几個 GB；如果再加上調试日誌、慢查询日誌和缓存文件，占用會更快。磁盘寫满时，最先出問题的往往不是頁面本身，而是日誌寫不進去、會话無法儲存、临时文件建立失敗、資料库無法寫入。表現可能是間歇性 500、登入狀態丢失，嚴重时整站打不開。
一次完整的自查清單
1. 先看還剩多少空間
- 用 df -h 查看各分区使用率，重点關注 / 和 /var 這類系統分区，使用率超過 80% 就该處理；
- 用 df -i 查看 inode 使用率。小文件特別多时，空間没满但 inode 先耗尽，同样會寫入失敗；
- 把目前數值记下来，作為後續對比的基线。
2. 找到占用大头
- 用 du -sh 逐层定位到具体目錄，通常集中在日誌目錄、缓存目錄、上传目錄和备份目錄；
- 注意被刪除但進程仍持有的文件，du 看不到占用，重啟對應服務或释放句柄後空間才會回来；
- 分清哪些文件可以压缩归档，哪些必须原样保留。
3. 日誌轮轉是否真的在工作
- 检查轮轉配置（如 logrotate）的周期、保留份數、是否压缩；
- 確認轮轉後服務是否需要 reload 或重開文件句柄，否則會繼續寫舊文件；
- 留意轮轉静默失效的情况：權限不足、配置语法错誤、磁盘已满都可能让轮轉不执行。
日誌不是越少越好。做 URL 發現和抓取分析时，经常需要回看一段時間的蜘蛛訪問记錄，保留周期建议按分析需求设定，而不是一律只留三天。
4. 设定清理與告警規則
- 按類型设定保留期：訪問日誌保留 30 到 90 天，調试日誌保留數天，归档後压缩；
- 配置阈值告警，例如使用率達到 75% 提醒、85% 告警，別等到寫满才收到消息；
- 清理脚本先在測試环境驗證匹配范围，避免誤删上传目錄或資料库文件；
- 把“查看磁盘與日誌狀態”寫進例行巡检，每周固定看一眼。
顺手能發現的几件事
整理日誌时，顺便翻一下 error.log。如果 5xx 集中出現在某些路径，多半是程序或資料库层面的問题；如果日誌里出現大量重复的異常 UA 或異常高频請求，也可以作為後續限流與防護的參考。這些信息平时不翻日誌是看不到的。
小结
磁盘和日誌属于“平时没感觉、出問题很致命”的那類事項。建议先做一次基线记錄：各分区使用率、日誌目錄大小、轮轉配置現状，然後补上告警和清理規則，把巡检變成固定動作。留足空間，站点才有余量應對流量的正常波動。