容器監(jiān)控實踐—Prometheus基本架構(gòu)

系統(tǒng)架構(gòu)圖

1.x版本的Prometheus的架構(gòu)圖為：


image

目前Prometheus版本為2.7，架構(gòu)圖為：

image

Prometheus從exporter拉取數(shù)據(jù)，或者間接地通過網(wǎng)關(guān)gateway拉取數(shù)據(jù)（如果在k8s內(nèi)部署，可以使用服務發(fā)現(xiàn)的方式），它默認本地存儲抓取的所有數(shù)據(jù)，并通過一定規(guī)則進行清理和整理數(shù)據(jù)，并把得到的結(jié)果存儲到新的時間序列中，采集到的數(shù)據(jù)有兩個去向，一個是報警，另一個是可視化。PromQL和其他API可視化地展示收集的數(shù)據(jù)，并通過Alertmanager提供報警能力。

組件內(nèi)容

  • Prometheus Server
    負責從 Exporter 拉取和存儲監(jiān)控數(shù)據(jù),并提供一套靈活的查詢語言（PromQL）

    • Retrieval: 采樣模塊
    • TSDB: 存儲模塊默認本地存儲為tsdb
    • HTTP Server: 提供http接口查詢和面板，默認端口為9090

  • Exporters/Jobs
    負責收集目標對象（host, container…）的性能數(shù)據(jù)，并通過 HTTP 接口供 Prometheus Server 獲取。支持數(shù)據(jù)庫、硬件、消息中間件、存儲系統(tǒng)、http服務器、jmx等。只要符合接口格式，就可以被采集。

  • Short-lived jobs
    瞬時任務的場景，無法通過pull方式拉取，需要使用push方式，與PushGateway搭配使用

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

  • 客戶端sdk
    官方提供的客戶端類庫有g(shù)o、java、scala、python、ruby，其他還有很多第三方開發(fā)的類庫，支持nodejs、php、erlang等

  • PromDash
    使用rails開發(fā)的dashboard，用于可視化指標數(shù)據(jù)，已廢棄

  • Alertmanager
    從 Prometheus server 端接收到 alerts 后，會進行去除重復數(shù)據(jù)，分組，并路由到對收的接受方式，發(fā)出報警。常見的接收方式有：電子郵件，pagerduty，OpsGenie, webhook 等。

  • Service Discovery
    服務發(fā)現(xiàn)，Prometheus支持多種服務發(fā)現(xiàn)機制：文件，DNS，Consul,Kubernetes,OpenStack,EC2等等。基于服務發(fā)現(xiàn)的過程并不復雜，通過第三方提供的接口，Prometheus查詢到需要監(jiān)控的Target列表，然后輪訓這些Target獲取監(jiān)控數(shù)據(jù)。

其大概的工作流程是：

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

關(guān)于Push與Pull

Prometheus采集數(shù)據(jù)是用的pull也就是拉模型,通過HTTP協(xié)議去采集指標，只要應用系統(tǒng)能夠提供HTTP接口就可以接入監(jiān)控系統(tǒng)，相比于私有協(xié)議或二進制協(xié)議來說開發(fā)、簡單。優(yōu)點主要是：

  • 開發(fā)任何新功能，你甚至可以在電腦上查看你的監(jiān)控
  • 如果目標實例掛掉，你可以很快知道
  • 你可以手動指定目標實例，并且在瀏覽器中查看他的健康狀態(tài)

總體來說，Pull模式比Push模式更好一些，在監(jiān)控系統(tǒng)中這也不是一個很重要的點。
如果要使用push的方式，可以使用Pushgateway的方式，如定時任務的采集。

對于定時任務這種短周期的指標采集，如果采用pull模式，可能造成任務結(jié)束了，Prometheus還沒有來得及采集，這個時候可以使用加一個中轉(zhuǎn)層，客戶端推數(shù)據(jù)到Push Gateway緩存一下，由Prometheus從push gateway pull指標過來。(需要額外搭建Push Gateway，同時需要新增job去從gateway采數(shù)據(jù))

推的代表有 ElasticSearch，InfluxDB，OpenTSDB 等，需要你從程序中將指標使用 TCP，UDP 等方式推送至相關(guān)監(jiān)控應用，只是使用 TCP 的話，一旦監(jiān)控應用掛掉或存在瓶頸，容易對應用本身產(chǎn)生影響，而使用 UDP 的話，雖然不用擔心監(jiān)控應用，但是容易丟數(shù)據(jù)。

拉的代表，主要代表就是 Prometheus，讓我們不用擔心監(jiān)控應用本身的狀態(tài)。而且，可以利用 DNS-SRV 或者 Consul 等服務發(fā)現(xiàn)功能就可以自動添加監(jiān)控。

當然，InfluxDB 加上 collector，或者 ES 加上 metricbeat 也可以變?yōu)?『拉』，而 Prometheus 加上 Push Gateway 也可以變?yōu)?『推』。

更多區(qū)別可以參考下圖：


image

存儲機制

Prometheus有著非常高效的時間序列數(shù)據(jù)存儲方法，每個采樣數(shù)據(jù)僅僅占用3.5byte左右空間，上百萬條時間序列，30秒間隔，保留60天，大概花了200多G（引用官方PPT）。

Prometheus內(nèi)部主要分為三大塊，Retrieval是負責定時去暴露的目標頁面上去抓取采樣指標數(shù)據(jù)，Storage是負責將采樣數(shù)據(jù)寫磁盤，PromQL是Prometheus提供的查詢語言模塊。

Prometheus內(nèi)置了一個基于本地存儲的時間序列數(shù)據(jù)庫。在Prometheus設計上，使用本地存儲可以降低Prometheus部署和管理的復雜度同時減少高可用（HA）帶來的復雜性。 在默認情況下，用戶只需要部署多套Prometheus，采集相同的Targets即可實現(xiàn)基本的HA。同時由于Promethus高效的數(shù)據(jù)處理能力，單個Prometheus Server基本上能夠應對大部分用戶監(jiān)控規(guī)模的需求。

同時為了適應數(shù)據(jù)持久化的問題，Prometheus提供了remote_write和remote_read的特性，支持將數(shù)據(jù)存儲到遠端和從遠端讀取數(shù)據(jù)。通過將監(jiān)控與數(shù)據(jù)分離，Prometheus能夠更好地進行彈性擴展。

關(guān)于存儲用量規(guī)劃：http://www.lxweimin.com/p/93412a925da2
更多：Prometheus存儲機制詳解

https://yunlzheng.gitbook.io/prometheus-book/part-ii-prometheus-jin-jie/readmd

https://www.cnblogs.com/vovlie/p/7709312.html

https://www.linuxidc.com/Linux/2018-04/152057.htm

https://segmentfault.com/a/1190000008629939

https://www.infoq.cn/article/Prometheus-theory-source-code

關(guān)于日志處理

不建議將日志監(jiān)控放在Prometheus中，這不是他的專長，還是使用ELK或EFK的方式處理日志信息

競品對比

參考: https://toutiao.io/posts/fsjq8t/preview

未來規(guī)劃

  • 服務端度量指標元數(shù)據(jù)支持
    在度量指標類型和其他元數(shù)據(jù)僅僅在客戶庫和展示格式中使用，并不會在Prometheus服務中持久保留或者利用。將來我們計劃充分利用這些元數(shù)據(jù)。第一步是在Prometheus服務的內(nèi)存中聚合這些數(shù)據(jù)，并開放一些實驗性的API來提供服務

  • 支持OpenMetrics
    OpenMetrics組開放了一個新的監(jiān)控指標暴露標準，我們將支持這種標準：https://openmetrics.io/

  • 回溯時間序列
    允許將過去一段時間的數(shù)據(jù)發(fā)送到其他的監(jiān)控系統(tǒng)

  • HTTP服務支持TLS安全認證

當前的Prometheus, Alertmanager和一些官方exporter，暴露服務時，都不支持tls認證，有很大的安全風險，現(xiàn)在的實現(xiàn)都是基于反向代理，之后將內(nèi)置到組件中

  • 支持子查詢

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

  • 支持生態(tài)建設

Prometheus有很多的client庫和exporter，我們將會對其進行規(guī)范和生態(tài)建設。

在K8S中使用

在之前的版本中，k8s默認以及推薦的監(jiān)控體系是它自己的一套東西：Heapster + cAdvisor + Influxdb + Grafana，1.8后Heaspter由Metric-server替代。如果你部署了Dashboard，就能看到監(jiān)控數(shù)據(jù)（來自heapster）

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

1.8版本以后，K8S希望將核心監(jiān)控指標收攏到metric api的形式，而自定義監(jiān)控指標，由prometheus來實現(xiàn)，prometheus正式成為k8s推薦的監(jiān)控實現(xiàn)方案。

參考文檔：

本文為容器監(jiān)控實踐系列文章，完整內(nèi)容見：container-monitor-book

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

推薦閱讀更多精彩內(nèi)容