## STORAGE 存儲
---
Prometheus有一個復雜的本地存儲子系統。對于索引，它使用levelDB。對于批量的樣本數據，它由自己的自定義存儲層，并以固定大小（1024個字節有效負載）的塊組織樣本數據。然后將這些塊存儲在每個時間序列的一個文件中的磁盤上。
### Memory usage 內存使用量
Prometheus將所有當前使用的塊保留在內存中。此外，它將最新使用的塊保留在內存中，最大內存可以通過`storage.local.memory-chunks`標志配置。如果你有較多的可用內存，你可能希望將其增加到默認值1048576字節以上（反之亦然，如果遇到RAM問題，可以嘗試減少內存值）。請注意，服務器的實際RAM使用率將高于將`storage.local.memory-chunks`*1024字節所期望的RAM使用率。管理存儲層中的樣本數據是不可避免的開銷。此外，服務器正在做更多的事情，而不僅僅存儲樣本數據。實際開銷取決于你的使用模式。在極端情況下，Prometheus必須保持更多的內存塊，而不是配置，因為所有這些塊都在同一時間使用。你必須試一下。Prometheus導出導出的度量指標`prometheus_local_storage_memory_chunks`和`process_resident_memory_bytes`將派上用場。作為經驗法則，你應該至少擁有內存塊所需三倍以上。
設計到大量時間序列的PromQL查詢大量使用LevelDB支持的索引。如果需要運行這種查詢，則可能需要調整索引緩存大小。以下標志是相關的：
- `-storage.local.index-cache-size.label-name-to-label-values`: 正則表達式匹配
- `-storage.local.index-cache-size.label-pair-to-fingerprints`: 如果大量的時間序列共享相同的標簽，增加內存大小
- `-storage.local.index-cache-size.fingerprint-to-metric` and `-storage.local.index-cache-size.fingerprint-to-timerange`: 如果你有大量的目標時間序列，例如：一段時間還沒有被接收的樣本數據時間序列，但是數據又還沒有失效。這時也需要增加內存.
你必須嘗試使用flag，才能找出有用的。如果一個查詢觸及到100000多個時間序列數據，幾百M內存使用可能是合理的。如果你有足夠的內存可用，對于LevelDB使用更多的內存不會有任何傷害。
### 磁盤使用量 disk usage
Prometheus存儲時間序列在磁盤上，目錄由flag `storage.local.path`指定。默認path是`./data`（關聯到工作目錄），這是很好的快速嘗試，但很可能不是你想要的實際操作。這個flag`stroage.local.retention`允許你配置這個保留的樣本數據。根據你的需求和你的可用磁盤空間做出合適的調整。
### Chunking encoding
Prometheus當前提供三種不同類型的塊編碼（chunk encodings）。對于新創建塊的編碼由flag `-storage.local.chunk-encoding-version`決定。 有效值分別是0，1和2.
對于Prometheus的第一塊存儲存，類型值為0實現了delta編碼。類型值為1是當前默認編碼, 這是有更好的壓縮算法的雙delta編碼，比類型值為0的delta編碼要好。這兩種編碼在整個塊中都具有固定的每個樣本字節寬度，這允許快速隨機訪問。然而類型值為0 的delta編碼是最快的編碼，與類型值為1的編碼相比，編碼成本的差異很小。由于具有更好的壓縮算法的編碼1，除了兼容Prometheus更老的版本，一般建議使用編碼1。
類型2是可變寬度的編碼，例如：在塊中的每個樣本能夠使用一個不同數量的bit位數。時間戳也是雙delta編碼。但是算法稍微有點不同。一些不同編碼范式對于樣本值都是可用的。根據樣本值類型來決定使用哪種編碼范式，樣本值類型有：constant，int型，遞增，隨機等
編碼2的主要部分的靈感來源于Facebook工程師發表的一篇論文：[Gorilla: A Fast, Scalable, In-Memory Time Series Database](http://www.vldb.org/pvldb/vol8/p1816-teller.pdf)
編碼2必須順序地訪問塊，并且編解碼的代價比較高。總體來看，對比編碼1，編碼2造成了更高的CPU使用量和增加了查詢延時，但是它提供一個改進的壓縮比。準確值非常依賴于數據集和查詢類型。下面的結果來自典型的生產環境的服務器中：
| 塊編碼類型 | 每個樣本數據占用的比特位數 | CPU核數 | 規則評估時間 |
| ---------- | -------------------------: | -------:| :----------: |
| 1 | 3.3 | 1.6 | 2.9s |
| 2 | 1.3 | 2.4 | 4.9s |
每次啟動Prometheus服務時，你可以改變塊的編碼類型，因此在實驗中測試不同編碼類型是我們非常鼓勵的。但是考慮到，僅僅是新創建的塊會使用新選擇塊編碼，因此你將需要一段時間才能看到效果。
### 設置大量時間序列數據
Prometheus能夠處理百萬級別的時間序列數據。然而，你必須調整存儲設置到處理多余100000活躍的時間序列。基本上，對于每個時間序列要存儲到內存中，你想要允許這幾個確定數量的塊。對于`storage.local.memory-chunks`flag標志的默認值是1048567。高達300000個時間序列時，平均來看，每個時間序列仍然有三個可用的塊。對于更多的時間序列，應該增加`storage.local.memory-chunks`值。三倍于時間序列的數量是一個非常好的近似值。但請注意內存使用的含義（見上文）。
如果你比配置的內存塊有更多的時間序列數據，Prometheus不可避免地遇到一種情況，它必須保持比配置更多的內存塊。如果使用塊數量超過配置限制的10%， Prometheus將會減少獲取的樣本數據量（通過skip scrape和rule evaluation）直到減少到超過配置的5%。減少獲取樣本數量是非常糟糕的情況，這是你我都不愿意看到的。
同樣重要地，特別是如果寫入磁盤，會增長`storage.local.max-chunks-to-persist`flag值。根據經驗，保持它是`storage.local.memory-chunks`值的50%是比較好的。`storage.local.max-chunks-to-persist`控制了多少塊等待寫入到你的存儲設備，它既可以是spinning磁盤，也可以是SSD。如果等待塊過多，這Prometheus將會減少獲取樣本數量，知道等待寫入的樣本數量下降到配置值的95%以下。在發生這種情況之前，Prometheus試著加速寫入塊。詳見[文檔](https://prometheus.io/docs/operating/storage/#persistence-pressure-and-rushed-mode)
每個時間序列可以保留更多的內存塊，你就可以批量編寫更多的寫操作。對spinning磁盤是相當重要的。注意每個活躍的時間序列將會有個不完整的頭塊，目前還不能被持久化。它是在內存的塊，不是磁盤塊數據。如果你有1M的活躍時間序列數據，你需要3M`storage.local.memory-chunks`塊，為每個時間序列提供可用的3塊內存。僅僅有2M可持久化，因此設置`storage.local.max-to-persist`值大于2M，可以很容易地讓內存超過3M塊。盡管存儲`storage.local.memory-chunks`的設置，這再次導致可怕的減少樣本數量（Prometheus服務將盡快再此出現之前加速消費）。
等待持久性塊的高價值的另一個缺點是檢查點較大。
如果將大量時間序列與非常快速和/或較大的scrapes相結合，則預先分配的時間序列互斥所可能不會很奏效。如果你在Prometheus服務正在編寫檢查點或者處理代價大的查詢時，看到獲取較慢，請嘗試增加`storage.local.num-fingerprint-mutexes`flag值。有時需要數萬甚至更多。
### 持續壓力和“沖動模式” Persist pressure and “rushed mode”
本質上，Prometheus服務將盡可能快遞將完成的塊持久化到磁盤上。這樣的策略可能會導致許多小的寫入操作，會占用更多的I/O帶寬并保持服務器的繁忙。spinning磁盤在這里更加敏感，但是即使是SSD也不會喜歡這樣。Prometheus試圖盡可能的批量編寫寫操作，如果允許使用更多的內存，這樣做法更好。因此，將上述flag設置為導致充分利用可用內存的值對于高性能非常重要。
Prometheus還將在每次寫入后同步時間序列文件（使用`storage.local.series-sync-strategy = adaptive`, 這是默認值）， 并將磁盤帶寬用于更頻繁的檢查點（根據“臟的時間序列”的計數，見下文），都試圖在崩潰的情況下最小化數據丟失。
但是，如果等待寫入的塊數量增長太多，怎么辦？Prometheus計算一個持久塊的緊急度分數，這取決于等待與`storage.local.max-chunks-to-persist`值相關的持久性的快數量，以及內存中的快數量超過存儲空間的數量。`local.memory-chunks`值（如果有的話，只有等待持久性的塊的最小數量，以便更快的幫助）。分數在0~1.其中1是指對應于最高的緊急程度。根據得分，Prometheus將更頻繁地寫入磁盤。如果得分超過0.8的門檻，Prometheus將進入“沖動模式”（你可以在日志中國看到）。在沖動模式下，采用以下策略來加速持久化塊：
- 時間序列文件不再在寫操作之后同步（更好地利用操作系統的頁面緩存，在服務器崩潰的情況下，丟失數據的風險會增加）， 這個行為通過`storage.local.series-sync-strategy`flag。
- 檢查點僅僅通過`storage.local.checkpoint-interval`flag啟動配置時創建（對于持久化塊，以崩潰的情況下更多丟失數據的代碼和運行隨后崩潰恢復的時間增加，來釋放更多的磁盤帶寬）
- 對于持久化塊的寫操作不再被限制，并且盡可能快地執行。
一段得分下降到0.7以下，Prometheus將退出沖動模式。
### 設置更長的保留時間 setting for very long retention time
如果你有通過`storage.local.retention`flag(超過一個月), 設置一個更長的留存時間，你可能想要增加`storage.local.series-file-shrink-ratio`flag值。
每當Prometheus需要從一系列文件的開頭切斷一些塊時，它將簡單地重寫整個文件。（某些文件系統支持“頭截斷”，Prometheus目前由于幾個原因目前不使用）。為了不重寫一個非常大的系列文件來擺脫很少的塊，重寫只會發生在至少10％的塊中 系列文件被刪除。 該值可以通過上述的`storage.local.series-file-shrink-ratio`flag來更改。 如果您有很多磁盤空間，但希望最小化重寫（以浪費磁盤空間為代價），請將標志值增加到更高的值，例如。 30％所需的塊刪除為0.3。
### 有用的度量指標
在Prometheus暴露自己的度量指標之外，以下內容對于調整上述flag特別有用：
- prometheus_local_storage_memory_series: 時間序列持有的內存當前塊數量
- prometheus_local_storage_memory_chunks: 在內存中持久塊的當前數量
- `prometheus_local_storage_chunks_to_persist`: 當前仍然需要持久化到磁盤的的內存塊數量
- `prometheus_local_storage_persistence_urgency_score`: 上述討論的緊急程度分數
- 如果Prometheus處于沖動模式下，`prometheus_local_storage_rushed_mode`值等于1; 否則等于0.
### Crash恢復 Carsh Recovery
Prometheus在完成后盡快將塊保存到磁盤。常規檢查點中不完整的塊保存到磁盤。您可以使用`storage.local.checkpoint-interval`flag配置檢查點間隔。如果太多的時間序列處于“臟”狀態，那么Prometheus更頻繁地創建檢查點，即它們當前的不完整的頭部塊不是包含在最近檢查點中的。此限制可通過`storage.local.checkpoint-dirty-series-limit`flag進行配置。
然而，如果您的服務器崩潰，您可能仍然丟失數據，并且您的存儲空間可能處于不一致的狀態。因此，Prometheus在意外關機后執行崩潰恢復，類似于文件系統的fsck運行。將記錄關于崩潰恢復的詳細信息，因此如果需要，您可以將其用于取證。無法恢復的數據被移動到名為孤立的目錄（位于storage.local.path下）。如果不再需要，請記住刪除該數據。
崩潰恢復通常需要不到一分鐘。如果需要更長時間，請咨詢日志，以了解出現的問題。
### Data corrution 數據損壞
如果您懷疑數據庫中的損壞引起的問題，則可以通過使用`storage.local.dirty`flag啟動服務器來強制執行崩潰恢復。
如果沒有幫助，或者如果您只想刪除現有的數據庫，可以通過刪除存儲目錄的內容輕松地啟動：
1. stop prometheus.
2. `rm -r <storage path>/*`
3. start prometheus
