Prometheus是新一代的監控系統解決方案，原生支援雲環境，和kubernetes無縫對接，的卻是容器化監控解決方案的不二之選。當然對傳統的監控方案也能夠相容，通過自定義或是用開源社群提供的各種exporter無疑又為prometheus豐滿羽翼。那麼從今天開始我將會持續更新我對prometheus使用過程中的瞭解和踩坑記錄，一是為了沉澱自己，二是為同學們提供個思路。
- 1、架構介紹
上圖就是prometheus的一個整體的架構圖，這篇文章就圍繞這張圖展開，介紹prometheus的工作機制和各元件提供的功能。
-
1.1 Prometheus server元件介紹
a. Prometheus server:
它是prometheus的主程式，本身也是一個時序資料庫，它來負責整個監控叢集的資料拉取、處理、計算和儲存。和zabbix採取push監控資料的方式不同，
1、prometheus的設計是使用pull方式由服務端主動拉取監控資料。關於push和pull兩種方式的優缺點爭論一直存在，這裡不再過多贅述，只需知道即可。
當prometheus拉取到資料之後首先進行的操作是資料的處理：根據配置的資料格式或者標籤轉換/刪除等操作。
2、資料處理完成後是根據rule中配置的規則進行計算：比如CPU使用率達到80%是一條告警規則，則prometheus會對資料進行計算看是否命中規則，命中則傳送訊息給alertmanager元件，否則不做操作。
3、完成上面的一些操作之後，prometheus會根據配置時間週期儲存資料到本地或者是第三方儲存中
以上便是prometheus server做的比較重要的事情(大致流程是這樣，細節方面未做探討。) -
1.2 Alertmanager 元件介紹
b. Alertmanager:
它是prometheus的告警元件，負責整個叢集的告警傳送、分組、排程、警告抑制等功能。
需要知道的是alertmanager本身是不做告警規則計算的，簡單來說就是，alertmanager不去計算當前的監控取值是否達到我設定的閾值，上面已經提過該部分規則計算是prometheus server來計算的，alertmanager監聽prometheus server發來的訊息，然後在結合自己的配置，比如等待週期，重複傳送告警時間，路由匹配等配置項，然後把接收到的訊息傳送到指定的接收者。同時他還支援多種告警接收方式，常見的如郵件、企業微信、釘釘等。 -
1.3 Pushgateway 元件介紹
c. Pushgateway
它是prometheus的一箇中間網管元件，類似於zabbix的zabbix-proxy。它主要解決的問題是一些不支援pull方式獲取資料的場景，比如：自定義shell指令碼來監控服務的健康狀態，這個就沒辦法直接讓prometheus來拉資料，這時就可以藉助pushgateway，它是支援推送資料的，我們可以把對應的資料按照prometheus的格式推送到pushgateway，然後配置prometheus server拉取pushgateway即可。 -
1.4 資料展示元件介紹
上圖右下角的幾個元件,grafana、prometheus-ui是用來圖形化展示資料的元件，其中prometheus-ui是prometheus專案原生的ui介面，但是在資料展示方面不太好用，因此推薦grafana來展示你的資料，grafana支援prometheus的PromQL語法，能夠和prometheus資料庫互動，加上grafana強大的ui功能，我們可以很輕鬆的獲取到很多好看的介面，同時也有很多做好的模版可以使用。 -
1.5 服務發現元件介紹
對一個監控系統來說，自動發現肯定是一個最基礎的功能，試想如果沒有自動發現，新增10000臺主機到監控系統該是中什麼體驗？還好，prometheus是有該元件的，而且還很多，支援多種自動發現機制，比如基於檔案、DNS、consul、zookeeper、etcd、kuberbetes等服務自動發現的方式,這些服務發現方式後面都會寫到。
本篇寫到這裡就要結束了，主要是簡要介紹了下prometheus中各元件的大致功能，對prometheus又一個大致的瞭解。下一篇會寫幾種prometheus的安裝方式。