Prmetheus 主要用來做來Metrics的監控和報警，這張圖是官方的架構圖。
這是他的核心 它的作用是根據我們的配置去完成數據的采集、服務的發現，以及數據的存儲。
這是服務的發現，通過Service discovery,prmethesu就會知道去哪里采集數據。Service discovery有兩種形式，一種是是靜態的，就是通過文件去配。告訴它你要去哪拿這個Metrics的數據，另一種就是動態的，通過zookeeper或者其他的一些配置中心，配置中心里面的數據變化的時候，Prometheus也跟着變，去不同的地方去抓數據，
這都是我的應用來提供的，普羅米修斯是抓數據，是一個拉的模式，Prometheus調用我們的接口，然后把我們的數據抓走，是Prometheus來我們這拉數據，這樣的好處是，對於我們的應用來說，我們不需要知道Prometheus的服務在哪的，不需要做這些配置，我們只要暴露我們的數據就看可以了。 統一在Prometheus里面來配置.這樣Prometheus就可以去各種 地方抓各種各樣的數據。
Pushgateway是用來支持推模式的，因為有些時候，有些數據它並不是一直存在的，比如說我們的定時任務，Prometheus來抓的時候，我的定時任務剛好沒啟動，那么你就抓不到數據，所以向定時任務的數據 它會發給Pushgateway一個推送網關，這個時候，定時任務調用Pushgateway調用的接口，把數據直接給到Pushgateway。然后Prometheus去Pushgateway去拿東西，相當於Pushgateway是一個中間的臨時存儲，把這種短活的數據把它存儲起來。然后供Prometheus來拉。
采集的都是一些格式化的數據，流量啊，響應時間，這些數字格式化的數據，這個頁面可以幫你把這些數據 圖形化的展示出來。但這個頁面很簡陋。所以為了解決這個問題有個專門的項目叫做Grafana，它是一個更高級的圖形界面Grafana，它可以從Prometheus里面拿數據。把數據用圖標的形式展示出來。然后讓你一眼就看到你現在的系統是什么狀況。
當然你可以自己去寫代碼API clients去調Prometheus的服務，然后你自己拿出來去做處理。。
他們和Prometheus通訊的時候，主要 用到的語言是PromQL,Prometheus自己的一個查詢語言，和SQL類型，但是唯一不同的是，這個語言只能寫查詢，
右上角，AlertManager管理警告警用的，它來做報警，報警的方式有很多種。
Prometheus和AlertManager之間會有一些推送，你可以定義一些規則，Prometheus是做Metrics監控的，所謂的Metrics就是所有可以用數字來表示的數據，都可以用Metrics來采集。比如說你的系統的流量，服務的相應時間 ，那么根據這些Metrics可以去定義一些規則，比如說可以定義，服務的相應時間 如果大於100毫秒，那么我就報警，如果你定下了這樣的規則以后，Prometheus隔一段時間，這個時間也是你自己指定的，比如說每隔10秒，或者每隔一分鍾就去評估一下采集到的數據，然后根據你定的規則去評估，如果你采集的數據超過了你定義的預值，比如說響應時間超過了100毫秒，那么它就會往這邊推送一個警告。但是這個警告推過去以后，並不會立刻報警。因為它會再連續的評估幾個周期。比如說你設的評估周期是10秒。他可能再評估5次左右，在這個后面5次都是要報警的情況，它才會真正的報這個警。而不是說每一次評估沒過就立馬報警。這樣很可能就會出現誤報的情況。比如說網絡抖動啊。導致你的服務某些情況延遲了。 但是可能這些抖動，可能馬上就會過去了。 這個時候如果你采集到異常數據，馬上報警。很可能有很多的報警是假的，是沒有真正發現問題的。
這個就是整個Prometheus大的架構
在項目里面建了個文件夾。叫做monitoring，監控的一個文件夾，
這里面放了很多的配置文件。代碼不再敲了 帶着大家一行行的去讀代碼。
這是一個docker的復合文件，作用是一次替我裝幾個docker鏡像。
一旦你裝了Prometheus，橙色的框的就都安裝上了 ， 只有黃色的框需要單獨安裝。
這里安裝了兩個 一個是prometheus和hgrafana,
image配置的，啟動后就會docker的中央倉庫把它拉下來。一run起來，我就有了一個Prometheus的服務器了。
每個鏡像run的時候就生成一個容器，給這個容器起個名字prometheus.
我們下了prometheus，我們要給它一些配置，告訴你這個prometheus去哪里抓數據，
需要有一個服務發現的配置。告訴它你要去我的那些服務orderService抓我的監控數據，，那么這些配置怎么放進去。就是通過volumes ，掛載卷的方式，
也就是我們之前講的物力資源映射到容器的方式
那么映射的值是什么？就是配置的這個
冒號前面是我本地機器的目錄，相對我當前所在的這個目錄，里面的prometheus文件夾。
實際上指的就是我左邊項目里的這個文件夾，里面放了一個prometheus的配置文件。
然后我把這個文件放在prometheus鏡像里的/etc/prometheus這個文件夾下面。
也就是說這各prometheus.yml最終會出現在鏡像的/etc/prometheus/這個目錄里。默認情況prometheus就是從這個路徑下/etc/prometheus讀配置文件的。這樣我就可以把我的配置文件放到了prometheus的鏡像里，那么跑的時候就按照我定義的配置來跑。
機器訪問用9092端口，9090是容器的端口。為什么沒有用9090的端口，因為我的9090端口被認證服務器的api占用了。所以這里把它映射到9092
進入到monitoring文件夾
-f指定一個文件為docker-compose.yml 。up是啟動。
第一跑的話，可能會有下鏡像的日志，因為這里已經運行過了。所以這里直接量done
訪問9092。這個是就peometheus自身帶的ui
targets就是你要從哪里采集你的數據
現在這里有兩個目標。一個是prometheus本身。它從自己9090/metrics這個路徑來采集信息，狀態 up表示正常啟動。因為prometheus本身是啟動着的，
最新的一次從這個端點獲取數據，
srpingBoot這個app還沒啟動起來。
那么這兩個目標是從哪里來的呢？
它怎么知道去要去這個位置抓springboot-app的 信息的呢？
prometheus.yml的配置文件
全局的配置，抓取的頻率。prometheus是一個拉的模式，每隔一段時間去目標拉取數據，合理配置的就是拉取的頻率默認是每隔十五秒一次。
拉取的目標，定義了兩個job
抓取prometheus本身的時候又配置了 scrape_interval頻率是5秒。這就意味着抓取自己的時候是 5秒每次。
靜態的配置下有個targets，就是你要去哪抓數據。配置的是去本機的9090端口去抓。
prometheus是跑在容器里面的，容器你本身可以認為它就是一個機器。我們自己的電腦是另一個機器。你要理解為這兩個是兩個完全不同的機器。這個配置文件你要明白它是放在prometheus的機器上的。
抓數據，請求路徑。一會我們會在Order-APi上做一些操作，讓他可以提供出這個路徑的接口來。供普羅米修斯來抓數據。
你要去運行docker環境的宿主機的9082端口上去抓，springboot-app的數據。 一會我們會吧orderAPi跑在9082的端口上。
labels就是把抓出來的數據打一個標簽。標簽名字叫做springboot-app
結束