Prometheus 提供了一个通用的HTTP 服务发现,使其能够通过 HTTP 端点发现目标。
HTTP 服务发现是对支持的服务发现机制的补充,也是基于文件的服务发现的替代方案。
这是一个比较我们两个通用服务发现实现的表格。
项 | 文件服务发现 | HTTP 服务发现 |
---|---|---|
基于事件 | 是,通过 inotify | 否 |
更新频率 | 即时,感谢 inotify | 遵循 refresh_interval |
格式 | Yaml 或 JSON | JSON |
传输 | 本地文件 | HTTP/HTTPS |
安全 | 基于文件的安全性 | TLS、基本身份验证、授权标头、OAuth2 |
如果您实现了一个 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_http_failures_total
计数器指标会跟踪刷新失败的次数。
每次抓取时都必须返回整个目标列表。不支持增量更新。Prometheus 实例不会发送其主机名,并且服务发现端点无法知道服务发现请求是否是重启后的第一个请求。
HTTP 服务发现的 URL 不被认为是秘密的。身份验证和任何 API 密钥都应使用适当的身份验证机制传递。Prometheus 支持 TLS 身份验证、基本身份验证、OAuth2 和授权标头。
[
{
"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"
}
}
]
此文档是开源的。请通过提交问题或拉取请求来帮助改进它。