深色模式
Prometheus 架构详解
用一张图讲清 Prometheus 是怎么“拉”数据的，以及各组件在可观测性体系里的位置，新手也能一眼看懂。
适用环境
- Linux 服务器（CentOS / Ubuntu 均可）
- 已了解基础运维概念（进程、端口、HTTP）
- 后续将按本文的组件认知进行安装与配置
bash
# 查看本机监听端口，理解“被采集方暴露 HTTP 端口”的概念
ss -ltnp | head1
2
2
操作步骤
1. 理解 pull 模型
Prometheus 不是“被监控对象主动上报”，而是 Prometheus 主动去拉（scrape） 各个目标的 /metrics 接口：
2. 核心组件职责
| 组件 | 职责 |
|---|---|
| Prometheus Server | 拉取、存储时序数据，执行 PromQL 查询 |
| Exporter | 把第三方系统指标转成 /metrics 格式 |
| Pushgateway | 接收短期任务主动推送的指标 |
| Alertmanager | 去重、分组、静默并发送告警 |
| Grafana | 可视化查询与大盘展示 |
3. 数据模型要点
每条样本 = 指标名 + 一组标签（label）+ 时间戳 + 数值。标签是 PromQL 过滤和聚合的基础。
验证
想通三个问题即可：
- 谁暴露
/metrics？（Exporter / 应用） - 谁去拉？（Prometheus 定时 scrape）
- 谁负责展示与告警？（Grafana / Alertmanager）
常见坑
不要混用 push 与 pull
长期运行的服务用 pull 模型；只有“跑完就退出”的批处理任务才用 Pushgateway，否则指标会堆积。
不要自建远端存储前先想清楚
单机 Prometheus 默认本地 TSDB 即可，避免一上来就上 Thanos/Mimir 增加复杂度。