很多站点出故障，原因並不是内容出了問题，而是服務器忽然寫不進去。蜘蛛在某一天集中抓取，訪問日誌、错誤日誌、爬虫日誌同时膨胀，磁盘水位從六七成一路冲到 100%，接着資料库無法寫入、缓存無法落盘、临时文件建立失敗，蜘蛛拿到的不是内容頁，而是 5xx 或長時間等待。更麻烦的是，恢复正常往往要几十分钟，這段時間里抓取频率會明顯下滑，恢复後也需要一段時間才回来。
先確認日誌到底長了多少
排查不要凭感觉，先看几個硬指标，列出来再判断：
- 磁盘使用率：df -h 看各挂载点，注意日誌目錄和資料目錄是否在同一块盘上。
- inode 使用率：df -i。磁盘還有空間但 inode 用尽，同样無法建立新文件，這種情况在小文件多的日誌目錄里很常见。
- 日誌目錄体积：du -sh 逐個目錄看，通常訪問日誌占大头。
- 增長速率：连續两天同一時間记錄一次体积，算出日均增長，估算還能撑几天。
- 單文件大小：有没有一個几年没切分的巨型日誌文件，打開、压缩、传輸都會很吃力。
日誌轮轉：切分、压缩、保留
主流做法是用 logrotate 或系統自带的服務管理器，把日誌按天或按大小切分。配置时几個细节容易漏：
- 保留份數別照抄模板，按日均增長算。日均 2GB 的日誌，留 30 份就是 60GB，很多小服務器扛不住。
- 轮轉後要压缩歷史文件，纯文本日誌压缩率通常很高。
- 轮轉完必须让服務重新打開文件句柄，例如 nginx 可以發送 USR1 信号或执行 reopen，否則進程還握着舊文件，磁盘空間不會释放。
- 確認新生成的日誌文件属主和權限與原来的服務進程一致，否則會出現“能跑但寫不進日誌”的静默問题。
不要直接 rm 正在寫入的日誌文件。文件被刪除後句柄仍在，磁盘空間不會立刻释放，看起来像删了但水位没降，容易誤判。
归档分层，別把所有日誌堆在一起
把日誌分成三层来管，成本和可查性都能兼顾：
- 热資料：最近 7 到 14 天，保留在本地磁盘，方便查错和临时分析。
- 冷归档：压缩後移到大容量盘或對象存储，需要时再拉回。
- 抓取分析用：如果要用日誌做蜘蛛抓取分析，單獨归集一份，不要和日常排错日誌混用，避免為了保分析資料而長期占用主盘。
和抓取高峰错開，减少無谓寫入
日誌不是越多越好，寫入量本身也是可以运营的：
- 關閉生产环境的 debug 日誌，調试級別日誌的体量常常是訪問日誌的好几倍。
- 静態资源（图片、CSS、JS）的訪問记錄按需保留，或單獨輸出到另一個文件，避免主日誌被刷屏。
- 慢查询日誌、详细错誤堆栈按需開啟，排查完及时關掉。
- 對明顯異常的抓取来源做频率限制，既省服務器资源，也让日誌更干净。
监控和告警要放在寫满之前
等到 100% 再處理已经很被動。建议至少配置這几條：
- 磁盘使用率超過 80% 告警，超過 90% 升級提醒。
- inode 使用率纳入同一套告警。
- 监控寫入失敗的相關错誤關键字，比如磁盘满、無法建立文件。
- 记錄站点 5xx 比例，和磁盘水位放在同一張图上看，便于判断因果關系。
一次可执行的检查清單
- 查磁盘與 inode 水位，確認日誌目錄所在挂载点。
- 統計日誌日均增長，估算可支撑天數。
- 检查轮轉配置的份數、压缩、句柄重開、權限四項。
- 把超過保留期的冷日誌压缩归档，移出主盘。
- 確認生产环境已關閉調试日誌，静態资源日誌已分流。
- 配置 80% 水位與 inode 告警，驗證告警能真正發出。
- 在下次预期抓取高峰前，复查一次水位余量。
這套维護動作不复杂，但需要定期做一次。日誌和磁盘水位稳住了，服務器在抓取高峰才有余量把頁面正常返回出去，蜘蛛也才有机會把该抓的頁面抓走。