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

集群容量概覽

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

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

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

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

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

架構(gòu)

我們的集群上沒(méi)有可用的持久化存儲(chǔ)(所有服務(wù)都保持無(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ù)庫(kù)還有一個(gè) AWS RDS。這個(gè)數(shù)據(jù)庫(kù)不必很龐大(降低成本)，我們團(tuán)隊(duì)也不需要管理 MySQL。

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

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

Query：負(fù)責(zé)查詢(xún) receive 數(shù)據(jù)庫(kù)。

Store：讀取 S3 以獲取不再存儲(chǔ)在 receive 中的長(zhǎng)期 metrics。

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

Data Ingestion

所有集群的 data ingestion 都由集群內(nèi)運(yùn)行的專(zhuā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 查詢(xún)提供一個(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)行長(zhǎng)期留存。Receive 每 2 小時(shí)(當(dāng)每個(gè) TSDB 塊關(guān)閉時(shí))上傳一次 block，這些 metric 可用于使用 Store 組件進(jìn)行查詢(xún)。

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

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

數(shù)據(jù)查詢(xún)

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

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

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

數(shù)據(jù)查詢(xún)

它還管理重復(fù)數(shù)據(jù)刪除，因?yàn)樗樵?xún)所有服務(wù)器并配置了 replication，所有 metrics 都有多個(gè)副本。可以使用分配給 metrics 的標(biāo)簽和查詢(xún)參數(shù) (--query.replica-label=QUERY.REPLICA-LABEL) 來(lái)完成。通過(guò)這些配置，query 組件知道從 Receiver 和 Store 收集的 metrics 是否重復(fù)并僅使用一個(gè)數(shù)據(jù)點(diǎn)。

長(zhǎng)期數(shù)據(jù)

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

遠(yuǎn)程數(shù)據(jù)查詢(xún)

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

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

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

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

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

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

每分鐘收集約 27w 個(gè)指標(biāo);

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

為 Kubernetes 組件創(chuàng)建了 40 個(gè)專(zhuān)用儀表盤(pán);

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

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

總結(jié)

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

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

此外，通過(guò)集成 Grafana 的 LDAP 可以達(dá)到更精細(xì)的團(tuán)隊(duì)權(quán)限控制。開(kāi)發(fā)人員和 SRE 可以訪問(wèn)大量?jī)x表盤(pán)，其中包含有關(guān)其命名空間、ingress 等的相關(guān) metrics。

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

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

審核編輯：湯梓紅