記錄檔：唯一一個沒有人決定卻會自己長大的東西

填滿磁碟的東西大多是管理者自己加進去的：虛擬機器、備份、安裝映像檔。每一樣都是一個決定。

記錄檔不一樣。它們會變大，只因為系統在運作。從來沒有人下令讓這個檔案變大。

增長很慢，但沒有上限

一個記錄檔一天可能只增長幾 KB。好幾個月都不會引起注意。一年後它仍然很小。

但它沒有上限。而沒有上限的增長，不論多慢，只要等得夠久就會變成問題。

沒人料到的乘數：故障會加速寫入

這才是本文真正的重點。

健康的系統寫得很少。如果某項檢查每次執行都出錯，每次執行就會有一行落進同一個檔案。對每十五分鐘執行一次的工作來說，一天就是 96 行，而且不會停止。

所以記錄檔恰好在最沒有餘力查看它的時候長得最快：也就是故障正在發生的時候。

還有最糟的版本

問題出現，記錄檔加速，磁碟填滿。磁碟滿了又引發新的問題。新的問題又產生更多記錄。

從這時起，找出最初的故障會變得更難，因為畫面上大多數的錯誤，並不是第一個問題造成的，而是磁碟已滿造成的。

原則：凡是會寫入的東西，都必須有上限

以後再清理並不是計畫。需要的是一個機械式的限制，不必靠任何人記得就會自行運作。

這條原則不只適用於系統記錄：它適用於所執行的服務、排程工作與收集器所產生的每一個檔案。

設定輪替時常犯的兩個錯誤

其一：規則因為不存在的檔案而失效。有些檔案只有在使用相關功能時才會出現。規則必須寫成在檔案不存在時不會出錯；否則一個從未使用的功能，就會讓整個輪替工作停擺。

其二：輪替方法錯誤。將檔案改名，再向負責寫入的服務送出重新開啟的訊號，是常見的做法，但只有在存在長時間運作的服務時才有效。如果寫入者是每次開啟又關閉的短暫工作，就沒有對象可以接收訊號；這種情況下正確的方法是複製內容，再就地清空檔案。

兩者都是無聲的失敗：規則就在那裡，檔案持續變大，卻沒有人注意到規則沒有發揮作用。

還有已安裝機器的問題

如果只在安裝腳本中寫入輪替規則，它永遠不會送達在規則出現之前就已安裝的機器。這些機器會在沒有規則的情況下運作好幾年。

正確的做法是在每次啟動時寫入規則：如此一來，較早的安裝在升級到新版本時就會取得它。

Atlas 的做法

整篇文章都來自 Atlas 自己的量測，因此需要誠實說明。

Atlas 在客戶的機器上以 root 身分執行，並寫入多個記錄檔：每十五分鐘一次的 Atlas Watch 摘要、每次執行的排程更新輸出，以及它自己的自我更新記錄。經過量測，它們全都沒有被輪替，因為安裝程式沒有在任何地方寫入輪替規則。在一台實際運作的機器上，Atlas Watch 的記錄在 32 天內已達到 180 KB，而且沒有任何能縮減它的機制。

這個數字看起來很小，當天也不是問題。問題在於增長是沒有上限的，再加上前面描述的加速。排程更新的記錄每次執行都會擷取套件管理器的完整輸出，每次執行可能達到數 MB。

現在規則已經寫入，上述兩個陷阱也都經過刻意處理：容許檔案不存在，而且輪替採用先複製再清空的方法，因為寫入者是由排程工作啟動的短暫程序。

而且規則是在啟動時寫入，而不是寫在安裝腳本中。理由正是上面那個問題：讓較早安裝的機器在升級到新版本時，也能取得這條規則。