1. 课程导论：值班机器人面临的挑战、可观测性三大支柱、OpenTelemetry 简介与课程目标
1.1 值班机器人的现实困境
在现代微服务与云原生架构中，值班机器人（On-Call Bot）承担着告警接收、故障定位与协同响应的核心职责。然而，随着系统规模膨胀，传统监控手段暴露出三大痛点：
- 告警风暴：单次故障可能触发数十条相关告警，值班人员淹没在噪声中，难以识别根因。
- 数据孤岛：日志、指标、链路追踪分属不同工具，故障排查时需手动切换上下文，效率低下。
- 缺乏关联：无法将一次用户请求的完整路径与对应的基础设施指标、错误日志自动关联。
核心矛盾：值班机器人需要从“被动接收告警”升级为“主动聚合关联”，而实现这一目标的前提是统一的可观测数据底座。
1.2 可观测性三大支柱
可观测性（Observability）并非单一工具，而是由三种数据类型共同构建的系统理解能力：
| 支柱 | 定义 | 典型数据 | 值班机器人使用场景 |
|---|---|---|---|
| 日志（Logs） | 离散的、带时间戳的事件记录 | 错误堆栈、访问日志、审计日志 | 故障发生后，检索异常上下文 |
| 指标（Metrics） | 可聚合的数值型时间序列数据 | CPU 使用率、请求延迟 P99、错误率 | 触发告警规则、生成仪表盘 |
| 链路追踪（Traces） | 端到端请求路径与各阶段耗时 | Span 树、服务依赖图、调用链 | 快速定位故障服务与瓶颈节点 |
关键认知：三大支柱并非孤立存在。链路追踪中的每个 Span 可以关联对应的日志与指标，形成“可观测性三角形”。值班机器人的告警聚合正是基于这种关联能力。
1.3 OpenTelemetry 简介
OpenTelemetry（简称 OTel）是 CNCF 孵化的可观测性标准框架，旨在统一三大支柱的数据采集、处理与导出规范。其核心组件包括：
- API：定义 Traces、Metrics、Logs 的数据模型与操作接口。
- SDK：提供语言级实现，包括采样、上下文传播、处理器与导出器。
- Collector：独立部署的代理/网关，支持数据接收、处理、过滤与转发。
- Exporter：将数据发送到后端（如 Jaeger、Prometheus、Loki、Datadog）。
以下示意图展示了 OpenTelemetry 在值班机器人架构中的核心位置：
1.4 课程目标与学习路径
本课程旨在帮助 SRE 与可观测性工程师，基于 OpenTelemetry 构建一套面向值班机器人的链路追踪与告警聚合系统。完成本课程后，你将能够：
| 模块 | 核心能力 | 交付物 |
|---|---|---|
| OTel 基础 | 理解 Trace/Span 模型，掌握 Python SDK 手动埋点 | 可运行的链路追踪 Demo |
| Collector 管道 | 配置 Receiver/Processor/Exporter，实现数据过滤与采样 | 生产级 Collector 配置 |
| 告警关联 | 基于 TraceID 关联日志与指标，设计告警去重与聚合规则 | 告警聚合引擎原型 |
| 值班机器人集成 | 将聚合后的告警推送至钉钉/飞书/企业微信，附带链路上下文 | 可交互的机器人插件 |
前置要求：建议具备 Python 基础开发能力，了解 Docker 与基本微服务概念。无需 OpenTelemetry 或可观测性经验，课程将从零开始搭建。
本章作为导论，后续章节将逐步深入每个技术细节。下一节我们将从 OpenTelemetry 核心数据模型 开始，亲手构建第一个 Trace。