Thanos 架構剖析（一）Thanos 架構總覽

Thanos 是什麼，是打了響指滅了一半人類的滅霸嗎？不是，在監控領域，Thanos 是 Prometheus 的高可用解決方案，由英國遊戲技術公司 Improbable 開源，在 2018 年的 9 月 14 日釋出了第一個版本，v0.1.0，到現在已經釋出了 v0.23.1。

Thanos 官網首頁上簡單易懂一段英文介紹如下：Open source, highly available Prometheus setup with long term storage capabilities。開源，高可用性的 Prometheus 設定，并提供長期存儲能力。這是對 Thanos 最準确的描述。

Thanos 以簡單且高成本效益的方式，為 Prometheus 提供一個叢集，目的是要實作大規模的監控。Thanos目前的核心維護者來自 Polar Signals、紅帽和 位元組跳動，已經被位元組跳動、騰訊、華為、VIVO、eBay 等公司用于生産環境。

Thanos 很早就進入了 CNCF 的沙盒階段，在 2020.08.19 通過 TOC 的稽核進入 CNCF 的孵化階段，目前已經穩定釋出一年多了，在不久的将來也許就畢業了。

Thanos 維護者 Frederic Branczyk 提到，Thanos 是一種易于安裝的解決方案，可以将使用者的 Prometheus 執行個體過渡到具有長期儲存功能的監控系統。大多數的 Thanos 都部署在 Kubernetes 上，可用來監控跨多叢集與多雲的微服務或是基礎設施。

Thanos 的特點

Thanos 在首頁就大方的放出了自己的 4 個優點，分别是：

• 全局查詢
• 無限制的存儲
• 相容 Prometheus

• 資料降準和壓縮

  其實 Thanos 還有第 5 個優點，那就是高可用叢集。

全局查詢

Thanos 可以跨多個 Prometheus 執行個體來查詢存儲的監控名額，這樣就實作了 Prometheus 的水準擴充，當單機 Prometheus 性能不足時，通過水準拆分就可以完成擴充 Prometheus 的承載能力。

無限制存儲

Thanos 本身不提供存儲，但是它支援多種對象存儲系統，使用對象存儲來擴容資料存儲，以此來無限的存儲監控資料，它支援 Google 的 GCP、AWS 的 S3、Azure、Swift、Tencent 的 COS、AliYun 的 OSS。

相容 Prometheus

Thanos 完全相容 Prometheus 的 API 接口，無論你使用 Grafana 或者其他支援 Prometheus API 的工具，使用過程非常絲滑，一點都感覺不到在使用 Thanos ，就像在直接操作 Prometheus 一樣。

資料降準和壓縮

Thanos 會對 Prometheus 的資料進行降準，當查詢大時間範圍的監控資料或者配置複雜的保留政策時可以加快查詢速度，另外也會對實時資料進行壓縮，這樣可以節省一定的存儲空間。

高可用叢集

Thanos 可以針對 Prometheus 提供高可用叢集，并且對重複資料進行删除和合并。

Thanos 架構

Thanos 的架構看起來非常複雜，但是分析以後非常簡單。

Thanos 提供了 Sidecar、Query、Store、Receive、Rule、Compact、Query Frontend、tools 8 個元件，但是建構一個 Thanos 叢集最少使用 4 個就可以完成一個簡單的叢集，最多也隻要 6 個元件就可以建構非常複雜的叢集。

這些元件的功能分别是：

• Sidecar： Thanos 的資料上傳元件，用來和 Prometheus 通信，并且将 Prometheus 的監控資料上傳到對象存儲
• Query：Thanos 的查詢元件，用來查詢監控資料
• Store：Thanos 的資料存儲元件，用來和對象存儲通信，為對象存儲提供資料代理服務。
• Receive：Thanos 的資料收取元件，支援 Prometheus 的遠端寫功能，對于同一個 Prometheus 執行個體，隻能在 Sidecar 和 Receiver 中間二選一。
• Rule：Thanos 的集中的告警管理元件
• Compactor：Thanos 的資料處理元件，用來将監控資料降準和壓縮
• Query Frontend：Thanos 的查詢前端
• tools：Thanos 的運維工具，用途很多。

Thanos 看上去有這麼多元件，其實部署的時候隻有一個二進制包，搭配不同的參數實作不同的功能，非常友善，比如 Query 元件就是

./thanos query

，Sidecar 元件就是

./thanos sidecar

，所有元件在同一個包裡，而且包的體積很小。

Thanos 叢集有兩種模式，分别是使用 Sidecar 來進行監控資料上傳的邊車模式和使用 Receive 來接受資料的收取模式，兩種模式隻有資料從 Prometheus 到對象存儲的方式有差別，其他結構是一樣的。

我們首先來看邊車模式：

從資料發生的 Prometheus 看起，Prometheus 在擷取資料以後，通過 Sidecar 将資料上傳到 對象存儲，Store 從對象存儲讀取資料供其他元件查詢，Query 從 Sidecar 擷取實時資料、從 Store 擷取曆史資料對外提供查詢功能，Rule 從 Sidecar 和 Store 擷取資料進行規則計算，如果觸發告警就推送給 AlertManager ，Compactor 對對象存儲進行讀寫，下載下傳資料進行資料降準和壓縮，将處理好的資料上傳到對象存儲，并且删除已經降準過和壓縮過的資料。Query Frontend 在 Query 前邊提供查詢緩存和查詢分解的功能。

接着我們來看收取模式：

對于收取模式，大緻的結構和邊車模式是一樣的，隻是沒有了 Sidecar 元件，Prometheus 通過遠端寫功能将資料直接寫給 Receive ，Receiver 将資料寫給對象存儲，Query 查詢資料從 Receive 和 Store 擷取，Rule 從 Receive 和 Store 擷取資料進行規則計算，Store 和 Compacter 的功能不變。

如果要在一台機器上部署 Thanos 的所有元件，那麼可以按照下邊的表格來規劃端口。

元件	接口協定	端口
Sidecar	gRPC	10901
Sidecar	HTTP	10902
Query	gRPC	10903
Query	HTTP	10904
Store	gRPC	10905
Store	HTTP	10906
Receive	gRPC (store API)	10907
Receive	HTTP (remote write API)	10908
Receive	HTTP	10909
Rule	gRPC	10910
Rule	HTTP	10911
Compact	HTTP	10912
Query Frontend	HTTP	10913

Component Interface Port

Sidecar gRPC 10901

Sidecar HTTP 10902

Query gRPC 10903

Query HTTP 10904

Store gRPC 10905

Store HTTP 10906

Receive gRPC (store API) 10907

Receive HTTP (remote write API) 10908

Receive HTTP 10909

Rule gRPC 10910

Rule HTTP 10911

Compact HTTP 10912

Query Frontend HTTP 10913

釋出周期

Thanos 的目标是每 6 周釋出一個版本，這個是要嚴格執行的，如果沒有緊急的 BUG 修複，那麼等待一個多月就會有新的版本釋出。不過最近好像有點延期。