可观测性三支柱核心机制：Metrics、Trace、Log

本文讲清指标、链路、日志各自解决什么问题、如何靠 OpenTelemetry 打通，以及一套落地方案从选型到成本控制的完整路径。

监控 ≠ 可观测性

监控（Monitoring）：回答"已知会不会坏"——预设好的仪表盘和告警
可观测性（Observability）：回答"unknown-unknowns"——
  系统出了没预料到的问题，能否从外部输出把内部状态"问"出来

判别标准很实用：
  监控给你"CPU 高了"；可观测性能让你追问
  "哪个租户的哪次请求，在哪台机器的哪个依赖上，因为哪条慢 SQL 变慢"

三个信号不是并列的三份数据，而是同一事实的三个投影：
  Metrics 告诉你"有异常" → Trace 告诉你"慢/错在哪一跳" →
  Log 告诉你"具体为什么"
缺一环，排障就从"顺藤摸瓜"退化成"三个系统来回人肉对时间戳"。

Metrics：聚合的数字

数据形态：时间序列 = (指标名 + label 集合) → 随时间的数值
  例：http_requests_total{service="order",code="500",instance="10.1.2.3"} 12743

四类标准类型：
  Counter   只增计数（请求数、错误数）——配 rate() 看每秒增速
  Gauge     可增可减瞬时值（内存、队列长度、在线人数）
  Histogram 按桶计数（延迟分布）——P95/P99 的数据来源，
            可跨实例聚合：各实例各自吐桶，查询时求和再算分位
  Summary   在客户端就地算分位——不能聚合，多实例场景慎选

为什么"高基数"是 Metrics 的头号杀手：
  label 每多一个维度，时间序列条数按乘积爆炸
  把 user_id / 请求 URL 全文塞进 label = 时序库被打爆的经典事故
  原则：Metrics 存"分布与趋势"，个体维度交给 Trace/Log

黄金信号（Google SRE）：延迟 / 流量 / 错误 / 饱和度
  USE 法看资源（Utilization/Saturation/Errors），
  RED 法看服务（Rate/Errors/Duration）——两套互补的检查清单

Trace：一次请求的因果链

数据模型（Dapper / OpenTelemetry）：

Trace = 若干 Span 组成的树，靠 (trace_id, span_id, parent_span_id) 串起
  Span{
    name: "POST /orders"     kind: SERVER
    trace_id: 4bf9...        span_id: f781...   parent: a5d1（网关）
    start / end（微秒）
    attributes: {http.status_code=500, db.statement="INSERT ..."}
    events:   [{exception}, {retry}]
    status:   ERROR
  }

传播（最关键的一环）：
  跨进程时把 traceparent 放进 header：
    traceparent: 00-<trace-id>-<parent-id>-<flags>
  线程/协程内靠上下文对象显式传递，或 Context Variables（异步框架）
  业务字段要随链路走 → baggage（租户ID、发布版本），
  否则"只有这个租户慢"这类问题永远定位不到

采样策略：
  边缘采样（入口决定收不收）：成本低，但可能漏掉"全链路里唯一的错"
  尾部采样（等 Trace 完整结束再决定）：错误/慢全保、正常抽 1%
    → 需要 Trace 汇聚层缓冲整条链路，是主流进阶方案

Log：事件的原文

形态演进：结构化 > 半结构化 > 纯文本
  现代方案：JSON/键值对（level、service、trace_id、message...）
  trace_id 打进每行日志 = 三支柱打通的最便宜手段

日志管线：
  App → 采集 Agent（Filebeat/Fluent Bit/Vector，尾读文件+记录 offset）
      → 缓冲/总线（Kafka，削峰与解耦）
      → 处理（解析、脱敏、富化、丢弃 debug）
      → 存储（ES / ClickHouse / Loki）→ 查询（倒排 or 列存）

存储选型直觉：
  Loki：不索引正文只索引 label，便宜，适合"按服务+时间捞日志"
  ES：  全文检索强，贵，适合需要关键词捞全网日志的场景
  ClickHouse：列存 + 高压缩，分析型日志（按维度聚合排查）性价比极高

纪律：
  1. 别把 DEBUG 开到生产、别在循环里打日志（日志本身能打挂服务）
  2. 必须脱敏（身份证/手机号/token），管道里做而非业务代码里做
  3. 采样日志（如 1% 请求打全量上下文）比全量日志更易存活

OpenTelemetry：三合一的标准

┌──────────────────────────────────────────────────┐
│ 应用：SDK（Java/Go/Python/JS...，自动埋点 agent） │
│   API 层（埋码只依赖接口）→ SDK 层（处理+导出）   │
└───────────────┬──────────────────────────────────┘
                │ OTLP（gRPC/HTTP，统一协议）
        ┌───────▼────────┐
        │ Collector      │  接收→处理（采样/脱敏/批压）→导出
        └───┬───────┬────┴────────┐
            ▼       ▼             ▼
      Prometheus  Tempo/Jaeger  Loki/ES
      (Metrics)    (Trace)      (Log)

价值：
  - 埋点写一次，后端随便换（厂商解耦）
  - Trace 的 span 事件可自动转日志（log-bridge），
    Metrics 的 exemplar 可反向跳进具体 Trace
代价：语义约定要对齐（http.* 旧名 vs http.*.new 命名迁移期），
     自动埋点有性能开销，热点路径用显式埋点补精度

关联：从告警到根因的完整动线

设计目标：每个信号都能"一键跳"到另外两个

Alert(P99>500ms) ──▶ Grafana 面板 ──[exemplar 按钮]──▶ 一条具体 Trace
Trace 的某个 ERROR Span ──[logs_by_trace]──▶ 该请求的全部日志行
日志详情 ──▶ 该实例的指标水位 / 同时间段的其他错误分布

落地要素：
  统一资源属性（service.name、deployment.environment、host、
  k8s.pod.name）——三支柱共用同一套"实体身份证"，这是打通的地基
  告警只从 Metrics 发（Trace/Log 太贵太碎，适合做下钻不适合做哨兵）

实战：落地路线与成本刀法

分阶段路线（别一步到位）：
  阶段1：指标 + 日志 + 基础告警（黄金四信号），先消灭"无数据盲区"
  阶段2：链路接入（HTTP/RPC/DB 三类自动埋点），补 exemplar 打通
  阶段3：尾部采样 + 业务维度下钻（按租户/版本看 RED），SLO 告警
  阶段4：异常检测/容量预测等高级玩法（有数据地基后才谈得上）

成本刀法（可观测性最终死于成本，这是行业共识）：
  Metrics：降采样频率（15s→60s）、histogram 桶数克制、
          高基数 label 上移应用层治理
  Trace： 错误/慢全采 + 正常 0.1%~1% 抽样，Collector 侧丢弃
  Log：   开发级日志不进中心存储（本地滚动即可）、
          管道层按 level+service 做白名单、冷热分层（7天热查，之后归档）
  存储：  按查询频率分层——热（SSD/近 7 天）温（对象存储）冷（归档）

反模式清单：
  仪表盘当作目的（有人看才有意义，半年没人访问的图删掉）
  告警风暴（同根因几十条通知 → 靠 Alertmanager 分组抑制与依赖收敛）
  Trace 只接不采样（全量入仓 = 三个月后存储爆炸被迫切源，前功尽弃）

总结

理解可观测性的核心在于：三支柱是同一份"请求事实"的三种压缩方式——Metrics 压缩成数字、Trace 保留因果骨架、Log 保留细节原文；工程成败的关键不在选哪个工具，而在统一资源语义把三者串成"告警→链路→日志"的下钻动线，并用采样与分层把成本压到查得起的范围内。