前言
本系列着重介紹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的技術資料
