监控基础概念：指标、标签、样本、时间序列、拉取模型与推送模型的区别，以及监控系统的分层架构
在进入 Prometheus 与 Grafana 的具体操作之前，必须先建立一套统一的监控语言。很多初学者直接跳入 PromQL 查询或 Dashboard 设计，却对底层数据模型缺乏理解，导致后续在配置告警规则、设计采集任务时频繁返工。本章将围绕监控系统的五个核心概念——指标、标签、样本、时间序列——以及两种数据采集模型（拉取与推送）和监控分层架构展开，帮助你建立从数据采集到业务可观测性的完整认知框架。
2.1 指标与标签：监控数据的原子单位
核心原理：指标（Metric）是监控系统描述被观测对象某一量化特征的名称，例如 http_requests_total 表示 HTTP 请求总数，node_cpu_seconds_total 表示 CPU 累计使用秒数。指标本身只定义了“测什么”，而标签（Label）则定义了“从哪个维度测”。标签是键值对，例如 method="GET"、instance="10.0.0.1:9100"。在 Prometheus 中，指标名与一组标签共同构成一个时间序列的唯一标识。
判断方法：设计指标时，应遵循以下原则：
- 命名规范：使用
namespace_subsystem_name_unit_suffix格式，例如node_network_receive_bytes_total。 - 标签基数控制：标签的取值组合数量称为基数。高基数标签（如
user_id）会导致时间序列数量爆炸，应避免。 - 标签语义明确：标签应描述不变的维度（如实例、方法、状态码），而非易变的值（如当前 CPU 使用率）。
orders_created_total 配合标签 status="success" 与 status="failed"，可以分别统计成功与失败订单数。若再增加 region="cn-north-1" 标签，则可按地域维度分析。但若将 order_id 作为标签，则每个订单都会产生一条独立时间序列，这属于典型的标签滥用。
api_count，然后试图用标签区分所有接口。这会导致查询时 PromQL 表达式冗长且难以维护。正确做法是：将不同业务含义的指标拆分为多个独立指标，标签仅用于细分同一指标的维度。
2.2 样本与时间序列：数据存储的基本形态
核心原理：样本（Sample）是时间序列中的一个数据点，由三部分组成：指标名、标签集合、时间戳和值。例如 http_requests_total{method="GET"} @ 1710000000 = 1024。时间序列（Time Series）则是同一指标名与同一标签集合下，按时间顺序排列的样本集合。Prometheus 的 TSDB（时间序列数据库）以时间序列为基本存储单元，每个序列独立存储，支持高效的范围查询。
操作流程：理解样本与时间序列的关系，是掌握 PromQL 的基础。查询时，PromQL 首先根据指标名和标签匹配器筛选出目标时间序列，然后对这些序列执行聚合、速率计算等操作。例如：
# 查询所有 GET 请求的速率（5分钟窗口）
rate(http_requests_total{method="GET"}[5m])上述查询会先找到所有 method="GET" 的序列，再计算每个序列的每秒增长率。
| 概念 | 定义 | 示例 | 存储方式 |
|---|---|---|---|
| 指标 | 被观测对象的量化特征名称 | node_memory_usage_bytes | 元数据 |
| 标签 | 描述指标维度的键值对 | instance="192.168.1.1:9100" | 索引 |
| 样本 | 单个数据点（值+时间戳） | @1710000000 = 8388608 | 数据块 |
| 时间序列 | 同一指标+标签组合的样本集合 | node_memory_usage_bytes{instance="..."} | 独立存储单元 |
2.3 拉取模型与推送模型：两种采集哲学
核心原理：Prometheus 默认采用拉取（Pull）模型：Prometheus 服务器定期（默认 15 秒）向目标暴露的 HTTP 端点（如 /metrics）发起请求，获取当前样本值。推送（Push）模型则相反，由被监控对象主动将数据推送到中间网关（如 Pushgateway），再由 Prometheus 从网关拉取。
对比分析：两种模型各有适用场景，选择不当会导致监控盲区或资源浪费。
| 维度 | 拉取模型 | 推送模型 |
|---|---|---|
| 目标状态感知 | 拉取失败即视为目标离线 | 无法感知目标是否存活 |
| 生命周期 | 适合长期运行的服务 | 适合短任务、批处理作业 |
| 网络要求 | Prometheus 需能访问目标端口 | 目标需能访问网关 |
| 数据一致性 | 同一时刻所有目标被同时抓取 | 数据到达时间不确定 |
| 扩展性 | 通过服务发现自动添加目标 | 需手动管理网关中的指标 |
案例拆解：某公司有一个定时运行的数据清洗任务，每次运行约 10 分钟。若采用拉取模型，任务结束后 Prometheus 将无法抓取到数据，导致监控断档。此时应使用推送模型：任务启动时向 Pushgateway 推送开始时间，结束时推送处理行数与耗时。Prometheus 只需从 Pushgateway 拉取即可获得完整数据。
push_time_seconds 等指标判断数据新鲜度。
2.4 监控系统的分层架构：从采集到消费
核心原理：一个完整的监控系统通常分为四层：数据采集层、存储与计算层、告警与通知层、可视化与消费层。理解分层架构有助于在故障时快速定位问题环节，也有助于规划监控系统的扩展方向。
各层职责与关键组件：
- 数据采集层：负责从各种来源收集指标。常见组件包括 Node Exporter（主机指标）、MySQL Exporter（数据库指标）、cAdvisor（容器指标），以及应用内嵌的 Prometheus SDK。
- 存储与计算层：Prometheus 服务器本身承担此角色。它负责抓取数据、压缩存储到本地 TSDB，并通过 PromQL 提供查询与计算能力。对于大规模场景，可引入 Thanos 或 VictoriaMetrics 实现长期存储与高可用。
- 告警与通知层：Prometheus 根据告警规则评估指标，触发告警后发送给 Alertmanager。Alertmanager 负责去重、分组、路由，并通过邮件、钉钉、Webhook 等方式通知运维人员。
- 可视化与消费层：Grafana 是此层的核心，通过数据源连接 Prometheus，将查询结果渲染为图表、仪表盘。此外，API 接口也可供其他系统消费监控数据。
实战场景：假设某微服务架构出现响应时间飙升。排查路径如下：
- 首先在 Grafana 查看服务整体 QPS 与延迟面板，确认问题范围。
- 然后通过 PromQL 按实例标签拆分，定位到具体 Pod。
- 接着检查该实例的 CPU、内存、网络指标，判断是否为资源瓶颈。
- 最后查看告警历史，确认是否有相关告警被触发或遗漏。
这一过程体现了分层架构的价值：采集层保证数据完整，存储层提供快速查询，告警层提前发现问题，可视化层辅助快速定位。