1. Metric 设计基础
1.1 什么是 Metric
Metric（指标） 是系统在某一时刻或某一时间窗口内可量化的观测数据，通常由 名称、标签（Label）、时间戳 和 数值 四部分组成。它是可观测性三大支柱（Metric、Log、Trace）中最适合做 聚合分析 和 告警阈值判断 的数据类型。
核心特征：Metric 是数值型、可聚合、可降采样、可长期存储的时序数据。它回答的是“系统现在怎么样”和“系统过去一段时间怎么样”的问题。
| 组成部分 | 说明 | 示例 |
|---|---|---|
| Metric Name | 指标名称，唯一标识一类测量 | http_requests_total |
| Labels | 维度标签，用于分组和过滤 | method="GET", status="200" |
| Timestamp | 数据采集时间点 | 1710000000 |
| Value | 测量数值（整数或浮点数） | 1024 |
1.2 Metric 的四大黄金信号
Google SRE 经典著作《Site Reliability Engineering》中定义了 四大黄金信号（Four Golden Signals），它们是衡量用户侧和系统侧健康度的核心维度：
- 延迟（Latency） — 请求处理耗时，区分成功请求与失败请求的延迟。
- 流量（Traffic） — 系统承载的请求量或数据吞吐量。
- 错误（Errors） — 显式错误（HTTP 5xx）与隐式错误（返回成功但结果错误）。
- 饱和度（Saturation） — 资源使用程度，越接近上限越危险。
实战建议：告警规则应优先覆盖四大黄金信号。如果只能选 3 个指标做告警，优先选延迟、错误、饱和度；流量通常用于容量规划而非直接告警。
| 黄金信号 | 典型 Metric 示例 | 聚合方式 | 告警阈值参考 |
|---|---|---|---|
| 延迟 | http_request_duration_seconds |
P50 / P90 / P99 分位数 | P99 > 500ms 持续 5min |
| 流量 | http_requests_total |
速率（rate / irate） | 同比突增 > 300% |
| 错误 | http_requests_total{status=~"5.."} |
错误率 = 错误数 / 总请求数 | 错误率 > 1% 持续 3min |
| 饱和度 | node_memory_MemAvailable_bytes |
使用率 = 1 - 可用量 / 总量 | 使用率 > 85% |
1.3 Metric 与 Log / Trace 的关系
在可观测性体系中，Metric、Log、Trace 三者并非孤立存在，而是 相互补充、交叉验证 的关系。理解它们的关系是设计高质量告警策略的前提。
| 维度 | Metric | Log | Trace |
|---|---|---|---|
| 数据形态 | 时序数值 | 非结构化/半结构化文本 | 有向无环图（Span 链） |
| 核心用途 | 聚合监控、告警阈值 | 故障根因定位、审计 | 请求链路追踪、性能瓶颈 |
| 存储成本 | 低（可降采样） | 高（全文索引） | 中（采样存储） |
| 告警适用性 | ★★★★★ | ★★☆☆☆ | ★★★☆☆ |
| 典型工具 | Prometheus, VictoriaMetrics | ELK, Loki | Jaeger, Zipkin |
常见误区：不要试图用 Log 做高频告警阈值判断。Log 适合关键词匹配和模式发现，但无法高效计算 P99 延迟或错误率。正确的做法是：Metric 负责告警触发，Log 负责告警确认，Trace 负责告警定位。
1.4 Metric 设计的关键原则
- 面向用户设计：优先采集用户可感知的指标（如 API 延迟、错误率），而非仅关注基础设施指标。
- 标签维度可控：避免高基数标签（如 user_id、request_id），防止时序数据库膨胀。
- 标准化命名：遵循
namespace_measure_unit格式，例如http_request_duration_seconds。 - 聚合粒度分层：原始指标保留高精度（如 10s 粒度），长期存储降采样（如 5min 粒度）。
- 与告警阈值对齐：每个 Metric 设计时就要考虑“这个指标如果异常，阈值应该设多少”。
降噪前置思考：好的 Metric 设计本身就是告警降噪的第一步。如果指标定义模糊、标签爆炸、聚合粒度混乱，后续的告警规则无论如何优化都会产生大量误报和重复告警。