高可用prometheus集群方案選型分享

Prometheus采用Pul模型收集監控數據，服務高可用意味著同一個服務需要至少兩個節點同時拉取或者切換為Push模型，使用一致性哈希，將不同實例的Metrics推送到固定推送到其中一臺服務，這個模式優勢是，在保障服務可用性的同時，資源消耗量少一半;新節點不需要重新配置抓取規則可以做到快速平行擴容。但缺點是，節點故障將導致歷史數據丟失。應用于生產環境的監控服務，單機Promtheus往往是無法滿足需求的，此時就要搭建一套Prometheus集群，此時就需要考慮:

服務高可用:服務要冗余備份，以消除單點故障。

水平可擴展:可以通過增加服務數量，線性提高服務能力。

數據持久化:節點故障數據不丟失、海量歷史數據存儲

數據一致性:冗余結點之間數據需要保證一致性。

選型?

Prometheus 根據功能或服務維度進行拆分，即如果要采集的服務比較多，一個Prometheus 實例就配置成僅采集和存儲某一個或某一部分服務的指標，這樣根據要采集的服務將 Prometheus 拆分成多個實例分別去采集，也能一定程度上達到水平擴容的目的。

優點：

服務被拆分給多個prometheus實例例收集，從而降低了單實例的性能瓶頸

不同的prometheus實例配置可以不同

拆分存儲，分攤采集指標的量

缺點

統?查詢入?不統?，每個prometheus都是一個查詢入口

采集數據依然存在本地，受本地磁盤容量和io限制

選型?

針對選型一，一個Prometheus實例可能連這單個服務的采集任務都扛不住。

prometheus需要向這個服務所有后端實例發請求采集數據，由于后端實例數量規模太大，采集并發量就會很高，一方面對節點的帶寬、CPU、磁盤lo都有一定的壓力，另一方面Prometheus使用的磁盤空間有限，采集的數據量過大很容易就將磁盤塞滿了，通常要做一些取舍才能將數據量控制在一定范圍，但這種取舍也會降低數據完整和精確程度，不推薦這樣做。那么我們可以給這種大規模類型的服務做一下分片(Sharding)，將其拆分成多個group，讓一個Prometheus 實例僅采集這個服務背后的某一個group 的數據，這樣就可以將這個大體量服務的監控數據拆分到多個Prometheus 實例上。

優點︰

解決單個服務監控指標大，利用切片方式讓不同prometheus負責不同分片

可以做Prometheus水平擴容

缺點︰

加劇了監控數據落盤的分散程度，使用grafana查詢數據依然需要添加多個數據源

不同數據源之間的數據還不能聚合查詢

選型三

可以讓Prometheus 不負責存儲，僅采集數據并通過remote write接口方式寫入遠程存儲的adapter，遠程存儲使用OpenTSDB或InfluxDB這些支持集群部署的時序數據庫。然后Grafana添加我們使用的時序數據庫作為數據源來查詢監控數據來展示。

優點

數據存儲遠程寫入，實現單數據源的查詢

缺點:

查詢語句得使用遠程數據源的語法，并不能使用prometheus的promeQL語法查詢

選型四

雖然上面我們通過一些列操作將Prometheus進行了分布式改造，但并沒有解決Prometheus 本身的高可用問題，即如果其中一個實例掛了，數據的查詢和完整性都將受到影響，那么我們可以將所有Prometheus實例都使用兩個相同副本，分別掛載數據盤，它們都采集相同的服務，所以它們的數據是一致的，查詢它們之中任意一個都可以，所以可以在它們前面再掛一層負載均衡，所有查詢都經過這個負載均衡分流到其中一臺Prometheus，如果其中一臺掛掉就從負載列表里踢掉不再轉發。

優點:

保障了prometheus的高可用

缺點:

數據并不能保證完全一致，當其中一臺故障恢復后，他將丟失該時間的數據

選型五

thanos架構，可以幫我們簡化分布式 Prometheus的部署與管理，并提供了一些的高級特性︰全局視圖，長期存儲，高可用，該架構使用grpc保持各個組件的通訊，sidecar組件負責連接Prometheus，將其數據提供給Thanos Query查詢，并且/或者將其上傳到對象存儲，以供長期存儲。Query組件實現了Prometheus APl，將來自下游組件提供的數據進行聚合最終返回給查詢數據的client(如grafana)，類似數據庫中間件。Thanos Store Gateway組件將對象存儲的數據暴露給Thanos Query去查詢,Thanos Compact組件將對象存儲中的數據進行壓縮和降低采樣率,大時間區間監控數據查詢的速度。Thanos Ruler組件對監控數據進行評估和告警，還可以計算出新的監控數據，將這些新數據提供給Thanos Query查詢并且/或者上傳到對象存儲，以供長期存儲。

優點:

采集數據可永久性保存

全局Query入口查詢支持PromeQL語法。支持監控數據的聚合和去重

保障prometheus的高可用

缺點︰

sidecar如果分布在不同地域，容易造成較高延遲，查詢速度會較慢。但可以用Receiver模式(還不穩定)

鯤鵬 云原生 軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。