對於普羅米修斯的介紹能夠參考這篇文章,寫的很是好,很是權威,不遜色於官方文檔,能夠說是中文環境下最好的參考資料html
Prometheus 入門與實踐
吳莉, 殷一鳴, 和蔡林
2018 年 5 月 30 日發佈node
我想寫出一篇超過這篇文章顯然以如今的實力是不太現實web
畢竟是很權威的文章,這種文章的通病就是太過學術,沒有了解過的人很難讀過就能明確的理解。docker
那麼就有我本身的理解來說講Prometheus的各個方面的問題 數據庫
可能有的觀點是錯誤的,因此仍是把他當成茶餘飯後的休閒文章看看吧 json
首先要解答這個問題,咱們必須瞭解一個重要的概念 api
Metric 服務器
這個官方文檔出現頻率的最高的單詞 架構
谷歌機翻翻譯爲度量,我以爲翻做指標可能更加貼切 運維
其實它的本質就是存在某一款數據庫的一條記錄
這篇文章介紹的也很詳細
總之就是監控系統經過服務將某個監控數據存入某個數據庫的某條記錄
這條記錄能夠動態的增長字段,最終獲得了通用的metric結構,name,label(與tag{}同義僅名字不一樣,在Prometheus中爲label),value,timestamp
咱們將額外須要擴展增長的數據生成json存入label{} ,這樣能夠方便的擴展字段,而不用每次都修改數據庫的表結構
(PS:在Prometheus中提供四種 Metric 類型 Counter, Gauge, Histogram,Summary)
具體的內容我就再也不贅述,能夠經過上文來了解Metric
那麼瞭解Metric,咱們還須要瞭解alert
Alert其實就是警報,咱們的監控系統就是爲了在集羣出現問題的時候
及時向運維人員報告
它的組成
用於收集和存儲時間序列數據。
客戶端庫,爲須要監控的服務生成相應的 metrics 並暴露給 Prometheus server。
當 Prometheus server 來 pull 時,直接返回實時狀態的 metrics。Push Gateway: 主要用於短時間的 jobs。
因爲這類 jobs 存在時間較短,可能在 Prometheus 來 pull 以前就消失了。
爲此,此次 jobs 能夠直接向 Prometheus server 端推送它們的 metrics。
這種方式主要用於服務層面的 metrics,對於機器層面的 metrices,須要使用 node exporter。
用於暴露已有的第三方服務的 metrics 給 Prometheus。
從 Prometheus server 端接收到 alerts 後,會進行去除重複數據,分組,並路由到對收的接受方式,發出報警。
常見的接收方式有:電子郵件,pagerduty,OpsGenie, webhook 等。
。。。。。。。。
其中jobs/Eeporters就是生成metric的,而後咱們的Prometheus server從它們那按期獲取metrics,或者一些短暫的jobs生成的metric推送給Pushgateway
再由Pushgateway推送給Prometheus server,或者其餘機器的Prometheus server發給本機的Prometheus server,
總之咱們想獲取的的數據源在Prometheus server中彙總後按照咱們規定的報警機制(alert.rules)推送警報到Alertmanager或者刷新時間序列(就是不報警,相安無事)
最後Alertmanager 根據配置文件,對接收到的警報進行處理,發出告警。在圖形界面中,可視化採集數據(這一步咱們放在grafana上去作)
(PS:
一個單獨 scrape 的目標, 通常對應於一個進程。
一組同種類型的 instances(主要用於保證可擴展性和可靠性))
job: api-server instance 1: 1.2.3.4:5670 instance 2: 1.2.3.4:5671 instance 3: 5.6.7.8:5670 instance 4: 5.6.7.8:5671
當 scrape 目標時,Prometheus 會自動給這個 scrape 的時間序列附加一些標籤以便更好的分別,例如: instance,job。
下面以實際的 metric 爲例,對上述概念進行說明。
如上圖所示,這三個 metric 的名字都同樣,他們僅憑 handler 不一樣而被標識爲不一樣的 metrics。這類 metrics 只會向上累加,是屬於 Counter 類型的 metric,且 metrics 中都含有 instance 和 job 這兩個標籤
到此咱們已經瞭解了Prometheus 最基礎的個概念,下一篇咱們就要小試牛刀,試試實際運行