昨晚發生了某件事：記錄實際上在哪裡

機器在夜裡重新啟動了，而且沒有人要求它這麼做。一切都已恢復執行，沒有明顯故障，任何人唯一能誠實說出的就是：發生了某件事。

監控有三種記錄，各自回答不同的問題。警示說明發生了某件事。指標說明它呈現什麼樣貌。記錄說明為什麼。本文談的是第三種，以及一個尷尬的事實：涵蓋關鍵那一分鐘的記錄，正是最可能已經消失的那一份。

第一個問題比想像中更小

在提出硬體理論之前，先問最便宜的問題：它是被關機，還是自己倒下的？

一行就能回答。正常關機會在上一次開機的系統記錄（journal）結尾留下特徵：記錄服務記下它被要求停止，接著記下它已停止。斷電的機器則完全沒有結尾，記錄就停在日常活動的中途。

這一個區別就把整個調查切成兩半。有正常結尾，代表有某個東西決定重新啟動，所以要找出是誰提出的要求：一次更新、一個看門狗、一項排程工作，或一個人。沒有結尾，代表機器被中斷了，所以要檢查電源、溫度、記憶體，以及底下的儲存空間。

但前提是上一次開機的記錄還在

陷阱就在這裡。只有在磁碟上存在某個特定目錄時，journal 才會持續保存歷史。這個目錄不存在時，journal 只存在於記憶體中，每次重新啟動都會抹掉前來尋找的那份證據。沒有錯誤，也沒有警告；查詢上一次開機時，得到的答案只是沒有這次開機。

這件事值得在平靜的午後檢查，而不是等到需要它的那個早晨。它只是一個目錄，卻決定了是真的有記錄，還是只是以為有記錄。

它和另一個值得提兩次的陷阱是同一種形狀：記錄器和它所記錄的對象同生共死。最想看的圖表，正是在事情變得有趣的那一刻停止寫入的那一張；最想看的記錄，則來自那次已經不存在的開機。

網路上一半的教學叫人去讀的那個檔案，可能根本不存在

在目前的安裝上實測，Proxmox VE 9.2.6 搭配 Debian 13.6：傳統的系統記錄常駐程式沒有安裝，/var/log/syslog 也不存在。

這件事比聽起來更重要。過去十五年寫下的疑難排解建議，有很大一部分開頭就是檢查 /var/log/syslog。在目前的機器上，這個指令什麼也不會回傳，而對一個正承受壓力的人來說，這個結果讀起來像是我沒有任何記錄，而不是我找錯地方了。現在的系統記錄就是 journal，而且要用查詢的方式讀取，不是用編輯器打開。

Proxmox 還保有第二份記錄，而它回答的是另一個問題

在系統 journal 之外，Proxmox VE 另外保有自己的工作記錄。每一項透過網頁介面或 API 啟動的操作都會成為一個工作，具有識別碼、開始時間、結束時間和最終狀態，並且在個別的工作檔案旁還有一份索引。在一台實驗室主機上，這份索引有 283 行，背後約有 960 個工作檔案。

這兩份記錄擅長的事情不同。journal 擅長回答系統當時在做什麼。工作記錄擅長回答誰要求了什麼，以及它是否完成。當一台虛擬機器有個沒有人記得建立過的快照，或某項變更出現卻找不到作者時，工作記錄通常比 journal 更快給出答案，因為它是一份意圖的清單，而不是一串事件流。

在需要歷史之前，先決定上限

journal 的上限預設是以檔案系統的比例表示，而不是以時間長度表示。在上述實測的主機上，沒有設定明確的上限，journal 已經成長到約 276 MB。

有兩個數字值得事先知道：journal 可以占用多少空間，以及在這台機器上，這些空間實際上能往回涵蓋多久。順序很重要，而且和指標適用的順序相同。先決定需要往回看多遠，再選擇能涵蓋那麼遠的設定。等到事故發生時才去找答案，就等於發現答案是不夠遠。

Atlas 做什麼，不做什麼

Atlas 不會取代 journal，也不會試圖代替管理員閱讀記錄。這裡沒有記錄搜尋功能，若宣稱有，只會讓人在某個早晨措手不及。

Atlas 承擔的是前一半：每日摘要會把一次非計畫性的重新啟動當作事實回報，附上機器與時間，讓這個問題至少會被提出。閱讀記錄的仍是管理員本人，答案也仍然在 journal 裡。

這個區別正是重點所在。昨晚最糟的版本，不是開著錯誤的檔案去調查的那次重新啟動，而是根本沒有人注意到的那次重新啟動，因為一份從來沒有人打開的記錄，什麼也回答不了。