prometheus监控架构核心是稳定可扩展的数据采集管道，以pull模型为起点，通过exporter适配异构指标、服务发现动态管理targets，并经relabel清洗后落库。
Prometheus 监控架构的核心，是建立一条稳定、可扩展、可维护的数据采集管道。它不是简单地把指标“拉过来”，而是通过组件协同、配置驱动和协议约定，让数据从源头到存储形成闭环。关键在于理解各环节的职责边界和衔接方式，避免常见断点。
拉取模型是整个管道的起点
Prometheus 默认采用 Pull 模型：Server 主动向目标发起 HTTP 请求，周期性获取 /metrics 接口返回的文本格式指标。这种设计天然适配云原生环境的动态性，只要目标服务能持续暴露该端点，Prometheus 就能发现并采集。
- 抓取间隔由 scrape_interval 控制（默认 15s），需根据指标变化频率权衡精度与负载
- 每个抓取任务（job）必须定义清晰的 targets，可以是静态 IP 列表，也可以通过服务发现自动填充
- 若目标无法长期运行（如 CronJob），不能直接暴露 /metrics，则需借助 Pushgateway 中转，但要注意其单点和过期风险
Exporter 是标准化的适配层
Exporter 不是可选插件，而是数据进入 Prometheus 生态的“翻译官”。它把异构系统的原始指标（如 MySQL 的 SHOW STATUS、Linux 的 /proc/stat）转换为 Prometheus 可识别的键值对+标签格式。
- Node Exporter 负责主机级指标（CPU、内存、磁盘 I/O），部署在被监控节点上，监听 9100 端口
- Blackbox Exporter 用于探测类监控（HTTP 响应码、TCP 连通性、DNS 解析），不依赖目标暴露指标
- 业务应用应优先在代码中集成 client_golang 等 SDK，直接暴露 /metrics，比外挂 Exporter 更轻量、更实时
服务发现确保管道动态可靠
在 Kubernetes 等动态环境中，IP 和 Pod 数量频繁变化，静态 targets 配置很快失效。Prometheus 内置多种服务发现机制，自动同步目标列表。
- kubernetes_sd_config 支持按 endpoints、services、pods 等角色发现目标，配合 relabel_configs 可过滤、重写标签
- 常用实践是给 Service 加注解 prometheus.io/scrape: "true"，再通过 role: endpoints 自动关联后端 Pod
- 发现结果会实时反映在 /targets 页面，状态为 UP 表示连接成功、解析正常、响应格式合规
数据落地前的校验与分流
采集来的数据并非直接入库。Prometheus Server 在存储前会做两件事：一是按 relabel_configs 过滤或重标记，二是根据 scrape_configs 中的 metric_relabel_configs 对指标本身做清洗。
- 例如屏蔽高频低价值指标（如 per-process 的 cpu_usage），避免 TSDB 膨胀
- 将 hostname 标签统一替换为 instance 标签，保证跨集群查询时语义一致
- 保留关键维度（job、instance、env、region）便于后续 PromQL 多维聚合
