騰訊雲帳號購買 騰訊雲伺服器日誌佔滿空間導致系統崩潰怎麼清理

第一章：問題的本質——日誌為何能把磁碟吃光

「日誌佔滿空間導致系統崩潰」聽起來像是一個突然發生的意外，但大多數情況它其實是長期累積的結果。日誌的作用是記錄系統與應用的行為；問題在於：當磁碟空間不足、輪轉策略失效、磁碟被誤掛載、服務異常爆量輸出，或者 logrotate/容器日誌機制沒有設定時，日誌就會像漏水的水管一樣越積越多，直到系統開始「拒絕工作」。

當根分區（/）被打滿，後果往往比你想像更快：程序無法再寫入臨時檔案，資料庫可能因寫入錯誤停止或進入不可預期狀態；更糟的是，系統的某些服務在日誌寫入失敗後會反覆重啟，形成惡性循環。你可能會看到：CPU 未必高，但服務完全不可用；SSH 連不上；應用啟動失敗並反覆報錯；甚至重啟也因寫入失敗卡住。

因此清理的第一要務不是「立刻刪掉所有文件」，而是先搞清楚：

• 到底是哪些檔案/目錄被寫滿？
• 是日誌檔本身長到太大，還是檔案系統/掛載點出錯？
• 是單次事件造成（例如服務崩潰後爆量刷屏），還是長期策略缺失？

接下來的步驟會圍繞這些問題展開，並給出可直接落地的處理流程。

第二章：先活下來——在崩潰邊緣的處理順序

如果你已經遇到磁碟 100% 或接近 100%，建議按「先降風險、再定位、最後修復」的順序做。原因很簡單：刪檔不一定安全，停止寫入不一定能在服務正常時完成，所以你需要一個合理的操作順序。

2.1 檢查磁碟使用與目標分區

先確認是哪個分區被打滿。登入機器後（能 SSH 就用 SSH，不能就通過雲端控制台或救援方式進入），執行：

df -h

重點看以下幾點：

• 根分區（/）是否已達 95%~100%
• 是否有獨立掛載的資料分區（/var、/home、/data 等）也被打滿
• 檔案系統類型與掛載是否正常（偶爾會出現掛載目錄空了但磁碟其實滿在別的地方）

如果你看到類似「Use% 100%」，就先把目標鎖定在那個滿的目錄。

2.2 列出最大佔用者：找出到底是哪個日誌

當磁碟幾乎滿時，你最需要的是定位「最大那幾個文件」。常見日誌位置包含：

• /var/log（系統與服務日誌大多在這裡）
• /var/lib/docker/containers 或容器相關目錄（若是 Docker，容器日誌可能爆量）
• /usr/local/xxx/logs（你自建的應用、代理、背景任務）
• /tmp（某些服務把輸出寫到臨時目錄）

你可以用以下方式快速找出最大檔案（建議以「該目錄」為單位，而不是整台掃全盤）：

sudo du -ah /var/log --max-depth=2 | sort -rh | head -n 30

或針對更精準的目錄：

sudo du -ah /var/log --max-depth=1 | sort -rh | head -n 30

同時配合檢查 log 檔的檔名與最近變更時間：

ls -lh /var/log | tail

以及查看某幾個最大檔是否正在被寫入（如果檔案大小不停增長，說明不是歷史殘留而是活躍問題）。

2.3 立即止血：先阻止「持續寫入」而不是盲刪

如果確認是某個服務日誌在爆量，刪檔同時可能還在被程式持續寫入；你刪掉的是「檔案名」，但程式仍持有舊檔案的文件描述符，磁碟空間不會立刻釋放。這是很多人清理失敗的原因。

因此止血策略通常是：

• 騰訊雲帳號購買 先停止/重啟造成爆量的服務（或至少先暫停其寫入日誌的行為）
• 再對目錄/檔案做清理
• 最後恢復服務並加上輪轉與限額

停止服務可用：

sudo systemctl stop 你的服務名

騰訊雲帳號購買 若你不確定服務名，可以先找出誰在寫該日誌檔：

sudo lsof | grep /var/log | head

或針對特定檔案：

sudo lsof /var/log/xxx.log

一旦你定位到寫入者，就能更精準地控制風險。

第三章：常見日誌膨脹原因與對應處理

日誌佔滿空間不是單一原因造成。下面我把最常見的場景整理出來，對應你在現場會看到的現象與處理方式。

3.1 /var/log 下某個檔案持續增長

現象：你會看到某個檔案（例如 messages、syslog、nginx/access.log、app.log）大小每天或每分鐘都在飆升。

處理思路：

• 先確認它是「正常流量」還是「錯誤風暴」：查前後內容是否充斥重複報錯
• 停止服務或把輸出暫時降到合理層級
• 清理舊檔並啟用輪轉

例如如果是 Nginx 訪問日誌爆量，除了清理，還要檢查是否某些請求異常（爬蟲、攻擊、回圈重試）導致大量 404/500。只做清理不解決攻擊/錯誤源，日誌很快又會回到同樣狀態。

騰訊雲帳號購買 3.2 logrotate 沒跑或配置失效

現象：你發現有 .1、.2 的輪轉檔，但數量明顯不符合預期；或者壓根沒有輪轉，檔案從某個時間點開始變得異常巨大。

騰訊雲帳號購買 處理思路：

• 檢查 logrotate 是否啟用：systemctl status logrotate
• 檢查 cron：/etc/cron.daily/logrotate 是否執行
• 檢查 logrotate 配置文件：/etc/logrotate.conf 與 /etc/logrotate.d/

常見問題：配置檔設定了輪轉，但「沒有指定 compress / missingok / notifempty」，或設定檔目標路徑不對，導致輪轉腳本沒有作用。還有一種情況是 logrotate 需要的權限不足，導致執行報錯。

3.3 容器日誌（Docker/K8s）沒設輪轉

現象：/var/lib/docker/containers 下某個容器目錄特別大；或者 /var/lib/docker/overlay2 也膨脹嚴重，間接導致磁碟滿。

Docker 常見是 json-file 驅動沒有設 max-size / max-file。如果你有用 Docker，建議把日誌輪轉策略補上。

處理思路（原則）：先停止爆量容器或更新配置，再清理舊日誌，再確認策略生效。

注意：清理容器日誌時要先判斷該磁碟是「根分區滿」還是「容器相關分區滿」。因為清掉容器日誌可能同時影響排錯資料。

3.4 誤把檔案輸出到 /var/log 或 /tmp

現象：應用寫錯路徑，把大量輸出當日誌；或者 debug 模式下把堆疊/原始資料不斷寫到磁碟。

處理思路：

• 修改應用配置或環境變數（調低 log level、關閉 debug dumping）
• 把產生日誌的目錄改到獨立掛載（例如單獨掛載到 /log 或 /data/log）
• 加上輪轉與上限

第四章：逐步清理流程（實操導向）

下面給出一個通用的清理流程，適用於多數 Linux 發行版上的騰訊雲主機。你可以把它當成「救火 SOP」。

4.1 先決條件：確認你有足夠權限並避免誤操作

建議使用具有 sudo 權限的帳號。操作前可先記錄一下磁碟使用：

df -h

同時列出可疑目錄：

騰訊雲帳號購買 du -sh /var/log /tmp 2>/dev/null

騰訊雲帳號購買 這些記錄在你清理後能用來驗證是否真有效。

4.2 找到「最大的幾個」日誌檔案

以 /var/log 為例：

sudo find /var/log -type f -size +100M -printf '%s %p\n' 2>/dev/null | sort -nr | head -n 20

這條命令會列出大於 100MB 的檔案，然後排序取前 20。你可以調整 100M 門檻以適配磁碟狀況。

若你看到某個檔案幾乎佔滿空間，下一步就要判斷是否正被寫入。

4.3 判斷檔案是否仍在被寫入

使用：

sudo lsof | grep -E '/var/log/.*\.log|/var/log/messages|/var/log/syslog' | head -n 20

更精準可以直接查某個文件，例如：

sudo lsof /var/log/nginx/access.log

如果 lsof 有輸出，說明程式正在寫入該檔案。那就不要直接 rm，而是先停止寫入來源，再清理。

4.4 先停止寫入，再清理或截斷

停止方式取決於你是什麼服務。通常 systemd 對應：

sudo systemctl stop nginx

如果你不確定服務名，至少可以先停止你確認的寫入者（由 lsof 得知）。

清理時有兩種常用策略：

• 刪除舊檔（檔案確實不再被寫入，且你不需要回溯）
• 截斷檔案（保留檔案存在與權限，避免程式因檔案不存在而報錯）

截斷方式：

sudo truncate -s 0 /var/log/你要清理的檔案.log

或：

sudo : > /var/log/你要清理的檔案.log

如果你刪除：

sudo rm -f /var/log/你要刪除的檔案.log

但注意：若你沒完全停掉寫入者，刪掉檔案可能仍佔用磁碟，因為舊文件描述符仍存在於內核中，磁碟不會立刻釋放。

4.5 清理後立刻驗證磁碟是否真的釋放

清理完成後再看一次：

df -h

如果 df 沒變，通常表示：

• 你刪掉的是「仍在被寫入的舊檔案」
• 有其他目錄（例如 /tmp、容器層）才是主因
• 騰訊雲帳號購買 你清理的不是目前佔用磁碟的那個檔案

必要時重新回到「找最大佔用者」步驟。

第五章：重新啟動服務並做風險控制

當磁碟不再滿載後，你可以恢復服務。但恢復不等於放任，否則很快就會再次爆掉。

5.1 檢查服務狀態與錯誤訊息

重新啟動：

sudo systemctl start nginx

然後查看狀態：

sudo systemctl status nginx --no-pager

同時查看近期錯誤：

sudo journalctl -u nginx -n 200 --no-pager

如果你看到大量錯誤（例如反覆的連線失敗、認證失敗、上游超時），要把日誌爆量的原因同步處理。否則你只是把現象壓下去，根因仍存在。

5.2 清理後要避免「立刻又寫滿」

日誌輪轉與限額是關鍵。但如果在你還沒完成配置前就已重新啟動，建議先調低 log level 或暫時降低寫出頻率（若應用支援）。

如果你無法調整應用，就至少先把輪轉策略啟用，並確保 logrotate 能正常執行。

第六章：落實預防——輪轉、限額與監控才是長久解法

騰訊雲帳號購買 清理只是恢復可用性；預防才是讓你不必再次經歷「系統崩潰」。下面的策略你可以依照你的環境逐項落地。

6.1 logrotate：設定要有「輪轉 + 壓縮 + 保留數量」

以 /etc/logrotate.d/ 為例，你可能需要為特定服務寫一個配置檔。核心字段通常包括：

• daily 或 weekly（輪轉頻率）
• rotate N（保留 N 份）
• compress（壓縮舊檔節省空間）
• missingok（檔案不存在不報錯）
• notifempty（空檔不輪轉）
• copytruncate 或使用適當策略避免服務崩潰（依服務而定）

你可以先以「你實際的日誌檔路徑」為準，避免設定對不上。很多問題就出在配置檔寫對了，但實際日誌路徑在別處。

6.2 為關鍵目錄做獨立掛載（建議）

如果你能調整架構，最可靠的方式是把日誌目錄單獨掛載，讓 / 不會被吃光。常見做法是：

• 騰訊雲帳號購買 將 /var/log 或 /var/lib/docker/containers 對應的分區獨立
• 或者把容器日誌落在單獨磁碟

這樣即使某個服務異常爆量，也不至於整台機器完全失去服務能力。

6.3 監控與告警：別等到 100%

監控的價值不在於告訴你「已經滿了」，而在於讓你在 70%~80% 就能提前處理。你至少應該監控：

• 磁碟使用率（按分區）
• 日誌增長速度（近 10 分鐘/1 小時變化）
• 關鍵服務錯誤率（出現錯誤風暴時，日誌爆量通常緊隨其後）

當告警出現時，不要只看「磁碟已滿」的告警文字，而要快速回到本文的定位流程：是哪個目錄/檔案在增長。

6.4 設定容器日誌輪轉（如果你使用 Docker/K8s）

騰訊雲帳號購買 如果是 Docker，確保啟用 log driver 的輪轉限制，例如設置 max-size 和 max-file（具體如何配置取決於你的啟動方式）。如果是 K8s，則要檢查 container log 的採集方式與 retention 策略。

原則是：容器日誌也要有上限，不能讓它們無限制地寫入宿主磁碟。

第七章：把事件做成可重複的排查清單

每次「日誌佔滿」事件都不必從零開始。你可以把排查流程做成內部清單，讓團隊每次照流程執行：

• df 檢查：是哪個分區滿了
• du 掃描：找出最大目錄/檔案
• lsof 檢查：是否仍被寫入
• 止血：停止寫入者，再截斷或清理
• 驗證：df 是否釋放，服務是否恢復
• 修復根因：logrotate/容器輪轉/應用 log level/攻擊或錯誤源
• 監控落地：設告警與節點預警

當你把這些步驟固定化，未來遇到同類問題，處理時間會明顯縮短，也更不容易做出危險操作。

第八章：結語——真正的解法不是「刪掉」，而是「讓日誌有邊界」

伺服器被日誌佔滿並崩潰，表面上是「日誌太多」，深層原因是「沒有邊界」。日誌需要輪轉，需要保留策略，需要壓縮與限額；同時也需要針對異常流量或錯誤風暴做源頭治理。你在清理時用對了順序——先停止寫入者、再截斷或輪轉、再驗證釋放與恢復服務——就能快速把機器拉回可用狀態。

當你最後落實預防措施（logrotate、容器日誌輪轉、分區隔離、監控告警），這類事件就不會反覆上演。你不必每次都靠「運氣」活下來；你可以靠流程把風險壓到可控範圍。

如果你願意在下一步提供你實際看到的關鍵資訊（例如 df -h 的輸出、最大日誌檔案的路徑與大小、是否是 Docker/容器），我可以再把清理方案精準化到你的環境，讓每一步都更短、更安全。