資訊專欄INFORMATION COLUMN
摘要：根據配置文件，對接收到的警報進行處理，發出告警。在默認情況下，用戶只需要部署多套，采集相同的即可實現基本的。通過將監控與數據分離，能夠更好地進行彈性擴展。參考文檔本文為容器監控實踐系列文章，完整內容見
系統架構圖
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與PullPrometheus采集數據是用的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
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/33134.html
摘要：根據配置文件，對接收到的警報進行處理，發出告警。在默認情況下，用戶只需要部署多套，采集相同的即可實現基本的。通過將監控與數據分離，能夠更好地進行彈性擴展。參考文檔本文為容器監控實踐系列文章，完整內容見 系統架構圖 1.x版本的Prometheus的架構圖為：showImg(https://segmentfault.com/img/remote/1460000018372350?w=14...
摘要：宋體本文從拉勾網的業務架構日志采集監控服務暴露調用等方面介紹了其基于的容器化改造實踐。宋體此外，拉勾網還有一套自研的環境的業務發布系統，不過這套發布系統未適配容器環境。寫在前面 拉勾網于 2019 年 3 月份開始嘗試將生產環境的業務從 UHost 遷移到 UK8S，截至 2019 年 9 月份，QA 環境的大部分業務模塊已經完成容器化改造，生產環境中，后臺管理服務已全部遷移到 UK8...
摘要：容器內文件日志平臺支持的文件存儲是，避免了許多復雜環境的處理。以上是數人云在實踐容器日志系統過程中遇到的問題，更高層次的應用包括容器日志分析等，還有待繼續挖掘和填坑，歡迎大家提出建議，一起交流。 業務平臺每天產生大量日志數據，為了實現數據分析，需要將生產服務器上的所有日志收集后進行大數據分析處理，Docker提供了日志驅動，然而并不能滿足不同場景需求，本次將結合實例分享日志采集、存儲以...
摘要：本文將分享是為何以及如何開發出最佳實踐方法來使用在中監控應用程序的。什么是監控最近有很多關于的消息，尤其是在中監控應用程序這方面。方法遵循中提及的原則，聚焦于檢測最終用戶在使用服務時關心的東西。 本文來自Weaveworks的工程師Anita Burhrle在Rancher Labs與Weaveworks聯合舉辦的Online Meetup上的技術分享。在此次分享中，嘉賓們討論了如何使...
摘要：還可以把數據導入到第三方工具展示或使用場景共同組成了一個流行的監控解決方案原生的監控圖表信息來自在中也用到了，將作為，向其獲取，作為水平擴縮容的監控依據監控指標流程首先從獲取集群中所有的信息。 概述 該項目將被廢棄（RETIRED） Heapster是Kubernetes旗下的一個項目，Heapster是一個收集者，并不是采集 1.Heapster可以收集Node節點上的cAdvis...
閱讀 2096·2023-04-25 17:57
閱讀 1294·2021-11-24 09:39
閱讀 2492·2019-08-29 16:39
閱讀 3322·2019-08-29 13:44
閱讀 3138·2019-08-29 13:14
閱讀 2329·2019-08-26 11:36
閱讀 3823·2019-08-26 11:00
閱讀 955·2019-08-26 10:14
