1. 课程导学与背景：可观测性、链路追踪与 OpenTelemetry
1.1 什么是可观测性？
可观测性（Observability）是衡量系统内部状态可通过其外部输出推断的程度。在分布式系统中，它通常由三大支柱构成：日志（Logs）、指标（Metrics） 和 追踪（Traces）。
| 支柱 | 定义 | 典型问题 |
|---|---|---|
| 日志 | 离散的、带时间戳的事件记录 | “这个错误发生在什么时候？” |
| 指标 | 可聚合的数值数据（如 QPS、延迟、错误率） | “系统当前负载是否过高？” |
| 追踪 | 端到端的请求链路，记录跨服务的调用关系与耗时 | “这个慢请求到底卡在哪个服务？” |
核心观点：可观测性不是“拥有数据”，而是“无需预知问题就能快速定位根因”的能力。日志、指标、追踪三者互补，缺一不可。
1.2 为什么需要链路追踪？
在单体应用中，一次请求的调用栈清晰可见。但在微服务架构下，一个用户请求可能跨越 5～10 个服务、数十个数据库与缓存实例。当出现“页面加载慢”或“接口超时”时，传统监控只能告诉你“哪个服务慢了”，却无法回答“为什么慢”。
链路追踪（Distributed Tracing）通过为每个请求注入全局唯一的 Trace ID，串联起所有经过的服务节点，形成完整的调用拓扑与时间线。它的核心价值在于：
- 定位瓶颈：精确找出耗时最长的 Span（跨度），是数据库查询、RPC 调用还是序列化操作。
- 还原依赖：自动绘制服务依赖图，发现隐藏的循环调用或异常拓扑。
- 关联数据：将 Trace ID 与日志、指标关联，实现“一键跳转”排障。
真实场景：某 Go Web 服务在高峰期出现 5% 的请求超时。通过链路追踪发现，并非所有服务都慢，而是某个 Redis 缓存节点因热 key 导致响应延迟从 2ms 飙升到 800ms。没有追踪，这种“针尖上的瓶颈”几乎无法定位。
1.3 OpenTelemetry 项目简介与优势
OpenTelemetry（简称 OTel）是 CNCF 的毕业项目，由 OpenTracing 和 OpenCensus 合并而来，旨在提供一套厂商中立、统一标准的可观测性数据采集框架。
它的核心组件包括：
- API：定义 Traces、Metrics、Logs 的数据模型与操作接口。
- SDK：实现 API，提供采样、上下文传播、导出等能力。
- Collector：独立的代理服务，负责接收、处理、导出遥测数据。
- Exporter：将数据发送到后端（如 Jaeger、Zipkin、Prometheus、Datadog）。
选择 OpenTelemetry 的五大优势：
| 优势 | 说明 |
|---|---|
| 统一标准 | 一套 API 覆盖追踪、指标、日志，避免多套 SDK 混用 |
| 厂商中立 | 不绑定任何后端，可随时切换 Jaeger、Zipkin、SkyWalking 等 |
| 多语言支持 | Go、Java、Python、JavaScript 等主流语言均有官方 SDK |
| 自动插桩 | 通过 Instrumentation 库自动拦截 HTTP、gRPC、数据库等常见库 |
| 社区活跃 | CNCF 毕业项目，贡献者众多，迭代迅速 |
1.4 本课程的核心目标
本课程将带领你从零开始，使用 OpenTelemetry Go SDK 为 Go Web 应用构建完整的链路追踪体系。你将学到：
- 如何为 Go HTTP 服务、gRPC 服务、数据库操作添加追踪插桩。
- 如何配置采样策略、上下文传播与 Span 属性。
- 如何搭建 OTel Collector 并导出数据到 Jaeger 进行可视化分析。
- 如何通过链路追踪定位慢查询、慢调用等性能瓶颈。
前置要求：你需要具备 Go 语言基础（熟悉 net/http、context 包），了解微服务基本概念。无需 OpenTelemetry 或链路追踪经验，本课程会从原理到实践逐步讲解。