文章的翻譯是專門為課程的學生準備的 .
是一名軟體開發人員、Go 狂熱者和問題解決者。他也是 Prometheus 維護者和 Kubernetes SIG 工具的聯合創始人。過去，他是 SoundCloud 的生產工程師，並領導 CoreOS 的監控團隊。目前在谷歌工作。
- Improbable 的基礎設施工程師。他對分散式系統的新技術和問題感興趣。他擁有 Intel 的底層程式設計經驗、Mesos 的貢獻者經驗以及 Improbable 的世界級 SRE 生產經驗。致力於改善微服務世界。他的三大愛好：Golang、開源和排球。
看看我們的旗艦產品 SpatialOS，您可以猜測 Improbable 需要一個高度動態的、全球規模的雲端基礎設施，其中包含數十個 Kubernetes 叢集。我們是最早使用監控系統的公司之一 。 Prometheus 能夠即時追蹤數百萬個指標，並附帶強大的查詢語言，可讓您提取所需的資訊。
Prometheus 的簡單性和可靠性是其主要優點之一。然而，一旦超過某個規模，我們就會遇到一些缺點。為了解決這些問題我們開發了 是由 Improbable 創建的一個開源項目，旨在將現有的 Prometheus 叢集無縫轉換為具有無限歷史資料儲存的單一監控系統。 Thanos 已在 Github 上提供 .
我們與薩諾斯的目標
在一定規模上，出現的問題超出了普通普羅米修斯的能力。如何可靠且經濟地儲存 PB 級歷史資料？這可以在不影響反應時間的情況下完成嗎？是否可以透過單一 API 請求存取位於不同 Prometheus 伺服器上的所有指標？有什麼方法可以合併使用 Prometheus HA 收集的複製資料嗎？
為了解決這些問題，我們創建了薩諾斯。以下部分描述了我們如何解決這些問題並解釋我們的目標。
查詢多個Prometheus實例的資料（全域查詢）
Prometheus 提供了一種功能性的分片方法。即使單一 Prometheus 伺服器也能提供足夠的可擴展性，使用戶在幾乎所有用例中擺脫水平分片的複雜性。
雖然這是一個很好的部署模型，但通常需要透過單一 API 或 UI（全域視圖）存取不同 Prometheus 伺服器上的資料。當然，可以在一個 Grafana 面板中顯示多個查詢，但每個查詢只能在一台 Prometheus 伺服器上執行。另一方面，使用 Thanos，您可以查詢和聚合來自多個 Prometheus 伺服器的數據，因為它們都可以從單一端點存取。
之前，為了取得 Improbable 的全域視圖，我們將 Prometheus 實例組織成多層級 。這意味著創建一個 Prometheus 元伺服器，從每個葉伺服器收集一些指標。
事實證明這種方法是有問題的。這導致了更複雜的配置、增加了額外的潛在故障點以及應用複雜的規則來確保聯合端點僅接收其所需的資料。此外，這種聯合不允許您獲得真正的全域視圖，因為並非所有資料都可以透過單一 API 請求取得。
與此密切相關的是高可用性（HA）Prometheus 伺服器上收集的資料的統一視圖。 Prometheus的HA模型獨立收集兩次數據，簡單得不能再簡單了。然而，使用兩個串流的組合和重複資料刪除視圖會方便得多。
當然，需要高可用的 Prometheus 伺服器。在 Improbable，我們非常重視每分鐘的資料監控，但每個叢集只有一個 Prometheus 實例會導致單點故障。任何配置錯誤或硬體故障都可能導致重要資料遺失。即使是簡單的部署也可能會導致指標收集出現輕微中斷，因為重新啟動的時間可能明顯長於抓取間隔。
歷史資料的可靠存儲
廉價、快速、長期的指標儲存是我們的夢想（大多數 Prometheus 用戶都有這個夢想）。在 Improbable 中，我們被迫將指標保留期配置為 1.8 天（對於 Prometheus XNUMX）。這明顯限制了我們的回顧能力。
Prometheus 2.0 在這方面有所改進，因為時間序列的數量不再影響伺服器的整體效能（請參閱。 ）。然而，Prometheus 將資料儲存在本機磁碟上。雖然高效率的資料壓縮可以顯著減少本地SSD的使用，但最終可以儲存的歷史資料量仍然是有限的。
此外，在 Improbable，我們關心可靠性、簡單性和成本。大的本機磁碟操作和備份都比較困難。它們成本更高，需要更多備份工具，從而導致不必要的複雜性。
下採樣
一旦我們開始處理歷史數據，我們就意識到 Big-O 存在根本性的困難，當我們處理數週、數月和數年的數據時，這些問題會讓查詢變得越來越慢。
這個問題的標準解決方案是 （下取樣）- 降低訊號取樣頻率。透過下採樣，我們可以「縮小」到更大的時間範圍並保持相同數量的樣本，從而保持查詢回應。
對舊資料進行下採樣是任何長期儲存解決方案的必然要求，並且超出了普通 Prometheus 的範圍。
額外目標
Thanos 專案的最初目標之一是與任何現有的 Prometheus 安裝無縫整合。第二個目標是易於操作，最小化進入障礙。對於小型和大型用戶來說，任何依賴性都應該很容易滿足，這也意味著基礎成本較低。
薩諾斯架構
在上一節中列出我們的目標後，讓我們逐一研究它們，看看 Thanos 如何解決這些問題。
全球視野
為了獲得現有 Prometheus 實例之上的全域視圖，我們需要將單一請求入口點連結到所有伺服器。這正是 Thanos 元件的作用。 。它部署在每個 Prometheus 伺服器旁邊，充當代理，透過 gRPC Store API 提供本地 Prometheus 數據，允許按標籤和時間範圍檢索時間序列資料。
另一方面是橫向擴充、無狀態 Querier 元件，它的作用只不過是透過標準 Prometheus HTTP API 回答 PromQL 查詢。 Quierer、Sidecar 和其他 Thanos 組件透過以下方式進行通信 .
- Querier收到請求後，連接到對應的Store API伺服器，即我們的Sidecar，並從對應的Prometheus伺服器接收時間序列資料。
- 之後，它會組合回應並對它們執行 PromQL 查詢。查詢器可以合併來自 Prometheus HA 伺服器的不相交資料和重複資料。
這解決了我們的一個主要難題 - 將來自孤立的 Prometheus 伺服器的資料組合到一個視圖中。事實上，Thanos只能用於這個功能。無需對現有 Prometheus 伺服器進行任何更改！
保存期限無限！
然而，遲早我們會想要儲存超過正常 Prometheus 保留時間的資料。我們選擇物件儲存來儲存歷史資料。它可廣泛用於任何雲端以及本地資料中心，並且非常具有成本效益。此外，幾乎所有物件儲存都可以透過眾所周知的 S3 API 取得。
Prometheus 大約每兩個小時將資料從 RAM 寫入磁碟。儲存的資料塊包含固定時間內的所有資料且是不可變的。這非常方便，因為 Thanos Sidecar 可以簡單地查看 Prometheus 資料目錄，並在新區塊可用時將它們載入到物件儲存桶中。
寫入磁碟後立即載入到物件儲存中還可以讓您保持抓取器（Prometheus 和 Thanos Sidecar）的簡單性。這簡化了支援、成本和系統設計。
如您所見，資料備份非常簡單。但是查詢物件儲存中的資料呢？
Thanos Store 元件可作為從物件儲存中檢索資料的代理程式。與 Thanos Sidecar 一樣，它參與 gossip 叢集並實作 Store API。這樣，現有的查詢器就可以將其視為 Sidecar，作為時間序列資料的另一個來源 - 無需特殊配置。
時間序列資料塊由多個大檔案組成。按需加載它們的效率非常低，並且在本地緩存它們將需要大量的記憶體和磁碟空間。
相反，Store Gateway 知道如何處理 Prometheus 儲存格式。由於採用智慧型查詢排程器並僅快取區塊的必要索引部分，可以將複雜查詢減少到對物件儲存檔案的 HTTP 請求的最小數量。透過這種方式，您可以將請求數量減少四到六個數量級，並實現通常難以與本地 SSD 上的資料請求區分的回應時間。
如上圖所示，Thanos Querier 透過利用 Prometheus 儲存格式並將相關資料並排放置，顯著降低了物件儲存資料的每次查詢成本。使用這種方法，我們可以將許多單一請求組合成最少數量的批量操作。
壓縮和下取樣
一旦新的時間序列資料塊成功載入到物件儲存中，我們就將其視為「歷史」數據，可以透過 Store Gateway 立即使用。
然而，一段時間後，來自一個來源（帶有 Sidecar 的 Prometheus）的區塊會累積，並且不再使用完整的索引潛力。為了解決這個問題，我們引入了另一個元件，稱為Compactor。它只是將 Prometheus 的本地壓縮引擎應用於物件儲存中的歷史數據，並且可以作為簡單的定期批次作業運行。
由於有效的壓縮，長時間查詢儲存不會造成資料大小的問題。然而，解壓縮十億個值並透過查詢處理器運行它們的潛在成本將不可避免地導致查詢執行時間的急劇增加。另一方面，由於螢幕上每個像素有數百個數據點，因此甚至不可能以全解析度視覺化資料。因此，下採樣不僅是可能的，而且不會導致精度的明顯損失。
為了對資料進行下採樣，Compactor 以五分鐘和一小時的分辨率連續聚合資料。對於使用 TSDB XOR 壓縮編碼的每個原始區塊，儲存不同類型的聚合數據，例如一個區塊的最小值、最大值或總和。這允許 Querier 自動選擇適合給定 PromQL 查詢的聚合。
使用者無需特殊配置即可使用降低精度的資料。當使用者放大和縮小時，查詢器會自動在不同解析度和原始資料之間切換。如果需要，使用者可以直接透過請求中的「step」參數進行控制。
由於儲存 1 GB 的成本較低，Thanos 預設儲存原始資料、五分鐘和一小時解析度資料。無需刪除原始資料。
錄音規則
即使使用 Thanos，記錄規則也是監控堆疊的重要組成部分。它們降低了查詢的複雜性、延遲和成本。它們也方便用戶按指標獲取聚合數據。 Thanos 是基於普通 Prometheus 實例，因此在現有 Prometheus 伺服器上儲存記錄規則和警報規則是完全可以接受的。然而，在某些情況下這可能還不夠：
- 全域警報和規則（例如，當服務無法在三個叢集中的兩個以上運行時發出警報）。
- 本地儲存之外的資料的規則。
- 希望將所有規則和警報存放在一個地方。
對於所有這些情況，Thanos 包含一個名為 Ruler 的獨立元件，它透過 Thanos 查詢計算規則和警報。透過提供眾所周知的 StoreAPI，查詢節點可以存取新計算的指標。隨後，它們也儲存在物件儲存中，並透過 Store Gateway 提供。
薩諾斯的力量
Thanos 足夠靈活，可以根據您的需求進行客製化。從普通的 Prometheus 遷移時，這特別有用。讓我們透過一個簡單的範例快速回顧一下我們對 Thanos 元件的了解。以下是如何將普通 Prometheus 引入「無限指標儲存」的世界：
- 將 Thanos Sidecar 新增至您的 Prometheus 伺服器 - 例如 Kubernetes Pod 中的 Sidecar 容器。
- 部署多個 Thanos Querier 副本以便能夠查看資料。在這個階段，很容易在 Scraper 和 Querier 之間建立八卦。若要檢查組件的交互，請使用「thanos_cluster_members」指標。
只需這兩個步驟就足以從潛在的 Prometheus HA 副本提供全局視圖和無縫重複資料刪除！只需將儀表板連接到 Querier HTTP 端點或直接使用 Thanos UI。
但是，如果您需要指標備份和長期存儲，則需要完成另外三個步驟：
- 建立 AWS S3 或 GCS 儲存桶。配置 Sidecar 將資料複製到這些儲存桶。現在可以最小化本地資料儲存。
- 部署 Store Gateway 並將其連接到現有的 gossip 叢集。現在就可以查詢備份的資料了！
- 部署 Compactor 以使用壓縮和下採樣來提高長時間的查詢效率。
如果您想了解更多，請隨時查看我們的 и !
只需五個步驟，我們就將 Prometheus 變成了一個可靠的監控系統，具有全局視圖、無限的儲存時間和潛在的指標高可用性。
拉取請求：我們需要你！
從一開始就是一個開源專案。與 Prometheus 的無縫整合以及僅使用 Thanos 的一部分的能力使其成為輕鬆擴展監控系統的絕佳選擇。
我們始終歡迎 GitHub Pull 請求和問題。同時，請隨時透過 Github Issues 或 slack 聯繫我們如果您有疑問或回饋，或想分享您的使用體驗！如果您喜歡我們在 Improbable 所做的事情，請隨時與我們聯繫 - !
來源： www.habr.com