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

集群容量概覽

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

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

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

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

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

架構(gòu)

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

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

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

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

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

• Receive：負(fù)責(zé) TSDB，還管理所有運(yùn)行 receive 的服務(wù)器和 TSBD 塊上傳到 S3 之間的復(fù)制。
• Query：負(fù)責(zé)查詢 receive 數(shù)據(jù)庫。
• Store：讀取 S3 以獲取不再存儲(chǔ)在 receive 中的長期 metrics。
• Compactor：管理存儲(chǔ)在 S3 中的 TSDB 塊的數(shù)據(jù)下采樣和壓縮。

Data Ingestion

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

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

data ingestion

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

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

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

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

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

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

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

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

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

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

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

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

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

鏈接：https://luizrojo.medium.com/prometheus-but-bigger-b678d8d6b29d

（版權(quán)歸原作者所有，侵刪）