【Prometheus·入门篇】Prometheus 是什么：从 Nagios 到云原生监控的演进

前言

在云原生时代，系统从单体走向微服务，从物理机走向容器，监控的对象从几十台服务器变成了几千个 Pod。传统的监控工具（Nagios、Zabbix）在这个变化中逐渐力不从心。Prometheus 应运而生，成为了云原生监控的事实标准。本篇带你理解监控的演进史和 Prometheus 的核心定位。

---

一、监控的演进历程

第一代：脚本化监控（2000 年前后）

管理员写 Shell 脚本 → cron 定时执行 → 检查端口/进程 → 邮件通知

#!/bin/bash
# check_httpd.sh
if ! pgrep httpd > /dev/null; then
    echo "ALERT: Apache is down on $(hostname)" | mail -s "Alert" admin@example.com
fi

特点：简单直接，但不可扩展、无历史数据、无可视化。

第二代：Nagios 时代（2000-2010）

Nagios 架构：
  Nagios Server
    ├── Plugin（NRPE）→ 采集目标主机指标
    ├── 主动检查 → ping / check_http / check_disk
    └告警通知 → 邮件 / 短信

Nagios 的优势 ：

• 丰富的插件生态

• 灵活的告警规则

• 状态机模型（OK → WARNING → CRITICAL）

Nagios 的局限 ：

• 关注状态而非趋势（"现在是否正常" vs "趋势如何"）

• 不适合海量时间序列数据

• 告警逻辑写在配置文件，难以动态调整

• 无原生分布式支持

第三代：Zabbix 时代（2005-2015）

Zabbix 架构：
  Zabbix Server
    ├── 数据库（MySQL/PostgreSQL）
    ├── Zabbix Agent → 采集主机指标
    ├── SNMP/JMX → 采集网络/Java 指标
    └── Web UI → 可视化 + 告警

Zabbix 的优势 ：

• 一站式（采集+存储+告警+可视化）

• Agent 安装即用，门槛低

• 自动发现功能

Zabbix 的局限 ：

• 中心化架构，数据库成为瓶颈

• 不适合容器/Kubernetes 环境

• 指标维度单一（主机/端口），不支持多维标签

第四代：Prometheus 云原生时代（2015-至今）

Prometheus 设计理念：
  - 多维标签（label）驱动
  - 拉模型（Pull），而非推模型（Push）
  - 原生支持容器/K8s
  - 时间序列数据库（TSDB）内置
  - 强大的查询语言（PromQL）

---

二、Prometheus 的诞生背景

SoundCloud 的痛点

2012 年，SoundCloud（音乐平台）面临监控挑战：

• 微服务化后，服务从几十个变成几百个

• 每个服务有多个实例，动态扩缩容

• 传统的 Nagios/Zabbix 无法适应弹性环境

• 需要按多维度查询指标（服务名 + 实例 + 方法 + 状态码）

设计思路

受 Google 内部监控系统 Borgmon 启发：

Borgmon 的核心思想：
  1. 声明式监控：定义要监控什么，而非怎么监控
  2. 时序数据库：原生存储时间序列数据
  3. 维度标签：每个指标都可以打多个标签
  4. 查询语言：类似 PromQL 的查询能力
  5. 拉模型：主动从目标拉取指标

开源与发展

2012年  SoundCloud 内部开发
2015年  开源发布 1.0
2016年  加入 CNCF（第二个项目，仅次于 Kubernetes）
2018年  毕业 CNCF
2024年  v2.50+，全球最大监控项目之一

---

三、Prometheus 核心特性

1. 多维数据模型

# 传统监控：一个指标只有值
disk_usage = 85%

# Prometheus：一个指标有多个维度
disk_usage{host="server-01", device="/dev/sda1", mountpoint="/", fstype="ext4"} = 85%
disk_usage{host="server-01", device="/dev/sdb1", mountpoint="/data", fstype="xfs"} = 62%
disk_usage{host="server-02", device="/dev/sda1", mountpoint="/", fstype="ext4"} = 45%

优势：同一个指标可以用不同标签组合查询：

# 查询所有主机根分区使用率
disk_usage{mountpoint="/"}

# 按主机聚合平均使用率
avg(disk_usage) by (host)

# 使用率超过 80% 的主机
disk_usage > 80

2. 拉模型（Pull）

推模型（StatsD/InfluxDB）：
  应用 → 主动推送指标 → 监控服务器
  - 服务器不知道有哪些目标
  - 目标不可达时，指标会丢失但服务器不知道

拉模型（Prometheus）：
  监控服务器 → 主动拉取 → 目标暴露 /metrics 端点
  - 服务发现知道所有目标
  - 目标不可达时，标记为 down，触发告警
  - 天然支持负载均衡和健康检查

3. 内置时序数据库

不需要外部依赖：
  Prometheus Server 自带 TSDB
  - 高效压缩（Gorilla 压缩算法）
  - 快速查询（倒排索引）
  - 适合短期存储（通常 15 天）
  - 长期存储通过远程存储（Thanos/VictoriaMetrics）

4. PromQL 查询语言

# 实时查询
http_requests_total{method="GET", status="200"}

# 速率计算
rate(http_requests_total[5m])

# 聚合
sum(rate(http_requests_total[5m])) by (method)

# 数学运算
(rate(http_requests_total{status="500"}[5m]) / rate(http_requests_total[5m])) * 100

# 预测
predict_linear(node_filesystem_free_bytes[1h], 4*3600) < 0

5. 服务发现

# Kubernetes 服务发现
scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

---

四、Prometheus 生态全景

┌──────────────────────────────────────────────┐
│              可视化层                          │
│         Grafana / Perses / Lens               │
└──────────────┬───────────────────────────────┘
               │ (查询)
┌──────────────┴───────────────────────────────┐
│           Prometheus Server                   │
│  ┌────────────┐ ┌──────────┐ ┌────────────┐ │
│  │ Retrieval  │ │ TSDB     │ │ HTTP Server│ │
│  │ (采集)     │ │ (存储)   │ │ (查询API)  │ │
│  └────────────┘ └──────────┘ └────────────┘ │
│  ┌────────────────────────────────────┐       │
│  │      Service Discovery             │       │
│  │  (K8s/Consul/DNS/EC2/File)         │       │
│  └────────────────────────────────────┘       │
└──────┬───────────────────┬────────────┬─────┘
       │ Pull              │ Push       │ 远程存储
       │                   │            │
  ┌────┴──────┐    ┌──────┴──────┐  ┌──┴──────────┐
  │ Exporters │    │ Pushgateway │  │ Thanos      │
  │           │    │ (短任务)     │  │ VictoriaMetrics│
  │ Node      │    └─────────────┘  │ Cortex      │
  │ MySQL    │                      │ Mimir       │
  │ Redis    │                      └─────────────┘
  │ Blackbox │
  └──────────┘
               ┌────────────────────┐
               │   Alertmanager     │
               │  (告警路由/分组/抑制)│
               └────────────────────┘
               ┌────────────────────┐
               │   Exporter 生态      │
               │ node_exporter      │
               │ mysqld_exporter    │
               │ blackbox_exporter  │
               │ kafka_exporter     │
               │ ... 100+ exporters │
               └────────────────────┘

---

五、Prometheus vs 其他监控工具

特性	Nagios	Zabbix	Prometheus	Datadog
数据模型	状态机	标量	多维时序	多维时序
采集方式	插件主动检查	Agent 推	服务端拉	Agent 推
容器支持	弱	弱	原生	中等
查询语言	无	SQL(部分)	PromQL	专有
告警	内置	内置	Alertmanager	内置
可视化	插件	内置 Web	Grafana 集成	内置
分布式	无	代理模式	联邦/Thanos	SaaS
开源	是	是	是	否
适合规模	小	中大	云原生	SaaS

---

六、什么场景适合用 Prometheus

✅ 适合

• Kubernetes 集群监控
• 微服务指标监控（HTTP 请求量/延迟/错误率）
• 容器化应用监控
• 基础设施指标监控（CPU/内存/磁盘/网络）
• 短期指标告警（SLI/SLO）

❌ 不适合

• 长期存储（需要 Thanos 等扩展）
• 事件日志（用 ELK/LoKi）
• 分布式追踪（用 Jaeger/Tempo）
• 用户行为分析（用 GA/Amplitude）
• 高精度数据（不支持，最小间隔 15s）

---

要点回顾

• Prometheus 从 SoundCloud 内部工具演变为 CNCF 毕业项目
• 核心理念：多维标签 + 拉模型 + TSDB + PromQL
• 解决了传统监控在云原生环境中的三大问题：弹性目标、多维查询、容器化支持
• 生态丰富：Exporter 100+，Grafana 可视化，Alertmanager 告警
• 与 K8s 深度集成，是云原生监控的事实标准

---

下一篇预告

理解了 Prometheus 是什么之后，下一篇 【Prometheus·入门篇】架构详解：Server、Exporter、Pushgateway 与 Alertmanager 将深入拆解 Prometheus 的每个组件，让你理解数据从采集到告警的完整链路。