第 1 章 · 认识 Prometheus 与可观测性

1.1 监控 vs 可观测性

很多人把"监控（Monitoring）"和"可观测性（Observability）"当成同义词，其实它们是不同层次的概念。监控回答的是"系统是否正常"——你事先知道会出什么问题，为它设好指标和阈值；可观测性回答的是"系统为什么不正常"——面对没预料到的问题，你能否只靠外部输出把内部状态推断出来。

Monitoring 监控: 针对已知的未知（known-unknowns）：CPU 会不会爆、磁盘会不会满、QPS 会不会跌。是主动设定好的仪表盘与告警。
Observability 可观测性: 针对未知的未知（unknown-unknowns）：能否事后任意维度下钻定位一个从没见过的故障。是一种系统属性。
Metrics 指标: 可聚合的数值型时间序列，如请求数、延迟、内存。存储成本低、查询快，适合告警与趋势——Prometheus 的主场。
Logs 日志: 离散的带时间戳事件记录，信息最全但体量大、难聚合。代表：Loki、ELK。
Traces 链路追踪: 一次请求跨多个服务的调用链，用于定位分布式系统的延迟瓶颈。代表：Jaeger、Tempo、OpenTelemetry。
SLI / SLO: SLI（服务等级指标）是衡量服务质量的具体度量（如成功率）；SLO（服务等级目标）是对 SLI 设定的目标值（如 99.9%）。第 10 章展开。

三支柱的定位

Prometheus 专注 Metrics 这一支柱。生产环境通常 Prometheus（指标）+ Loki/ELK（日志）+ Jaeger/Tempo（追踪）三者互补，OpenTelemetry 则试图统一采集层。

1.2 Prometheus 简史与生态定位

Prometheus 由 SoundCloud 于 2012 年开发，灵感来自 Google 内部的 Borgmon。2016 年它成为继 Kubernetes 之后 CNCF 收纳的第二个项目，2018 年正式毕业（Graduated）。如今它几乎是云原生监控的事实标准，与 Kubernetes 深度集成。

1.3 整体架构

Prometheus 不是一个单体，而是一组协作组件：

Prometheus Server：核心，负责抓取（scrape）目标、存储时序、执行 PromQL 与告警规则。
Exporter：把第三方系统（主机、MySQL、Redis…）的状态暴露成 Prometheus 格式的 /metrics 端点。
Pushgateway：给短生命周期的批处理任务临时暂存指标，等待被拉取。
Alertmanager：接收 Server 发来的告警，做去重、分组、抑制、静默与多渠道通知。
服务发现：从 Kubernetes/Consul/DNS 等动态获取抓取目标列表。
Grafana：外部可视化前端，把 Prometheus 当数据源。

# 数据流向示意
targets(/metrics) <--pull-- Prometheus Server --push--> Alertmanager --> 邮件/钉钉/Webhook
                                    ^
       Pushgateway --pull----------+
                                    |--query--> Grafana / API / PromQL 控制台

1.4 Pull 模型：为什么是"拉"不是"推"

Prometheus 采用 pull（拉取）模型：Server 按配置周期主动去 HTTP GET 各目标的 /metrics 端点，而不是等目标把数据推过来。这是它区别于 StatsD、InfluxDB 传统 push 模型的关键设计。

维度	Pull（Prometheus）	Push（StatsD 等）
目标健康探测	抓取失败即知目标 down（up 指标）	目标不推数据 ≈ 挂了？还是没数据？难区分
配置中心	集中在 Server，一处管理	分散在每个客户端
抗雪崩	Server 控制抓取节奏，不会被打垮	流量高峰客户端可能压垮收集端
短任务	不友好，需 Pushgateway 中转	天然适合
穿透 NAT/防火墙	需 Server 能访问目标	客户端主动外连更容易

up 指标

每次抓取，Prometheus 会自动生成一条 up{job="...", instance="..."} 指标：成功为 1，失败为 0。这是最基础也最重要的"目标是否存活"信号。

1.5 TSDB 时序数据库

Prometheus 自带一个专为时序优化的本地存储引擎（TSDB）。理解几个概念有助于后续调优：

Sample 样本: 一次采集得到的一个数据点，由 (timestamp, float64 value) 组成。
Time Series 时间序列: 由 metric 名 + 一组 label 唯一确定的样本流。序列数量（cardinality，基数）是 Prometheus 的核心成本来源。
Block 块: TSDB 把数据按时间切成不可变的 block（默认 2 小时），后台再压缩合并成更大的 block。
WAL 预写日志: 最新数据先写内存 + WAL（write-ahead log），崩溃后可从 WAL 恢复，避免丢失尚未落盘的样本。

1.6 安装与启动

方式一：二进制

# 下载并解压（以 Linux amd64 为例）
$ wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz
$ tar xzf prometheus-2.53.0.linux-amd64.tar.gz
$ cd prometheus-2.53.0.linux-amd64

# 用自带的示例配置启动，默认监听 :9090
$ ./prometheus --config.file=prometheus.yml

方式二：Docker

$ docker run -d --name prometheus -p 9090:9090 \
    -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \
    prom/prometheus:v2.53.0

最小配置 prometheus.yml

global:
  scrape_interval: 15s     # 默认每 15s 抓取一次
  evaluation_interval: 15s # 每 15s 评估一次规则

scrape_configs:
  # Prometheus 抓取自己的指标
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

启动后打开 http://localhost:9090，进入内置的表达式浏览器（Expression Browser），在查询框输入 up 回车，就能看到所有目标的存活状态。

本地 TSDB 不是长期存储

Prometheus 本地存储默认只保留 15 天（--storage.tsdb.retention.time）。长期留存、跨实例聚合需要 remote_write + Thanos/VictoriaMetrics/Mimir，第 9 章详解。

1.7 小结与下一步

监控回答"是否正常"，可观测性回答"为什么不正常"；Prometheus 主攻 metrics 支柱。
核心是 pull 模型 + 多维数据模型 + PromQL，配 Exporter、Alertmanager、Grafana 组成完整方案。
TSDB 以时间序列为单位存储，序列基数是主要成本，本地存储非长期方案。
下一章深入 数据模型与四种指标类型——这是用好 Prometheus 的地基。