3. Prometheus 入门：架构、核心概念与安装配置

大家好，我是你们的运维架构师。今天我们来聊聊 Prometheus，这个云原生监控领域的事实标准。

说实话，我第一次接触 Prometheus 是在 2016 年，那时候它还没成为 CNCF 的毕业项目。当时公司要重构监控体系，Zabbix 和 Nagios 用得我头疼。后来我试着搭了一套 Prometheus，嗯，用了不到一周就决定全面迁移了。为什么？因为它太符合云原生时代的思维方式了。

3.1 Prometheus 架构：一张图看懂全局

Prometheus 的架构其实不复杂。我习惯把它拆成三个核心部分：采集端、存储端、告警与展示端。

  • 采集端：Prometheus Server 主动拉取（Pull）各个目标（Target）的指标数据。
  • 存储端：拉取到的数据以时间序列（Time Series）的形式存储在本地磁盘上。
  • 告警与展示端：通过 Alertmanager 发送告警，通过 Grafana 或自带的 Web UI 展示数据。

你可能会问：「为什么 Prometheus 不把数据存到数据库里？」

我个人觉得，这正是它的高明之处。Prometheus 的本地存储是专门为时间序列优化的，读写性能极高。我在项目中遇到过一台机器上采集 50 万个时间序列，查询响应依然在毫秒级。当然，如果你需要长期存储，可以对接 Thanos 或 VictoriaMetrics，这是后话了。

3.2 核心概念：指标、标签与时间序列

要玩转 Prometheus，必须先理解三个核心概念。

3.2.1 指标（Metric）

指标就是你要监控的某个量。比如 CPU 使用率、内存占用、请求数。Prometheus 支持四种指标类型：

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

我记得有一次，团队里有人用 Counter 来监控内存使用量，结果发现数据一直在涨。我一看就笑了：「Counter 只能增不能减，你拿它监控内存，不涨才怪。」所以，选对指标类型很重要。

3.2.2 标签（Label）

标签是 Prometheus 的灵魂。每个指标可以附带多个标签，用来区分不同的维度。

举个例子：http_requests_total{method="GET", endpoint="/api/v1/users", status="200"}

这个指标表示：GET 请求 /api/v1/users 接口，返回 200 状态码的总次数。标签让数据变得极其灵活。你可以按 method 聚合，也可以按 status 过滤。

我的经验：标签不是越多越好。每个唯一的标签组合都会产生一个新的时间序列。我曾经见过有人给每个请求的 User-Agent 都加了个标签，结果时间序列数量爆炸，Prometheus 直接 OOM。建议标签的基数（Cardinality）控制在几千以内。

3.2.3 时间序列（Time Series）

时间序列 = 指标名 + 标签组合 + 时间戳 + 值。Prometheus 本质上就是一个时间序列数据库。

你想想看，每次拉取数据，Prometheus 都会记录下当前时间点的值。这些点连起来，就是一条时间序列曲线。Grafana 上那些漂亮的折线图，背后就是这些时间序列在支撑。

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

这是面试高频题，也是很多新手困惑的地方。

传统的监控系统（比如 Zabbix）用的是 Push 模型：被监控的机器主动把数据推送到中心服务器。而 Prometheus 用的是 Pull 模型：Prometheus Server 主动去拉取各个目标的数据。

为什么 Prometheus 要反其道而行之？

  • 更容易控制采集频率：Prometheus 自己决定什么时候拉，拉多快。Push 模型下，如果客户端疯狂推数据，服务器可能扛不住。
  • 更容易发现故障：如果某个目标挂了，Prometheus 拉不到数据，立刻就能感知到。Push 模型下，服务器只能等超时。
  • 更安全：Pull 模型下，被监控的目标不需要开放端口给 Prometheus，只需要暴露一个 HTTP 端点即可。

当然，Pull 模型也有缺点。比如跨网络拉取不方便，或者目标在防火墙后面。这时候可以用 Pushgateway 作为中转。我在项目中就遇到过这种情况：一些批处理任务跑完就结束，Prometheus 来不及拉取。我的做法是让任务结束时把数据推给 Pushgateway，Prometheus 再去拉 Pushgateway 的数据。

避坑指南：我曾经见过有人把所有指标都推到 Pushgateway，然后 Prometheus 从 Pushgateway 拉。这完全违背了 Pull 模型的设计初衷。Pushgateway 只适合短生命周期任务的指标，不适合长期运行的服务的指标。

3.4 安装与基础配置：5 分钟上手

好了，理论说完了，我们来动手。安装 Prometheus 其实很简单。

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 -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 UI 了。嗯，就是这么简单。

3.4.2 基础配置解析

Prometheus 的配置文件是 YAML 格式。我们来看一个最基础的配置：

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

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']  # 监控 Prometheus 自身

这里有几个关键点：

  • scrape_interval：每隔多久拉一次数据。我一般设 15s，对大多数场景够用了。如果你要监控高频指标（比如 QPS），可以设 5s。
  • evaluation_interval：每隔多久检查一次告警规则。这个值通常和 scrape_interval 保持一致。
  • job_name：一组目标的逻辑名称。比如你可以把所有的 Web 服务器归为一个 job，所有的数据库归为另一个 job。
  • targets：具体的拉取地址。格式是 IP:端口。
重要：Prometheus 默认只监控自己。如果你想监控其他服务，需要在 scrape_configs 里添加对应的 job。比如监控 Node Exporter，就加一个 job，targets 指向 Node Exporter 的地址。

3.4.3 添加一个 Node Exporter 目标

Node Exporter 是 Prometheus 官方提供的系统指标采集器。我们来把它加进去。

# 在 prometheus.yml 的 scrape_configs 下添加：
  - job_name: 'node'
    static_configs:
      - targets: ['192.168.1.100:9100']  # 替换成你的 Node Exporter 地址

重启 Prometheus 后，你就能在 Web UI 的 Targets 页面看到这个目标了。如果状态是 UP，说明采集成功。

我记得第一次配置时，怎么都连不上 Node Exporter。后来发现是防火墙没开端口。嗯，这种低级错误我犯过不止一次。所以，排查问题时先检查网络连通性。

3.5 小结

今天我们聊了 Prometheus 的架构、核心概念、Pull vs Push 模型，以及怎么安装和配置。说白了，Prometheus 的设计哲学就是「简单、可靠、云原生」。你不需要复杂的架构，一个二进制文件就能跑起来。

下一章，我们会深入 PromQL，也就是 Prometheus 的查询语言。学会了它，你才能真正从数据中挖掘出价值。到时候见。

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