如何解決 systemd 日誌滿載的問題

systemd 日誌會儲存伺服器產生的每則記錄訊息，若在根分割區較小的 VPS 上，它可能會悄無聲息地耗盡您的可用磁碟空間。一旦發生這種情況，服務將無法啟動、寫入作業會停滯，而您也將失去用來釐清問題根源的關鍵診斷資料。本指南將說明如何診斷問題、立即釋放空間，並設定 journald 以防止此情況再次發生。

問題診斷

首先檢查日誌檔案佔用了多少空間：

journalctl --disk-usage

此處顯示所有活躍與歸檔日誌檔案的總大小。請將其與您的可用磁碟空間進行比較，使用 df -h。在 20 GB 的根分區中，即使 2 GB 的日誌也佔總磁碟空間的 10% 以上，這足以引發問題。

接著，找出哪些服務產生了最多的日誌。這行指令會列出過去 24 小時內前 10 大日誌來源：

journalctl --since "24 hours ago" | awk '{print $5}' | cut -d'[' -f1 | sort | uniq -c | sort -rn | head -10

使用 journalctl -p err -b 來篩選錯誤訊息，以確認是否有單一服務陷入崩潰循環並淹沒日誌。您也可以檢查 journald 是否對任何服務進行了速率限制：

journalctl -u systemd-journald | grep -i "suppressed"

被壓制的訊息表示某項服務在 30 秒內超過了 10,000 筆條目的預設閾值。那就是肇事者。

在 VPS 實例上，有幾種情況特別常見。如果 Storage=auto 已設定且 /var/log/journal/ 且該檔案存在，journald 會使用持久儲存空間，其預設上限約為 4 GB。在較小的根分區上，此空間會迅速耗盡。非正常關機也可能留下帶有 .journal~ 後綴。這些檔案無法正常輪替，會持續佔用空間。

安全清除日誌

在刪除任何內容之前，請先輪替活躍的日誌檔案，以保留當前日誌：

journalctl --rotate

接著清理歸檔的日誌。您可以根據時間、大小或檔案數量進行篩選：

sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-files=5

第一個指令會刪除超過 24 小時的日誌。第二個指令會將日誌總大小縮減至 100 MB。第三個指令則僅保留最近的五個歸檔檔案。請選擇最符合您現況的選項。

若磁碟空間已完全滿載且 journalctl 指令無回應，您可能需要手動刪除日誌檔案：

sudo rm -rf /var/log/journal/*
sudo systemd-tmpfiles --create --prefix /var/log/journal

此為最後手段。此操作將清除所有儲存的日誌，並以正確權限重新建立目錄。完成任何清理後，請重新啟動守護程序並進行驗證：

sudo systemctl restart systemd-journald
journalctl --disk-usage

設定 Journald 大小限制

預設的 journald 設定相當寬鬆。在 VPS 上，這些設定甚至過於寬鬆。請編輯設定檔以對日誌儲存空間設定硬性上限。建議建立覆寫檔案而非直接編輯主設定檔，如此一來您的變更才能在套件更新後保留：

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/size-limits.conf

關鍵指令：

同時設定兩者 SystemMaxUse 和 SystemKeepFree 可提供雙重保障：日誌會限制在固定大小，且無論磁碟上還有什麼內容，系統總是有餘裕。

持久性儲存與暫存性儲存

`logs` Storage= 指令控制日誌的儲存位置。設定 Storage=persistent 將日誌寫入 /var/log/journal/ 。這正是生產伺服器所需的設定，因為日誌在重新開機後仍會保留，您可事後調查系統當機原因。若目錄不存在，則會自動建立：

sudo mkdir -p /var/log/journal

另一種選擇， Storage=volatile則將日誌保留在 RAM 中的 /run/log/journal/。重啟後日誌將消失。此模式適用於短暫存在的容器，或會將所有日誌轉發至外部系統的伺服器。

在高流量伺服器上停用壓縮

Journald 預設會壓縮大於 512 位元的資料物件。在處理大量日誌吞吐量的伺服器上，這會增加 CPU 負載。若您將日誌轉發至外部且無需最小化本地儲存空間，請設定 Compress=no 若您將日誌轉發至外部且無需最小化本地儲存空間。同時請在生產環境中設定 ForwardToConsole=no 。主控台轉發是同步的，若虛擬序列主控台陷入停滯，可能會完全阻塞 journald 守護程序。

進行任何設定變更後，請重新啟動服務：

sudo systemctl restart systemd-journald

自動化日誌維護

手動清理無法擴展。請建立一個 systemd 定時器，以排程方式清理日誌。在 /etc/systemd/system/journal-vacuum.service:

[Unit]
Description=Vacuum old journal logs
 
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d --vacuum-size=500M

接著在 /etc/systemd/system/journal-vacuum.timer:

[Unit]
Description=Weekly journal vacuum
 
[Timer]
OnCalendar=Sun 02:00
Persistent=true
 
[Install]
WantedBy=timers.target

透過 sudo systemctl enable --now journal-vacuum.timer。此定時器每週日凌晨 2 點執行，並在單次處理中同時套用基於時間與基於大小的保留規則。

有一點是定時器無法處理的：損壞的日誌檔案。在發生非正常關機後，journald 會透過在檔案名稱後附加 ~ 。這些 .journal~ 檔案仍會佔用磁碟空間，但不會被自動清理。請定期檢查並移除舊檔案：

find /var/log/journal/ -name "*.journal~" -mtime +30 -delete

將日誌轉發至外部

對於需要長期保留日誌但又不希望增加本地儲存空間的伺服器，請將日誌轉發至集中式系統。最簡單的方法是在 journald.conf:

ForwardToSyslog=yes

對於包含完整元資料（PID、UID、單元名稱）的結構化日誌，請使用 systemd-journal-remote 將 JSON 格式的記錄條目傳送至日誌管理平台。若本地磁碟發生故障或伺服器遭入侵，外部日誌儲存亦能保護您的稽核追蹤紀錄。

結論

系統日誌（systemd journal）填滿的問題既容易解決，也容易預防。關鍵步驟如下：

• 使用 journalctl --disk-usage 並識別會產生過多日誌的服務。
• 立即透過 journalctl --rotate ，接著執行 --vacuum-size 或 --vacuum-time.
• 在 journald.conf 覆寫檔案中設定明確的大小限制。
• 使用 systemd 定時器自動化清理作業。
• 將日誌轉發至外部進行長期保留。

FDC 的 VPS 和專用伺服器方案提供生產環境日誌工作負載所需的磁碟 I/O 及儲存空間。