1. 课程导论：可观测性发展趋势、OpenTelemetry 项目背景、管线服务目录的核心价值
1.1 可观测性发展趋势：从监控到智能运维
传统监控体系以“已知故障模式”为核心，依赖预定义的阈值与告警规则。随着微服务、容器化与 Serverless 架构的普及，系统拓扑动态变化、故障根因难以追溯，传统监控已无法满足现代分布式系统的诊断需求。可观测性（Observability）应运而生，其核心理念是通过系统外部输出的数据（日志、指标、链路），推断内部状态，无需预先定义所有故障场景。
关键趋势：
- 三大信号融合：Metrics（指标）、Logs（日志）、Traces（链路）从独立工具走向统一采集与分析平台。
- eBPF 与零埋点：内核级数据采集技术降低应用侵入性，实现无代码变更的可观测性。
- AI for Observability：基于机器学习的异常检测、根因分析与智能告警成为标配。
- 成本治理：数据量爆炸式增长，采样、过滤与存储分层成为架构刚需。
1.2 OpenTelemetry 项目背景：行业标准的确立
在 OpenTelemetry（简称 OTel）出现之前，可观测性领域存在 OpenTracing 与 OpenCensus 两大竞争标准。社区意识到碎片化标准阻碍了生态发展，2019 年两大项目合并，由 CNCF（云原生计算基金会）孵化，形成统一的数据采集、处理与导出规范。OTel 并非一个可观测性后端，而是一套与厂商无关的 SDK、API 与 Collector，用于生成、收集和导出遥测数据。
| 维度 | OpenTracing | OpenCensus | OpenTelemetry |
|---|---|---|---|
| 发起方 | CNCF | Google / 微软 | 合并后统一 CNCF |
| 覆盖信号 | 仅 Traces | Traces + Metrics | Traces + Metrics + Logs |
| 数据导出 | 需手动适配 | 内置部分导出器 | OTLP 原生协议 + 丰富导出器 |
| 当前状态 | 已停止维护 | 已停止维护 | 活跃演进（GA 稳定） |
OTel 核心设计原则：
- 厂商中立：数据格式与传输协议不绑定任何商业产品。
- 低侵入性：通过自动埋点（Auto-instrumentation）减少业务代码改动。
- 可扩展：支持自定义 Processor、Exporter 与 Extension。
- 向后兼容：兼容 OpenTracing 与 OpenCensus 的存量数据。
1.3 管线服务目录的核心价值：标准化与复用
企业在落地 OTel 时，常面临以下痛点：
- 每个团队独立配置 Collector Pipeline，导致重复劳动与配置碎片化。
- 数据路由、采样策略、敏感字段脱敏等逻辑散落在不同 YAML 文件中，难以审计与治理。
- 新服务接入可观测性管线需要数天甚至数周，效率低下。
管线服务目录（Pipeline Service Catalog）正是为解决上述问题而设计。它是一套标准模板驱动的、可注册、可发现、可治理的管线资产库，将 OTel Collector 的 Pipeline 配置抽象为可复用的服务单元。
| 核心价值 | 说明 | 收益 |
|---|---|---|
| 标准化 | 通过预定义模板统一数据采集、处理与导出规范 | 消除配置碎片，降低运维复杂度 |
| 可复用 | 服务目录中的 Pipeline 模板可被多个团队按需引用 | 减少重复开发，加速新服务接入 |
| 可治理 | 目录提供版本管理、审批流程与合规审计能力 | 满足安全与合规要求，变更可追溯 |
| 可发现 | 提供搜索与依赖分析，快速定位管线与服务的关联关系 | 提升排障效率，降低认知负载 |
常见误区：管线服务目录不是“又一个配置管理工具”，而是将可观测性管线视为一等架构资产进行管理。它需要与 CI/CD、服务注册中心、CMDB 等现有基础设施深度集成，而非孤立运行。
1.4 本课程定位与学习路径
本课程面向可观测性工程师、SRE、平台架构师与 DevOps 团队，旨在帮助学员掌握：
- 如何设计标准化的 OTel Collector Pipeline 模板。
- 如何构建与维护管线服务目录，实现模板的注册、版本管理与发布。
- 如何将服务目录与现有基础设施（Kubernetes、CI/CD、CMDB）集成。
- 如何通过目录实现数据治理、成本优化与合规审计。
前置知识建议：了解 OTel Collector 基本配置（receivers、processors、exporters），熟悉 YAML 语法与 Kubernetes 基础概念。本课程不深入 OTel SDK 埋点细节，专注 Collector 侧管线编排。