對于彈性伸縮和高可用的系統(tǒng)來說，一般有大量的指標數(shù)據(jù)需要收集和存儲，如何為這樣的系統(tǒng)打造一個監(jiān)控方案呢?本文介紹了如何使用 Thanos+Prometheus+Grafana 構(gòu)建監(jiān)控系統(tǒng)。

集群容量概覽

直到今年 1 月，我一直在使用一款企業(yè)級監(jiān)控解決方案來監(jiān)控 Kubernetes 集群，這款監(jiān)控方案還用于 APM。它用起來很自然，與 Kubernetes 的集成非常容易，只需要進行一些細微的調(diào)整，并且可以集成 APM 和基礎(chǔ)設(shè)施指標。

盡管這款監(jiān)控方案可以很容易地收集和存儲數(shù)據(jù)，但使用指標創(chuàng)建警報卻有很大的查詢限制。經(jīng)常我們收到的告警和儀表盤上顯示的內(nèi)容會不一樣。更不用說我們有 6 個集群，收集和存儲的指標數(shù)量非常多，這在很大程度上增加了我們的經(jīng)濟成本。

經(jīng)過一番考慮，我們認識到繼續(xù)使用這款監(jiān)控方案弊大于利。是時候替換我們的監(jiān)控方案了!但是，該使用什么產(chǎn)品或者工具呢?Grafana 是可視化工具的最佳選項，但我們的“后端”需要具備彈性伸縮和高可用能力，該使用什么工具呢?

純粹使用 OpenTSDB 的話，安裝需要太多的工作和精力;單機 Prometheus 不提供復(fù)制能力，還需要為其配備多個數(shù)據(jù)庫;TimeScaleDB 看起來不錯，但我不太會使用 PostgreSQL。

在對以上這些方案進行了一些實驗后，我查看了 CNCF 網(wǎng)站，最后找到了 Thanos!它滿足我們所有的需求：可長期保留數(shù)據(jù)、可復(fù)制、高可用、適合微服務(wù)、對使用相同數(shù)據(jù)庫的所有集群有一個 global view!

架構(gòu)

我們的集群上沒有可用的持久化存儲(所有服務(wù)都保持無狀態(tài))，所以默認的 Prometheus + Thanos sidecar 方法不可用，metric 存儲必須置于集群之外。此外，集群之間相互隔離，將 Thanos 組件綁定到一組特定的集群是不可能的，必須從“外部”監(jiān)控集群。

綜上所述，考慮到高可用性以及 Thanos 在虛擬機上運行的可能性，我們最終的架構(gòu)是這樣的：

如圖所示，我們是多數(shù)據(jù)中心的架構(gòu)。其中每個中心都有一組 Grafana + Query 服務(wù)器，一組存儲服務(wù)器和三個 Receive 服務(wù)器(集群數(shù)量的一半)。

Grafana 使用的數(shù)據(jù)庫還有一個 AWS RDS。這個數(shù)據(jù)庫不必很龐大(降低成本)，我們團隊也不需要管理 MySQL。

在 Thanos 提供的所有組件中，我們實現(xiàn)了其中的 4 個：

Receive：負責(zé) TSDB，還管理所有運行 receive 的服務(wù)器和 TSBD 塊上傳到 S3 之間的復(fù)制。

Query：負責(zé)查詢 receive 數(shù)據(jù)庫。

Store：讀取 S3 以獲取不再存儲在 receive 中的長期 metrics。

Compactor：管理存儲在 S3 中的 TSDB 塊的數(shù)據(jù)下采樣和壓縮。

Data Ingestion

所有集群的 data ingestion 都由集群內(nèi)運行的專用 Prometheus Pod 管理。它從 control plate(API 服務(wù)器、控制器和調(diào)度程序)、etcd 集群以及集群內(nèi)的 Pod 收集指標，這些集群內(nèi)具有與基礎(chǔ)設(shè)施和 Kubernetes 本身相關(guān)的指標(Kube-proxy、Kubelet、Node Exporter、State Metrics 、Metrics Server 和其他具有 scraping annotation 的 Pod)。

Prometheus Pod 然后將信息發(fā)送到使用遠程存儲配置管理 TSDB 的 receive 服務(wù)器之一。

data ingestion

所有數(shù)據(jù)都發(fā)送到單個服務(wù)器，然后復(fù)制到其他服務(wù)器。Prometheus 使用的 DNS 地址是一個 DNS GSLB，它探測每個 receive 服務(wù)器并平衡健康的服務(wù)器之間的 DNS 解析，在所有服務(wù)器之間分擔(dān)負載，因為 DNS 解析只為每個 DNS 查詢提供一個 IP。

需要強調(diào)一下，數(shù)據(jù)必須發(fā)送到單個 receive 實例并讓它管理復(fù)制，發(fā)送相同的 metric 會導(dǎo)致復(fù)制失敗和行為異常。

在這個層面上，metrics 也會上傳到 S3 存儲桶進行長期留存。Receive 每 2 小時(當(dāng)每個 TSDB 塊關(guān)閉時)上傳一次 block，這些 metric 可用于使用 Store 組件進行查詢。

還可以設(shè)置本地數(shù)據(jù)的保留時間。在這種情況下，所有本地數(shù)據(jù)都會保留 30 天以供日常使用和故障排除，這樣可以加快查詢速度。

超過 30 天的數(shù)據(jù)僅在 S3 上可用，最長可保留 1 年，用于長期評估和比較。

數(shù)據(jù)查詢

數(shù)據(jù)被收集并存儲在 receiver 中以供查詢。這部分也設(shè)置為多數(shù)據(jù)中心可用。

每臺服務(wù)器都運行 Grafana 和 Query，如果其中一臺(或兩臺)出現(xiàn)故障，我們可以更輕松地從負載均衡器中識別并刪除。在 Grafana 中，數(shù)據(jù)源配置為 localhost，因此它始終使用本地 Query 來獲取數(shù)據(jù)。

對于查詢配置，它必須知道所有存儲了 metrics 的服務(wù)器(Receiver 和 Store)。query 組件知道哪個服務(wù)器在線并且能夠從它們收集 metrics。

數(shù)據(jù)查詢

它還管理重復(fù)數(shù)據(jù)刪除，因為它查詢所有服務(wù)器并配置了 replication，所有 metrics 都有多個副本?？梢允褂梅峙浣o metrics 的標簽和查詢參數(shù) (--query.replica-label=QUERY.REPLICA-LABEL) 來完成。通過這些配置，query 組件知道從 Receiver 和 Store 收集的 metrics 是否重復(fù)并僅使用一個數(shù)據(jù)點。

長期數(shù)據(jù)

如前所述，數(shù)據(jù)在本地最多保留 30 天，其他所有內(nèi)容都存儲在 S3 上。這樣可以減少 Receiver 上所需的空間量并降低成本，因為塊存儲比對象存儲更貴。更何況查詢超過 30 天的數(shù)據(jù)不是很常見，主要用于資源使用歷史和預(yù)測。

遠程數(shù)據(jù)查詢

該 Store 還保留存儲在 S3 存儲桶上的每個 TSDB 塊的索引的本地副本，因此如果需要查詢超過 30 天的數(shù)據(jù)，它知道要下載和使用哪些塊來提供數(shù)據(jù)。

數(shù)據(jù)情況

考慮到所有集群，該監(jiān)控方案：

監(jiān)控了 6 個 Kubernetes 集群;

收集了 670 個服務(wù)的 metrics;

使用 Node Exporter 監(jiān)控了 246 個服務(wù)器;

每分鐘收集約 27w 個指標;

每天 ingest 約 7.3 GB 的數(shù)據(jù)，或每月 ingest 約 226.3 GB 的數(shù)據(jù);

為 Kubernetes 組件創(chuàng)建了 40 個專用儀表盤;

在 Grafana 上創(chuàng)建了 116 個警報。

對于每月費用，由于大部分組件在本地運行，成本降低了 90.61%，從每月 38,421.25 美元降至 3,608.99 美元，其中包括 AWS 服務(wù)成本。

總結(jié)

配置和設(shè)置上述架構(gòu)大約需要一個月左右的時間，包括測試其他一些解決方案、驗證架構(gòu)、實現(xiàn)、在集群上開啟收集以及創(chuàng)建所有儀表盤。

在第一周，好處是顯而易見的。監(jiān)控集群變得更加容易，儀表盤可以快速構(gòu)建和定制，收集 metrics 幾乎是即插即用的，大多數(shù)應(yīng)用程序以 Prometheus 格式導(dǎo)出 metrics，并根據(jù) annotations 自動收集。

此外，通過集成 Grafana 的 LDAP 可以達到更精細的團隊權(quán)限控制。開發(fā)人員和 SRE 可以訪問大量儀表盤，其中包含有關(guān)其命名空間、ingress 等的相關(guān) metrics。

原文標題：使用 Thanos 和 Prometheus 打造一個高可用的 Kubernetes 監(jiān)控系統(tǒng)

文章出處：【微信公眾號：馬哥Linux運維】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

審核編輯：湯梓紅