1. 课程导入与可观测性全景
在传统应用系统里，可观测性通常围绕“服务是否健康、接口是否变慢、错误是否增多”展开。但到了 AWS 数据平台，问题会变得更复杂：一条数据从业务库、日志文件或消息队列进入平台，经过采集、缓冲、清洗、建模、聚合，最终被 BI、特征工程或下游 API 消费。任何一个环节出现延迟、丢数、重复、口径漂移或权限异常，都可能让最终报表和模型结果失真。因此，数据平台的可观测性不是单纯“看监控大盘”，而是围绕数据本身、承载数据的计算与存储资源、以及数据流动路径建立可验证的观测能力。
可以把本节要建立的全景概括为一句话：可观测性 = 用日志、指标、追踪三类信号，回答数据平台“现在是否正常、哪里不正常、为什么异常、影响哪些数据与消费者”这四个问题。它的目标不是采集越多越好，而是让关键问题在可接受时间内被定位。边界也很重要：可观测性负责发现、定位和解释异常，不直接替代数据修复、权限治理或成本优化，但它必须为这些动作提供证据。
三大支柱在数据平台中的映射
日志、指标、追踪在通用软件中已有成熟定义，但在数据平台中要映射到具体对象。日志主要回答“发生了什么事件”，例如 Glue 作业运行日志、Lambda 函数日志、Kinesis 消费者错误日志、Athena 查询失败信息。指标回答“随时间变化的数值是否越界”，例如 Kinesis 的 GetRecords.IteratorAgeMilliseconds、Glue 的 glue.driver.aggregate.numFailedTasks、Redshift 的 QueryDuration、S3 的 5xxErrors。追踪回答“一次数据流动经过哪些环节、各环节耗时与结果如何”，在数据平台中常表现为端到端数据血缘与作业执行链路，例如从 S3 原始区到 Glue 清洗、再到 Redshift 加载、最后到 QuickSight 数据集刷新。
需要特别注意的是，数据平台的可观测性对象不只是“服务”，还包括“数据”。因此除了资源指标，还要关注数据质量指标：行数、空值率、主键唯一性、分区新鲜度、schema 变更、数据延迟。这些指标往往比 CPU 使用率更能解释业务异常。
从摄取到消费：每一层该看什么
在摄取层，最典型的异常是“数据到了但消费慢”或“数据根本没到”。以 Kinesis Data Streams 为例，如果 GetRecords.IteratorAgeMilliseconds 持续升高，说明消费者处理速度跟不上写入速度，可能是 Lambda 并发不足、下游写入限流或单条记录处理过重。此时日志中往往能看到重试或超时，追踪则能显示具体卡在哪个处理阶段。DMS 场景下要关注 CDCLatencySource 和 CDCLatencyTarget，它们分别表示从源库读取变更的延迟和写入目标的延迟，两者差值可以帮助判断瓶颈在源端还是目标端。
存储层要同时看资源与数据。S3 的 5xxErrors、FirstByteLatency 反映访问健康度；但更重要的是分区新鲜度，例如某张按天分区的表，最新分区时间是否已超过预期 SLA。Redshift 则要关注 QueryDuration、WLMQueueWaitTime 和 DiskSpaceUsed，因为慢查询可能不是 SQL 写得差，而是队列等待或磁盘溢出导致。
处理层是问题最集中的地方。Glue 作业要同时看运行时长、失败任务数、DPU 使用率和 shuffle 溢出；EMR 要关注 YARN 队列资源、Container 失败率和 Stage 重试。一个实用判断是：如果作业运行时长突然翻倍，但输入数据量没有明显变化，优先检查 shuffle 分区数、数据倾斜和下游写入限流，而不是直接扩容。
消费层决定业务影响。QuickSight 数据集刷新失败、SageMaker 特征组延迟、Athena 查询超时，都会直接表现为“报表不对”或“模型不准”。这一层要建立消费依赖图：哪些报表依赖哪些表、哪些模型依赖哪些特征、哪些 API 依赖哪些聚合结果。只有这样，当上游异常时才能快速回答“影响谁”。
一个可落地的观测起点
不必一开始就追求全链路追踪。更务实的做法是先为每条关键数据流定义三个最小观测项：新鲜度（最新数据时间与当前时间差）、完整性（实际行数与预期行数偏差）、一致性（主键唯一性与关键字段空值率）。再为承载这条流的计算资源绑定两个资源指标，例如 Glue 作业的失败任务数和运行时长。这样就能用最小成本覆盖“数据是否正常”和“作业是否正常”两个最基本问题。
最后要明确边界：可观测性平台本身也需要被观测。CloudWatch 日志组是否持续写入、指标是否被正确采集、告警是否成功送达，这些元监控决定了整套体系是否可信。下一阶段的学习会围绕日志、指标、追踪的具体采集与建模展开，而本节的全景框架将作为后续所有章节的参照坐标。