Prometheus是CNCF基金會管理的一個開源監控項目，由於其良好的架構設計和完善的生態，迅速成爲了監控領域事實上的標準，尤其是在雲原生領域。

隨着深入地瞭解Prometheus，你會發現一些非常好的功能：

• 服務發現使配置更加容易。Prometheus支持consul，etcd，kubernetes以及各家公有云廠商自動發現。對於監控目標動態發現，這點特別契合Cloud時代，應用動態擴縮的特點。我們無法想象，在Cloud時代，需要運維不斷更改配置。
• 開源社區建立了數百個exporter。基本上涵蓋了所有基礎設施和主流中間件。
• 工具庫可從您的應用程序獲取自定義指標。基本上主流開發語言都有對應的工具庫。
• 它是CNCF旗下的OSS，是繼Kubernetes之後的第二個畢業項目。Kubernetes已經與Promethues深度結合，並在其所有服務中公開了Prometheus指標。
• Pushgateway，Alermanager等組件，基本上涵蓋了一個完整的監控生命週期。

對於一家小型單位，Prometheus足夠了。幾乎不需要任何的開發，就足以應對所有監控需求。

我們都知道Prometheus，自身的時序數據庫TSDB是一個單機的數據庫，不支持分佈式是其天生的劣勢。當你的 metrics 數量足夠多的時候，單機Prometheus就顯得捉襟見肘。您的Prometheus服務器開始崩潰，大多時候是內存問題。Prometheus中的內存使用量與存儲的時間序列數量成正比，並且隨着時間序列數量的增加，Prometheus會OOM。具有數百萬個指標的Prometheus可以使用超過100GB的RAM，很多時候我們受限制於一些主機本身的大小，我們無法不斷的通過縱向調整機器大小來解決這個問題。

因此解決Prometheus的擴展性，是打造企業分佈式監控平臺的關鍵。

如何解決Prometheus的擴展性

聯邦

官方的解決方案是集羣聯邦，主要提供了分層聯邦和跨服務聯邦。

分層聯邦

分層聯邦允許 Prometheus 能夠擴展到十幾個數據中心和上百萬的節點。在此場景下，聯邦拓撲類似一個樹形拓撲結構，上層的 Prometheus 服務器從大量的下層 Prometheus 服務器中收集和匯聚的時序數據。

跨服務聯邦

在跨服務聯邦中，一個服務的 Prometheus 服務器被配置來提取來自其他服務的 Prometheus 服務器的指定的數據，以便在一個 Prometheus 服務器中對兩個數據集啓用告警和查詢。

這兩種聯邦，其實有很大的問題，本質上Prometheus的單機能力依舊沒有得到解決。

拆分

拆分永遠是解決問題的一個好思路。尤其是當你的場景是，不需要一個全局的監控視圖。

我們可以根據環境(test,uat, prod)或是業務類型(基礎設施，中間件，業務)，甚至是根據部門類型來拆分。

當然可以通過grafana配置不同的數據源，給使用方營造一種整體的假象。

但是這種方案，會帶來很多問題：

• 隨着你metrics量的增加，切分的維度會越來越細。
• 缺乏一個全局的視圖，我們仍然無法跨不同集羣查詢服務，並且無法真正執行全局查詢。
• 給統一報警增加了困難。
• 如果羣集是動態的或變化的，則每次羣集中部署Prometheus時，您通常都需要實現一種自動向Grafana添加數據源的方法。

長期存儲

Prometheus社區也意識到了同樣的問題，於是提供了遠程讀寫兩個接口，讓大家可以使用一些社區的時序數據庫方案，來擴展prometheus。

當前，有幾個提供長期存儲（LTS）的開源項目，而這些社區項目則領先於其他項目：Cortex，Thanos或M3。

當然這些項目實現的方式是不同的，均有不同的優勢和劣勢，需要大家根據自己單位實際的場景需求來選擇。

諸如Thanos，最終的儲存是S3等對象存儲，整體架構比較複雜。

M3db社區活躍度不夠，文檔比較少，但是M3db相比其他幾個，是典型的時序數據庫。

Influxdb集羣版本沒有開源。

Victoria 數據是沒有副本的。

我曾經在生產環境中，使用過Clickhouse作爲長期存儲。該解決方案存在的問題是，Clickhouse併發查詢能力比較低，導致查詢的時候慢。當然寫入倒是沒有什麼大的問題。

採集端hash mod

尤其當Prometheus部署到kubernetes當中，並且我們使用了Prometheus的kubernetes sd 服務發現時，當我們集羣變得非常大的時候，單臺的Prometheus採集能力也成爲一個瓶頸。此時，我們可以使用hash mod, 對採集任務進行分片。

總結

本文是利用Prometheus 打造企業分佈式監控平臺系列中的第一篇文章。主要講了Prometheus的可擴展性上的一些解決方案。其實沒有百分百完美的方案，大家需要根據自己metrics的數量來選擇最合適自己的方案。

相關文章