3. Prometheus 基础：架构设计、数据模型、Pull vs Push 模式、安装部署

好，咱们进入 Prometheus 的正题。这一章可以说是整个监控体系的基石。你想想看，如果连 Prometheus 本身都搞不明白，后面那些告警规则、Grafana 面板，全都是空中楼阁。

我个人习惯，学任何新东西，先看它的架构。就像看一个人，先看骨架，再看血肉。Prometheus 的架构，说白了就是「一个中心，多个采集点」。这个中心就是 Prometheus Server，采集点就是各种 Exporter 和应用程序。

3.1 架构设计：一张图看懂 Prometheus

Prometheus 的架构其实不复杂。我画个图给你描述一下：

  • Prometheus Server：核心大脑，负责拉取数据、存储数据、执行告警规则。
  • Exporters：翻译官，把各种系统指标（CPU、内存、磁盘）翻译成 Prometheus 能懂的格式。
  • Pushgateway：临时中转站，专门处理那些短生命周期任务的指标。
  • Alertmanager：告警管家，负责把告警消息分发给钉钉、邮件、企业微信。
  • Service Discovery：自动发现，不用你手动一个个配目标，K8s 或者 Consul 会自动告诉 Prometheus 该抓谁。

嗯，这里要注意一点：Prometheus 的架构是「去中心化」的。每个 Prometheus 实例都是独立的，不依赖外部存储。这跟传统的 Zabbix 那种中心化架构完全不同。我在项目中遇到过，有些团队硬要把 Prometheus 搞成集群模式，结果复杂度上去了，稳定性反而下来了。其实单机 Prometheus 扛个几百万时间序列，完全没问题。

核心原则：Prometheus 的设计哲学是「每个实例自治」。不要一开始就想着搞集群，先跑起来再说。

3.2 数据模型：标签是灵魂

Prometheus 的数据模型，说白了就是「指标名 + 标签」。举个例子：

http_requests_total{method="GET", endpoint="/api/v1/users", status="200"} 1024

这个 http_requests_total 是指标名，后面花括号里的 method、endpoint、status 就是标签。标签是 Prometheus 的灵魂。为什么？因为你可以通过标签做任意维度的聚合。

我记得有一次排查线上问题，某个接口响应变慢了。我直接在 PromQL 里写：

avg(rate(http_request_duration_seconds_sum[5m])) by (endpoint)

一秒就定位到是哪个接口出了问题。如果没有标签，你只能看到一堆聚合后的平均值，根本没法定位。

Prometheus 的数据模型有四种核心指标类型：

类型 说明 典型场景
Counter 只增不减的计数器 请求总数、错误总数
Gauge 可增可减的仪表盘 CPU 使用率、内存使用量
Histogram 直方图，统计分布 请求延迟的 P99、P95
Summary 类似 Histogram，但客户端计算分位数 请求延迟的预计算分位数

避坑指南：Counter 类型不要用 sum() 直接聚合，要用 rate() 或 increase()。我曾经见过有人直接用 sum(http_requests_total)，结果数值越滚越大，根本看不出趋势。

3.3 Pull vs Push 模式：为什么 Prometheus 选择 Pull？

这个问题，面试经常问，实际工作中也经常被争论。Prometheus 默认是 Pull 模式，也就是 Prometheus Server 主动去拉取数据。而传统的监控系统（比如 Zabbix、OpenTSDB）用的是 Push 模式，客户端主动上报。

为什么 Prometheus 选 Pull？我总结三个核心原因：

  1. 可控性：Pull 模式下，Prometheus 自己决定什么时候拉、拉谁。如果某个目标挂了，Prometheus 立刻就能感知到。Push 模式下，你永远不知道是客户端没上报，还是网络断了。
  2. 简化客户端：客户端只需要暴露一个 HTTP 接口，不需要关心数据往哪发、怎么发。说白了，客户端就是个「哑巴」，Prometheus 是那个「主动问话的人」。
  3. 易于调试：你直接用浏览器访问 http://target:9100/metrics，就能看到原始数据。Push 模式下，数据一旦发出去，你就再也看不到了。

但是，Pull 模式也有短板。比如批处理任务，跑几秒就结束了，Prometheus 还没来得及拉，任务就没了。这时候就需要 Pushgateway 来救场。任务启动时把指标推到 Pushgateway，Prometheus 再从 Pushgateway 拉。

注意：Pushgateway 是「不得已而为之」的方案。不要把所有指标都往 Pushgateway 里塞，它只是个临时中转站，不是长期存储。我曾经见过有人把 Pushgateway 当数据库用，结果内存爆了，整个监控都挂了。

3.4 安装部署：5 分钟跑起来

好，理论说完了，咱们动手。Prometheus 的安装非常简单，说白了就是下载一个二进制文件，解压，运行。

我个人习惯用 Docker 部署，干净利落。但为了让你理解原理，咱们先用手动安装的方式走一遍。

3.4.1 下载与启动

# 下载 Prometheus（以 Linux amd64 为例）
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz

# 解压
tar xvf 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 UI 了。嗯，就这么简单。

3.4.2 配置文件详解

prometheus.yml 是核心配置文件。我贴一个最简配置：

global:
  scrape_interval: 15s      # 默认抓取间隔
  evaluation_interval: 15s  # 告警规则评估间隔

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']

这里 scrape_interval 是抓取频率，我建议生产环境设成 10-15 秒。太频繁了浪费资源，太稀疏了数据粒度不够。

我记得有一次，一个团队把 scrape_interval 设成了 1 秒，结果 Prometheus 的 CPU 直接飙到 100%，所有目标都超时了。你想想看，如果监控系统自己先挂了，那还监控个啥？

3.4.3 安装 Node Exporter

光有 Prometheus 还不够，你得有数据源。Node Exporter 是最常用的系统指标采集器。

# 下载 Node Exporter
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz

# 解压并启动
tar xvf node_exporter-1.6.0.linux-amd64.tar.gz
cd node_exporter-1.6.0.linux-amd64
./node_exporter

启动后，访问 http://localhost:9100/metrics，你会看到一堆指标。这就是 Prometheus 要拉取的数据。

小技巧：Node Exporter 默认会采集很多指标，有些你可能用不上。可以用 --collector.disable-defaults 参数禁用不需要的采集器，减少资源消耗。

3.4.4 验证数据是否正常

在 Prometheus Web UI 的查询框里输入：

up

如果返回 1，说明目标正常。返回 0，说明目标挂了。这个 up 指标是 Prometheus 内置的，专门用来做健康检查。

嗯，到这里，Prometheus 的基础安装就完成了。你可能会觉得，就这么点东西？对，Prometheus 的设计哲学就是「简单」。但简单不代表简陋，后面咱们会一步步给它加上告警、可视化、自动发现，让它变成一个完整的监控体系。

下一章，咱们聊聊 PromQL，这是 Prometheus 最强大的武器。学会了 PromQL，你就能从海量数据中精准地找到问题。

← 上一章 📖 返回目录 下一章 →