Prometheus 服务发现机制详解
概述 在 Prometheus 的监控体系中，服务发现（Service Discovery，简称 SD）是连接"被监控目标"与"采集引擎"的桥梁。当你的基础设施从几台虚拟机扩展到数百个 Kubernetes Pod、跨可用区云主机、Consul 注册节点时，手动维护 static_configs 就变成了一场灾难——每次扩容、缩容、迁移都要改配置、重启 Prometheus，告警还会因为 target 不可达而误报。 Prometheus 原生支持十余种服务发现机制，能够在目标变更后自动感知，无需重启。我将从静态配置出发，逐步深入 file_sd、kubernetes_sd、consul_sd、dns_sd、ec2_sd 等主流方案，并详细讲解 relabel_configs 标签管理这一核心能力，最后给出多集群监控的落地实践。 参考来源：Prometheus 官方文档 — Configuration 一、为什么需要服务发现 1.1 静态配置的局限 先看一个最简单的静态配置： scrape_configs: - job_name: 'node' static_configs: - targets: - '192.168.1.10:9100' - '192.168.1.11:9100' - '192.168.1.12:9100' labels: env: 'production' region: 'beijing' 这在服务器数量固定时没什么问题。但考虑以下场景： 场景 静态配置的痛点 Kubernetes Pod 扩缩容 Pod IP 每次重建都变，手动改配置不现实 云厂商 Auto Scaling 弹性伸缩后新实例无法被监控，存在盲区 蓝绿部署 / 金丝雀发布 新版本实例需要自动加入监控 多机房迁移 IP 段变更，需要批量修改配置 容器化微服务 实例数量随时变化，生命周期短 1.2 服务发现的核心价值 ┌─────────────┐ ┌───────────────────┐ ┌──────────────┐ │ 服务注册中心 │ ← 感知 → │ Prometheus SD │ ← 采集 → │ Target 实例 │ │ (Consul/K8s) │ │ (自动更新 target) │ │ (Exporter) │ └─────────────┘ └───────────────────┘ └──────────────┘ │ ▼ ┌───────────────────┐ │ relabel_configs │ │ (标签过滤/改写) │ └───────────────────┘ 服务发现机制让 Prometheus 从"被动配置"变为"主动感知"：...