1. 课程导论：eBPF 技术演进、OTel 生态概览、制品库场景定义与课程目标
1.1 eBPF 技术演进：从内核沙盒到网络观测基石
eBPF（extended Berkeley Packet Filter）起源于 1992 年 BSD 系统的数据包过滤工具，经过 30 余年发展，已成为 Linux 内核最核心的动态插桩技术。其核心价值在于：在不修改内核源码、不加载内核模块的前提下，安全高效地注入观测逻辑。
| 阶段 | 时间 | 关键能力 | 网络观测意义 |
|---|---|---|---|
| BPF 原始期 | 1992–2013 | 内核态数据包过滤（tcpdump） | 仅支持网络抓包，无程序性扩展 |
| eBPF 内核化 | 2014–2018 | 内核态虚拟机、Map 通信、辅助函数 | 可编程跟踪网络协议栈、套接字、XDP |
| 观测生态爆发 | 2019–2022 | CO-RE（一次编译到处运行）、BTF、libbpf | 生产环境安全部署，网络延迟/丢包/吞吐全链路可见 |
| 标准化与云原生 | 2023–至今 | eBPF 与 OTel 集成、CNCF 生态、eBPF 网络策略 | 成为云原生网络观测的标准数据面 |
关键认知：eBPF 不是“另一个抓包工具”，而是内核级可编程观测框架。它让网络观测从“黑盒采样”升级为“白盒全量事件流”，这是本课程所有标签体系设计的技术前提。
1.2 OTel 生态概览：统一观测数据模型与标签体系
OpenTelemetry（OTel）是 CNCF 的第二个毕业级观测项目，旨在提供厂商无关的遥测数据采集、处理与导出标准。其核心组件包括：
- OTel SDK/API：为应用提供 Trace、Metric、Log 的生成接口。
- OTel Collector：数据管道核心，支持接收、处理、导出三大阶段。
- OTel 语义约定（Semantic Conventions）：定义资源、Span、Metric 的标准化属性键值对。
- OTel 协议（OTLP）：二进制/gRPC 与 HTTP/Protobuf 双模式传输。
在网络观测场景中，OTel 语义约定提供了 net.*、http.*、dns.* 等预定义属性，但面对 eBPF 产生的内核级细粒度事件（如 TCP 重传、连接队列溢出、XDP 丢包），现有约定存在明显缺口——这正是本课程要解决的“标签体系补全”问题。
1.3 制品库场景定义：为什么需要“模板制品库”？
在大型微服务架构中，网络观测面临三大痛点：
- 标签不统一：不同团队对“连接”“请求”“重传”的定义各异，导致数据无法关联。
- 重复开发：每个新服务都要重新编写 eBPF 探针和 OTel 导出逻辑。
- 运维成本高：缺乏标准化的标签模板，告警和仪表盘难以复用。
制品库（Artifact Repository） 在本课程中指：一组预定义的、版本化的、可复用的 eBPF 网络观测模板与 OTel 标签配置集合。它包含：
| 制品类型 | 内容 | 复用方式 |
|---|---|---|
| eBPF 探针模板 | XDP/Tracepoint/Kprobe 的 BPF 代码骨架 | 按需选择 hook 点，注入自定义过滤逻辑 |
| OTel 标签映射表 | 内核字段 → OTel 属性的 JSON/YAML 配置 | 直接导入 Collector 配置，无需手动编写 |
| 观测仪表盘模板 | Grafana / Kibana 的预置面板 JSON | 一键导入，关联标签自动生效 |
| 告警规则模板 | 基于标签的 PromQL / 阈值规则 | 按场景（重传风暴、连接泄漏）启用 |
注意：制品库不是“代码仓库”，而是可执行观测配置的标准化集合。每个制品都经过版本测试，确保在不同内核版本（5.10+）和 OTel Collector 版本（0.80+）下兼容。
1.4 课程目标与学习路径
完成本课程后，你将具备以下能力：
- 理解 eBPF 网络观测的完整数据路径：从内核事件触发到 OTel 标签导出。
- 掌握 OTel 语义约定的扩展方法：为 eBPF 特有字段创建自定义命名空间。
- 独立构建制品库：设计、打包、版本化网络观测模板。
- 实战落地：在 Kubernetes 环境中部署 eBPF 探针 + OTel Collector + 制品库。
1.5 本章小结
核心要点：
- eBPF 已从抓包工具演进为内核级可编程观测框架，是网络观测的“数据面”。
- OTel 提供了统一的数据模型和语义约定，但 eBPF 内核事件需要自定义标签扩展。
- 制品库是解决标签不统一、重复开发、运维成本高的标准化方案。
- 课程按“基础→设计→构建→部署”四阶段递进，最终交付可复用的制品库。