需要一套指標系統，還是內建檢視已經能回答問題？

幾乎每個家用實驗室都會經歷這個階段：有人架好一套指標系統、做出漂亮的儀表板，然後就再也沒打開過。這通常被解讀為缺乏自律。更常見的原因其實是錯配：這套系統在回答一個沒人在問的問題。

警示與指標看起來像同一件事，其實不是。警示回答的是現在是否出了問題。指標回答的是當時發生了什麼。需要哪一種，完全取決於實際會問的問題。

決定關鍵的問題

問題不在於該不該監控伺服器，因為當然該。該問的是：答案需要回溯到多久以前？

現在壞了嗎？內建檢視就能回答。目前的負載、記憶體、磁碟使用量、哪些客體正在執行。為了這個問題加裝指標系統，只會多一項服務，卻得不到任何新答案。

上週二凌晨三點左右是不是很慢？這時就需要歷史資料，而內建功能無法以那樣的解析度保存那麼長的時間。這才是執行指標系統的真正理由，而且是個好理由。

春天之前磁碟空間會不會用完？這需要一條趨勢線，也就是在歷史資料上再加一點運算。這也是真正的理由。

這兩項變更中，哪一項讓速度變快？這需要把變更前後放在同一張圖中比較。真正的理由。

如果實際會問的問題都不需要回溯到昨天以前，指標系統就是一種嗜好，而不是工具。擁有這種嗜好完全沒問題，只是值得清楚知道正在打造的是哪一種。

坦白說，它的代價

它是另一項需要維持運作的服務。一套已經停擺三週的指標系統比沒有更糟，因為會以為手上有歷史資料，其實沒有。

它通常就執行在被監控的那台機器上。這是值得點名的陷阱：主機出狀況的那一晚，那一晚的記錄也跟著一起消失。最想看的那張圖，偏偏在事情變得值得一看的那一刻停止寫入。

儲存空間悄悄增長。少數幾台客體的細粒度指標，累積速度比多數人預期的快，而且在磁碟塞滿之前，這種增長完全看不出來。

儀表板會老化。為去年某個問題建立的面板，在問題解決很久之後仍持續佔據畫面空間。

讓它值得的兩個習慣

把記錄者放在被記錄者以外的地方。即使是放在別處的一台小機器，即使很便宜也好。如果做不到，至少要知道歷史資料與主機命運相同，並把圖表當成方便的參考，而不是證據。

先決定保留期限，再決定解析度。多數人先挑擷取間隔，事後才發現儲存成本。比較有用的順序正好相反：先決定需要回顧多久，再選擇能放進願意提供的空間的解析度。保留一週的三十秒資料，通常不如保留一年的五分鐘資料有用。

Proxmox 已經提供的功能

比多數人以為的多。不需要安裝任何東西，就內建了每個節點與每台客體的圖表，涵蓋處理器、記憶體、網路與磁碟，並可切換多種時間範圍。對於只有一台主機、少數幾台客體的環境，這已能回答大部分昨天是不是很忙之類的問題。

另外也有一種有文件說明的方式，可以把指標推送到外部的時間序列資料庫，這是確定需要時官方支援的路徑。這點很重要：代表選擇不是東拼西湊，而是一種有支援的交接方式。

本文不是在說什麼

不是反對 Grafana。它確實非常出色，對於多台主機或長期容量規劃的問題，沒有替代品。

不是主張儀表板沒有用。一個每週都會打開的儀表板，勝過十個建好就忘掉的。

Atlas 會做什麼，不會做什麼

Atlas 不是指標系統，也不打算成為指標系統。它沒有時間序列資料庫，不會保存數個月的細粒度歷史資料；如果問題是上週二 03:14 網路狀況如何，Atlas 是錯的工具，Grafana 才是對的工具。

Atlas 回答的是另一個問題：今天這裡有沒有需要親自處理的事。每日摘要涵蓋非預期的重新啟動、已安裝但尚未用於開機的核心、最新備份距今多久、磁碟與記憶體壓力，以及已停止的關鍵客體。這些是關於現在的是非題答案，而不是關於過去的趨勢。

兩者唯一重疊的地方是容量，而 Atlas 在這方面刻意保持淺層：它回報的是當下的壓力，而不是推算一條曲線。如果需要那條曲線，那就是指標系統的工作，誠實的建議是架一套。

把這些話說清楚的理由，與這個 wiki 其他內容存在的理由相同。一個會說明自己不做什麼的工具，在它能做的事情上更值得信任。