前言
本系列著重介紹Prometheus以及如何用它和其周邊的生態來搭建一套屬於自己的實時監控告警平臺。
本系列受眾物件為初次接觸Prometheus的使用者，大神勿噴，偏重於操作和實戰，但是重要的概念也會精煉出提及下。系列主要分為以下幾塊
Prometheus各個概念介紹和搭建，如何抓取資料(一步步教你用Prometheus搭建實時監控系統系列(一)——上帝之火，普羅米修斯的崛起)- 如何推送資料至
Prometheus，推送和拉取分別用於什麼樣的場景(本次分享內容) Prometheus資料的結構以及查詢語言PromQL的使用- Java應用如何和
Prometheus整合，如何啟用服務發現，如果自定義業務指標 Prometheus如何和Grafana視覺化套件進行整合和設定告警- 教你如何手寫一個整合了監控Dubbo各個指標的java套件
- 實際案例分享，如何做各個業務端和系統端的監控大盤
抓取和推送
拉取模式：
Prometheus獲取資料的方式只有拉取(PULL)，即Prometheus會以固定頻率去請求每個target所提供的http url來獲取資料。這就需要每個服務端點提供http的介面來獲取實時的資料。
推送模式：
Prometheus也變相的實現了推送資料的方式。
為什麼說是變相呢。因為Prometheus獲取資料的方式一直是拉取方式，官方並沒有提供推送資料的功能。但是官方為了相容推送這種方式，增加了一個PushGateway元件。
這個元件相當於一個代理服務，獨立部署。它沒有資料抓取功能，只能被動的等待資料推送。應用把資料推送到PushGateway後，Prometheus再從PushGateway抓取。
推送模式要注意的點
即便客戶端推了全量的資料到了PushGateway，Prometheus也不是每次拉取這個期間使用者推上來的所有資料。
事實上Prometheus只拉取使用者最後一次push上來的資料。
在這個系列一的時候，曾經提到過Prometheus其實並不需要每一個精確的資料，長期儲存的是中等或者低精度的資料。它每次只抓取一個資料，在固定的頻率下。也能形成某種資料的趨勢。
如果客戶端一直沒有推送新的指標到PushGateway，那麼Prometheus將始終拉取最後推送上的資料，直到指標消失，預設是5分鐘。
Pushgateway本意是不會儲存指標的，但是為了讓pushgateway意外重啟一類的故障之後能夠重新讀取到原來的指標，新增了一個將指標暫時儲存到本地的功能，引數--persistence.interval=5m就是預設保持5分鐘，5分鐘後，本地儲存的指標會刪除。可以通過調節這個值來修正發現異常的時間。
通過單個Pushgateway監控多個例項時，Pushgateway有可能成為單點故障和潛在瓶頸
如果要用Pushgateway的話，建議多點部署。然後前面通過nginx進行反向代理多個節點，進行負載均衡。
推送模式適用的場景
Prometheus採用定時拉取模式，可能由於子網路或者防火牆的原因，不能直接拉取各個Target的指標資料，此時可以採用各個Target往PushGateway上推送資料，然後Prometheus去PushGateway上定時拉取- 在監控各個業務資料時，需要將各個不同的業務資料進行統一彙總，此時也可以採用
PushGateway來統一收集，然後Prometheus來統一拉取
搭建
Pushgateway分docker安裝和普通安裝兩種，這裡才用普通安裝
先上prometheus的github release主頁
按照需要下載對應的包，我這裡是需要部署在linux伺服器上，所以下載這個
下載好，解壓。執行：
nohup ./pushgateway &
啟動起來後，預設埠為9091
在瀏覽器上根據ip+port可以訪問到如下頁面，就算啟動成功了：
除此之外還要在Prometheus的配置檔案裡設定Target:
- job_name: 'pushgateway'
scrape_interval: 10s # 每過10秒拉取一次
honor_labels: true
static_configs:
- targets: ['localhost:9091']
labels:
instance: pushgateway
設定完畢後重啟Prometheus，然後會在Target選項卡里看到狀態為UP的Pushgateway。
設定階段就完成了。
URL推送測試
我這裡用postman軟體進行推送測試，推送url的格式為：/metrics/job/<JOBNAME>{/<LABEL_NAME>/<LABEL_VALUE>}
這個測試用例為意思是，推送一個指標aaa，標籤為bbb=BBB,ccc=CCC，值為111.1到一個組上，這個組為job=pushgateway,instance=demo。
其實你可以簡單的理解為這個指標aaa帶有4個標籤：job，instance，bbb，ccc。只是job和instance是屬於組上的標籤。
同一個組裡的相同的指標，Prometheus每次只取最新的，不同組內可以有相同的指標。
關於資料結構和標籤結構系列的下一篇文章會詳細介紹。
總之，你提交這個POST請求後，可以在http://ip:9091上看到如下資料：
可以看到，aaa這個標籤已經成功的被提交到Pushgateway裡了。
接下來，我們在Prometheus裡查詢這個指標：
可以看到，Prometheus也成功的拉取到了這個指標。
Java端利用SDK進行推送
雖然我們在java服務端也能利用httpclient等工具進行提交，但是需要自行組裝很多請求體。Prometheus官方提供了一個SDK。
首先在Maven中引入依賴包：
<dependency>
<groupId>io.prometheus</groupId>
<artifactId>simpleclient_pushgateway</artifactId>
<version>0.9.0</version>
</dependency>
對Gauge,Timer,Counter,Summary四種常見的指標進行推送示例：
public void run(String... args) throws Exception {
Gauge guage = Gauge.build("my_custom_metric", "This is my custom metric.")
.labelNames("aaa","bbb").register();
Gauge.Child child = guage.labels("AAA","BBB");
child.set(334.5);
Gauge timerGauge = Gauge.build("my_timer_metric","this is my timer metric.").register();
Gauge.Timer timer = timerGauge.startTimer();
Thread.sleep(3000L);
Counter counter = Counter.build("my_count_metric","this is my count metric.").register();
counter.inc();
counter.inc();
Summary summary = Summary.build("my_summary_metric","this is my summary metric.").register();
summary.observe(45.6);
summary.observe(54.5);
String url = "xxx.xxx.xxx.xxx:9091";
PushGateway pg = new PushGateway(url);
Map<String, String> groupingKey = new HashMap<>();
groupingKey.put("instance", "my_instance");
pg.pushAdd(CollectorRegistry.defaultRegistry, "my_job", groupingKey);
}
這段程式碼演示了4個指標批量提交的場景。通過註冊到CollectorRegistry.defaultRegistry裡，最後一起pushAdd。
我們可以在Pushgateway裡查詢到提交的指標：
同樣在Prometheus裡也能查詢到這4個指標，具體圖示就不貼了。可以自己嘗試下。
最後
這個系列旨在利用實戰操作教你一步步搭建自己系統和業務監控大盤。後面會繼續更新。下一個章節將分析：Prometheus中的資料格式分析以及PromQL的使用。
關注作者
如果你喜歡作者的文章，歡迎微信公眾號關注 「元人部落」，一個只做原創的技術科技分享號
關注後回覆“資料”獲取50G的技術資料
