1. 课程导入与可观测性全景
在云上排障，最让人头疼的往往不是“修不好”，而是“不知道从哪里看”。一台 EC2 实例响应变慢，可能是 CPU 被压满、可能是磁盘 IO 打满、可能是安全组规则被改、也可能是下游 RDS 连接池耗尽；一个 API 偶发 5xx，可能是 Lambda 冷启动、可能是 ALB 后端健康检查抖动、也可能是某个可用区的网络路径异常。传统运维里“登上机器看日志”的做法，在弹性、无服务器、多可用区的 AWS 环境里迅速失效——实例随时被替换，容器随时被调度，日志分散在几十个日志组里。可观测性（Observability）要解决的，正是这种“系统内部状态不可直接看见”的问题：通过系统对外输出的信号，反推它此刻到底发生了什么。
本课程围绕 AWS 云基础设施的可观测性与故障诊断展开，目标不是把 AWS 所有监控服务罗列一遍，而是建立一条可复用的排障路径：先明确要回答什么问题，再选择能回答该问题的信号，最后用工具把信号串成证据链。学完 30 章后，你应当能够独立完成一次从“告警触发”到“定位根因”的完整诊断，并能把诊断过程沉淀为可复用的仪表盘、告警规则与运行手册。
可观测性三支柱：指标、日志、追踪
业界通常把可观测性拆成三根支柱，它们不是三个并列的工具，而是三种不同粒度、不同成本、不同回答能力的信号。
指标（Metrics）是随时间变化的数值序列，回答“有没有问题、什么时候开始、影响多大”。在 AWS 中，CloudWatch 指标是最基础的信号源：EC2 的 CPUUtilization、NetworkIn/Out，ALB 的 TargetResponseTime、HTTPCode_Target_5XX_Count，RDS 的 DatabaseConnections、FreeableMemory，Lambda 的 Duration、Errors、Throttles。指标的优势是便宜、可长期保留、天然适合做告警；劣势是维度有限，通常只能告诉你“哪个资源异常”，很难告诉你“为什么异常”。
日志（Logs）是离散的事件记录，回答“具体发生了什么”。CloudWatch Logs 日志组、VPC Flow Logs、CloudTrail 事件、ALB 访问日志都属于这一类。日志信息量大、细节丰富，但成本高、检索慢，且格式不统一时难以聚合。排障时日志往往用于“确认假设”：指标提示 5xx 上升，日志里就能看到具体是哪个异常栈、哪条 SQL 超时。
追踪（Traces）是请求在分布式系统中的完整调用链，回答“慢在哪一跳、错在哪一环”。AWS X-Ray 通过 trace ID 把一次请求经过的 API Gateway、Lambda、DynamoDB、下游 HTTP 服务串起来，展示每一段的耗时与状态。追踪弥补了指标“看不到调用关系”和日志“难以跨服务关联”的空白，是微服务与无服务器架构排障的关键。
三支柱如何协同：一次 5xx 排障的推演
假设某电商应用部署在 ALB + EC2 Auto Scaling + RDS 架构上，凌晨 2 点收到告警：ALB 的 HTTPCode_Target_5XX_Count 在 5 分钟内从 0 升到 120。此时如果直接去翻日志，面对几十个日志组会非常低效。合理的顺序是：
- 用指标缩小范围：先看 ALB 的
TargetResponseTime是否同步上升。若响应时间正常但 5xx 突增，多半是应用抛异常；若响应时间也飙升，则可能是后端资源瓶颈。同时查看HealthyHostCount，确认是否有实例被判定不健康。 - 用追踪定位环节：在 X-Ray 中按时间窗口筛选错误 trace，观察 trace map 中哪一段标红。若红色出现在 RDS 的 subsegment，说明数据库调用失败；若出现在 Lambda 或外部 HTTP 调用，则指向对应下游。
- 用日志确认根因：拿到 trace ID 后，在 CloudWatch Logs Insights 中按该 ID 检索应用日志，通常能直接看到异常类型，例如
TimeoutError: connection pool exhausted或AccessDenied。 - 修复并沉淀：若是连接池耗尽，调整池大小或增加 RDS 最大连接数；随后把“5xx 突增 + 连接池使用率”做成组合告警，避免同类问题再次被动发现。
学习路径与工具地图
本课程后续章节会沿着“信号采集 → 信号分析 → 故障定位 → 体系化建设”的主线推进。你会依次接触到：CloudWatch 指标与告警、CloudWatch Logs 与 Logs Insights 查询语法、X-Ray 追踪与采样策略、CloudTrail 审计事件、VPC Flow Logs 与网络诊断、以及基于 CloudWatch Dashboard 和 Contributor Insights 的体系化观测。每一章都会尽量落到具体的资源、参数和判断依据上，而不是停留在服务介绍层面。
需要提前建立的一个认知是：可观测性不是“装一个 Agent 就完事”，而是围绕问题设计信号。同一个 Lambda 函数，如果你关心的是冷启动，就该重点看 InitDuration；如果关心的是下游依赖，就该打开 X-Ray 主动追踪；如果关心的是权限问题，就该把 CloudTrail 和函数日志关联起来。工具是固定的，问题决定了你该看什么。
接下来，我们会从最基础也最常用的 CloudWatch 指标开始，逐步把这三根支柱落到具体的 AWS 资源与操作上。