本篇是《Prometheus 从入门到生产实践》第 1 / 24 篇。配置以文中版本与环境前提为准，实验和故障均为教学场景。完整程序、配置及校验范围见配套实验包。
Prometheus 是围绕指标时间序列构建的监控系统。它适合回答“现在是否异常、异常持续多久、最近的趋势是什么”，并能把条件转成告警。学习它，需要同时理解数据从哪里来、怎样计算、怎样通知，以及系统自身怎样可靠运行。
1. 先区分指标、日志和链路
指标是随时间变化的数值，例如每秒请求数、当前内存、延迟分布；日志记录事件细节；链路把一次请求经过的服务关联起来。指标适合聚合和持续观察，但通常不能保留每个用户和每次请求的完整细节。
Prometheus 不是日志搜索引擎，也不应把每个订单号变成标签来模仿事件数据库。故障时可以先用指标缩小范围，再进入日志或链路追踪寻找原因。整体能力和适用范围见 官方概览。
2. 一条监控链路有哪些部件
| 部件 | 职责 | 常见误解 |
|---|---|---|
| 应用与 exporter | 暴露可抓取指标 | 安装 exporter 不会自动让 Prometheus 找到它 |
| 服务发现 | 提供候选目标及元数据 | 被发现不代表已成功采集 |
| Prometheus | 抓取、存储、查询、规则求值 | 单机本地存储不是分布式数据库 |
| Alertmanager | 通知路由、分组、静默、抑制 | firing 不等于人已经收到消息 |
| Grafana 等界面 | 展示查询和交互分析 | 漂亮图表不能弥补错误指标和查询 |
典型流程是应用暴露 /metrics，Prometheus 定期拉取；PromQL 从存储查询；规则求值生成告警；Alertmanager 决定如何通知。Pushgateway、remote_write 和 OTLP 属于其他数据流，不能简单理解为主采集路径全部变成推送。
3. 为什么以拉取为主
抓取方掌握周期、超时和目标状态，便于统一判断一次采集是否失败。应用只需要暴露端点，通常无需知道监控服务器在哪。
拉取并不消除网络问题。抓取端需要能够到达目标，认证、证书、命名空间和代理都影响结果。Prometheus 运行在容器时，它看到的 localhost 属于容器环境，而不是宿主机。
up=1 表示相应目标最近一次抓取成功；up=0 表示抓取失败。业务接口可能仍有故障，或者目标已从发现中消失、查询根本没有结果。因此不能把所有健康判定都压缩成一个 up。
4. 这套教程怎样由浅入深
前六篇建立实验、数据模型、业务指标、exporter 和服务发现；第七到十二篇学习 PromQL、直方图、匹配、性能和 SLO；十三到十八篇打通告警、安全和 Kubernetes；最后六篇进入 TSDB、容量、HA、远程存储及生产验收。
每篇有图解、命令或配置、预期、排错点和练习。示例以 Prometheus 3.x 的常见能力为基础；可选特性、发行版和插件行为要按实际版本核对，不能把 latest 文档中的新字段原样交给旧二进制。
5. 统一实验环境与边界
实验使用本机 Prometheus 19090、教学 exporter 19100、Alertmanager 19093、webhook 18085，均限制在回环地址。默认 5 秒抓取和求值用于快速观察，不是生产环境统一推荐值。
教学业务指标固定为 ops_demo_requests_total、ops_demo_request_duration_seconds 和 ops_demo_inflight_requests。路由标签固定 /api，状态码只有 200、500，避免一边学习一边制造高基数。
配套包包含程序、配置和规则测试：下载完整示例与教学数据。先独立建立练习目录，保留现有监控配置；后面的配置片段和完整文件会分别说明。本文中的故障是教学情境，不冒充真实事故记录。
6. 学完之后如何自我验收
你应能解释一条曲线的指标定义、单位、标签和时间窗口；能用已知输入验证请求率、错误率和延迟；能追踪一条告警从条件成立到消息恢复；能描述容量与高可用的故障边界。
练习：画出你现有业务的指标链路，标明谁暴露、谁发现、谁抓取、谁存储、谁发送通知。每画一条箭头，就写明地址、协议和身份，这会成为以后排查的起点。
本篇为系列起点 · 系列目录 · 下一篇：安装与完整实验：从进程启动到真正采集成功