訪問日誌、错誤日誌、缓存日誌、資料库日誌，只要服務在跑，日誌就在寫。平时不太會注意，直到某個凌晨磁盘寫满，站点開始报 500，後台传不了图，資料库也寫不進去。對运营来说，日誌和磁盘属于那種不出問题没感觉、一出問题很耽誤事的环节。
先看磁盘和 inode，不只看剩余空間
很多服務器面板會展示磁盘使用率，但 inode 使用率经常被忽略。磁盘空間還有余量，不代表能繼續建立新文件；如果小文件太多，inode 先耗尽，同样會出現無法寫入的情况。建议同时看两個數字：磁盘使用率和 inode 使用率。
常见的增長来源包括：訪問日誌、错誤日誌、應用日誌、缓存文件、會话文件、上传的临时文件、資料库 binlog 或慢查询日誌。可以按目錄大小排序，找出增長最快的几個位置。
查看日誌目錄的常用思路
- 按目錄統計占用：看 /var/log、應用日誌目錄、缓存目錄、临时目錄。
- 按文件大小排序：找出單個特別大的日誌文件，比如訪問日誌没有轮轉。
- 看增長趋势：對比昨天和今天同一目錄的大小，判断是稳定增長還是異常暴涨。
- 看 inode：確認是否被大量小文件占用，比如會话文件、缩略图缓存。
日誌轮轉配置要能真正生效
日誌轮轉不是設定了就萬事大吉。需要確認轮轉周期、保留份數、压缩方式和轮轉後是否需要通知服務重新打開日誌文件。如果配置寫错，可能出現日誌文件被重命名後，進程還在往舊文件句柄寫，磁盘占用没有释放。
比較稳妥的做法是：给訪問日誌和错誤日誌分別設定保留天數，压缩舊日誌，限制總保留体积。對增長快的日誌，轮轉周期可以缩短，但不要只按天，必要时按小时或按大小触發。
轮轉後常见的小問题
- 舊日誌被刪除但進程未重载，磁盘空間没有真正释放。
- 压缩任務和清理任務時間重叠，短时 CPU 和磁盘 IO 升高。
- 保留份數過多，虽然單文件不大，累計起来仍占空間。
- 日誌目錄權限不對，轮轉脚本执行失敗但没有告警。
把日誌清理和抓取观察放在一起做
訪問日誌不只是占空間，它也是观察蜘蛛行為的原始材料。清理之前，可以考虑先保留一段時間的压缩归档，方便之後做抓取频次、狀態碼分布、異常 IP 的复盘。如果日誌直接刪除，再想查某個時間段的抓取情况就比較被動。
對于蜘蛛池或需要观察 URL 發現的站点，訪問日誌能反映哪些地址被訪問、返回什么狀態、是否存在大量 404 或 5xx。定期抽取日誌做統計，比等到磁盘告警再處理更從容。
日常自查清單
- 磁盘使用率和 inode 使用率是否低于警戒线，比如 80%。
- 日誌目錄總大小是否在预期范围内，增長是否平稳。
- 轮轉配置是否覆盖訪問日誌、错誤日誌、應用日誌和資料库日誌。
- 轮轉後的舊日誌是否保留合理天數，压缩是否正常。
- 是否有清理任務，清理後磁盘空間是否實际释放。
- 是否有告警，磁盘或 inode 超過阈值时能通知到人。
- 日誌归档是否足够支撑一段時間的抓取复盘。
發現空間不足先做什么
如果已经收到磁盘告警，先不要盲目刪除。可以先確認哪個分区、哪個目錄增長最快，再判断是日誌、缓存、临时文件還是資料库文件。優先清理可再生成的临时文件和過期日誌，避免誤删資料库文件或上传源文件。
清理之後，检查對應服務是否恢复正常寫入，並观察一段時間。如果日誌增長很快，說明轮轉或清理策略需要調整，而不是每次手動删。
磁盘和 inode 的告警往往来得突然，但增長是渐進的。把日誌轮轉和清理纳入日常巡检，比故障後救火省事得多。
站点运营不需要每天盯着日誌，但需要知道日誌寫在哪里、保留多久、磁盘還有多少余量。把這几個數字定期看一眼，很多寫入類故障可以提前避開。