📚 课程目录第1章课程导论

1. 课程导论：什么是 OpenTelemetry、为什么需要属性与资源元数据注入、课程目标与前置知识

OpenTelemetry（简称 OTel）是一个开源的可观测性框架，旨在为分布式系统提供统一的数据采集、处理和导出标准。它由 OpenTracing 和 OpenCensus 两个项目合并而成，现已成为 CNCF（云原生计算基金会）的毕业项目，也是业界事实上的可观测性标准。

OTel 的核心能力是生成、采集和关联三类可观测性信号：

OTel 通过一套标准化的 API、SDK 和协议，让开发者只需一次埋点，就能将数据发送到任意兼容的后端（如 Prometheus、Jaeger、Grafana、Datadog 等），彻底告别厂商锁定。

  核心优势：统一标准、跨语言支持（Python/Go/Java/JS 等 12+ 语言）、与云原生生态深度集成、社区活跃度极高。

在微服务和云原生环境中，仅仅采集 Traces、Metrics、Logs 的原始数据远远不够。生产环境中的可观测性数据量巨大，如果没有足够的上下文信息，数据就像一堆没有标签的零件——无法快速定位问题。

属性（Attributes） 和 资源元数据（Resource Metadata） 就是给这些数据打上的“标签”和“身份证”。

属性是键值对（Key-Value Pairs），附加在 Span、Metric 或 Log Record 上，用于描述该数据点的具体特征。例如：

资源元数据描述生成数据的实体（如服务、主机、容器、Pod），通常附加在 TracerProvider 或 MeterProvider 上，全局生效。例如：

最佳实践：属性用于区分同一服务内的不同操作细节；资源元数据用于区分不同服务、不同部署环境或不同物理节点。两者结合，才能构建出可过滤、可聚合、可关联的高质量可观测性数据。

场景	无元数据注入	有元数据注入
定位慢请求	只知道某个 Span 耗时 5s，不知道是哪个服务、哪个版本	快速过滤出 `service.version="v2.1"` 的异常 Span
多环境对比	生产与测试数据混在一起，无法区分	通过 `deployment.environment="production"` 一键隔离
故障根因分析	看到错误码，但不知道是哪个 Pod 或 Region 产生的	通过 `k8s.pod.name` 和 `cloud.region` 精准定位

通过本课程，你将掌握以下核心能力：

为了获得最佳学习体验，建议你具备以下基础：

领域	具体要求
编程语言	至少熟悉 Python、Go、Java 中的一种，能阅读简单代码
可观测性基础	了解 Traces、Metrics、Logs 的基本概念，知道 Span 是什么
云原生基础	了解微服务架构、Docker、Kubernetes 的基本术语
工具准备	安装好 Python 3.8+、Go 1.18+、Java 11+ 以及对应的 OTel SDK

注意：本课程不从头讲解 OTel 的安装和基础使用，但会在每章提供必要的代码片段和配置示例。如果你对 OTel 完全陌生，建议先阅读官方快速入门文档。

下图展示了属性与资源元数据在 OTel 数据流中的位置和注入方式：

从全景图可以看出：应用代码通过 OTel SDK 注入属性（每个 Span 独立）和资源元数据（全局共享），元数据来源可以是环境变量、K8s 平台信息或配置文件。最终，带有丰富上下文的数据被发送到后端，实现高效的可观测性分析。