3. 可观测性数据采集策略设计
在 AWS 数据平台上，可观测性数据采集不是“把所有能开的日志都打开”，而是围绕数据平台的五层结构——存储、计算、编排、消息、查询——分别回答三个问题：这一层会产生什么信号？这些信号用什么工具采集最合适？采集后如何与其它层关联？只有把采集策略按层设计，才能避免日志泛滥、指标缺失、链路断裂三类常见问题。
按层拆解：每层该采什么、用什么采
存储层以 Amazon S3 为核心，关键信号是访问模式、请求延迟、错误码和存储量。S3 本身不产生细粒度请求日志，需要开启 S3 Server Access Logging 或 CloudTrail 数据事件，前者记录每个请求的桶、操作、来源 IP、HTTP 状态码，后者记录对象级读写。指标侧依赖 CloudWatch 的 BucketSizeBytes、NumberOfObjects、5xxErrors、FirstByteLatency。采集原则是：访问日志走 S3 目标桶 + Athena 查询，指标走 CloudWatch Metrics，二者通过请求 ID 和桶名关联。
计算层包括 AWS Glue、Amazon EMR、Lambda 和 Athena 引擎。Glue 作业的 glue.driver.aggregate.numFailedTasks、glue.driver.aggregate.elapsedTime 通过 CloudWatch Metrics 采集；EMR 的 YARN 队列、Container 状态通过 EMR Metrics 和 Prometheus Exporter 采集；Lambda 的冷启动、并发、错误率走 CloudWatch Logs 和 Lambda Insights。计算层最需要的是“作业级”指标，而不是单机指标，因此采集时要按 jobName、runId 打标签。
编排层以 AWS Step Functions 和 Amazon MWAA 为主。Step Functions 的执行历史本身就是结构化事件，可通过 CloudWatch Logs 的 ExecutionFailed、ExecutionSucceeded 事件采集，也可用 X-Ray 追踪状态机内各任务的耗时。MWAA 的 Airflow 任务日志默认写入 CloudWatch Logs，DAG 运行状态通过 airflow.task.duration 等指标暴露。编排层的采集重点是“任务依赖关系”和“重试次数”，这决定了故障定位能否快速收敛。
消息层包括 Amazon Kinesis、MSK、SQS 和 SNS。Kinesis 的 IncomingRecords、IteratorAge、ReadProvisionedThroughputExceeded 是判断消费滞后的核心指标；MSK 需要开启 Prometheus JMX Exporter 采集 Broker 的 UnderReplicatedPartitions、RequestHandlerAvgIdlePercent；SQS 的 ApproximateNumberOfMessagesVisible 和 ApproximateAgeOfOldestMessage 直接反映积压。消息层采集原则是：指标优先，日志按需，因为消息量极大，全量日志成本不可控。
查询层以 Amazon Athena、Redshift、OpenSearch 为主。Athena 的 ProcessedBytes、QueryQueueTime、TotalExecutionTime 通过 CloudWatch Metrics 采集；Redshift 的 QueryDuration、WLMQueueLength、DiskSpaceUsed 走 Redshift 系统表和 CloudWatch；OpenSearch 的慢查询日志、JVM 堆使用率通过 OpenSearch 插件和 CloudWatch 采集。查询层要特别关注“扫描量”和“排队时间”，因为它们直接对应成本和用户体验。
工具选型与集成原则
工具选型不是“哪个流行用哪个”，而是按信号类型和采集成本决定。以下四条原则可以直接用于方案评审。
- 指标优先用 CloudWatch Metrics，自定义指标用 Prometheus。 AWS 托管服务默认把指标推送到 CloudWatch，直接读取即可；EMR、MSK 等需要 JMX 暴露的指标，用 Prometheus Exporter 拉取后写入 Amazon Managed Prometheus，再用 Grafana 统一展示。
- 日志采集统一走 Fluent Bit，不要在每个服务里各写一套。 Fluent Bit 以 DaemonSet 或 Sidecar 方式部署，输入源包括文件、系统日志、容器日志，经过
grep、record_modifier过滤后输出到 CloudWatch Logs 或 S3。这样日志格式、标签、采样率可以集中控制。 - 链路追踪用 OpenTelemetry 做统一埋点，X-Ray 做 AWS 原生集成。 自研服务用 OTel SDK 生成 Trace，通过 OTel Collector 导出到 X-Ray 或 Jaeger；Lambda、API Gateway、Step Functions 等托管服务直接开启 X-Ray 主动追踪。两者通过
trace_id关联。 - 所有采集信号必须带统一标签。 至少包含
layer（storage/compute/orchestration/messaging/query）、service、env、jobName或streamName。没有标签的指标和日志在排障时无法快速过滤，等于没有采集。
一个可落地的采集配置示例
以 Glue 作业为例，下面是一段 Fluent Bit 配置片段，用于把 Glue 作业日志按标签路由到不同 CloudWatch Log Group，并附加作业名和运行 ID。示例参数为教学假设，实际使用时需替换为真实值。
[INPUT]
Name tail
Path /aws/glue/jobs/*/output.log
Tag glue.job
DB /var/lib/fluent-bit/glue.db
[FILTER]
Name record_modifier
Match glue.job
Record layer compute
Record service glue
Record env prod
[FILTER]
Name grep
Match glue.job
Regex log (ERROR|WARN|Exception)
[OUTPUT]
Name cloudwatch_logs
Match glue.job
region us-east-1
log_group_name /aws/glue/jobs/errors
log_stream_prefix glue-
auto_create_group true
这段配置做了三件事：给每条日志打上 layer=compute、service=glue、env=prod 标签；只保留包含 ERROR、WARN 或 Exception 的日志行，降低存储成本；把过滤后的日志写入 /aws/glue/jobs/errors 日志组。运行后可以在 CloudWatch Logs Insights 中用 fields @timestamp, jobName, runId | filter layer = "compute" | sort @timestamp desc 快速定位最近失败作业。
采集策略的验证与迭代
采集方案上线后，需要验证三件事：第一，关键指标是否齐全，例如 Glue 作业失败时能否在 1 分钟内看到 numFailedTasks 上升；第二，日志能否按 jobName 和 runId 过滤到具体一次运行；第三，Trace 能否从 Step Functions 一路串到 Glue 和 S3。验证方法是用一次故意失败的作业触发告警，检查告警内容是否包含层、服务、作业名和运行 ID。如果缺少任何一项，就回到采集配置中补标签或补字段。采集策略不是一次性的，随着数据平台新增服务，标签体系和工具集成方式需要同步更新。