编写 HTTP 服务发现
Prometheus 提供了一种通用的 HTTP 服务发现,使其能够通过 HTTP 端点发现目标。
HTTP 服务发现是对现有受支持的服务发现机制的补充,也是 基于文件的服务发现 的替代方案。
基于文件的服务发现与 HTTP 服务发现的对比
下表对比了我们这两种通用的服务发现实现。
| 项目 | 基于文件的服务发现 (File SD) | HTTP 服务发现 (HTTP SD) |
|---|---|---|
| 是否基于事件 | 是,通过 inotify | 否 |
| 更新频率 | 即时,得益于 inotify | 遵循 refresh_interval |
| 格式 | Yaml 或 JSON | JSON |
| 传输方式 | 本地文件 | HTTP/HTTPS |
| 安全性 | 基于文件的安全性 | TLS、基本认证、Authorization 头部、OAuth2 |
HTTP 服务发现端点的要求
如果您要实现一个 HTTP SD 端点,需要了解以下几点要求。
响应将被原样使用,不进行修改。在每个刷新间隔(默认:1 分钟)时,Prometheus 将向 HTTP SD 端点执行 GET 请求。该 GET 请求包含一个 X-Prometheus-Refresh-Interval-Seconds HTTP 头部,指明了刷新间隔。
SD 端点必须以 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 实例不会发送其主机名,因此 SD 端点无法知道某次请求是否是重启后的第一次请求。
指向 HTTP SD 的 URL 不被视为机密。身份验证和任何 API 密钥应通过适当的身份验证机制传递。Prometheus 支持 TLS 身份验证、基本身份验证、OAuth2 和授权头部。
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 SD 集成列表可以在 Prometheus 文档的 集成页面上找到。