概述

Prometheus Server的資料抓取工作於Pull模型，因而，它必需要事先知道各Target的位置，然後才能從相應的 Exporter 或 Instrumentation 中抓取資料 對於小型的系統環境來說，通過static_configs指定各Target便能解決問題，這也是最簡單的配置方法；

• 每個Targets用一個網路端點（ip:port）進行標識；

對於中大型的系統環境或具有較強動態性的雲端計算環境來說，靜態配置顯然難以適用； 因此，Prometheus為此專門設計了一組服務發現機制，以便於能夠基於服務註冊中心（服務匯流排）自動發現、檢測、分類可被監控的各Target，以及更新發生了變動的Target；

指標抓取的生命週期

下圖展示了Prometheus上進行指標抓取的簡單生命週期

• 在每個scrape_interval期間，Prometheus都會檢查執行的作業（Job）；
• 這些作業首先會根據Job上指定的發現配置生成target列表，此即服務發現過程；
  • 服務發現會返回一個Target列表，其中包含一組稱為元資料的標籤，這些標籤都以“__meta_”為字首；
  • 服務發現還會根據目標配置來設定其它標籤，這些標籤帶有“__”字首和字尾，包括“__scheme__”、“__address__”和“__metrics_path__”，分別儲存有target支援使用協議(http或https，預設為http）、target的地址及指標的URI路徑（預設為/metrics）；
  • 若URI路徑中存在任何引數，則它們的字首會設定為“__param_”
  • 這些目標列表和標籤會返回給Prometheus，其中的一些標籤也可以配置中被覆蓋；

配置標籤會在抓取的生命週期中被重複利用以生成其他標籤，例如，指標上的instance標籤的預設值就來自於__address__標籤的值； 對於發現的各目標，Prometheus提供了可以重新標記(relabel) 目標的機會 它定義在job配置段的relabel_config配置中，常用於實現如下功能

• 將來自服務發現的元資料標籤中的資訊附加到指標的標籤上；
• 過濾目標；

這之後，便是資料抓取、以及指標返回的過程； 抓取而來的指標在儲存之前，還允許使用者對指標重新打標並過濾的方式；

• 它定義在job配置段的metric_relabel_configs配置中，常用於實現如下功能
  • 刪除不必要的指標；
  • 從指標中刪除敏感或不需要的標籤；
  • 新增、編輯或修改指標的標籤值或標籤格式；

Prometheus可整合的服務發現機制

不同場景中，服務註冊中心的指代也會有所不同 公有或私有IaaS雲自身儲存有平臺上的所有資源資訊，其API Server便可作為Prometheus的服務發現媒介；

• azure、ec2、digitalocean、gce、hetzner、

Prometheus也可以整合到多種不同的開源服務發現工具上，以動態發現需要監控的目標；

• Consul、Eureka Zookeeper Serverset或Airbnb Nerve等

Prometheus也可以很好地整合到Kubernetes平臺上，通過其API Server動態發現各類被監控的Pod（容器集）、Service、Endpoint、Ingress和Node物件；

• 它也支援基於dockerswarm和marathon兩款編排工具進行服務發現；

Prometheus還支援基於DNS或檔案的動態發現機制；

服務發現的實現

靜態檔案

基於檔案的服務發現

基於Consul的服務發現

基於DNS的服務發現

作者：閆世成

出處：http://cnblogs.com/yanshicheng

聯絡：[email protected]

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，如有問題或建議，請多多賜教，非常感謝。