云原生微服务全链路可观测性：OpenTelemetry 与 Prometheus 实践

随着单体系统向微服务架构演进，一次用户请求可能经过 API 网关、认证中心、订单服务、支付微服务及多个消息队列的复杂串联。传统靠 SSH 登录单机 grep error.log 的运维方式完全失效，全链路可观测性（Observability）成为了系统的核心底座。

1. 可观测性的三大支柱

• Metrics (度量指标)：聚合统计数据（如每秒请求量 QPS、P99 延迟、CPU/内存占用率），适合用来发现“系统是否出故障了”。常用组件：Prometheus。
• Tracing (分布式追踪)：追踪单个请求跨越多个节点调用的全生命周期 Span，精确定位“故障具体出在哪一步”。常用标准：OpenTelemetry / Jaeger。
• Logs (日志)：带有离散时间戳的详细上下文记录，解答“这步为什么会报错”。常用组件：Loki / ELK。

2. 为什么选择 OpenTelemetry (OTel)？

过去业界存在 OpenTracing 与 OpenCensus 两大标准，各有生态导致厂商绑定严重。CNCF 将二者合二为一，推出了统一的工业级标准 OpenTelemetry。其最大优势是定义了统一的跨语言 API、SDK 与 OTel Collector 收集代理，避免了对后端存储厂商（如 Jaeger、Datadog、SkyWalking）的代码级强绑定。

# otel-collector-config.yaml 采集器配置示例
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
  otlp/jaeger:
    endpoint: "jaeger:4317"
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp/jaeger]
    metrics:
      receivers: [otlp]
      exporters: [prometheus]

3. 大规模生产环境的采样率控制

在日均上亿请求的系统里，100% 记录 Tracing 数据会带来巨大的网络开销与存储成本。必须实施合理的采样策略：

• 头采样 (Head Sampling)：在请求入口处按百分比（如 5%）决定是否记录链路。
• 尾采样 (Tail Sampling)：在 OTel Collector 层暂存链路，若请求耗时超过 500ms 或产生 HTTP 5xx 错误，则 100% 强制保存，正常快速请求按 1% 保存。这是信噪比最高的高级策略。