容器監控實踐—Prometheus基本架構

系統架構圖

1.x版本的Prometheus的架構圖爲：

目前Prometheus版本爲2.7，架構圖爲：

Prometheus從exporter拉取數據，或者間接地經過網關gateway拉取數據（若是在k8s內部署，可使用服務發現的方式），它默認本地存儲抓取的全部數據，並經過必定規則進行清理和整理數據，並把獲得的結果存儲到新的時間序列中，採集到的數據有兩個去向，一個是報警，另外一個是可視化。PromQL和其餘API可視化地展現收集的數據，並經過Alertmanager提供報警能力。

組件內容

• Prometheus Server
  負責從 Exporter 拉取和存儲監控數據,並提供一套靈活的查詢語言（PromQL）

  • Retrieval: 採樣模塊
  • TSDB: 存儲模塊默認本地存儲爲tsdb
  • HTTP Server: 提供http接口查詢和麪板，默認端口爲9090
• Exporters/Jobs

負責收集目標對象（host, container…）的性能數據，並經過 HTTP 接口供 Prometheus Server 獲取。支持數據庫、硬件、消息中間件、存儲系統、http服務器、jmx等。只要符合接口格式，就能夠被採集。

• Short-lived jobs

瞬時任務的場景，沒法經過pull方式拉取，須要使用push方式，與PushGateway搭配使用

• PushGateway

可選組件，主要用於短時間的 jobs。因爲這類 jobs 存在時間較短，可能在 Prometheus 來 pull 以前就消失了。爲此，此次 jobs 能夠直接向 Prometheus server 端推送它們的 metrics。這種方式主要用於服務層面的 metrics，對於機器層面的 metrices，須要使用 node exporter。

• 客戶端sdk

官方提供的客戶端類庫有go、java、scala、python、ruby，其餘還有不少第三方開發的類庫，支持nodejs、php、erlang等

• PromDash

使用rails開發的dashboard，用於可視化指標數據，已廢棄

• Alertmanager

從 Prometheus server 端接收到 alerts 後，會進行去除重複數據，分組，並路由到對收的接受方式，發出報警。常見的接收方式有：電子郵件，pagerduty，OpsGenie, webhook 等。

• Service Discovery

服務發現，Prometheus支持多種服務發現機制：文件，DNS，Consul,Kubernetes,OpenStack,EC2等等。基於服務發現的過程並不複雜，經過第三方提供的接口，Prometheus查詢到須要監控的Target列表，而後輪訓這些Target獲取監控數據。

其大概的工做流程是：

• Prometheus server 按期從配置好的 jobs 或者 exporters 中拉 metrics，或者接收來自 Pushgateway 發過來的 metrics，或者從其餘的 Prometheus server 中拉 metrics。
• Prometheus server 在本地存儲收集到的 metrics，並運行已定義好的 alert.rules，記錄新的時間序列或者向 Alertmanager 推送警報。
• Alertmanager 根據配置文件，對接收到的警報進行處理，發出告警。
• 在圖形界面中，可視化採集數據。

關於Push與Pull

Prometheus採集數據是用的pull也就是拉模型,經過HTTP協議去採集指標，只要應用系統可以提供HTTP接口就能夠接入監控系統，相比於私有協議或二進制協議來講開發、簡單。優勢主要是：

• 開發任何新功能，你甚至能夠在電腦上查看你的監控
• 若是目標實例掛掉，你能夠很快知道
• 你能夠手動指定目標實例，而且在瀏覽器中查看他的健康狀態

整體來講，Pull模式比Push模式更好一些，在監控系統中這也不是一個很重要的點。
若是要使用push的方式，可使用Pushgateway的方式，如定時任務的採集。

對於定時任務這種短週期的指標採集，若是採用pull模式，可能形成任務結束了，Prometheus尚未來得及採集，這個時候可使用加一箇中轉層，客戶端推數據到Push Gateway緩存一下，由Prometheus從push gateway pull指標過來。(須要額外搭建Push Gateway，同時須要新增job去從gateway採數據)

推的表明有 ElasticSearch，InfluxDB，OpenTSDB 等，須要你從程序中將指標使用 TCP，UDP 等方式推送至相關監控應用，只是使用 TCP 的話，一旦監控應用掛掉或存在瓶頸，容易對應用自己產生影響，而使用 UDP 的話，雖然不用擔憂監控應用，可是容易丟數據。

拉的表明，主要表明就是 Prometheus，讓咱們不用擔憂監控應用自己的狀態。並且，能夠利用 DNS-SRV 或者 Consul 等服務發現功能就能夠自動添加監控。

固然，InfluxDB 加上 collector，或者 ES 加上 metricbeat 也能夠變爲 『拉』，而 Prometheus 加上 Push Gateway 也能夠變爲 『推』。

更多區別能夠參考下圖：

存儲機制

Prometheus有着很是高效的時間序列數據存儲方法，每一個採樣數據僅僅佔用3.5byte左右空間，上百萬條時間序列，30秒間隔，保留60天，大概花了200多G（引用官方PPT）。

Prometheus內部主要分爲三大塊，Retrieval是負責定時去暴露的目標頁面上去抓取採樣指標數據，Storage是負責將採樣數據寫磁盤，PromQL是Prometheus提供的查詢語言模塊。

Prometheus內置了一個基於本地存儲的時間序列數據庫。在Prometheus設計上，使用本地存儲能夠下降Prometheus部署和管理的複雜度同時減小高可用（HA）帶來的複雜性。 在默認狀況下，用戶只須要部署多套Prometheus，採集相同的Targets便可實現基本的HA。同時因爲Promethus高效的數據處理能力，單個Prometheus Server基本上可以應對大部分用戶監控規模的需求。

同時爲了適應數據持久化的問題，Prometheus提供了remote_write和remote_read的特性，支持將數據存儲到遠端和從遠端讀取數據。經過將監控與數據分離，Prometheus可以更好地進行彈性擴展。

關於存儲用量規劃：https://www.jianshu.com/p/934...
更多：Prometheus存儲機制詳解

https://yunlzheng.gitbook.io/...

https://www.cnblogs.com/vovli...

https://www.linuxidc.com/Linu...

https://segmentfault.com/a/11...

https://www.infoq.cn/article/...

關於日誌處理

不建議將日誌監控放在Prometheus中，這不是他的專長，仍是使用ELK或EFK的方式處理日誌信息

競品對比

參考: https://toutiao.io/posts/fsjq...

將來規劃

• 服務端度量指標元數據支持
  在度量指標類型和其餘元數據僅僅在客戶庫和展現格式中使用，並不會在Prometheus服務中持久保留或者利用。未來咱們計劃充分利用這些元數據。第一步是在Prometheus服務的內存中聚合這些數據，並開放一些實驗性的API來提供服務
• 支持OpenMetrics

OpenMetrics組開放了一個新的監控指標暴露標準，咱們將支持這種標準：https://openmetrics.io/

• 回溯時間序列

容許將過去一段時間的數據發送到其餘的監控系統

• HTTP服務支持TLS安全認證

當前的Prometheus, Alertmanager和一些官方exporter，暴露服務時，都不支持tls認證，有很大的安全風險，如今的實現都是基於反向代理，以後將內置到組件中

• 支持子查詢

當前的Promq不支持子查詢，如max_over_time() of a rate())，後續將會支持

• 支持生態建設

Prometheus有不少的client庫和exporter，咱們將會對其進行規範和生態建設。

在K8S中使用

在以前的版本中，k8s默認以及推薦的監控體系是它本身的一套東西：Heapster + cAdvisor + Influxdb + Grafana，1.8後Heaspter由Metric-server替代。若是你部署了Dashboard，就能看到監控數據（來自heapster）

k8s 自身的 HPA (Horizontal Pod Autoscaler)，默認從 Heapster 中獲取數據進行自動伸縮

1.8版本之後，K8S但願將核心監控指標收攏到metric api的形式，而自定義監控指標，由prometheus來實現，prometheus正式成爲k8s推薦的監控實現方案。

參考文檔：

• https://www.ibm.com/developer...
• https://prometheus.io/docs/in...
• https://www.kancloud.cn/cdh08...
• https://yunlzheng.gitbook.io/...

本文爲容器監控實踐系列文章，完整內容見：container-monitor-book