Prometheus 实战 01：入门与监控基础

Prometheus 实战系列（共 10 篇） 下一篇 Prometheus 实战 02 → 返回监控索引

Prometheus 从 0 到 1 新手实战手册

本篇是写给零基础同学的 Prometheus 上机手册：不堆概念，每一步都告诉你在哪个目录、用什么用户、敲什么命令、应该看到什么、错了怎么修，跟着敲完就能搭出一套中小企业在用的监控告警系统。

这份手册怎么用

适合这样的你：

没接触过监控，连"端口""进程"这些词都还模模糊糊；
会开 Linux 终端、能复制粘贴命令，但不知道命令背后的意思；
想学一门企业里真正在用的监控技术，并且希望学完就能写进简历、上手干活。

不追求这些：不考你历史年份、不让你背长篇原理。所有理论都遵循"三句话原则"——是什么、为什么需要、跟当前操作有什么关系，讲完立刻上机。

学习方法建议：

准备一台可以随便折腾的 Linux 机器（虚拟机或云服务器都行），系统用 Ubuntu 22.04 / 24.04 LTS；用 RHEL/Rocky/CentOS 的同学，手册里同时给出了对应命令。
手册是一环扣一环的，请按顺序做，不要跳章。上一条命令的输出，往往就是下一步的输入。
每个大阶段末尾都有"命令速查表"和"常见坑与解决"，卡住了先翻这两块。

贯穿全书的实战项目：星辰电商监控平台

光讲零散命令学不会，本手册用一个贴近中小企业的真实项目把所有知识点串起来。

项目背景：星辰电商是一家几十人规模的电商公司，有 3 台核心业务服务器（Web、应用、数据库），后来又上了容器和 Kubernetes。公司要求搭一套监控系统，做到：

主机 CPU、内存、磁盘、网络出问题前提前预警；
Nginx、MySQL、Redis、Java 应用等中间件运行状态可视；
网站打不开、接口超时能在 1 分钟内通知值班人员；
定时备份脚本、批处理任务的执行结果可监控；
监控数据长期保存，出了故障能回溯；
后期扩展到多机房、Kubernetes 集群。

主机与 IP 规划（示例，请替换成你自己的）：

角色	主机名	示例 IP	部署的组件
监控服务器	monitor	10.0.0.10	Prometheus、Alertmanager、Grafana、Pushgateway、Blackbox Exporter
Web 服务器	web01	10.0.0.11	Nginx、Node Exporter
应用服务器	app01	10.0.0.12	Java/Go 业务应用、Node Exporter
数据库服务器	db01	10.0.0.13	MySQL、Redis、Node Exporter、MySQL Exporter、Redis Exporter
备用/扩展主机	node02	10.0.0.14	Node Exporter（演示扩容、联邦用）

如果你只有一台机器也没关系：可以用 Docker 在一台机器上模拟所有角色；手册会在对应位置说明单机做法。

约定：凡是命令中出现【】包裹的内容，都是需要你替换成自己环境实际值的占位符，例如：

占位符	含义	示例填法
【监控服务器IP】	Prometheus 所在机器的 IP	10.0.0.10
【Web服务器IP】	Web 主机的 IP	10.0.0.11
【应用服务器IP】	应用主机的 IP	10.0.0.12
【数据库服务器IP】	数据库主机的 IP	10.0.0.13
【你的邮箱】	接收告警的邮箱	ops@example.com
【邮箱授权码】	邮箱 SMTP 授权码（不是登录密码）	邮箱后台生成

命令格式约定：

命令代码块里只有命令本身，不带 [root@...] 提示符，可以直接复制；
需要 root 权限的步骤，会明确告诉你是用 sudo 命令、sudo -i 切到 root，还是用普通用户；
预期输出单独用文本块给出，你实际看到的时间戳、ID 等会不一样，属正常；
提示框含义：::: tip 是小技巧，::: warning 是生产环境必须注意的红线。

软件版本清单（2026 年 9 月核验的当前稳定版）：

软件	本手册采用版本	默认端口	作用
Prometheus	3.15.0	9090	监控核心：采集、存储、查询、产生告警
Node Exporter	1.12.1	9100	采集主机 CPU/内存/磁盘等指标
Alertmanager	0.34.1	9093	处理告警：分组、去重、路由、发送
Pushgateway	1.11.3	9091	接收短任务/批处理主动推送的指标
Blackbox Exporter	0.28.0	9115	黑盒探测：HTTP/TCP/ICMP/DNS 探活
MySQLd Exporter	0.20.0	9104	采集 MySQL 指标
Redis Exporter	1.92.1	9121	采集 Redis 指标
Nginx Prometheus Exporter	1.5.3	9113	采集 Nginx 指标
JMX Exporter	1.6.0	（随 Java 进程）	采集 Java/JVM 指标
cAdvisor	v0.60.6	8080	采集容器指标
Grafana	13.2.2	3000	图形化大屏展示
VictoriaMetrics	v1.152.0	8428 / 8480-8482	远程长期存储
Consul	1.22.7	8500	服务注册与发现

WARNING

生产环境不要用 latest 标签，也不要追新到发布没几天的版本。本手册刻意选择已发布一段时间、经过验证的稳定版；版本号会随时间变化，安装前可以到官方下载页核对一眼，链接见文末"相关速查"。

学习路线图

阶段一：搞懂监控和 Prometheus 的基本概念与架构（不动手，约 30 分钟）；
阶段二：把 Prometheus、Node Exporter、Grafana、Pushgateway 装起来，看到第一张监控图；
阶段三：学会 PromQL 查询语言，自己写 exporter；
阶段四：玩转标签；
阶段五：搭告警，邮件/钉钉/企业微信都能收到报警；
阶段六：服务发现，新机器上线不用手改配置；
阶段七：监控 MySQL、Redis、Nginx、Java 等各种中间件；
阶段八：监控 Docker 容器；
阶段九：联邦集群，支撑多机房；
阶段十：远程存储，数据长期保存与回溯；
阶段十一：在 Kubernetes 上落地 Prometheus。

阶段一：认识监控与 Prometheus

阶段目标

用大白话搞懂"监控系统"由哪几部分组成、监控些什么；
记住 Prometheus 全家桶每个组件是干什么的；
理解 Prometheus 最核心的两个特点：拉（Pull）模式和标签数据模型；
能对着架构图把数据流向别人讲清楚。

本阶段以理解为主，不需要上机。

1.1 监控系统由哪几部分组成

先打个比方：一套监控系统就像小区物业的安保体系——

监控系统的环节	小区里对应什么	干什么
数据产生	电梯、水泵、电表本身会产生运行数据	被监控的设备和软件天然带有状态信息
数据采集	保安巡逻、传感器抄表	周期性地把状态数据收集上来
数据存储	物业档案室	把数据存起来，以后能查
数据处理	整理报表、算平均值	对原始数据做计算（比如平均 CPU 使用率）
数据展示	监控大屏	用图形把数据画出来给人看
告警	火警铃、给值班保安打电话	数据异常时主动通知人处理

一个完整的监控系统，就是由数据产生 → 数据采集 → 数据存储 → 数据处理 → 数据展示 → 告警这六部分组成的闭环。少了任何一环都不完整：只采集不告警，等于装了摄像头但没人看；只告警不存数据，报警了也没法回溯原因。

1.1.1 可观测性的三大信号

你会反复听到"可观测性（Observability）"这个词。

是什么：可观测性就是"不用登录到机器里面，光看系统对外暴露的输出，就能判断系统内部哪里出了问题"的能力。
为什么需要：云原生时代一个应用可能拆成几十上百个服务、几千个容器，出了问题不可能一台台机器登上去翻。
和操作的关系：Prometheus 负责其中的"指标"信号，知道三者区别后，你才不会指望用 Prometheus 去查日志、找调用链。

它包含三大信号（也叫三大支柱），用去医院看病来记：

信号	医院类比	记录的内容	典型工具
指标 Metrics	体温计、血压计读出的数字	可聚合的数值（CPU 使用率、请求数）	Prometheus
日志 Logging	医生写的病历本	一条条带时间的事件记录	ELK、Loki
追踪 Tracing	医院走廊监控回放你走过的路线	一个请求在多个服务间的完整调用链	Jaeger、SkyWalking

本手册只讲"指标"这一支，但要知道另外两支的存在。

1.1.2 数据从哪来、怎么采

数据来源主要有三类：

硬件/系统本身的记录：比如 CPU 温度、内存占用，以内核文件或内存属性的形式存在（Linux 上常见于 /proc、/sys 目录）；
应用主动暴露的接口：比如 Redis 的 INFO 命令、各种软件的 status 页面，主动告诉你"我现在好不好"；
采集工具执行系统命令：通过 ps、df 这类命令间接拿到状态。

这些被固定记录下来的"属性指标"，英文叫 metric（指标）——一个带名字的、可测量的数值，比如"CPU 使用率""当前在线人数"。

采集方式按协议分，先混个眼熟，后面用到再细说：

方式	一句话解释
Agent	在被监控机器上装一个专用小程序（代理），由它负责收集本机数据
HTTP	基于网页协议传输数据，在浏览器输入网址能看到数据，Prometheus 主要用这种
SSH	远程登录到机器上执行命令取数，需要登录凭证
SNMP	简单网络管理协议，主要用于交换机、路由器等网络设备
IPMI	智能平台管理接口，用于采集硬件的温度、电压、风扇、电源等物理状态（关机也能采）

TIP

为什么强调"周期性"采集？一个孤立的数字没有意义——"CPU 使用率现在是 80%"说明不了问题，但"过去 7 天每天下午 3 点 CPU 都冲到 100%"就能定位规律。所以监控数据必须持续、周期地采。

1.1.3 数据为什么要存进"时序数据库"

采集来的数据有个共同点：每个数值都带着一个时间戳。这种"按时间顺序记录状态变化"的数据，叫时间序列数据（Time Series Data）；专门存它的数据库叫时序数据库（TSDB，Time Series Database）。

类比：时序数据就像心电图、股票 K 线图——横轴永远是时间，纵轴是数值，一笔一笔连续画出来。
为什么需要专门的数据库：监控数据量极大（一台机器几千个指标、每 15 秒采一次，一天就是上千万个点），但结构极简单（某个指标在某个时刻只有一个值），普通关系型库存它又慢又占地方。
和操作的关系：Prometheus 自带一个时序数据库，装完就有，不用单独装；阶段十会讲它怎么存、怎么外接长期存储。

时序数据的特点（了解即可）：基本只追加写入、很少修改；删除一般是删一整段时间；读取按时间正序或倒序；压缩率极高，一个数据点平均只占 1～2 个字节。

1.2 监控些什么、用什么标准衡量

1.2.1 监控的三大类内容

资源数据（基础设施）：
- 硬件：服务器、路由器、交换机、IO 设备；
- 系统资源：操作系统、网络、容器、虚拟机；
- 应用软件：Nginx、MySQL、Java 应用等。
业务服务（业务指标）：服务是否在线、QPS（每秒请求数）、DAU（日活跃用户数）、转化率、充值额度、用户投诉数，以及访问变慢、存储空间不足、主机宕机等故障。
趋势分析：用历史数据预测未来——比如"按现在的增长，磁盘再过 40 天会写满""双 11 当天流量大概是平时的 8 倍，需要提前扩容"。

1.2.2 衡量服务好坏：四个黄金指标

Google 总结了四个"黄金指标"，用来衡量一个在线服务的健康程度。用一家饭店来记：

黄金指标	含义	饭店类比	例子
延迟 Latency	处理一个请求花多长时间	客人点完菜多久能上菜	HTTP 请求平均响应时间；要区分成功请求和失败请求的延迟
流量 Traffic	每秒有多少请求进来（吞吐量）	饭点一小时进来多少客人	每秒 HTTP 请求数 QPS、数据库每秒事务数 TPS
错误 Errors	失败请求的数量或比例	上错菜、退菜的数量	HTTP 500 错误数、超时数、返回异常内容数
饱和度 Saturation	资源有多"满"	大厅上座率、厨师忙不忙得过来	CPU/内存/磁盘/网络利用率，队列积压长度

TIP

饱和度有个经验用法：很多资源在使用率到 80% 以后性能会陡增式下降，所以告警阈值常设在 80%～90%，而不是等 100% 才报警。

1.3 监控的三种实现路子

在 Linux 上做监控，大致三种方式：

系统命令：用 uptime、top、df、free、ss 等命令临时看一眼。优点是随装随有，缺点是关了终端数据就没了，不能持续、不能告警、不能看历史。
开源监控软件：
- Zabbix：传统监控的代表，诞生早、功能全，后端用关系型数据库；在微服务、容器大规模动态扩缩容的场景下逐渐吃力。
- Prometheus：为云原生、容器环境设计，自带时序库和强大的查询语言，是当前容器监控的事实标准。
云厂商监控平台：阿里云云监控、AWS CloudWatch 等，开箱即用，但通常绑定云厂商、收费、定制能力有限。

本手册讲第 2 种里的 Prometheus。

1.4 正式认识 Prometheus

1.4.1 它是什么

是什么：Prometheus（普罗米修斯）名字取自希腊神话中为人类盗火的神；它是一款开源的时序数据库，也是一套监控告警框架，用 Go 语言开发，灵感来自 Google 内部的 Borgmon 监控系统。
为什么需要它：传统监控扛不住云原生环境里海量、动态变化的监控目标；Prometheus 用多维标签模型和拉模式解决这个问题。
和操作的关系：它是本手册绝对的主角，阶段二就把它装起来。

它的主要特点：

多维数据模型：时间序列由"指标名 + 一组标签（键值对）"组成，想按哪个维度筛选、聚合都行；
自带时序数据库，不需要额外装数据库；
PromQL 查询语言：能做非常复杂的查询、聚合，是画图和告警的基础；
HTTP 拉（Pull）模式采集；
对短生命周期任务，可通过 Pushgateway 接收推送；
支持静态配置和服务发现两种方式找监控目标；
自带 Web 界面，也完美支持 Grafana 等第三方看板。

它擅长：记录任何纯数字的时间序列，无论是机器监控还是动态微服务监控；设计上强调"每个服务器独立工作、不依赖外部存储"，所以在故障发生、其他基础设施挂掉时，你依然能靠它看数据、定位问题。

它不擅长（心里要有数）：

单机版 Prometheus 自身不支持集群（高可用要靠双机+远程存储等方案，阶段五、阶段十讲）；
规模过大（上万目标）时单机性能有瓶颈（可用联邦、分片解决，阶段九讲）；
不保证 100% 精确：采集中可能丢点，所以不能用来做计费、账单这类要求分毫不差的场景，计费请用其他系统；
本身只是"采集+存储+查询+产生告警"，展示靠 Grafana、发告警靠 Alertmanager，需要组件配合。

1.4.2 最核心特点一：拉（Pull）模式

Prometheus 最典型的特性：它主动去被监控目标上"拉"数据，而不是等对方"推"过来。

类比：Pull 像老师上课点名——老师（Prometheus）按花名册主动点，谁没到（拉不到）当场就知道；Push 像学生主动交作业——老师只能等，谁没交不一定清楚。

Pull 模式的优点：

业务无侵入：应用只要暴露一个标准的 /metrics 网页接口就行（客户端库会自动生成），不用关心 Prometheus 在哪、失败怎么重试、怎么鉴权推送；
服务端集中管控：采集间隔、超时、标签、过滤、TLS、黑名单全写在 Prometheus 配置里，运维一处管理；
天然自带健康检查：拉取时如果目标挂了、超时了，Prometheus 会自动生成一个 up=0 的指标，直接就能对"实例是否存活"告警；
容器/K8s 友好：新 Pod 启动自动暴露指标，不用改业务代码。

Pull 模式的缺点（以及补救办法）：

缺点	说明	补救办法
Prometheus 必须能网络访问到目标	防火墙、网段不通就拉不到	放通网络/端口，或用远程采集代理
短生命周期任务拉不到	任务可能在两次拉取之间就结束了	用 Pushgateway，任务结束前主动推
离线/内网深处服务拉不到	Prometheus 无法直达	在该网络内部署采集代理再转发
对目标有轻微性能开销	每次拉取要消耗一点 CPU	控制采集频率和指标数量

1.4.3 最核心特点二：指标名 + 标签的数据模型

Prometheus 里存的每一条时间序列，由**指标名（Metric Name）和标签（Labels，键值对）**唯一确定。

指标名：表示"这是什么指标"，要有意义，比如 http_requests_total（HTTP 请求总数）。只能用字母、数字、下划线、冒号，且以字母或下划线开头；冒号是留给记录规则用的，自己起名别用。
标签：表示"这个指标的哪个维度"，格式是 标签名="标签值"。比如：

text

http_requests_total{method="POST", endpoint="/api/tracks"}

读法：http_requests_total 是指标名；method="POST" 表示只看 POST 请求；endpoint="/api/tracks" 表示只看 /api/tracks 这个接口。如果 method 换成 "GET"，那就是另一条全新的时间序列。

标签名只能用字母、数字、下划线；以 __（两个下划线）开头的标签名是内部保留的，不要自己定义。
标签值可以是任意字符；标签值为空等于这个标签不存在。
记住一句话：任何标签值的改变（包括增、删标签），都会产生一条新的时间序列。这是后面"标签爆炸撑爆内存"那个坑的根源。

1.4.4 Job 和 Instance

实例（Instance）：一个能被抓取的目标，通常是 IP:端口 的形式，对应一个具体的应用进程。
任务（Job）：一组同类型实例的集合，比如一个 API 服务部署了 4 个副本，这 4 个 instance 同属一个 job。

用学校来记：Job 是班级，Instance 是班里的学生。

text

job: api-server
  instance 1: 1.2.3.4:5670
  instance 2: 1.2.3.4:5671
  instance 3: 5.6.7.8:5670
  instance 4: 5.6.7.8:5671

这里顺带把网络基础概念补上：

IP 地址像"门牌号"：在网络中找到哪一台机器；
端口像"房间号"：一台机器上同时跑很多程序，靠端口区分数据交给哪个程序。端口范围 0～65535，Prometheus 生态的常用端口见版本清单表（9090、9100 等）。

每次抓取，Prometheus 还会自动生成几个"体检指标"，先眼熟：

指标	含义
`up`	抓取是否成功：1 正常，0 失败，做存活告警就靠它
`scrape_duration_seconds`	这次抓取花了多少秒
`scrape_samples_scraped`	这次抓到了多少个样本
`scrape_samples_post_metric_relabeling`	标签重写后还剩多少样本
`scrape_series_dded`	这次抓取新增了多少条序列

1.4.5 指标的文本长什么样

被监控目标暴露出来的数据，本质是一段纯文本，通过网页返回给 Prometheus。格式要点：

每行一条，空行忽略；
以 # HELP 开头的行是这个指标的说明；
以 # TYPE 开头的行声明指标类型，共四种：Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要），阶段三细讲；
其他 # 开头的是普通注释，会被忽略。

真实样子（阶段二装完就能在浏览器看到）：

text

# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 12345.67
node_cpu_seconds_total{cpu="0",mode="system"} 89.1

1.5 Prometheus 全家桶成员

组件	角色（一句话）	大白话类比
Prometheus Server	核心：抓取并存储时序数据、执行规则、产生告警	监控指挥中心
Client Library（客户端库）	给自研应用用的 SDK，帮应用生成并暴露指标	给应用发的"自测体检表"
Exporters（导出器）	部署在被监控端，把 MySQL/Nginx/主机等的现成数据翻译成 Prometheus 格式暴露出来	翻译官：把各软件的"方言"翻译成 Prometheus 听得懂的话
Pushgateway	临时存放短任务、批处理主动推来的指标，等 Prometheus 来拉	临时快递柜：短寿命任务把"作业"放柜子里
Alertmanager	接收 Prometheus 产生的告警，做去重、分组、静默、抑制，再路由到邮件/钉钉/企微等渠道	接警台 + 调度员
Grafana	把数据画成漂亮的仪表盘、大屏	监控大屏 / 画图师
Service Discovery（服务发现）	动态发现要监控的目标，Prometheus 内置	自动更新的花名册

WARNING

Pushgateway 只用来接收短任务、批处理的指标，不要用它推送主机层面的指标（主机指标请用 Node Exporter）。原因：Pushgateway 里的数据会一直保留，主机挂了它还在显示旧数据，会造成"机器都死了监控还显示正常"的假象。

1.6 架构与数据流向

下图是 Prometheus 的整体架构，本阶段的核心就是看懂它：

Prometheus 整体架构与数据流向

按图把工作流程走一遍（建议自己复述一遍）：

找目标：Prometheus 通过服务发现（DNS、Kubernetes、Consul、文件等）或静态配置，得到一份要监控的目标清单；
采数据：Prometheus Server 周期性地（默认每 15～60 秒）通过 HTTP 从各类 Exporter、应用的 /metrics 接口**拉取（pull）指标；短生命周期任务则先把指标推（push）**到 Pushgateway，再由 Prometheus 拉取；
存数据：拉来的数据存入本地时序数据库（TSDB），先写内存和预写日志（WAL），再定期压缩成数据块落盘；
算规则：Prometheus 按配置的记录规则预先计算常用查询、生成新序列；按告警规则周期性计算，条件满足就产生告警；
发告警：产生的告警推送给 Alertmanager，由它去重、分组、静默、抑制，再按路由发送到邮件、钉钉、企业微信、PagerDuty 等接收端；
看数据：人通过 Prometheus 自带 Web UI、Grafana 或调用 HTTP API 的其他客户端来查询、展示数据。

本阶段概念速查表

本阶段不上机，无命令可查；记住这张概念表即可：

术语	一句话记住
metric 指标	一个带名字、可测量的数值
时序数据 / TSDB	带时间戳、按时间排列的数据 / 专门存它的库
Pull / Push	Prometheus 主动去拉 / 目标主动来推
指标名 + 标签	唯一确定一条时间序列
Job / Instance	同类型实例的集合（班级）/ 单个目标（学生）
up	1 健康、0 挂了
Exporter	把第三方软件数据翻译给 Prometheus
Pushgateway	短任务放指标的临时快递柜
Alertmanager	告警的接警调度台
Grafana	画监控大屏的
四个黄金指标	延迟、流量、错误、饱和度
三大信号	指标、日志、追踪

本阶段常见坑与解决

坑 1：以为装了 Prometheus 就万事大吉，不装 Alertmanager、Grafana

新手做法：只装一个 Prometheus，以为它自带画图和发消息功能。
现象：打开 Prometheus 界面只有简单图表，告警也不知道去哪配。
根本原因：Prometheus 只负责"采集、存储、查询、产生告警"，展示靠 Grafana、发送告警靠 Alertmanager，职责是拆开的。
解决：按阶段二把 Prometheus + Grafana + Alertmanager 一起部署（Docker Compose 一条命令可全起来）。
预防：开工前先回看 1.5 的全家桶成员表，明确每个组件职责。

坑 2：网络不通就急着判定"软件坏了"

新手做法：浏览器打不开 Prometheus/Exporter 页面，反复重装软件。
报错原样（浏览器）：无法访问此网站，10.0.0.11 拒绝了连接请求；或 Prometheus 目标页显示 Get "http://10.0.0.11:9100/metrics": dial tcp 10.0.0.11:9100: connect: connection refused，目标状态为 DOWN，up=0。
根本原因：Pull 模式要求 Prometheus 能网络访问到目标；服务没启动、没监听对外地址、防火墙没放通、IP/端口写错，都会拉取失败。
解决步骤（阶段二会逐条实操）：
1. 在目标机执行 ss -lntp | grep 9100 确认服务是否在监听；
2. 只监听了 127.0.0.1 的要改成监听 0.0.0.0；
3. 放通防火墙：sudo ufw allow 9100/tcp（Ubuntu）或 sudo firewall-cmd --add-port=9100/tcp --permanent && sudo firewall-cmd --reload（RHEL 系）；云服务器还要在控制台安全组放行；
4. 在监控机执行 curl http://【Web服务器IP】:9100/metrics 验证。
预防：部署任何 exporter 后，立刻用 ss -lntp 和 curl 自检，再配 Prometheus。

坑 3：用 Pushgateway 推送主机指标

新手做法：图省事，让所有主机把 CPU、内存指标推给 Pushgateway。
现象：某台主机关机后，Pushgateway 里仍是它最后推的旧值，监控大屏显示一切正常，漏报宕机。
根本原因：Pushgateway 会一直保留推来的数据、不会因目标消失而删除；它本是为"可能在拉取前就消失的短任务"设计的。
解决：主机层面一律用 Node Exporter（拉不到时自动 up=0 并告警）；Pushgateway 只接收批处理、定时任务指标。
预防：记住 1.5 节的警告框。

坑 4：随手加标签、改标签值，导致序列爆炸

新手做法：把请求 ID、时间戳、用户 ID 这类每次都变的值放进标签。
报错/现象：Prometheus 内存、磁盘快速上涨，日志出现 too many series、failed to send series: server returned HTTP 400 ... series limit exceeded 类报错，Grafana 查询变慢。
根本原因：标签值一变就是一条新序列；高基数字段（每次都不同的值）会让序列数无限膨胀。
解决：去掉高基数标签；在 Prometheus 启动参数配置序列上限（--storage.tsdb.max-series）做保护。
预防：标签只放"可枚举、会用来分组筛选"的维度（如实例、接口、方法、状态码），绝不放每次都变的唯一值。

Prometheus 实战 01：入门与监控基础 ​

Prometheus 从 0 到 1 新手实战手册 ​

这份手册怎么用 ​

贯穿全书的实战项目：星辰电商监控平台 ​

学习路线图 ​

阶段一：认识监控与 Prometheus ​

阶段目标 ​

1.1 监控系统由哪几部分组成 ​

1.1.1 可观测性的三大信号 ​

1.1.2 数据从哪来、怎么采 ​

1.1.3 数据为什么要存进"时序数据库" ​

1.2 监控些什么、用什么标准衡量 ​

1.2.1 监控的三大类内容 ​

1.2.2 衡量服务好坏：四个黄金指标 ​

1.3 监控的三种实现路子 ​

1.4 正式认识 Prometheus ​

1.4.1 它是什么 ​

1.4.2 最核心特点一：拉（Pull）模式 ​

1.4.3 最核心特点二：指标名 + 标签的数据模型 ​

1.4.4 Job 和 Instance ​

1.4.5 指标的文本长什么样 ​

1.5 Prometheus 全家桶成员 ​

1.6 架构与数据流向 ​

本阶段概念速查表 ​

本阶段常见坑与解决 ​

Prometheus 实战 01：入门与监控基础

Prometheus 从 0 到 1 新手实战手册

这份手册怎么用

贯穿全书的实战项目：星辰电商监控平台

学习路线图

阶段一：认识监控与 Prometheus

阶段目标

1.1 监控系统由哪几部分组成

1.1.1 可观测性的三大信号

1.1.2 数据从哪来、怎么采

1.1.3 数据为什么要存进"时序数据库"

1.2 监控些什么、用什么标准衡量

1.2.1 监控的三大类内容

1.2.2 衡量服务好坏：四个黄金指标

1.3 监控的三种实现路子

1.4 正式认识 Prometheus

1.4.1 它是什么

1.4.2 最核心特点一：拉（Pull）模式

1.4.3 最核心特点二：指标名 + 标签的数据模型

1.4.4 Job 和 Instance

1.4.5 指标的文本长什么样

1.5 Prometheus 全家桶成员

1.6 架构与数据流向

本阶段概念速查表

本阶段常见坑与解决