‹ 返回《监控与日志》目录

📈 第01章 · Prometheus 概述

抓取模型/时序数据库

Prometheus 概述

服务器坏了才会被投诉,这话对一半。更糟的是"快坏了"你不知道,直到用户先发现。监控的本质是把机器的沉默翻译成人能看懂的信号,并让它在出事的下一秒就提醒你。这一章介绍 Prometheus 是什么、怎么工作、在这台服务器上已经跑成了一个什么样子——后面所有章节都在它的骨架上搭建。

监控解决什么问题

一台服务器最老实的指标是"现在还活着",但"活着"不保证"健康"。比如:

uptime            # 开机时长与平均负载
free -h           # 内存还剩多少
df -h /           # 根分区用了多少
systemctl status prometheus   # 服务是否 active

这些命令只能看"当下这一刻"。你半夜不在电脑前,磁盘悄无声息地涨到 97%,第二天用户才来骂。真正的监控要解决三件事:

诉求 含义 反面例子
看得见 历史趋势能回放,能看变化 只看到"现在 42%",不知道昨天多少
看得准 数字可量化、可对比 靠人肉记 date 和 df,记不齐
先一步 出问题前给信号,出事立刻知道 用户先发现,你后知道

Prometheus 是什么

Prometheus 是 CNCF(the Cloud Native Computing Foundation)旗下的开源监控系统,核心两个身份:抓取器和时序数据库(TSDB)。

  • 抓取器(pull 模型):它主动、定时去"拉"各目标的监控指标,而不是等一方"推"过来;
  • 时序数据库:每一条记录都是"某时刻的某个值",按时间轴组织,方便做趋势和聚合。

在这台服务器上已经跑着一个 Prometheus 2.45.3(由 systemd 托管),命令和端口如下:

prometheus --version
# prometheus, version 2.45.3+ds (branch: debian/sid, revision: 2.45.3+ds-2ubuntu0.3)

ss -ltnp | grep 9090      # 9090 是 Prometheus 自身 HTTP 服务端口
systemctl status prometheus
# Active: active (running); Main PID: 15583 (prometheus); Memory: 90.9M

核心概念:指标 / 标签 / 时序

Prometheus 的数据是"指标 + 标签"的序列。看一个真实的抓取结果:

node_cpu_seconds_total{cpu="0", mode="idle"} 54291.1
node_cpu_seconds_total{cpu="0", mode="iowait"} 10.4
node_memory_MemTotal_bytes 33653807104
概念 定义 例子中的体现
指标名 (metric) 描述"量的是什么",通常加单位 node_cpu_seconds_total、node_memory_MemTotal_bytes
标签 (label) 键值对,用来做维度区分 cpu="0"、mode="idle"
时序 (time series) 同一组标签下随时间变化的值序列 mode="idle" 这一条在每分钟都有一个值

标签是重中之重:同一个指标靠不同标签区分维度。后面 PromQL 里用 mode="idle" 挑出空闲态,就是用标签做筛选。

抓取模型:Pull vs Push

模型 特点 适用 例如
Pull(拉) Prometheus 主动来取 自建、需要明确控制采集节奏 Prometheus 抓 node-exporter
Push(推) 目标主动上报 短生命周期任务、数不清的实例 云厂商聚合、日志/计数字段上报

Prometheus 主打 Pull:好处是目标活着才能被抓——一个节点挂了,up 指标立刻为 0,天然具备存活探测能力。代价是它必须能网络直达目标,防火墙要多开一个端口(9100)。

主要组件与数据流

   ┌──────────────┐   15s 定时抓取     ┌──────────────────┐
   │ prometheus   │ ───────────────► │ node-exporter     │
   │ (TSDB+采集)  │  localhost:9100   │ (暴露 /metrics)   │
   └──────────────┘                   └──────────────────┘
         │ 9090
         ├─► HTTP API(查询/抓取状态)
         ├─► 内置 Web UI(浏览器访问 localhost:9090)
         └─► rule_files 评估规则 → 触发告警 → Alertmanager

一个 "scrape"(抓取)指 Prometheus 定时去某目标抓一次 /metrics,抓回来的数据写进本地时序数据库。抓取频率由 scrape_interval 控制,后面章节详讲。

数据类型:Counter / Gauge / Histogram / Summary

指标值不是只有一种含义,分四类:

类型 含义 典型例子 常见疑问
Counter(计数器) 只增不减,累计总量 node_cpu_seconds_total(CPU 累计秒数) 要"速率"得配 rate() 转一下
Gauge(仪表) 可增可减,当前快照 node_memory_MemAvailable_bytes 直接用,还能 + - 计算
Histogram(直方图) 把观测值分桶计数 请求耗时分布 用来算分位数(histogram_quantile)
Summary(摘要) 预聚合了分位数 耗时摘要 由目标自身算好

提示 这四类的分辨直接决定查询写法。node_exporter 里的指标名结尾 _total 的函数几乎都是 Counter,算比例、算速率前必须先 rate 或 irate,直接用 _total 只会增长不归零。

存储与保留

Prometheus 默认把数据写到 --storage.tsdb.path 指向的目录(通常是 --storage.tsdb.path=/var/lib/prometheus/,默认保留 15 天)。你可以通过启动参数调整保留时长,但别把保留期设成无限大——单机磁盘会被时序慢慢吃满。

# 查看数据目录
ls /var/lib/prometheus/ 2>/dev/null
# 查看存储与保留参数
prometheus --help 2>/dev/null | grep -i 'storage.tsdb'

这一章结束时,你已经能

  • 说清 Prometheus 是 pull 模型 + 时序数据库;
  • 分清指标名、标签、时序三个概念;
  • 知道 Counter 和 Gauge 在查询时的差别;
  • 在你服务器上确认 Prometheus 版本、端口、systemd 服务状态。

易错点

  • 把 node_cpu_seconds_total 当 CPU 使用率:它是累计秒数,永远在涨;要先 rate 或 irate 变成"每秒增量",才是百分比的基础。
  • 内存单位是字节:node_memory_MemTotal_bytes 是 33GB 级别的字节数,不换算就不要直接当 GB 看。
  • 防火墙只放行 9090 忘了 9100:Prometheus 自己通,但抓不到 node 数据,目标一直 down。
  • 抓取失败 ≠ 进程死:目标 down 也可能是端口没通、超时(默认 10s)或防火墙拦截,先 ss -ltnp 确认到底谁挂了。

相关命令

systemctl status prometheus、prometheus --version、ss -ltnp | grep 9090、curl localhost:9090/api/v1/status/buildinfo、promtool check config(校验配置,后续章节用)。

prometheus.yml 配置 ›