dns_sd 是什么
dns_sd_configs 让 Prometheus 通过 DNS 记录动态发现抓取目标：用 SRV 记录可以同时拿到主机与端口，用 A 或 AAAA 记录则只拿到地址、端口沿用配置里的默认值。它适合目标地址以域名集中管理的环境——在 DNS 里增加或删除一条记录就等于增删一个抓取目标，不必再推动一次 Prometheus 配置发布。
基本信息
| 配置位置 | scrape_configs[].dns_sd_configs |
|---|---|
| 支持记录类型 | SRV、A、AAAA |
| 关键字段 | names、type、refresh_interval、port |
| 行为特点 | SRV 记录中的端口会成为抓取端口 |
| 适用版本 | Prometheus 2.x |
典型使用场景
- 集中管理地址：目标清单维护在 DNS 里，由 DNS 流程负责变更与留痕
- 服务扩缩容：新增实例注册 SRV 记录即自动纳入抓取
- 多环境隔离：各环境使用各自域名，配置模板可以复用
- 无服务发现组件：不引入 Consul 或 Kubernetes 也能做动态发现
- 迁移过渡：从静态目标列表迁往动态发现的低成本方案
使用要点
- 需要改写端口时配合 relabel_configs 处理目标地址，不要硬改配置文件
- TTL 与 refresh_interval 一起决定变更生效速度，两者都要合理设置
- 解析失败时目标整体消失，up 序列也会消失（不是变成 0）
- 域名解析依赖可靠的 DNS 服务，解析链路本身也要纳入监控
- 用 Service Discovery 页面核对发现到的目标与最终标签
配置与对应记录
配置与对应记录
scrape_configs:
- job_name: 'dns-app'
dns_sd_configs:
- names: ['_http-metrics._tcp.app.example.com']
type: SRV
refresh_interval: 30s
# 对应的 SRV 记录（示例）
# _http-metrics._tcp.app.example.com. 30 IN SRV 0 5 8080 node1.example.com.
# _http-metrics._tcp.app.example.com. 30 IN SRV 0 5 8080 node2.example.com.记录类型对照
| 类型 | 拿到什么 | 适用 |
|---|---|---|
| SRV | 主机与端口 | 需要动态端口或集中登记 |
| A | IPv4 地址 | 端口固定、地址动态变化 |
| AAAA | IPv6 地址 | IPv6 环境 |
| names | 查询的域名列表 | 可配置多个域名合并结果 |
| refresh_interval | 刷新周期 | 与 TTL 一起权衡生效速度 |
SRV 记录中的端口会成为抓取端口；需要改写端口时配合 relabel_configs 处理目标地址标签，而不是在 DNS 记录里绕弯。
排查要点
- 目标整体消失先查 Prometheus 日志里的解析错误，不要只盯着 Targets 页面
- 新增记录后长时间不生效，先核对 TTL 与 refresh_interval 是否都偏大
- 抓取端口与预期不符时，先确认 SRV 记录里的端口字段写的是什么
- 在 Service Discovery 页面核对发现结果与 relabel 之后的最终标签
- 解析服务本身要有可用性监控，避免发现机制故障造成大面积目标丢失