Prometheus 的架構設計圖
通過prometheus的架構圖可以看出，prometheus提供了本地存儲，即tsdb時序數據庫。本地存儲的優勢就是運維簡單,缺點就是無法海量的metrics持久化和數據存在丟失的風險，我們在實際使用過程中，出現過幾次wal文件損壞，無法再寫入的問題。
當然prometheus2.0以後壓縮數據能力得到了很大的提升。爲了解決單節點存儲的限制，prometheus沒有自己實現集羣存儲，而是提供了遠程讀寫的接口，讓用戶自己選擇合適的時序數據庫來實現prometheus的擴展性。
prometheus通過下面兩種方式來實現與其他的遠端存儲系統對接
- Prometheus 按照標準的格式將metrics寫到遠端存儲
- prometheus 按照標準格式從遠端的url來讀取metrics
- Prometheus按2小時一個block進行存儲，每個block由一個目錄組成，該目錄裏包含：一個或者多個chunk文件（保存timeseries數據）、一個metadata文件、一個index文件（通過metric name和labels查找timeseries數據在chunk文件的位置）。最新寫入的數據保存在內存block中，達到2小時後寫入磁盤。爲了防止程序崩潰導致數據丟失，實現了WAL（write-ahead-log）機制，啓動時會以寫入日誌(WAL)的方式來實現重播，從而恢復數據。刪除數據時，刪除條目會記錄在獨立的tombstone文件中，而不是立即從chunk文件刪除。通過時間窗口的形式保存所有的樣本數據，可以明顯提高Prometheus的查詢效率，當查詢一段時間範圍內的所有樣本數據時，只需要簡單的從落在該範圍內的塊中查詢數據即可。這些2小時的block會在後臺壓縮成更大的block，數據壓縮合併成更高level的block文件後刪除低level的block文件。這個和leveldb、rocksdb等LSM樹的思路一致。這些設計和Gorilla的設計高度相似，所以Prometheus幾乎就是等於一個緩存TSDB。它本地存儲的特點決定了它不能用於long-term數據存儲，只能用於短期窗口的timeseries數據保存和查詢，並且不具有高可用性（宕機會導致歷史數據無法讀取）。