一步步教你用Prometheus搭建實時監控系統系列(二)——詳細分析拉取和推送兩種不同模式

前言

本系列着重介紹 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主頁

https://github.com/prometheus/pushgateway/releases

按照需要下載對應的包，我這裏是需要部署在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 裏查詢到提交的指標：