本篇是《Prometheus 从入门到生产实践》第 6 / 24 篇。配置以文中版本与环境前提为准，实验和故障均为教学场景。完整程序、配置及校验范围见配套实验包。
目标数量变化后，手工维护静态 IP 会变得脆弱。服务发现提供候选目标，relabeling 决定抓谁、去哪里抓以及保留哪些标签。本篇先用文件发现把处理顺序看清楚。
1. 把四个阶段分开
服务发现得到候选目标；relabel_configs 在抓取前处理目标；HTTP 抓取获得指标；metric_relabel_configs 在入库前处理样本。remote_write 还有自己的写出阶段重标记，不是同一个位置。
把标签改错位置，可能出现“图里没标签”“目标全消失”或“本地还能看到但远程没有”等不同问题。先定位数据在哪一阶段丢失，再修改配置。
顺序和语义见 官方配置参考。
2. 用 JSON 描述一组目标
保存 targets.json：
[
{"targets":["127.0.0.1:19100"],"labels":{"environment":"lab","service":"demo-api"}}
]
一组 targets 可以附带共同标签，地址中不包含 URL 路径；scheme、metrics_path 由 job 等配置确定。元数据标签和值仍应保持可控，不能因为来自 CMDB 就无条件信任。
3. 完整 file_sd 配置
下面是独立的 file-sd.yml，实验时用它启动另一个独立实例，或按实际情况把 job 合并到现有配置：
global:
scrape_interval: 5s
scrape_configs:
- job_name: demo
file_sd_configs:
- files: ['targets.json']
refresh_interval: 10s
relabel_configs:
- source_labels: [environment]
regex: lab
action: keep
- source_labels: [service]
target_label: app
metric_relabel_configs:
- source_labels: [__name__]
regex: ops_demo_inflight_requests
action: drop
keep 只保留 environment=lab 的候选目标；随后把 service 的值复制到 app。抓取后丢弃 inflight 这一个指标，其他业务指标保留。
示例目的是展示两个阶段，生产是否应该丢弃 inflight 要按使用需求决定。检查后运行：
promtool check config file-sd.yml
promtool check service-discovery file-sd.yml demo
第二条用于观察该 job 的发现和重标记结果，但不证明最终 HTTP 抓取一定成功。
4. 先看最终目标，再看最终序列
目标应包含 app=demo-api、environment=lab，抓取地址为127.0.0.1:19100。查询业务 counter 时应能看到这些目标标签；inflight 在新采样数据中会被丢弃。
如果把 environment 改成 prod，目标会被 keep 规则排除，它不是一个继续被抓取但 up=0 的目标。先看服务发现与 dropped targets，而不是只在 up 查询里找失败。
已写入的历史不会因为修改重标记立刻从 TSDB 删除，标签变化也会形成新序列。当前查询、历史范围和失效机制要分别理解。
5. 内部标签与正则的细节
__address__ 控制实际目标，__scheme__、__metrics_path__ 可控制协议和路径；发现系统会提供 __meta_* 元数据。内部标签通常在目标处理后移除，想长期保留应明确复制到普通标签。
多个 source_labels 默认按分隔符拼接，规则顺序逐条执行。正则使用 RE2 语义，默认匹配规则有锚定行为，不支持所有其他引擎的写法，尤其不能照搬前后向断言。
6. 为什么 labeldrop 不是万能降基数
如果两个样本仅 user_id 不同，直接去掉 user_id 不会把数值自动求和，反而可能造成相同标签集的冲突。正确方向通常是源头限制维度、改变埋点或明确聚合，而不是随手删除身份维度。
metric relabel 也不替代目标层过滤：如果整个目标都不需要，抓取前过滤通常更早控制成本。采集样本限制被触发时，还可能让整个抓取失败，而不是只静默截断某些指标。
7. 文件变更如何可靠发布
file_sd 可发现文件变化，不必每改一次目标列表就重启 Prometheus；修改主配置本身则需要对应重载流程。自动生成目标文件时，先写邻接临时文件并校验，再在同一文件系统中原子替换，避免读到半份内容。
练习：依次更改 service、environment、端口，分别观察标签变化、目标被过滤和抓取失败。把三种情况记录成不同结论，才能在后续 Kubernetes 发现中准确定位问题。
上一篇：Exporter与黑盒探测：主机正常不代表用户路径正常 · 系列目录 · 下一篇：PromQL 基础与时间语义：选择器、窗口、offset 和过期