前言

本文來自Prometheus官網手冊 和 Prometheus簡介

存儲

Prometheus是一個本地磁盤時間序列數據庫，但也可選擇與遠程存儲系統集成，其本地時間序列數據庫以自定義格式在磁盤上存儲時間序列數據。

1.1 磁盤布局

采集的樣本按每兩個小時的時間段保存到一個目錄，該目錄包含一個或多個塊文件，該文件包含該時間窗口的所有時間序列樣本，以及元數據文件和索引文件（用於將度量名稱和標簽索引到塊文件中的時間序列）。通過API刪除系列時，刪除記錄存儲在單獨的邏輯刪除文件中（而不是立即從塊文件中刪除數據）

當前傳入樣本的塊保存在內存中，但尚未完全保留。通過預寫日志（WAL）防止崩潰，可以在崩潰后重新啟動Prometheus服務器時重放。預寫日志文件以128MB段存儲在wal目錄中。這些文件包含尚未壓縮的原始數據，因此它們比常規塊文件大得多。 Prometheus將保留至少3個預寫日志文件，但是高流量服務器可能會看到三個以上的WAL文件，因為它需要保留至少兩個小時的原始數據。

Prometheus服務器的數據目錄的目錄結構如下所示：

./data
├── 01BKGV7JBM69T2G1BGBGM6KB12
│   └── meta.json
├── 01BKGTZQ1SYQJTR4PB43C8PD98
│   ├── chunks
│   │   └── 000001
│   ├── tombstones
│   ├── index
│   └── meta.json
├── 01BKGTZQ1HHWHV8FBJXW1Y3W0K
│   └── meta.json
├── 01BKGV7JC0RY8A6MACW02A2PJD
│   ├── chunks
│   │   └── 000001
│   ├── tombstones
│   ├── index
│   └── meta.json
└── wal
    ├── 00000002
    └── checkpoint.000001

注意，本地存儲的局限性在於它不是集群或復制的。 因此，面對磁盤或節點中斷，它不是任意可伸縮的或持久的，應該像對待任何其他類型的單節點數據庫一樣對待它。 建議將RAID用於磁盤可用性，快照用於備份，容量規划等，以提高耐用性。 通過適當的存儲耐久性和計划，可以在本地存儲中存儲多年的數據。

或者，可以通過遠程讀/寫API使用外部存儲。 這些系統在耐用性，性能和效率上差異很大，因此需要仔細評估。有關文件格式的更多詳細信息，請參見TSDB格式。

二、壓縮方面

最初的兩個小時的塊最終會在后台壓縮為更長的塊。壓縮將創建較大的塊，按最多保留時間的10％，或21天，以較小者為准。

三、運營方面

Prometheus具有幾個允許配置本地存儲的標志。最重要的是：

• --storage.tsdb.path：這決定了Prometheus寫入數據庫的位置。 默認為data/。
• --storage.tsdb.retention.time：這決定了何時刪除舊數據。 默認為15d。 如果此標志設置為默認值以外的任何值，則覆蓋storage.tsdb.retention。
• --storage.tsdb.retention.size：[EXPERIMENTAL]這確定了存儲塊可以使用的最大字節數（請注意，這不包括WAL大小，這可能很大）。 最早的數據將被刪除。 默認為0或禁用。 此標志是實驗性的，可以在將來的版本中進行更改。 支持的單位：KB，MB，GB，PB。 例如：“512MB”
• --storage.tsdb.retention：不推薦使用此標志，而使用storage.tsdb.retention.time。
• --storage.tsdb.wal-compression：此標志啟用預寫日志（WAL）的壓縮。 根據您的數據，您可以預期WAL大小將減少一半，而額外的CPU負載卻很少。 請注意，如果啟用此標志，然后將Prometheus降級到2.11.0以下的版本，則您將需要刪除WAL，因為它將不可讀。

平均而言，Prometheus每個樣本僅使用大約1-2個字節。 因此，要計划Prometheus服務器的容量，可以使用以下粗略公式：

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

要調整每秒采集樣本的速率，您可以減少抓取的時間序列數（每個目標的目標更少或更少的系列），或者可以增加抓取時間間隔。但是，由於壓縮序列中的樣本，減少序列數可能更有效。

如果您的本地存儲由於某種原因而損壞，最好的選擇是關閉Prometheus並刪除整個存儲目錄。 Prometheus的本地存儲不支持不兼容POSIX的文件系統，可能會發生損壞，無法恢復。 NFS僅是潛在的POSIX，大多數實現不是。您可以嘗試刪除單個塊目錄來解決該問題，這意味着每個塊目錄將損失大約兩個小時的數據時間窗口。同樣，Prometheus的本地存儲並不意味着持久的長期存儲。

如果同時指定了時間和大小保留策略，則在那一刻將使用第一個觸發的策略。過期的塊清除將在后台計划中進行。刪除過期的數據塊可能最多需要兩個小時。過期的塊在清除之前必須完全過期。

四、遠程存儲集成

Prometheus的本地存儲在可伸縮性和持久性方面受到單個節點的限制。 Prometheus並沒有嘗試解決Prometheus本身中的群集存儲，而是提供了一組允許與遠程存儲系統集成的接口。

4.1 概述

Prometheus通過兩種方式與遠程存儲系統集成：

• Prometheus可以將提取的樣本以標准格式寫入遠程URL。
• Prometheus可以以標准化格式從遠程URL讀取（返回）樣本數據。

 

讀寫協議都使用基於HTTP的快速壓縮協議緩沖區編碼。該協議尚未被認為是穩定的API，當可以安全地假定Prometheus和遠程存儲之間的所有躍點都支持HTTP / 2時，該協議將來可能會更改為在HTTP / 2上使用gRPC。

有關在Prometheus中配置遠程存儲集成的詳細信息，請參閱Prometheus配置文檔的“遠程寫入”和“遠程讀取”部分，有關請求和響應消息的詳細信息，請參閱遠程存儲協議緩沖區定義。

注意，在讀取路徑上，Prometheus僅從遠端獲取一組標簽選擇器和時間范圍的原始系列數據。 PromQL對原始數據的所有評估仍然在Prometheus本身中進行。這意味着遠程讀取查詢具有一定的可伸縮性限制，因為所有必需的數據都需要先加載到查詢的Prometheus服務器中，然后在那里進行處理。但是，支持PromQL的完全分布式評估暫時被認為是不可行的。

4.2 現有集成

要了解有關與遠程存儲系統的現有集成的更多信息，請參閱集成文檔。