Prometheus监控架构以拉取模型为核心、服务发现为支撑，实现动态可扩展监控：先通过static_configs或kubernetes_sd等机制发现目标，再定时向/metrics端点发起HTTP GET请求，解析Exposition格式数据并写入TSDB，全程自动适配容器生命周期与网络变化。

Prometheus 的监控架构以拉取（Pull）模型为核心，配合灵活的服务发现机制，共同支撑起动态、可扩展的监控能力。它不依赖被监控端主动上报，而是由 Prometheus Server 主动发起请求，这种设计在容器化和云原生环境中尤为稳健。

拉取模型的工作逻辑

拉取不是简单地“定时访问 URL”，而是一套闭环流程：

• 根据 scrape_configs 中定义的 job 和目标发现方式，生成待抓取的目标列表
• 每个目标附带一组标签（如 job="node_exporter"、instance="192.168.1.100:9100"），用于后续数据区分与聚合
• 向目标的 /metrics 端点发起 HTTP GET 请求，超时时间由 scrape_timeout 控制（通常略小于 scrape_interval）
• 响应必须符合 Prometheus Exposition Format（文本格式为主），例如：
  http_requests_total{method="get",code="200"} 1245
• 解析后的样本自动注入 job 和 instance 标签，并写入 TSDB 的 Head Block 中

服务发现解决的是“找谁抓”的问题

静态配置（static_configs）适合固定节点，但生产环境更多依赖动态发现：

• Kubernetes_sd：通过 API Server 实时监听 Pod、Service、Endpoint 等资源变化，自动增删 target
• file_sd：从外部 JSON/YAML 文件读取目标列表，支持热更新（Prometheus 定期轮询或监听文件变更）
• consul_sd / dns_sd：对接服务注册中心或 DNS SRV 记录，适用于混合云或多集群场景
• cloud provider sd：如 AWS EC2、Azure VM，直接基于云平台元数据发现实例

所有发现结果最终都会统一注入到 scrape 流程中，与拉取逻辑解耦，便于组合使用。

为什么拉取 + 服务发现是黄金组合

二者结合，让 Prometheus 在复杂环境中保持低运维负担和高适应性：

• 目标生命周期变化（如 Pod 启停、滚动更新）无需人工干预，自动同步
• 网络隔离场景下，只需确保 Prometheus 能访问服务发现后端（如 Kubernetes API），不必直连每个 target
• 健康状态天然可得：up{job="xxx"} == 0 即表示该 target 当前不可达，既是监控指标，也是发现故障的信号
• 抓取节奏由 Prometheus 统一控制，避免客户端推送导致的数据洪峰或时序错乱

常见变通与边界处理

并非所有场景都天然适配 Pull 模型，需要合理延伸：

• 短生命周期任务（如 CronJob）用 Pushgateway 中转：任务结束前推送指标，Prometheus 定期从中拉取
• 无法暴露 /metrics 端点的老系统，可通过定制 Exporter 或代理层（如 Claw-Prometheus）做协议转换和桥接
• 跨 VPC 或防火墙受限环境，可在目标侧部署轻量 exporter，Prometheus 通过跳板或反向代理间接拉取
• 大规模集群中，单个 Prometheus 实例压力大时，可借助联邦（Federation）或分片（Sharding）策略拆分抓取负载