编写 HTTP 服务发现

Prometheus 提供了通用的 HTTP 服务发现功能，使其能够通过 HTTP 端点发现目标。

HTTP 服务发现是对已支持的服务发现机制的补充，也是基于文件的服务发现的替代方案。

基于文件的服务发现与 HTTP 服务发现的比较

下表比较了这两种通用的服务发现实现。

项目	基于文件的服务发现	HTTP 服务发现
基于事件	是，通过 inotify	否
更新频率	即时，得益于 inotify	遵循 refresh_interval
格式	YAML 或 JSON	JSON
传输方式	本地文件	HTTP/HTTPS
安全性	基于文件的安全	TLS、Basic 认证、Authorization 头、OAuth2

HTTP 服务发现端点的要求

如果你实现一个 HTTP 服务发现端点，以下是一些你需要了解的要求。

响应按原样使用，不做修改。在每个刷新间隔（默认：1 分钟），Prometheus 将对 HTTP 服务发现端点执行 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 服务发现刷新尝试或性能。

每次抓取时必须返回完整的目标列表。不支持增量更新。Prometheus 实例不会发送其主机名，服务发现端点也无法知道该服务发现请求是否是重启后的第一个请求。

HTTP 服务发现的 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 服务发现集成

现有的 HTTP 服务发现集成列表可以在 Prometheus 文档的集成页面中找到。