Prometheus監控的生產化之路: 從單一叢集到企業級架構
在過去幾年中，Prometheus已成為Kubernetes環境中的標準監控解決方案。然而，當我們將Prometheus從開發環境擴充套件至生產環境時，往往會遇到許多未預期的挑戰。本文將分享我在多個企業級佈署中的經驗，探討Prometheus生產化過程中的常見問題與解決方案。
多叢集環境的監控挑戰
當你佈署第二個Kubernetes叢集（如測試環境）時，一切似乎還算順利。按照相同的流程佈署Prometheus、各種exporters和Grafana，整個過程相對簡單。測試叢集通常比開發環境大，但Prometheus仍能良好應對。應用程式還不多，儀錶板和使用者數量也較少，因此遷移過程相對容易。
然而，第一個小問題已經悄然出現：現在你有兩個不同的Grafana安裝，需要在它們之間切換才能檢視開發和測試環境的指標。此時，開發人員可能還不太在意這個問題，但這種不便已開始顯現。
當第三個叢集（生產環境）上線後，情況開始複雜化。你遵循相同流程再次佈署監控系統，但使用者對於需要存取三個不同的儀錶板門戶已經感到不滿，儘管這還不是致命問題。
隨著公司決定將更多應用遷移到Kubernetes，新使用者、設定、儀錶板和警示需要在每個叢集中分別新增。以一致的方式管理設定開始需要更多的精力和組織。
Node-exporter Node-exporter Node-exporter
KSM KSM KSM
開發環境 測試環境 生產環境
當應用數量增長，新需求出現，為了代管不同應用、服務不同地區和提高用性，更多的叢集被建立。為每個叢集維護不同的Prometheus和Grafana例項成為一項挑戰，DevOps和開發團隊開始抱怨。
保持全域可視性的困境
分散式監控模型帶來了多方面的挑戰：
- 無法提供全域可視性。當有多個生產叢集時，這成為一個新的需求。
- 操作繁瑣與耗時。
- 這種模型可能使治理和合規性變得複雜。
除了讓存取不同叢集變得更容易外，集中式視覺化工具還允許你在同一個儀錶板中視覺化和關聯來自多個叢集中服務的資訊。
乍看之下，這似乎很簡單：佈署一個集中式Grafana，並將執行在各個叢集中的Prometheus伺服器新增為資料來源。
然而，這種方法隱藏著一些挑戰：
安全性問題：Prometheus本身不包含安全特性。當Prometheus和Grafana在叢集內通訊時，這不是問題。但當你將Grafana移出叢集時，需要在Prometheus之上實作某種機制來保護連線並控制對指標的存取。解決這個問題有很多方案，但它們都需要一定的實施和維護工作（管理證書、建立入口控制器、設定Grafana中的安全設定等）。
動態叢集管理：如果叢集是動態的或經常變化，你需要實作一種方式來自動將資料源新增到Grafana，每當在叢集中佈署Prometheus時。
跨叢集查詢限制：此方法允許我們在儀錶板面板中混合不同來源的資料，但你仍無法跨不同叢集查詢服務並執行真正的全域查詢。
存取控制需求：控制誰可以存取哪些資料變得更加重要，可能需要RBAC系統。與身份服務的整合很可能是必要的，以保持使用者基礎的更新，這可能成為合規要求。
這些問題並非阻礙，但它們需要架構設計、開發和實施的努力。維護整個結構也需要大量資源。
Prometheus的水平擴充套件困境
經過團隊的努力，你建立了一個不錯的集中式系統，一切似乎完美，直到新問題出現。開發人員瞭解到自定義指標的強大功能，並開始在程式碼中新增業務相關的指標。隨著組織的成長，Kubernetes中的服務數量增加，指標的使用也隨之上升。叢集規模擴大，服務有更多的副本。
此時，你的Prometheus伺服器開始當機，經過研究，你清楚地看到這是一個記憶體問題。Prometheus中的記憶體使用直接與儲存的時間序列數量成正比，隨著時間序列的增長，你開始遇到OOM（Out of Memory）終止的情況。你可以提高資源配額限制，但這不能無限進行。最終會達到節點的記憶體容量，沒有Pod可以超過這個限制。
擁有數百萬個指標的Prometheus可能使用超過100GB的RAM，這在Kubernetes中執行可能是個問題。必須進行水平擴充套件以吸收容量，但簡短的答案是：你做不到。Prometheus不是設計用來水平擴充套件的。一旦達到垂直擴充套件的限制，就沒有更多的解決方案了。
垂直擴充套件 水平擴充套件
↑ → → →
單一 多個Prometheus
Prometheus （不支援）
有一些解決這個問題的變通方法，比如將不同的指標分散到多個Prometheus伺服器中，但這是一個棘手的過程。它增加了設定的複雜性，可能使故障排除變得困難。
Prometheus資料匯出策略
有幾種從Prometheus匯出資料的方法，可以幫助解決我們在本中看到的一些問題：
聯邦模式（Federation）
在這種情況下，Prometheus在一個端點上公開資訊，其他高層級的Prometheus伺服器可以從中提取指標，然後整合和聚合資料。
這種方法相當簡單，但有一些限制：
- 可以傳送的資料量有限，因為擴充套件問題更加嚴重。你在一個Prometheus例項中接收所有資料。
- 聚合必須首先在Prometheus本身中完成，然後聯邦端點的請求需要過濾和明確的資訊。
- 維護可能很棘手，因為你需要設定所有的Prometheus伺服器，並在環境增長時保持更新的列表。
可以看出，聯邦模式在某些情況下可能是一個不錯的工具，但無法解決大多數擴充套件問題。
遠端讀取（Remote Read）
這種情況在架構上與聯邦模式類別似，因為指標是從其他Prometheus伺服器提取的，但它被設計為更高效和互操作性更強。遠端讀取改善了可以提取和聚合的資料量，因為它們是在原始Prometheus例項中定義的。這使目標系統免於完成這部分工作。
遠端讀取的主要問題是網路和安全性。長期儲存或提取指標的目標系統需要存取Prometheus端點，這意味著你需要佈署一些安全措施。在簡單的環境中，這並不難做到，但在多雲和/或多區域環境中，這可能是一個真正的挑戰。
