數人云|淺論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/pr...

將來計劃

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