AWS 日志体系入门：CloudWatch、CloudTrail 与服务日志全景

AWS 日志生态以 CloudWatch Logs 为中枢，CloudTrail 管审计、各服务（RDS/ELB/VPC）产出专属日志、S3 承担归档。本文梳理这套体系的全貌与最佳实践，帮助你在 AWS 上建立完整的日志治理框架。

核心要点速览

• CloudWatch Logs 是枢纽：日志组（Log Group）→ 日志流（Log Stream）两级组织，保留期按组设置。
• CloudTrail ≠ CloudWatch：CloudTrail 记"谁调了什么 API"（审计），CloudWatch 记"系统运行产生什么"（运行）。
• 保留期必须主动设置：CloudWatch 默认永久保留——不设置就是成本黑洞。
• 管理流程：集中收集 → Insights 查询 → 告警（Alarms+SNS）→ S3 归档 → 定期审视策略。

1. AWS 服务都产生什么日志？

RDS 的日志可在控制台查看下载，或发布到 CloudWatch Logs 流式分析；ALB/VPC 日志默认写 S3。

2. CloudWatch Logs 核心概念

• 日志组：一个应用/服务一个组（如 /aws/lambda/order-api）；
• 日志流：组内按实例/时间分流的日志序列；
• 保留期：按组设置（1 天到 10 年），默认"永不过期"必须改；
• CloudWatch Logs Insights：专用查询语言，按字段过滤、统计、出图：

  fields @timestamp, @message
  | filter @message like /ERROR/
  | stats count() by bin(5m)
  

3. 告警与可视化

• Metric Filter：把日志模式转成指标（如 ERROR 计数）；
• CloudWatch Alarms：指标超阈值触发，经 SNS 发邮件/短信或调 Lambda 自动处置；
• Dashboards：指标、告警、日志查询结果同屏呈现。

4. 归档与外送

• 导出 S3：日志组创建导出任务，配合 S3 生命周期策略转 Glacier 降本；
• 订阅过滤器（Subscription Filter）：日志组实时流向 Lambda/Kinesis/Firehose，再转发第三方平台——这是外送的标准机制；
• Kinesis Firehose：批量缓冲后写 S3/HTTP 端点，适合大流量。

将 CloudWatch Logs 外送到观测云时，可参考 AWS Firehose HTTP Endpoint 接入步骤配置订阅、接收端和数据转换。先用一个日志组验证时间戳、消息内容和失败重试，再扩大范围；外送后仍需分别核算 AWS 侧与接收端的摄入、传输和保留费用。

5. AWS 日志最佳实践清单

1. 所有服务日志集中收集，不留死角（包括 CloudTrail）；
2. 用 Insights 实时查询代替翻控制台；
3. 关键模式配 Metric Filter + Alarm 告警；
4. 保留期按日志组差异化设置，历史转 S3 归档；
5. 日志加密与访问控制（IAM/KMS）到位；
6. 定期审视日志策略，删无用日志源控成本。

常见问题（FAQ）

CloudTrail 和 CloudWatch 到底怎么分工？

CloudTrail 回答"谁动了我的 AWS 资源"（API 审计、合规）；CloudWatch 回答"我的系统运行得怎么样"（运行日志、指标、告警）。两者都要，缺一不可。

CloudWatch 费用为什么超预期？

先分别核对摄入量、查询量和保留费用。按日志组设置保留期、裁剪无用日志源；归档或外送方案需要把传输、检索和重复存储的费用一起比较。

多云（AWS + 阿里云 + IDC）日志怎么统一看？

先确定统一的服务名、环境、时间戳与日志级别，再逐一配置各云的外送或文件采集。接收端需验证数据格式、访问权限及重试行为，不能把一种云服务的接入配置直接套给其他来源。

RDS 日志直接查还是发 CloudWatch？

短期排障控制台直接看；需要告警、跨实例聚合、长期分析时发布到 CloudWatch Logs，文件下载只适合一次性取数。

系列阅读

• 上一篇：Azure 日志实战
• 下一篇：AWS Lambda 日志实战
• 相关阅读：CloudTrail 日志实战 ｜ 什么是日志管理

---