一 服務發現適用場景

• Prometheus Server的資料抓取工作基於pull模型，因而，它必須要事先知道各Target的位置，然後才能從相應地exporter或Instrumentation中抓取資料；
  • 對於小型的系統環境來說，通過static_configs指定各Target便能解決問題，這也是最簡單的配置方法；
    • 每個Target用一個網路端點（ip:port）進行標識
  • 對於中大型的系統環境或具有較強動態性的雲端計算環境來說，靜態配置顯然難以使用；
  • 因此，Prometheus為此專門設計了一組服務發現機制，以便於能夠基於服務註冊中自動發現、檢測、分類可被監控的各Target，以及更新發生了變動的Target；

二 指標抓取生命週期

• 在每個scrape_interval期間，Prometheus都會檢測執行的作業（job）；
• 這些作業首先會根據job上指定的發現配置生成target列表，此即服務發現過程；
  • 服務發現會返回一個target列表，其中包含一組稱為元資料的標籤，這些標籤都以“__meta__”為字首；
  • 服務發現還會根據目標配置來設定其它標籤，這些標籤帶有“__”字首和字尾，包括“__scheme__”、"__address__"和“__metrics_path__”,分別儲存有target支援使用協議（http或https，預設http）、target第地址及指標的URL路徑（預設為/metrics）；
  • 若URL路徑中存在任何引數，則它們的字首會設定為"__param__";
  • 這些目標列表和標籤會返回給Prometheus，其中的一些標籤也可以配置中覆蓋；
• 配置標籤會在抓取的生命週期中被重複利用以生成其它標籤，例如，指標上的instance標籤的預設值就來自於__address__標籤的值；
• 對於發現的各目標。Prometheus提供了可以重新標記（relabel）目標的機會；
  • 它定義在job配置段的relabel_config配置中，通常用於實現如下功能：
    • 將來自服務發現的元資料標籤中的資訊附加到指標的標籤上；
    • 過濾指標；
• 這之後便是資料抓取、以及指標返回的過程；
• 抓取而來的指標在儲存之前，還允許使用者對指標從新達標並過濾的方式；
  • 它定義在job配置段的metric_relabel_configs配置中，常用於實現如下功能：
    • 刪除不必要的指標；
    • 從指標中刪除敏感或不需要的標籤；
    • 新增、編輯或修改指標的標籤值或標籤格式；

三 Prometheus可整合的服務發現機制

• 公有或私有IaaS雲自身儲存有平臺上的所有資源資訊，其API Server便可以作為Prometheus的服務發現媒介；
  • azure、ec2、digitalocean、gce；
• Prometheus也可以整合到多種不用的開源服務發現工具上，以動態發信啊需要監控的目標；
  • consul、Eureka Zookeeper Serverse或Airbnb Nerve等；
• Prometheus也可以很好的整合到kubernetes平臺上，通過其API Server動態發現各類被監控的Pod、Service、Endpoint、Ingress和Node物件；
  • 它也支援基於docker swarm和marathon兩款編排工具進行服務發現；
• Prometheus還支援基於DNS或檔案的動態發現機制；