集群容量概覽

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

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

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

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

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

架構

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

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

如圖所示，我們是多數據中心的架構。其中每個中心都有一組 Grafana + Query 服務器，一組存儲服務器和三個 Receive 服務器（集群數量的一半）。

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

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

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

Data Ingestion

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

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

data ingestion

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

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

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

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

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

數據查詢

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

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

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

數據查詢

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

長期數據

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

遠程數據查詢

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

數據情況

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

• 監(jiān)控了 6 個 Kubernetes 集群；
• 收集了 670 個服務的 metrics；
• 使用 Node Exporter 監(jiān)控了 246 個服務器；
• 每分鐘收集約 27w 個指標；
• 每天 ingest 約 7.3 GB 的數據，或每月 ingest 約 226.3 GB 的數據；
• 為 Kubernetes 組件創(chuàng)建了 40 個專用儀表盤；
• 在 Grafana 上創(chuàng)建了 116 個警報。

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

總結

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

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

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