📚 课程目录第1章 Metric基础概念

1. Metric 基础概念：从黄金信号到可观测性基石

在构建可观测性体系时，Metric（指标）是最核心、最轻量的数据基石。它通过数值化的方式描述系统在某一时刻或时间窗口内的状态，是告警、自动伸缩、容量规划等运维动作的直接依据。理解 Metric 的本质及其与 Log、Trace 的关系，是设计精准告警阈值的前提。

1.1 什么是 Metric

Metric 是一组带时间戳的数值序列，通常由 名称（Name）、标签（Labels/Tags）、值（Value） 和 时间戳（Timestamp） 四要素构成。它回答的是“系统现在怎么样”的问题，例如：http_requests_total{method="GET", status="200"}。

要素	说明	示例
名称	指标的唯一标识，通常使用命名空间	`http_requests_total`
标签	维度信息，用于多维度聚合与筛选	`method="POST"`, `status="500"`
值	数值类型，可以是 Counter、Gauge、Histogram 等	`1024`
时间戳	采集时间点，精度通常为毫秒	`1710000000`

设计要点：Metric 的标签设计决定了后续聚合的灵活性。每个标签值组合都会产生一条独立的时间序列，过多的标签基数（Cardinality）会导致存储爆炸，需在维度丰富度与性能之间做权衡。

1.2 四大黄金信号

Google SRE 经典著作中提出的四大黄金信号，是衡量用户侧体验与系统健康度的核心维度。任何告警阈值的设计都应围绕这四个信号展开，避免盲目监控。

1.2.1 延迟（Latency）

请求从发出到收到完整响应所消耗的时间。延迟直接影响用户体验，通常用 P50/P95/P99 分位数来衡量。告警阈值应关注高百分位（如 P99 > 500ms），而非平均值。

1.2.2 流量（Traffic）

系统承载的请求量或数据吞吐量。对于 Web 服务，常用 QPS（每秒请求数） 或 RPS（每秒速率）；对于消息队列，则是 吞吐量（bytes/s）。流量突增或突降都是告警信号。

1.2.3 错误（Errors）

请求失败的比率。包括显式错误（HTTP 5xx）、隐式错误（返回 200 但业务逻辑失败）、以及因超时或熔断导致的失败。建议使用 错误率（Error Rate） 而非错误数作为告警指标。

1.2.4 饱和度（Saturation）

系统资源被占用的程度，通常反映“还有多少余量”。典型指标包括 CPU 使用率、内存占用、磁盘 I/O 队列深度、连接池使用率等。饱和度达到 100% 通常意味着服务即将不可用。

  实战建议：设计告警阈值时，优先选择与用户体验直接相关的延迟和错误信号；流量和饱和度更多用于容量规划与异常检测。例如：当 P99 延迟 > 1s 且错误率 > 5% 时触发 P0 告警。

1.3 Metric 与 Log / Trace 的关系

在可观测性“三大支柱”中，Metric、Log、Trace 各自承担不同角色，又相互补充。理解它们的关系，有助于在告警设计中选择正确的数据源。

维度	Metric	Log	Trace
数据形态	数值序列，轻量、聚合	文本事件，详细、非结构化	请求链路，结构化、有向图
核心问题	系统现在怎么样？	系统发生了什么？	请求经历了什么？
存储成本	低（采样聚合）	高（全文索引）	中（采样存储）
告警适用性	强（实时阈值、趋势检测）	中（关键词匹配、异常模式）	弱（延迟分析、依赖故障定位）
典型工具	Prometheus, Grafana	ELK, Loki	Jaeger, Zipkin

三者协同的典型流程：Metric 告警 → 查看 Trace 定位故障服务 → 查看 Log 获取错误详情。Metric 负责“发现问题”，Trace 负责“定位问题”，Log 负责“排查根因”。

常见误区：不要试图用 Log 替代 Metric 做实时告警。Log 的写入延迟和存储成本远高于 Metric，且难以做多维度聚合。正确的做法是：用 Metric 做实时阈值检测，用 Log 做事后分析和上下文补充。

1.4 本章小结

Metric 是数值化的时间序列，由名称、标签、值、时间戳构成，标签设计直接影响聚合能力。
四大黄金信号（延迟、流量、错误、饱和度）是告警阈值设计的核心维度，优先关注延迟和错误。
Metric / Log / Trace 三者互补：Metric 负责发现，Trace 负责定位，Log 负责排查。
在后续章节中，我们将基于这些基础概念，深入讲解如何通过多维度聚合来优化告警阈值的精准度。