前言

在前文中，prometheus基本的用法都簡單的描述一遍，最後本文來討論一下prometheus高可用的問題

環境準備

1. 雙prometheus架構

• 2個prometheus採集同一份metrics，一旦有一個出問題，另外一個補上去就行了
• 該架構保證了prometheus服務的可用性以及數據的可用性
• 但是會有數據冗餘，始終採集了一份數據作為備用，並且prometheus單點壓力過大

2. 做橫向拆分的多prometheus架構

• 將數據拆分組，並且有不同的prometheus採集，並且prometheus也進行拆分，減少單點的壓力
• 該架構既保證了prometheus服務可用性和數據可用性，又減少了prometheus單點壓力
• 數據依然有冗餘，始終採集了一份數據作為備用，並且數據入口很分散，分組越多，會導致數據入口越分散

3. 多prometheus+數據統一查詢架構

• 有了統一的數據查詢入口，使得web可以實時查詢任一時刻的監控數據，如果數據已經超出了prometheus保留期，那也可以去外部存儲上獲取歷史數據
• 該架構繼承了架構2的優點，並且解決了：1）查詢入口分散的問題；2）查詢歷史數據的問題
• 該架構的配置複雜度與日常的維護成本就很高了

4. 更復雜的架構

以下思考純屬個人觀點，拋磚引玉而已

監控的本質問題，就在於準確獲取metrics，並且對其進行分析，所有的架構都是圍繞着這個目標來進行的，小到單點，大到多區域多中心，都不例外

對於獲取metrics，比較關注獲取速度、數據準確度以及覆蓋範圍

• 獲取速度，需要考慮：內網採集？跨公網vpn隧道採集？直接公共網絡採集？
• 數據準確度，需要考慮：多機器的時間是否統一？採集資源是否充足？
• 覆蓋範圍，需要考慮：所選的exporter是否準確？

對於分析metrics，比較關注數據持久性、數據安全、分析實時性

• 數據持久性，需要考慮：歷史數據要保存多久？新鮮數據和老數據分別去什麼地方獲取？
• 數據安全，需要考慮：數據是否是敏感數據？怎麼防止數據泄露？
• 分析實時性，需要考慮：多中心部署下怎麼保證數據獲取速度？多備份下采用哪一個備份的數據是最合理的？

小結

至此，k8s prometheus監控系列結束，期待下一個系列見，謝謝大家

聯繫我

• 聯繫我，做深入的交流
  

至此，本文結束
在下才疏學淺，有撒湯漏水的，請各位不吝賜教...