可观测性三支柱

监控 vs 可观测

监控（Monitoring）：你已经知道要看哪些指标 → 设阈值 → 告警
可观测（Observability）：系统出了没预料的状况 → 你能不能从数据里推出根因

可观测是监控的超集。三支柱（Metrics / Logs / Traces）是 2017 年前后由 Peter Bourgon 等人推广的常用切分法。

三支柱速览

	Metrics（指标）	Logs（日志）	Traces（链路）
数据形态	时序数字（counter / gauge / histogram）	时间戳 + 文本（最好结构化）	一个请求经过多个服务的有向图
回答的问题	"现在系统长什么样"	"刚才发生了什么"	"这个慢请求慢在哪"
典型工具	Prometheus / VictoriaMetrics	ELK / Loki / Splunk	Jaeger / Tempo / Zipkin
存储成本	低（高度压缩）	中-高（全文索引贵）	中（采样后可控）
查询性能	极快	中（取决于索引）	中
最适合	仪表板 / 告警	故障排查 / 审计	性能分析 / 微服务关联
保留周期	长（月-年）	中（周-月）	短（天-周）+ 采样

三者的关系：不是分层，是视角

同一个事件可以用三种方式记录：

HTTP 请求 GET /api/users
    ↓
Metrics:  http_requests_total{method="GET", path="/api/users"} +1
          http_request_duration_seconds histogram observation
    ↓
Logs:     {ts:..., level:info, method:GET, path:/api/users, status:200, duration:42}
    ↓
Traces:   span "GET /api/users" → "auth.check" → "db.users.find"

每种数据回答不同问题。好的可观测系统三者都有，且能互相跳转：

指标看到 5 分钟前 p99 飙升 → 跳到这段时间的 logs / traces
traces 找到一个慢 span → 看那时间窗口该服务的 metrics

高基数（High Cardinality）问题

把每个用户 ID 当成一个 metrics 标签 → 有 100 万用户 → 100 万条独立时序 → 存储爆掉

Metrics 的痛点：标签维度组合越多，存储成本越爆炸。所以 metrics 上不能放高基数字段（user_id / session_id / request_id 等）。

这些信息放哪？→ Logs 或 Traces。让数据的形态对齐它的用途。

"可观测性 2.0"思潮

2020 起 Honeycomb 等公司提倡：用结构化高基数事件（structured events）替代三支柱——一个事件里带足够多字段，事后切片就能得到 metrics / logs / traces 的效果。

实操还没成主流，但结构化日志的潮流已经回流了——传统三支柱也在变得更"事件化"。

数据保留策略

通常做法：

热（hot）：最近几天 / 周，全保留、可查
温（warm）：最近几周 / 月，只保聚合 / 采样
冷（cold）：归档到对象存储，几乎不查（合规 / 审计才动）

每一层成本递降几个数量级。

反模式

只有 metrics 没有 logs：故障排查靠猜
只有 logs 没有 metrics：仪表板做不出来
logs 全是非结构化文本：grep 找一找就完事的态度，规模一大就崩
traces 100% 采样：高 QPS 服务直接撑爆 trace 后端
三套独立工具，跳转要复制粘贴：故障时人会崩