📚 课程目录第1章课程导入与可观测性全景

1. 课程导入与可观测性全景

在生产环境中，故障从来不是“会不会发生”的问题，而是“什么时候发生、多久能定位、多久能恢复”的问题。很多团队在 AWS 上遇到的困境并不是缺少数据，而是数据太多却彼此割裂：CloudWatch 里有一堆指标曲线，日志散落在多个 Log Group，追踪数据又在 X-Ray 中，真正出问题时却没人能快速回答“到底是哪一层坏了”。本课程的目标，就是把这三种数据源串成一条可操作的诊断链路，让故障定位从“凭经验猜”变成“按证据推”。

可观测性三大支柱及其 AWS 映射

可观测性通常被拆成三个支柱：指标（Metrics）、日志（Logs）、追踪（Traces）。它们回答的问题不同，成本结构不同，适用场景也不同。

指标回答“系统整体是否正常、趋势如何”。它是按时间聚合的数值，成本低、查询快，适合做告警和容量判断。在 AWS 上主要对应 CloudWatch Metrics，包括 EC2 的 CPUUtilization、ALB 的 TargetResponseTime、Lambda 的 Duration 与 Errors、DynamoDB 的 ThrottledRequests 等。
日志回答“具体发生了什么、错误内容是什么”。它是离散的事件文本或结构化记录，信息密度高但体量大。在 AWS 上主要对应 CloudWatch Logs（Log Group / Log Stream）、以及可选的 OpenSearch、S3 归档等。
追踪回答“一次请求经过了哪些服务、时间花在哪一段”。它以 Trace 为单位，由多个 Span 组成，能还原跨服务的调用路径。在 AWS 上主要对应 AWS X-Ray，以及兼容 OpenTelemetry 的采集方案。

三者的关系可以这样理解：指标告诉你“有异常”，日志告诉你“异常是什么”，追踪告诉你“异常发生在调用链的哪一跳”。缺任何一环，诊断都会变慢。

生产故障诊断的核心目标

可观测性建设不是为了“数据好看”，而是为了三个可量化的目标：缩短 MTTD（平均检测时间）、缩短 MTTR（平均恢复时间）、降低误报率。在 AWS 上，这三个目标分别对应不同的工程动作：

MTTD 依赖告警质量。用 CloudWatch Alarm 的 EvaluationPeriods 和 DatapointsToAlarm 控制灵敏度，避免单点抖动触发告警。例如对 ALB 的 5xx 错误率，可设置“连续 3 个 1 分钟周期中有 2 个超过 1%”才触发。
MTTR 依赖诊断路径是否顺畅。如果指标、日志、追踪三者之间没有统一的关联标识（如 Trace ID、Request ID），工程师就要在多个控制台之间反复切换，时间全耗在“找数据”上。
误报率 依赖阈值与业务语义的匹配。CPU 高不等于服务不可用，真正该告警的是“错误率上升”或“P99 延迟超过 SLO”。

贯穿全课的关键线索：关联标识

三大支柱能串起来，靠的是同一个请求在三个数据源中携带相同的标识。在 AWS 上，最常用的是 X-Ray Trace ID 和 Lambda RequestId。一个典型的做法是在应用日志中显式打印 Trace ID：

{
  "timestamp": "2025-01-15T10:23:41.882Z",
  "level": "ERROR",
  "service": "order-service",
  "trace_id": "1-65a7b3c2-3f8e9d1a2b4c5e6f7a8b9c0d",
  "request_id": "a1b2c3d4-5678-90ab-cdef-1234567890ab",
  "message": "DynamoDB ProvisionedThroughputExceededException",
  "table": "orders-prod",
  "latency_ms": 2840
}

有了这个字段，工程师就可以先在 CloudWatch Metrics 上看到 DynamoDB 的 ThrottledRequests 飙升，再用 Logs Insights 查询 fields @timestamp, trace_id, message | filter level = "ERROR" | sort @timestamp desc 找到具体错误，最后用 Trace ID 在 X-Ray 中打开完整调用链，确认是哪个 Span 在重试。这条路径就是本课程反复训练的核心动作。

学习建议：本课程后续章节会按“指标 → 日志 → 追踪 → 综合诊断”的顺序展开。每学完一个支柱，建议在自己的测试账号中至少完成一次真实查询：用 CloudWatch 看一个服务的指标、用 Logs Insights 查一次错误日志、用 X-Ray 打开一条 Trace。只有亲手操作过，故障发生时才不会手忙脚乱。

本课程的学习路径

整个课程分为四个阶段。第一阶段建立可观测性全景与数据关联意识；第二阶段深入 CloudWatch Metrics 与 Alarm 的配置与调优；第三阶段掌握 CloudWatch Logs、Logs Insights 与结构化日志实践；第四阶段进入 X-Ray 追踪与跨服务诊断，并最终用综合案例把三者串成完整的故障诊断闭环。每一阶段都会给出可复现的示例参数、查询语句和判断依据，而不是停留在概念介绍。

需要强调的是，工具只是手段，诊断思维才是核心。面对一个“订单接口变慢”的告警，正确的第一反应不是打开某个控制台，而是先问：这是全局问题还是局部问题？是延迟上升还是错误率上升？最近有没有发布或配置变更？这些问题决定了你该先看指标、先看日志，还是先看追踪。本课程要训练的，正是这种有顺序、有依据、可复盘的诊断习惯。