1. 课程导入与体系总览

在传统 IDC 或单体应用时代，排障往往依赖一台能登录的服务器、一份本地日志文件，以及运维人员对系统拓扑的熟悉程度。进入云原生时代后，应用被拆分为容器、微服务、Serverless 函数，基础设施由托管服务动态调度，实例随时创建与销毁，一次用户请求可能横跨 API Gateway、Lambda、DynamoDB、SQS 和第三方服务。此时"登录机器看日志"的方式基本失效，因为机器可能已经不存在，日志分散在多个服务中，故障现场转瞬即逝。可观测性（Observability）正是为应对这种复杂性而生的能力体系。

可观测性不是"监控"的同义词。监控回答的是"系统是否正常"这一预设问题，依赖预先定义的指标阈值；可观测性回答的是"系统为什么变成这样"这一未知问题，依赖对系统内部状态的充分暴露与关联分析。在 AWS 云原生环境中，可观测性由三大支柱构成：指标（Metrics）、日志（Logs）、追踪（Traces）。三者并非并列的独立工具，而是从不同粒度、不同维度描述同一系统的互补视角。

上图展示了三大支柱的定位差异与协作关系。指标是"体温计"，用低成本、高聚合的方式告诉你系统是否发烧；日志是"病历本"，记录每一次具体事件的细节；追踪是"CT 扫描"，还原一次请求在分布式系统中的完整路径与各段耗时。三者通过 TraceID、RequestID 等关联标识串联，形成从"发现异常"到"定位根因"的完整诊断链路。

三大支柱在 AWS 环境中的具体落点

指标在 AWS 中最直接的载体是 CloudWatch Metrics。EC2 的 CPUUtilization、Lambda 的 Duration 与 Errors、ALB 的 TargetResponseTime、DynamoDB 的 ThrottledRequests 都是开箱即用的默认指标。对于容器化工作负载，Container Insights 会采集 Pod 与节点的资源指标；对于自定义业务指标，可通过 CloudWatch Embedded Metric Format（EMF）在日志中嵌入结构化指标，由 CloudWatch 自动提取，避免额外的 PutMetricData API 调用成本。指标的核心价值在于聚合与告警：通过统计周期（如 1 分钟）、百分位（p50/p95/p99）和告警阈值，快速圈定异常时间窗口与受影响范围。

日志在 AWS 中主要汇聚到 CloudWatch Logs。Lambda 的每次调用自动生成日志流，ECS 任务可通过 awslogs 驱动输出，API Gateway 可开启执行日志与访问日志。日志的关键在于结构化：使用 JSON 格式输出，包含 timestamp、level、service、traceId、message 等字段，才能被 CloudWatch Logs Insights 高效查询。例如，一条典型的 Lambda 错误日志可能如下：

{
  "timestamp": "2025-01-15T08:23:41.372Z",
  "level": "ERROR",
  "service": "order-service",
  "function": "processOrder",
  "traceId": "1-65a7b3c2-4f8e9d1a2b3c4d5e",
  "message": "DynamoDB ConditionalCheckFailedException",
  "orderId": "ORD-20250115-8821",
  "durationMs": 2340
}

有了 traceId 字段，就可以在 CloudWatch Logs Insights 中用 filter traceId = "1-65a7b3c2-..." 拉出该请求在所有服务中的日志，实现跨服务关联。

追踪在 AWS 中的原生服务是 X-Ray，同时 OpenTelemetry 已成为跨厂商的标准选择。X-Ray 通过 SDK 或 Daemon 采集 Span，构建服务地图（Service Map），展示每个节点的响应时间分布、错误率和调用关系。一次典型的 API Gateway → Lambda → DynamoDB 请求会产生三个 Span，形成父子关系。当 p99 延迟升高时，追踪能直接指出是 Lambda 冷启动、DynamoDB 限流还是下游超时。对于 EKS 环境，可通过 ADOT Collector 将追踪数据发送到 X-Ray 或第三方后端。

故障诊断的核心挑战与应对思路

云原生故障诊断的难点不在于"没有数据"，而在于"数据太多且彼此割裂"。一个中等规模的微服务系统每天可能产生数十 GB 日志、数百万个指标数据点和数十万条追踪记录。如果没有统一的关联标识和查询入口，排障就会退化为在多个控制台之间反复切换、凭经验猜测。

应对这一挑战的核心思路是以 TraceID 为纽带建立数据关联。具体做法包括：在入口层（API Gateway 或 ALB）生成或透传 RequestID；在应用代码中将其注入日志上下文和追踪 Span；在指标维度中携带服务名与环境标签。这样，当 CloudWatch 告警触发时，可以按时间窗口找到异常指标，再通过日志中的 traceId 定位具体错误，最后用 X-Ray 还原完整调用链，确认瓶颈节点。

需要特别注意的是，可观测性建设不是一次性工程，而是随系统演进的持续过程。初期可以从 CloudWatch 默认指标和基础日志入手，快速建立告警能力；随着微服务数量增加，再逐步引入结构化日志、分布式追踪和统一采集代理。关键是让每一层数据都能被下一层诊断所复用，避免重复建设和数据孤岛。