Prometheus通过Pull模型和标准化/metrics接口实现多源统一接入，支持原生暴露、Exporter桥接和服务发现自动纳管；其TSDB以指标名+标签构成唯一时间序列，本地存储高效但默认保留15天；Pushgateway仅作为短期任务的临时中转，避免替代Pull核心模式。
Prometheus 本身不直接做“多源汇聚”的中心调度，而是通过统一拉取（pull）模型+标准化指标格式，自然实现多源数据的归一化接入与存储。它的核心不是把不同系统硬塞进一个管道，而是让所有被监控对象按同一语义规则“说话”，再由 Prometheus 统一“听”和“记”。
多源数据如何统一接入
只要目标系统能暴露符合 Prometheus 数据模型的 /metrics HTTP 接口，就可被纳入监控体系。接入方式分三类：
- 原生暴露：应用集成 Prometheus 客户端库（如 Go/Java/Python 的 client_golang），在代码中定义 Counter、Gauge 等指标，并注册 HTTP handler，自动提供 /metrics 路径。
- Exporter 桥接：对无法改造的系统（如 MySQL、Redis、Node 主机），部署对应 Exporter（如 mysqld_exporter、redis_exporter、node_exporter）。它主动采集目标指标，再转换为 Prometheus 格式对外暴露。
- 服务发现自动纳管：在 Kubernetes 环境中，Prometheus 通过内置的服务发现机制（如 kubernetes_sd_config）自动识别 Pod、Service、Endpoints 等资源，动态生成抓取目标，无需手动维护 IP 列表。
存储模型：时序数据 + 标签维度
Prometheus 存储不是传统关系型数据库，而是一套专为指标优化的本地 TSDB（Time Series Database）。每条数据本质是：
metric_name{label1="value1", label2="value2"} value timestamp例如：
http_requests_total{job="api-server", instance="10.2.3.4:8080", method="POST", status="500"} 127 1720488120000
- 指标名 + 标签组合构成唯一时间序列，支持高基数（成千上万个 label 组合）；
-
本地存储采用块压缩 + 增量编码，写入快、查询高效，但默认只保留 15 天（可通过
storage.tsdb.retention.time配置）； - 不支持跨节点 join 或分布式事务，水平扩展靠 Thanos 或 Cortex 实现全局视图与长期存储。
为什么不用 push，而坚持 pull 模型
Pull 模式是 Prometheus 多源管理的关键设计选择：
- 避免被监控端因网络抖动、重试逻辑等导致指标重复或丢失；
- 由 Prometheus 统一控制抓取频率、超时、重试策略，保障采集节奏稳定；
- 天然适配云原生动态环境——即使目标实例频繁启停，只要它注册到服务发现系统，Prometheus 就能自动增删抓取任务。
短期任务与 Pushgateway 的定位
对于批处理作业、CronJob 等生命周期短于一次抓取周期的任务，Prometheus 无法通过常规 pull 获取指标。这时需用 Pushgateway 作为临时中转：
- 作业执行完后，将结果 push 到 Pushgateway；
- Prometheus 把 Pushgateway 当作普通 target 定期拉取；
- 注意：Pushgateway 不是通用数据入口，仅用于“瞬态任务”，否则会造成标签爆炸和数据滞留问题。
