1. 可观测性基础：概念、三大支柱与 OTel 项目
1.1 什么是可观测性
可观测性（Observability）源自控制理论，指通过系统外部输出来推断内部状态的能力。在软件工程中，可观测性意味着不依赖新增代码或重启服务，仅通过分析 Metrics、Logs、Traces 三类数据就能理解系统行为、定位故障根因。
核心公式： 可观测性 = Metrics + Logs + Traces + 关联分析能力
传统监控（Monitoring）关注已知故障模式（如 CPU > 90%），而可观测性面向未知问题——当系统出现从未见过的异常时，工程师仍能通过三类数据的交叉关联快速定位根因。
| 维度 | 传统监控 | 可观测性 |
|---|---|---|
| 关注点 | 已知故障模式 | 未知问题探索 |
| 数据源 | 单一指标 | Metrics + Logs + Traces |
| 故障定位 | 告警 → 人工排查 | 关联分析 → 自动根因 |
| 扩展性 | 需预定义规则 | 数据驱动，动态探索 |
1.2 三大支柱：Metrics、Logs、Traces
三大支柱各自解决不同层面的可观测性问题，只有三者协同才能构建完整的可观测性体系。
Metrics（指标）
- 特点：数值型、可聚合、低存储成本、适合长期趋势分析
- 典型场景：服务健康检查、容量规划、SLO 监控、告警触发
- 常见工具：Prometheus、Grafana、CloudWatch Metrics
Logs（日志）
- 特点：结构化或非结构化文本、高信息密度、存储成本高
- 典型场景：错误排查、审计合规、业务行为分析
- 常见工具：ELK Stack、Loki、Splunk
Traces（链路）
- 特点：请求级端到端视图、Span 树结构、分布式上下文传播
- 典型场景：性能瓶颈定位、依赖关系分析、分布式事务追踪
- 常见工具：Jaeger、Zipkin、Tempo
最佳实践：三大支柱不是孤立的。通过 TraceID 将 Logs 与 Traces 关联，通过 Metrics 聚合 Trace 延迟分布，才能实现真正的可观测性。
1.3 OpenTelemetry 项目简介
OpenTelemetry（简称 OTel）是 CNCF 孵化项目，旨在提供统一、厂商中立的可观测性数据采集标准。它合并了 OpenTracing 和 OpenCensus 两个项目，成为可观测性领域的事实标准。
OTel 核心能力
| 能力 | 说明 | 典型组件 |
|---|---|---|
| 统一数据模型 | 定义 Metrics、Logs、Traces 的标准数据结构 | OTel Protocol (OTLP) |
| 多语言 SDK | 支持 Java、Go、Python、JS、.NET 等主流语言 | 语言 SDK + API |
| 自动埋点 | 通过字节码增强或中间件自动采集 | Java Agent、Python Instrumentation |
| Collector 管道 | 数据接收、处理、导出，支持批量和重试 | OTel Collector |
| 厂商中立 | 可导出到 Prometheus、Jaeger、Datadog 等任意后端 | Exporters 插件 |
为什么选择 OTel
- 统一标准：一套 SDK 采集三类数据，无需维护多个 Agent
- 社区活跃：CNCF 顶级项目，贡献者超 1000 人，企业支持广泛
- 灵活导出：Collector 支持 50+ 后端，切换成本极低
- 上下文传播：内置 W3C TraceContext 标准，跨服务链路自动关联
- Mock 友好：OTel SDK 提供测试工具，支持 Mock SpanExporter 和 MetricReader
注意：OTel 只负责数据采集和导出，不包含可视化或告警引擎。你需要搭配 Grafana、Prometheus Alertmanager 等工具完成完整可观测性闭环。
1.4 三大支柱与 OTel 的关联
OTel 将三大支柱统一到同一个数据管道中，通过 OTLP 协议传输，并利用 TraceID 实现跨支柱关联。例如：
- 一个 Trace 中的某个 Span 出现错误 → 自动关联该 Span 对应的 Error Log
- Metrics 中的高延迟 P99 指标 → 下钻到具体 Trace 查看慢 Span 详情
- Logs 中的异常堆栈 → 通过 TraceID 找到完整的请求链路上下文