數人云|淺論Prometheus容器監控優缺點，2.0版本哪項改進受關注？

關於容器監控，數人云之前給大家分享了《解惑|你是否為容器監控操碎了心？》，就有有Prometheus的身影，那麼它都有哪些優缺點？近日發布的2.0版本又有哪些改進？本文見分曉~

Prometheus解決了Devs如何監控高動態容器環境的問題，在本文中，Frederick Ryckbosch講述了使用Prometheus的優點和缺點，以及它到底有多大的伸縮性。

Prometheus是一個基於時間序列的數值數據的監控解決方案，這是一個開源項目，由前Google員工在SoundCloud啟動，他們希望監控一個高度動態的容器環境，因為對傳統的監控工具不甚滿意，所以開發出Prometheus，並在上面進行工作。

在本文中，我們將討論Prometheus的重要設計決策及其影響，將重點討論「 Digital Ocean」如何成功地將Prometheus擴展到100萬台機器，以及在使用Coscale時如何利用Prometheus。

Prometheus是如何工作的

要使用Prometheus監控服務，服務需要公開一個Prometheus端點，這端點是一個HTTP借口，它公開了度量的列表和當前的值。

Prometheus提供了廣泛的服務發現選項，以查找您的服務並從它們開始檢索度量數據。Prometheus伺服器輪詢服務的指標介面並存儲數據。

在Prometheus UI中，用戶可以在PromQL語言中編寫查詢以提取度量信息。

例如：

topk(3, sum(rate(container_cpu_time[5m]) by (app, proc)))

將返回最上面的3個CPU消費服務。

告警可以在Alertmanager中配置，再次使用PromQL語言。Grafana 是一個流行的選項，為Prometheus的指標創建儀錶盤。

Prometheus的設計決策

這裡從Prometheus的度量終點開始，這些端點定義度量標準和值，並通過HTTP公開，它們為手機度量標準提供了一種標準化的方法，Prometheus度量遵循了度量2.0所指定的許多準則：度量標準有名稱、描述、維度和值。唯一缺少的是度量單位。

許多服務度暴露了Prometheus端點，這使得收集它們非常容易，對沒有本地Prometheus端點的其他服務，則需要轉換器。這意味著對於這些服務，必須部署一個額外的Sidecar容器，以公開Prometheus格式的字表。

在這裡討論的第二個設計決定是拉力和推力，Prometheus調查服務的指標，這意味著如果您想要使用Prometheus監控的所有服務都應該公開Prometheus度量端點，Prometheus使用服務發現，它與Kubernetes很好的集成在一起，以找到所有的服務一旦它找到了所有服務，將通過輪詢其他Prometheus度量端點收集所有這些服務的指標。

容器

Pull方法的優點是不需要安裝代理，而且可以通過多個Prometheus實例來提取指標。

而缺點同樣明顯：

對於Prometheus的使用者來說，所有的公制端點都必須是可達的，這意味著一個更加複雜的安全網路配置。

在大型部署中，擴展成為一個問題，Prometheus建議採用一種基於推特的方法來收集短期的工作指標。

Prometheus的主要設計目標之一是操作簡單性。這樣，Prometheus就限制了監控系統的可能失效模式數量，遵循著一原則，Prometheus目前只局限於單個點，因為集群帶來了額外的操作複雜性，使用單個節點不那麼複雜，但是對可以由Prometheus監控的度量指標適量有著嚴格的限制。

Prometheus不解決的問題

Prometheus並不打算解決幾個方面的問題：

首先是對日誌的支持：這兩個指標和日誌都是為用戶的應用程序提供完全可見性的必要部分，但是已經有大量的開源和閉源日誌聚合器來管理日誌。

Prometheus也不提供持久的長期存儲、異常檢測、自動水平縮放和用戶管理，但從作者的客戶基礎上，看到在多數企業環境中都需要這些特性。

Prometheus不是一個Dashboarding解決方案，它提供了一個簡單的UI來進行PromQL查詢，但它依賴於移植物的操作，增加了一些額外的設置複雜度。

Prometheus與Digital Ocean

在2016年的PromCon演講中，來自Digital Ocean的Matthew Campbell解釋了它們如何將Prometheus擴展到100萬台的，在演講當中，他解釋了他們是怎樣從一個默認的Prometheus裝置開始的，以及他們必須改變什麼，才能讓它變得更大。

他們以每天數據中心的一台Prometheus機開始，遇到了可伸縮性問題，並創建了更大的機器來運行Prometheus。一旦他們將機器按最大尺寸縮放，他們將系統保留時間減少到3天，並決定放棄某些指標。這種方法只能到目前為止，因此他們決定根據節點標籤進一步提高他們的Prometheus，這種方法的困難在於，查詢變得更加困難，他們最終實現了一個從多個碎片收集數據的Prometheus代理，他們無法用這種方法解決更大的問題是碎片重新分配和過度供應。

當從1萬個伺服器擴展到100萬個虛擬機時，他們決定採取不同的方法，創建了一個「反向節點出口商」，它基本上是安裝在節點上的代理，並將數據推到一個中心點，在後端方面，他們也做了重大的改變：保留了Prometheus API，但添加了一個Kafka集群，用於傳入的指標和Cassandra的度量存儲，他們還介紹了採樣，這個項目被稱為Vulcan，可用作開源。

Vulcan所採取的方法看起來很像CoScale所採取的方法，還使用代理和可伸縮、高可用的後端。

CoScal在哪裡合適？

我們相信有一個標準化的度量格式有很大的價值，這使得從不同類型的服務中心收集指標變得很容易，CoScale提供了一個Prometheus插件，它收集了在Prometheus格式中暴露的指標，這使得您可以輕鬆地從已啟動的服務中獲得指標。

但是仍然有很多服務沒有暴露出Prometheus端點。為這些服務部署一個轉換器非常麻煩，CoScale有廣泛的插件，支持多種服務的本地度量機制；錄用日誌、Api和其他線程的度量計數器。我們還提供了收集自定義指標的不同選項。

CoScale提供了一個可擴展的插件，包括一個代理和和一個可擴展的、高可用的後端作為SaaS和On-Premise，CoScale提供了Metrics，指標，和事件存儲（短期和長期），直觀的儀錶盤，告警和異常檢測。

Prometheus 2.0

Prometheus 1.0於2016年7月發布，就在前幾天，Prometheus發布了2.0的版本，帶來了巨大的性能改進，並變得更容易操作，下面讓我們看看這個版本都有哪些方面的改進。

許多公司和組織都採用了Prometheus，這個項目很快就擁有了一大批的活躍粉絲（開發人員）以及技術社區。5月的時候就傳出Prometheus 2.0版本的前瞻預測，據說會有一個很大的改進是，有新的存儲層，這意味著極大地提高了Kubernetes和其他分散式系統的監控可伸縮性。

Prometheus有一個簡單而健壯的操作模式，然而，基礎設施領域也在逐步發展，如Kubernetes何Mesos這樣的項目迅速地改變了應用部署和管理的方式，受監控的環境變得越來越動態化。

Prometheus存儲子系統需要仔細配置預期負載，雖然在Prometheus 1.6中，自動調諧能力讓其大為減輕，但用戶仍然會遇到一些不可避免的硬限制。

存儲

2017年，事情逐步發生改變，最初作為一種新的，更高效的時間序列資料庫的實驗，在實際的基準測試中得到了驗證，在過去的6個月當中，Prometheus的開發團隊一直在忙著穩定這個獨立的時間序列資料庫，並將其重新整合到Prometheus本身，其結果上，幾乎所有的維度上都有了改進，從而顯著地提高了Prometheus 2.0的性能，查詢延遲更為一致，特別是在高串擾的情況下，在不同的實際生產場景中，度量的資源消耗也顯著減少：

• 與Prometheus 1.8相比，CPU使用率降低了20%-40%
• 與Prometheus 1.8相比，磁碟空間使用減少到33%-50%
• 沒有太多查詢負載的磁碟I/O通常小於1%

在未來的幾年裡，它還可以處理現代計算環境日益增長的動態特性。

Staleness handling

此外，許多以小見大的變化使得Prometheus更加直觀，最值得注意的是Staleness處理，它是最古老和最需要路線圖的項目之一，隨著新的改進，從這些目標中消失的監控目標或系列已經被明確跟蹤，這減少了人工查詢，增強了告警響應能力。

其他改進

Prometheus 2.0還內置了對整個資料庫快照備份的支持。

同時，還將記錄和告警規則從一個自定義格式遷移到無處不在的YAML格式，這使得集成配置管理和模塊變得更加容易。

其他的變動改進請參看：https://prometheus.io/docs/prometheus/2.0/migration/

未來計劃

會將新的存儲子系統設計為可訪問和可擴展的，這就需要將新特性直接集成到Prometheus中，以及可以在它之上構建的定製工具，簡單而開放的存儲格式和庫也允許用戶輕鬆構建自定義擴展，比如動態保留策略，這使得存儲層能夠滿足廣泛的需求，而無需將複雜性引入到Prometheus本身中，讓它專註於它的核心目標。