3. Prometheus入门：架构、数据模型、安装部署与基本配置
好，咱们今天聊聊Prometheus。说实话，在云原生监控这个领域，Prometheus几乎成了标配。我最早接触它是在2017年，那时候Kubernetes刚火起来，传统的Zabbix和Nagios在容器环境里简直寸步难行。后来我主导了公司PaaS平台的监控体系重构，Prometheus成了我们的核心选型。今天我就把这几年的实战经验，掰开了揉碎了讲给你听。
3.1 Prometheus架构：一张图看懂全局
Prometheus的架构，说白了就是一个“拉”的模式。它主动去各个目标抓取指标数据，而不是等别人推过来。这个设计理念很有意思——你想想看，如果每个服务都主动推数据，那监控系统很容易被冲垮。Prometheus反其道而行，它自己控制节奏。
核心组件就这几个：
- Prometheus Server：负责抓数据、存数据、查数据。这是大脑。
- Exporters：各种数据采集器。比如node_exporter采集机器指标，mysqld_exporter采集数据库指标。
- Pushgateway：用于短期任务或批处理任务的指标推送。嗯，这个我其实用得不多，但有些场景确实需要。
- Alertmanager：处理告警。它负责去重、分组、静默，然后发通知。
- Grafana：可视化面板。虽然Prometheus自带Web UI，但说实话，那个界面太简陋了，我一般都用Grafana。
核心要点：Prometheus是拉模式，不是推模式。这个区别决定了它的架构设计——每个被监控的目标都需要暴露一个HTTP端点，Prometheus定期去抓取。
我在项目中遇到过一个问题：某个微服务集群有200多个实例，Prometheus默认的抓取间隔是15秒，结果导致Server端CPU飙升。后来我调整了抓取间隔和并发数，才稳定下来。这个后面会细说。
3.2 数据模型：时间序列的奥秘
Prometheus存储的数据，本质上就是时间序列。每个时间序列由指标名和标签唯一标识。举个例子：
http_requests_total{method="GET", endpoint="/api/users", status="200"} 1024这个指标名叫http_requests_total，后面跟着三个标签：method、endpoint、status。值1024是当前计数。每个时间点都会记录这样一个值，就形成了时间序列。
标签的设计非常关键。我见过不少新手把标签当字段用，塞了一大堆维度进去。结果呢？基数爆炸了。Prometheus的存储引擎对高基数数据非常敏感，标签值组合太多，内存和磁盘都扛不住。
避坑指南：我曾经有一个项目，把用户ID作为标签，结果几万个用户瞬间把Prometheus搞挂了。记住：标签的基数（不同取值的数量）一定要控制，一般建议不超过10万。像用户ID、请求ID这种高基数数据，不适合直接作为标签。
Prometheus支持四种指标类型：
| 类型 | 说明 | 典型场景 |
|---|---|---|
| Counter | 只增不减的计数器 | 请求总数、错误总数 |
| Gauge | 可增可减的仪表盘 | CPU使用率、内存使用量 |
| Histogram | 直方图，统计分布 | 请求延迟分布、响应大小分布 |
| Summary | 类似Histogram，但计算分位数 | 请求延迟的P99、P95 |
我个人习惯，大部分场景用Counter和Gauge就够了。Histogram和Summary虽然强大，但会额外增加存储开销，用之前要掂量掂量。
3.3 安装部署：从零开始跑起来
安装Prometheus其实很简单。我一般用二进制包直接部署，不依赖容器。为什么？因为Prometheus本身很轻量，二进制包才几十兆，解压就能用。当然，生产环境我建议用systemd管理。
步骤很简单：
- 下载Prometheus二进制包
- 解压到指定目录
- 编写配置文件prometheus.yml
- 启动服务
咱们直接看命令：
# 下载（以Linux amd64为例）
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
# 解压
tar -xzf prometheus-2.45.0.linux-amd64.tar.gz
cd prometheus-2.45.0.linux-amd64
# 启动（使用默认配置）
./prometheus --config.file=prometheus.yml启动后，访问http://localhost:9090就能看到Prometheus的Web界面了。嗯，这个界面虽然简陋，但用来查数据、做调试足够了。
小技巧：我第一次部署时，忘了开放防火墙端口，结果折腾了半天才发现。建议你提前检查9090端口是否开放。另外，生产环境一定要用systemd管理，不然进程挂了没人管。
3.4 基本配置：让Prometheus认识你的服务
配置文件是Prometheus的核心。默认的prometheus.yml长这样：
global:
scrape_interval: 15s # 抓取间隔，默认15秒
evaluation_interval: 15s # 告警规则评估间隔
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']这个配置只监控了Prometheus自己。要监控其他服务，需要添加新的job。比如监控一台Linux服务器：
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['192.168.1.100:9100']这里9100是node_exporter的默认端口。node_exporter需要单独安装，它会暴露机器的CPU、内存、磁盘等指标。
配置里有个关键参数——scrape_interval。我建议根据业务场景调整：
- 核心业务指标：5-10秒
- 系统资源指标：15-30秒
- 非关键指标：60秒以上
我在项目中遇到过一个问题：某个团队把所有指标的抓取间隔都设成了5秒，结果Prometheus Server的磁盘IO直接打满。后来我按优先级分了三个等级，问题就解决了。
重要提醒：Prometheus的配置文件支持热加载。修改配置后，执行kill -HUP <PID>或者发送POST请求到/-/reload，无需重启服务。这个功能在线上环境非常实用。
3.5 实战：搭建一个完整的监控Demo
光说不练假把式。咱们来搭一个完整的监控Demo，监控一台Linux服务器和Prometheus自身。
第一步，安装node_exporter：
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar -xzf node_exporter-1.6.0.linux-amd64.tar.gz
cd node_exporter-1.6.0.linux-amd64
./node_exporter &第二步，修改Prometheus配置：
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']第三步，重启Prometheus，然后在Web界面查询node_cpu_seconds_total，就能看到CPU指标了。
就这么简单。但生产环境远不止这些——你需要考虑高可用、持久化存储、告警配置等等。这些内容咱们后面的章节会逐一展开。
我的习惯：每次部署新环境，我都会先跑一个简单的查询验证数据是否正常。比如查up指标，它会返回1表示目标在线，0表示离线。这个指标虽然简单，但能快速定位问题。
好了，Prometheus入门就讲到这里。下一章咱们聊聊PromQL——这门查询语言虽然有点怪，但掌握了它，你就能从海量数据中挖出金子来。