編寫 HTTP 服務發現

Prometheus 提供了一種通用的HTTP 服務發現（HTTP Service Discovery），使其能夠透過 HTTP 端點發現目標。

HTTP 服務發現是對現有支援的服務發現機制的補充，並且是基於檔案的服務發現（File-based Service Discovery）的替代方案。

基於檔案的 SD 與 HTTP SD 的對比

下表對比了這兩種通用服務發現的實現方式。

專案	檔案 SD	HTTP SD
基於事件	是，透過 inotify	否
更新頻率	即時（得益於 inotify）	遵循 refresh_interval
格式	YAML 或 JSON	JSON
傳輸方式	本地檔案	HTTP/HTTPS
安全性	基於檔案的安全機制	TLS、Basic 認證、Authorization 請求頭、OAuth2

HTTP SD 端點的要求

如果您要實現 HTTP SD 端點，需要注意以下幾點要求。

響應將被原樣直接使用，不作任何修改。在每個重新整理間隔（預設：1 分鐘）內，Prometheus 都會向 HTTP SD 端點發起一次 GET 請求。該 GET 請求包含一個名為 X-Prometheus-Refresh-Interval-Seconds 的 HTTP 請求頭，其中攜帶了當前的重新整理間隔。

服務發現端點必須返回 HTTP 200 響應，且 HTTP 請求頭為 Content-Type: application/json。響應必須為 UTF-8 編碼。即使沒有要傳輸的目標，也必須返回 HTTP 200 響應及一個空列表 []。目標列表是無序的。

Prometheus 會快取目標列表。如果在獲取更新的目標列表時發生錯誤，Prometheus 會繼續使用當前的目標列表。目標列表不會在重啟後保留。prometheus_sd_refresh_failures_total 計數器指標用於跟蹤重新整理失敗的次數，而 prometheus_sd_refresh_duration_seconds 桶可用於跟蹤 HTTP SD 的重新整理嘗試或效能。當在重新載入 Prometheus 配置時底層抓取任務（scrape job）消失，這些指標也會被移除。

每次抓取時必須返回完整的目標列表。不支援增量更新。Prometheus 例項不會發送其主機名，因此服務發現端點無法得知該服務發現請求是否為重啟後的第一次請求。

HTTP SD 的 URL 不被視為秘密資訊。身份驗證和任何 API 金鑰應透過適當的驗證機制傳遞。Prometheus 支援 TLS 認證、Basic 認證、OAuth2 以及 Authorization 請求頭。

HTTP_SD 格式

[
  {
    "targets": [ "<host>", ... ],
    "labels": {
      "<labelname>": "<labelvalue>", ...
    }
  },
  ...
]

示例

[
    {
        "targets": ["10.0.10.2:9100", "10.0.10.3:9100", "10.0.10.4:9100", "10.0.10.5:9100"],
        "labels": {
            "__meta_datacenter": "london",
            "__meta_prometheus_job": "node"
        }
    },
    {
        "targets": ["10.0.40.2:9100", "10.0.40.3:9100"],
        "labels": {
            "__meta_datacenter": "london",
            "__meta_prometheus_job": "alertmanager"
        }
    },
    {
        "targets": ["10.0.40.2:9093", "10.0.40.3:9093"],
        "labels": {
            "__meta_datacenter": "newyork",
            "__meta_prometheus_job": "alertmanager"
        }
    }
]

HTTP SD 整合

您可以在 Prometheus 文件的整合頁面中找到現有的 HTTP SD 整合列表。