目錄
一、 prometheus介紹
二、Prom元件
三、Prom的架構
3.1 架構圖簡單說明
3.2 prometheus伺服器
3.2.1 時序資料庫節點安裝
3.2.2 服務發現
3.3 prom資料采集、報警、展示功能
3.3.1 資料采集
3.3.2 報警功能
3.3.3 資料展示
四、Prometheus_工作流程
附錄一、Prometheus核心元件
1.Prometheus伺服器
2.Client Library
3.Exporter
4.Pushgateway
5.Alertmanager
前面花了十多篇介紹了k8s，那麼大名鼎鼎的配合k8s的監控工具prometheus（簡稱prom）肯定是要用的。是以讓我們開始prometheus之旅吧
推薦書籍《Prometheus監控技術與實踐》我已經上專到csdn中可以點選下載下傳，感覺比較适合入門，挻不錯的
一、 prometheus介紹
Prometheus（普羅米修斯，有時簡稱Prom）是一個開源的容器和微服務監測和預警工具集。Prometheus是為提供豐富度量名額、又不影響目标系統性能而設計的、高度可定制的雲原生監控系統。Prometheus已經成為主流開源的監測工具，受到了廣大使用者的歡迎，對于那些嚴重依賴容器和微服務的人來說，Prometheus是他們最佳的選擇。Prometheus适用于各種規模、各個行業。Prometheus已經具備完整的生态，包括與監控密切關聯的報警系統，也非常友善與第三方的監控系統內建，成為監控報警平台。Prometheus為現代DevOps工作流提供了關鍵元件，監視雲原生應用程式和基礎設施，并與CNCF另一個流行的項目Kubernetes完美協同。
Prometheus是由SoundCloud開發的開源監控報警系統和時序資料庫（Time Series Database，TSDB）。Prometheus受Google的Brogmon監控系統的啟發（Kubernetes是從Google的Brog系統演變而來的），從2012年開始由前Google工程師在SoundCloud以開源軟體的形式進行研發，并且于2015年初對外釋出早期版本。2016年5月繼Kubernetes之後成為第二個正式加入CNCF基金會的項目，同年6月正式釋出1.0版本。2017年底釋出了基于全新存儲層的2.0版本，能更好地與容器平台、雲平台配合。2018年8月，Prometheus已成為CNCF曆史上第二個“畢業”的項目。
二、Prom元件
Prometheus生态系統包含多個元件，其中許多是可選的：
- Prometheus server ：Prometheus主伺服器，它會抓取并存儲時間序列資料
- client libraries：用戶端庫，用于檢測應用程式代碼
- push gateway：一個支援短期工作short-lived 的推送網關
- exporters導出器：諸如HAProxy，StatsD，Graphite等服務的專用導出器
- alertmanager：警報經理以處理警報
- 各種支援工具
更詳細說明 見附錄一
三、Prom的架構
學習一個軟體，看一下架構是很重要的，這樣你就能知道它的組成，工作流程等
根據 Prometheus 官網Architecture ，目前最新版本為2.20，構架如下：
3.1 架構圖簡單說明
上圖中，中間部分是最重要的，也是核心部分，即prometheus server
既然是監控軟體，肯定涉及到資料采集、展示、報警三大功能，你圖左邊為資料采集、圖右上為警告處理、圖右下為資料展示
3.2 prometheus伺服器
prometheus 伺服器，如中圖中：
這個是最核心部分，prometheus是使用Go語言編寫的，使用是非源碼安裝，是以已經把相關依賴都弄進去了，基本上不需要安裝任何依賴。
用于收集和存儲時間序列資料。Prometheus Server是Prometheus元件中的核心部分，負責實作對監控資料的擷取,存儲以及查詢。提供一套靈活高效的查詢( PromQL )
prometheus server分為三部分：
- Retrieval:采樣子產品，Prometheus的伺服器在哪裡拉取資料檢索拉去到的資料分發給TSDB進行存儲。
- TSDB:存儲子產品預設本地存儲為tsdb，如果資料量很大的話，那麼就需要獨立安裝獨立的序列資料庫了，可以看一下時序資料庫排行榜
- HTTP Server:提供http接口查詢和面闆,預設端口為9090
ps:
Prometheus 1.0版本的TSDB（V2存儲引擎）基于LevelDB，并且使用了和Facebook Gorilla一樣的壓縮算法，能夠将16個位元組的資料點壓縮到平均1.37個位元組。
Prometheus 2.0版本引入了全新的V3存儲引擎，提供了更高的寫入和查詢性能
3.2.1
Prometheus預設的本地時序資料庫，并不是很大，放在本地上主要是提高性能，如果需要儲存海量資料則需要獨立再安裝第三方時序資料庫，如圖中下，紫色方框部分：
從圖上我們可以看出,在最開始設計的時候Prometheus遵循了安裝就用的簡單原件，在本地內建了一個tsdb資料庫,用來做本地存儲。
優點：這樣做是是的架構簡單指令,在做prometheus的多台server HA的時候非常友善。
缺點：無法對海量的資料進行存儲(資料最多保留幾周或者幾個月) , 還有個缺點就是當我們的prometheus壓力有點大的時候,橫向擴容也是不友善的。
是以Prometheus提供了remote_ write和remote_ read的特性 ,支援将資料存儲到遠端和從遠端讀取資料。通過将監控與資料分離, Prometheus能夠更好地進行彈性擴充。
時序資料庫排行榜中的時序資料庫如下：
PS：
時序資料庫（Time Series Database，TSDB）用于儲存時間序列（按時間順序變化）的海量資料，是一種高性能、低成本、穩定可靠的專業化資料庫。它可以提供高效讀寫、高壓縮比低成本存儲、降精度、插值、多元聚合計算和查詢功能，解決由于裝置采集點資料量巨大、資料采集頻率高而造成的存儲成本高、寫入和查詢分析效率低的問題。時序資料庫廣泛應用于物聯網監控系統、企業能源管理系統、生産安全監控、電力檢測系統等行業場景。
3.2.2 服務發現
服務發現，如中圖上：
服務發現, Prometheus支援多種服務發現機制:檔案, DNS , Consul,Kubernetes,OpenStack,EC2等等。基于服務發現的過程并不複雜,通過第三方提供的接口, Prometheus查詢到需要監控的Target清單,然後輪訓這些Target擷取監控資料。
3.3 prom資料采集、報警、展示功能
3.3.1 資料采集
靠pull metrics（名額）去拉資料，看圖左邊。
左上圖：
short-lived jobs :
存在時間不足以被删除的短暫和批量作業,無法通過pull方式拉取,需要使用push方式，與PushGateway搭配使用
Pushgateway
在其他情況下Prometheus都是通過Pull的方式從Exporters拉取,但是有一些情況是我們網絡不允許Prometheus和Exporters直接通信的情況下，可以使用Pushgateway由用戶端主:動push資料到Pushgateway ,再由Prometheus拉取,很多時候我們需要自定義-些元件來采集。
主要是拉取從Pushgateway推送過來的metric。主要是因為
1.Prometheus 采用 pull 模式，可能由于不在一個子網或者防火牆原因，導緻 Prometheus 無法直接拉取各個 target 資料。
2.在監控業務資料的時候，需要将不同資料彙總, 由 Prometheus 統一收集。
由于以上原因,不得不使用pushgateway ,但在使用之前,有必要了解一下它的一些弊端:
1、将多個節點資料彙總到pushgateway, 如果pushgateway挂了, 受影響比多個target大。
2、Prometheus 拉取狀态up隻針對pushgateway,無法做到對每個節點有效。
3、Pushgateway 可以持久化推送給它的所有監控資料。
是以，可以做多個pushgateway;即使你的監控已經下線, prometheus還會拉取到舊的監控資料,需要手動清理pushgateway不要的資料。
左下圖：
Exporters/Jobs :
負責收集目标對象( host, container... )的性能資料,并通過HTTP接口供Prometheus Server擷取。支援資料庫、硬體、消息中間件、存儲系統、http伺服器、 jmx等。隻要符合接口格式,就可以被采集。
從已經配置好的job或者exporter中拉取metric。
ps：從其他的Prometheus伺服器中拉取metric
Prometheus伺服器擷取到資料後存儲在本地（也可以選擇遠端存儲），通過一定規則對資料進行清理和整理，并且把結果存儲到新的時間序列中。
PS：
- 所謂的metrics（名額），可以了解成符合它标準的資源，比較要cpu0、記憶體（總、剩餘、使用）等
- 在Prometheus中，任何被采集的目标，即每一個暴露監控樣本資料的HTTP服務都稱為一個執行個體（Instance），通常對應于單個程序。而具有相同采集目的的執行個體集合（比如為可伸縮性或可靠性而複制的流程）稱為作業（Job）
3.3.2 報警功能
報警功能主要是靠prom伺服器 push 警告到 alertmanager 元件上，圖右邊上
Prometheus伺服器定時查詢已經定義好的規則，若發現滿足定義的觸發條件，便将alert資訊推送至已配置好的Alertmanager。
Alertmanager收到alert資訊後，根據配置檔案對接收到的alert資訊進行處理（聚合、去重、降噪），然後将它們轉換為網頁、電子郵件和其他通知方式發出告警
3.3.3 資料展示
圖右下是資料展示：
靠PromQL 表達式語言，對prom的資料進行篩選，最後把結果顯示出來，可以是自帶的，也可以使用第三方的Grafana軟體
Prometheus在記錄純數字時間序列方面表現得非常優秀。它既适用于對伺服器硬體各項名額的監控，也适用于對高度動态的面向服務架構的監控。在當下比較火的微服務生态圈中，它對多元資料收集和查詢的支援具有特殊的優勢。
四、Prometheus_工作流程
綜合上面，知道Prometheus_工作流程大概如下：
1.Prometheus server定期從配置好的jobs或者exporters 中拉metrics ,或者接收來自Pushgateway發過來的metrics ,或者從其他的Prometheus server中拉metrics。
2 Prometheus server在本地存儲收集到的metrics ,并運作E定義好的alert.rules ,記錄新的時間序列或者向Alertmanager推送警報。
3 Alertmanager根據配置檔案,對接收到的警報進行處理,發出告警。
4.在圖形界面中,可視化采集資料,可以使用别人寫好的Grafana模闆,或者可以自己靈活定制相關方法。
附錄一、Prometheus核心元件
Prometheus生态圈系統由多個元件組成，其中許多元件是可選的。大多數Prometheus元件使用Go語言編
寫而成，這樣可以非常容易地建構和部署為靜态的二進制檔案。我們介紹幾個核心元件：
1.Prometheus伺服器
Prometheus伺服器（server）是Prometheus架構中的核心元件，基于Go語言編寫而成，無第三方依賴關
系，可以獨立部署在實體伺服器、雲主機、Docker容器内。主要用于收集每個目标資料，并存儲為時間序
列資料，對外可提供資料查詢支援和告警規則配置管理。
Prometheus伺服器可以對監控目标進行靜态配置管理或動态配置管理，它将監控采集到的資料按照時間
序列存儲在本地磁盤的時序資料庫中（當然也支援遠端存儲），自身對外提供了自定義的PromQL語言，可
以對資料進行查詢和分析。
2.Client Library
Client Library是用于檢測應用程式代碼的用戶端庫。在監控服務之前，需要向用戶端庫代碼添加檢測，
進而實作了Prometheus中metric的類型。
所有主要語言和運作時都可以用于用戶端庫。Prometheus項目提供了官方的用戶端庫，包括Go、
Python、Java/JVM和Ruby。還有第三方用戶端庫，例如Bash、C++、.Net/C#、Node.js、PHP、Haskell、
Erlang和Rust。
用戶端庫負責所有細節，如線程安全和生成Prometheus文本表示格式以響應HTTP請求。由于基于名額
的監視不跟蹤單個事件，用戶端庫記憶體使用不會随着事件的增加而增加。相反，記憶體與你擁有的監控名額
的數量相關。
根據庫和運作時環境的不同，一些名額通常是由用戶端庫提供的，比如CPU使用率和垃圾收集統計數
據。用戶端庫不限于以Prometheus文本格式輸出名額。Prometheus是一個開放的生态系統，用于生成文本格
式的API可以生成其他格式的名額。
3.Exporter
用于輸出被監控元件資訊的HTTP接口統稱為Exporter（導出器）。目前網際網路公司常用的元件大部分
都有Exporter供直接使用，比如Nginx、MySQL、Linux系統資訊（包括磁盤、記憶體、CPU、網絡等）。
Exporter是Prometheus系統中重要的組成部分。在實際中收集監控樣本資料都是由Exporter完成的。
Exporter可以是一個獨立運作的程序，對外提供一個用于擷取監控資料的HTTP服務。Prometheus server隻需
要定時通過這些Exporter提供的HTTP服務擷取監控資料即可。可以類似了解為我們傳統意義上的被監控目
标的agent，隻是差別在于Exporter不會主動推送監控資料到Prometheus server。