Log Metric Trace

解决什么问题：生产系统黑盒化 = 出问题找不到原因。Log + Metric + Trace = 可观测性三大支柱，覆盖"发生了什么 / 现在怎么样 / 哪一步慢"。

它是什么

可观测性（Observability） 的三大支柱（Peter Bourgon 2017 提出）：

支柱	回答	形态	例子
Log	发生了什么	离散事件文本	User 123 placed order 456
Metric	现在怎么样	数值时间序列	qps=1200, p99=230ms
Trace	哪一步慢	请求链路树	gateway→order→payment (230ms)

SE@G Ch 22："Logs, metrics, and traces are the three pillars of observability—each captures a different dimension of system behavior."

V2 视角（V2.7 B5 反馈）：三支柱 = 控制论"状态观测" 的三种粒度——点（log）/ 聚合（metric）/ 路径（trace）。

关键属性

属性	值/含义
Log	结构化（JSON）、带 traceId、级别分明
Metric	Counter / Gauge / Histogram / Summary
Trace	Span 树、传播 context（OpenTelemetry）
采样	Metric 全采 / Log 关键采 / Trace 头采样
反模式	只看 log 不看 metric / 字符串拼接 log
核心约束	三支柱互相关联（同 traceId 串起来）
判错标准	出问题靠 SSH 登机器 = 观测失效

怎么用

场景 1：结构化 Log（JSON + traceId）

log.info("order.placed",
    kv("orderId", order.id()),
    kv("customerId", order.customerId()),
    kv("amount", order.total()),
    kv("traceId", MDC.get("traceId")));

关键：结构化 log = 可查询——可以按 orderId 过滤、按 amount > 1000 过滤。

场景 2：业务 Metric（不只是系统 metric）

// Prometheus 风格
Counter.builder("orders_placed_total")
    .tag("channel", order.channel())
    .register(meterRegistry)
    .increment();

Histogram.builder("order_processing_duration")
    .register(meterRegistry)
    .record(duration);

关键：业务 metric 比系统 metric 更重要——orders_placed_total 比 cpu_usage 直接反映业务状态。

场景 3：分布式 Trace（OpenTelemetry）

// 自动 instrumentation 或手动
Span span = tracer.spanBuilder("placeOrder").startSpan();
try (Scope scope = span.makeCurrent()) {
    Order order = orderService.place(cmd);
    span.setAttribute("order.amount", order.total().toString());
} catch (Exception e) {
    span.recordException(e);
    span.setStatus(StatusCode.ERROR);
} finally {
    span.end();
}

关键：trace 必须跨服务传播 traceId——否则链路断裂。

常见误区

1. "Log 越多越好"——错。日志 = 成本 + 噪音。关键事件 + 错误 才打 log
2. "Metric = 业务 + 系统全打"——错。Metric 基数（cardinality）有限——userId 当 tag = 爆炸
3. "Trace 全采"——错。Trace 存储贵——头采样 + 错误全采 是常见策略
4. "三支柱割裂"——错。三支柱用 traceId 串联——从 metric 异常跳到 log、从 log 跳到 trace
5. "可观测性 = 监控"——错。监控是被动告警，可观测性是主动调试能力——出问题能查 = 可观测

关键洞察

Log Metric Trace = 控制论观测的三种粒度——点/聚合/路径 = 状态的不同切片。

控制论视角：观测 = 控制的前提。没观测 = 没控制——三支柱是观测的最小完备集。 IDDD Ch 13 视角：BC 之间的集成必须带 traceId——跨 BC 调用链可视化是 BC 自治的保障。 SE@G Ch 22-23 视角：Google 强调USE（Utilization/Saturation/Errors）和 RED（Rate/Errors/Duration）方法——三支柱配套使用。 EDM Ch 11 视角：事件系统的 producer/consumer 必须有独立的 metric——跨系统延迟不可见就是不可观测。

相关链接

• Tracking——业务维度的可观测性
• Single Writer Principle——状态观测的去重
• [V3 涌现作为] · 反馈——三支柱 = 反馈通道
• [V3 涌现视域] · 认识对象——观测是认识系统的前提
• 源典：SE@G Ch 22-23——三支柱工程实践
• 源典：控制论 Ch 1——状态观测的理论基础