可观测性三支柱落地实践——日志、指标与链路追踪的协同之道

为什么可观测性如此重要

在单体应用时代，我们靠 tail -f 看日志就能定位问题。但微服务架构下，一次请求可能横跨十几个服务，传统排查手段彻底失效。可观测性（Observability） 成为现代分布式系统的刚需。

业界公认的可观测性三大支柱是：Logging（日志）、Metrics（指标）、Tracing（链路追踪）。三者并非孤立，而是相互关联、协同工作的。

三支柱的定位与差异

关键认知：指标告诉你"出问题了"，链路追踪告诉你"哪里出问题了"，日志告诉你"为什么出问题"。

落地架构设计

一个成熟的可观测性平台通常包含：

应用层 → OpenTelemetry SDK → Collector → 后端存储 → 可视化
                                    ├── Prometheus (指标)
                                    ├── Loki (日志)
                                    └── Tempo (追踪)
                                          ↓
                                      Grafana (统一展示)

OpenTelemetry（OTel） 已成为事实标准，它统一了三大支柱的 SDK 和协议（OTLP），避免了厂商锁定。

关键实践一：统一 TraceID 贯穿三支柱

这是三支柱协同的核心。做法是：

1. 在入口处生成或透传 trace_id
2. 日志中自动注入 trace_id 字段
3. 指标中通过 exemplar 关联 trace
4. 链路追踪中记录 span 上下文

在 Go 中的示例：

// 从 context 中提取 trace_id 注入日志
func LogWithTrace(ctx context.Context, msg string) {
    span := trace.SpanFromContext(ctx)
    traceID := span.SpanContext().TraceID().String()
    slog.Info(msg, "trace_id", traceID)
}

这样在 Grafana 中，从指标异常点可以直接跳转到对应 trace，再从 trace 跳转到相关日志，形成闭环。

关键实践二：合理的采样策略

全量采集链路追踪的成本极高。推荐策略：

• 头部采样（Head-based）：在 SDK 层按比例采样，简单但可能丢失关键错误链路
• 尾部采样（Tail-based）：在 Collector 层根据规则采样，保留所有错误和慢请求，成本更高但更精准
• 混合策略：常规请求 1% 采样，错误请求 100% 保留，慢请求按延迟阈值采样

OpenTelemetry Collector 的 tail_sampling processor 支持这种复杂规则。

关键实践三：指标的分层设计

避免"指标爆炸"，需遵循：

1. RED 方法（服务层）：Rate（请求速率）、Errors（错误率）、Duration（延迟）
2. USE 方法（资源层）：Utilization（利用率）、Saturation（饱和度）、Errors（错误）
3. 标签基数控制：避免将 user_id 这类高基数标签放入指标，改用日志或 trace 记录

# 典型告警规则：P99 延迟超过 500ms
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)
) > 0.5

关键实践四：日志分级与结构化

• 结构化日志：使用 JSON 格式，字段固定（timestamp、level、service、trace_id、message）
• 分级策略：ERROR 全量、WARN 全量、INFO 采样、DEBUG 按需开启
• 敏感信息脱敏：在采集层过滤手机号、身份证等 PII 数据

成本控制

可观测性最大的痛点是成本。几个实用建议：

1. 冷热分离：7 天内热存储（SSD），30 天以上转冷存储（对象存储）
2. 日志降噪：过滤健康检查、静态资源等无价值日志
3. 指标降精度：原始数据保留 15 天，降采样后保留 1 年
4. 按团队/服务分摊成本：让成本可见，倒逼优化

总结

可观测性不是买一套工具就能解决的，而是需要从架构设计、埋点规范、采样策略到成本控制的系统性工程。三支柱的价值在于协同——通过统一的 TraceID 和 OTel 标准，让日志、指标、追踪形成一个可互相跳转、互相印证的有机整体。

落地建议：从小处着手，先在一个核心服务上跑通三支柱联动，形成标准模板后再推广到全公司。切忌一开始就追求大而全的平台建设。