https://cloud.tencent.com/developer/article/1645040
https://cloud.tencent.com/developer/article/1645040
這篇文章超級經典
前面我們已經學習了 Prometheus 的使用，了解了基本的 PromQL 語句以及結合 Grafana 來進行監控圖表展示，通過 AlertManager 來進行報警，這些工具結合起來已經可以幫助我們搭建一套比較完整的監控報警系統了，但是也僅僅局限於測試環境，對於生產環境來說則還有許多需要改進的地方，其中一個非常重要的就是 Prometheus 的高可用。
單台的 Prometheus 存在單點故障的風險，隨着監控規模的擴大，Prometheus 產生的數據量也會非常大，性能和存儲都會面臨問題。毋庸置疑，我們需要一套高可用的 Prometheus 集群。
可用性
我們知道 Prometheus 是采用的 Pull 機制獲取監控數據，即使使用 PushGateway 對於 Prometheus 也是 Pull，為了確保 Prometheus 服務的可用性，我們只需要部署多個 Prometheus 實例，然后采集相同的 metrics 數據即可：
這個方式來滿足服務的可用性應該是平時我們使用得最多的一種方式，當一個實例掛掉后從 LB 里面自動剔除掉，而且還有負載均衡的作用，可以降低一個 Prometheus 的壓力，但這種模式缺點也是非常明顯的，就是不滿足數據一致性以及持久化問題，因為 Prometheus 是 Pull 的方式，即使多個實例抓取的是相同的監控指標，也不能保證抓取過來的值就是一致的，更何況在實際的使用過程中還會遇到一些網絡延遲問題，所以會造成數據不一致的問題，不過對於監控報警這個場景來說，一般也不會要求數據強一致性，所以這種方式從業務上來說是可以接受的，因為這種數據不一致性影響基本上沒什么影響。這種場景適合監控規模不大，只需要保存短周期監控數據的場景。
這里數據的一致性問題：例如nginx做負載均衡的時候，外部的訪問通過nginx的負載均衡，一直訪問的是Prometheus1這台服務器，Prometheus2這台服務器是為了可用性單獨部署的，只有當Prometheus1這台服務器掛了之后，nginx才會切換到Prometheus2這台服務器來進行訪問，但是切換到Prometheus2這台服務器服務器的時候，會存在數據一致性的問題。因為Prometheus2 和Prometheus1有可能因為啟動時間不一致，導致安裝時間序列采集得到的數據是不一致的，但是對於時間序列數據庫來說，這種不一致對數據影響不大，但是上面還存在一個很最嚴重的問題，就是數據可能存在驗證的丟失問題，如果Prometheus2服務器磁盤異常了，就會導致Prometheus2上存儲的監控數據全部丟失，這是最為嚴重的問題
數據持久化
使用上面的基本 HA 的模式基本上是可以滿足監控這個場景，但是還有一個數據持久化的問題，如果其中一個實例數據丟了就沒辦法呢恢復回來了，這個時候我們就可以為 Prometheus 添加遠程存儲來保證數據持久化。
例如nginx做負載均衡的時候，外部的訪問通過nginx的負載均衡，一直訪問的是Prometheus1這台服務器，Prometheus2這台服務器是為了可用性單獨部署的，Prometheus1收集到的監控數據都是存儲到外部存儲上面的，這樣就不會存在數據丟失的請求，在Prometheus1收集數據的同時，Prometheus2這台服務器也是在工作的也是將數據存儲到第三方存儲上面，外部查詢數據的時候，通過nginx訪問的是Prometheus1這台服務器，Prometheus1通過接口讀取第三方存儲中的數據返回給客戶端。
當Prometheus1異常掛了之后，nginx的流量入口會切換到Prometheus2，Prometheus2收集到的數據也是存儲到第三次存儲的，在Prometheus2服務器的磁盤即使掛了，磁盤里面的歷史監控數據即使沒有了，但是在第三方存儲中保留了之前的監控數據，我們在啟動一個Prometheus3，去訪問第三方存儲，我們也可以得到之前的歷史數據，這個方案相當的完美
在給 Prometheus 配置上遠程存儲過后，我們就不用擔心數據丟失的問題了，即使當一個 Prometheus 實例宕機或者數據丟失過后，也可以通過遠程存儲的數據進行恢復。
但是上面存在的問題是：Prometheus2和Prometheus1都同時去拉取指標，對於監控指標很大的請求，對於數據的網絡開銷會很大，列如指標1那容器都同時收到Prometheus2和Prometheus1來拉取指標數據，有可能網絡開銷會很大，可以采用下面的辦法進行優化
缺點2：就是數據Prometheus2和Prometheus1都同時存儲數據，Prometheus1和Prometheus2如果存儲的數據相同，這個時候在第三方存儲中就會存在兩份相同的數據，數據查詢的時候，外部訪問通過nginx訪問到Prometheus1的時候，Prometheus1如何查詢數據了，如何對數據去重了，這個時候就需要引入第三方框架，就是常用的Thanos。thanos 查詢時做數據去重和join
通過鎖獲取 Leader
其實上面的基本 HA 加上遠程存儲的方式基本上可以滿足 Prometheus 的高可用了，這種方式的多個 Prometheus 實例都會去定時拉取監控指標數據，然后將熱數據存儲在本地，然后冷數據同步到遠程存儲中去，對於大型集群來說頻繁的去拉取指標數據勢必會對網絡造成更大的壓力。所以我們也通過服務注冊的方式來實現 Prometheus 的高可用性，集群啟動的時候每個節點都嘗試去獲取鎖，獲取成功的節點成為 Leader 執行任務，若主節點宕機，從節點獲取鎖成為 Leader 並接管服務。
在同一時刻，只有Prometheus1拉取指標數據並存儲到第三方存儲中，Prometheus1工作的時候Prometheus2節點不會去拉取指標，這個功能需要不過這種方案需要我們通過去寫代碼進行改造
上面的幾種方案基本上都可以滿足基本的 Prometheus 高可用，但是對於大型集群來說，一個 Prometheus 實例的壓力始終非常大。
聯邦集群
當單個 Promthues 實例 無法處理大量的采集任務時，這個時候我們就可以使用基於 Prometheus 聯邦集群的方式來將監控任務划分到不同的 Prometheus 實例中去。
我們可以將不同類型的采集任務划分到不同的 Prometheus 實例中去執行，進行功能分片，比如一個 Prometheus 負責采集節點的指標數據，另外一個 Prometheus 負責采集應用業務相關的監控指標數據，最后在上層通過一個 Prometheus 對數據進行匯總。
具體的采集任務如何去進行分區也沒有固定的標准，需要結合實際的業務進行考慮，除了上面的方式之外，還有一種情況就是單個的采集數據量就非常非常大，比如我們要采集上萬個節點的監控指標數據，這種情況即使我們已經進行了分區，但是對於單個 Prometheus 來說壓力也是非常大的，這個時候我們就需要按照任務的不同實例進行划分，我們通過 Prometheus 的 relabel 功能，通過 hash 取模的方式可以確保當前 Prometheus 只采集當前任務的一部分實例的監控指標。
# 省略其他配置...... relabel_configs: - source_labels: [__address__] modulus: 4 # 將節點分片成 4 個組 target_label: __tmp_hash action: hashmod - source_labels: [__tmp_hash] regex: ^1$ # 只抓第2個組中節點的數據(序號0為第1個組) action: keep
到這里我們基本上就完成了 Prometheus 高可用的改造。對於小規模集群和大規模集群可以采用不同的方案，但是其中有一個非常重要的部分就是遠程存儲，我們需要保證數據的持久化就必須使用遠程存儲。所以下面我們將重點介紹下遠程存儲的時候，這里我們主要講解目前比較流行的方案：Thanos，它完全兼容 Prometheus API，提供統一查詢聚合分布式部署 Prometheus 數據的能力，同時也支持數據長期存儲到各種對象存儲（比如 S3、阿里雲 OSS 等）以及降低采樣率來加速大時間范圍的數據查詢。
https://segmentfault.com/a/1190000022164038
- 官方建議數據做Shard，然后通過federation來實現高可用，但是邊緣節點和Global節點依然是單點，需要自行決定是否每一層都要使用雙節點重復采集進行保活。也就是仍然會有單機瓶頸。
- 另外部分敏感報警盡量不要通過global節點觸發，畢竟從Shard節點到Global節點傳輸鏈路的穩定性會影響數據到達的效率，進而導致報警實效降低。
上面普羅新聯邦機制還存在一個問題：
比如一個k8s集群下面有100個節點，我們搭建5個Prometheus實例分別來監控這100個節點，每個Prometheus實例分別監聽10個節點
，我們在查詢的時候，我們要以統一的視圖查詢100個節點的數據，這個時候就需要引入thanos框架了
全局視圖：按類型分開之后，雖然數據分散了，但監控視圖需要整合在一起，一個 grafana 里 n個面板就可以看到所有地域+集群+pod 的監控數據，操作更方便，不用多個 grafana 切來切去，或者 grafana中多個 datasource 切來切去。
作者：徐亞松
鏈接：https://segmentfault.com/a/1190000022164038
來源：SegmentFault 思否
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
query 的去重
query組件啟動時，默認會根據query.replica-label字段做重復數據的去重，你也可以在頁面上勾選deduplication 來決定。query 的結果會根據你的query.replica-label的 label選擇副本中的一個進行展示。可如果 0，1，2 三個副本都返回了數據，且值不同，query 會選擇哪一個展示呢？
作者：徐亞松
鏈接：https://segmentfault.com/a/1190000022164038
來源：SegmentFault 思否
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
https://segmentfault.com/a/1190000022164038
https://segmentfault.com/a/1190000022164038
上面這篇文章很經典呀https://segmentfault.com/a/1190000022164038