业务迁上 AWS 后，EC2、Lambda、RDS、API Gateway、DynamoDB 等服务交错运行，资源数量迅速增长。运维和开发团队最关心资源是否健康、何时扩容、错误日志如何定位、安全事件怎样及时发现。这些需求都指向 AWS 可观测性的三大核心：监控、告警和日志分析。本文从最基础、最实用的服务讲起，帮你快速搭建一套清晰、有效、可持续演进的监控告警体系。

一、AWS 监控体系概览：从 CloudWatch 开始

如果只选一个服务作为 AWS 可观测性的起点，那一定是 Amazon CloudWatch。它统一收集指标、日志和事件，原生集成超过 30 种 AWS 服务，无需额外安装代理，即可看到 EC2、Lambda、DynamoDB、API Gateway、RDS 等资源的基础指标，如 CPU、请求数、错误率、延迟等。

CloudWatch 的核心能力归纳为三块：指标收集与可视化、日志集中管理、告警与自动化。对刚接触 AWS 监控的团队，CloudWatch 无需额外采购第三方工具，支持快速启动报警、自动扩缩、容量规划和安全合规，是性价比最高的切入点。

二、日志分析：用 CloudWatch Logs 与 Logs Insights 深入排查

监控指标告诉你“系统出问题了”，日志则告诉你“为什么出问题”。CloudWatch Logs 是 AWS 日志分析的核心组件。

CloudWatch Logs 基础能力

CloudWatch Logs 使用日志组和日志流组织日志数据。日志组是某应用或服务的集合，日志流是具体来源，如某台 EC2 的日志文件或某个 Lambda 函数的输出。这种层级结构让大量日志也能清晰定位到具体资源。

你可以针对日志内容设置监控，例如统计 404 错误次数，或查找异常关键字，当日志出现特定模式时触发告警或自动化操作。日志支持传输和静态加密，保留策略可配置，可按成本设置为 7 天、30 天或更短。

CloudWatch Logs Insights：交互式查询与分析

日志量变大后，单纯搜索关键字不够用。CloudWatch Logs Insights 提供类似数据库的交互式查询能力。它内置查询语言，支持聚合、筛选、排序、正则表达式和图表展示。系统能自动发现日志字段，如 duration、status、functionName 等，查询时可直接引用，无需预先定义结构。它还提供生成式 AI 助手（预览版），可输入自然语言自动生成查询语句，降低日志分析的学习门槛。

日志分析最佳实践

开始做日志分析时，不必全量接入，建议从最有价值的服务日志开始：

• CloudTrail：记录 API 调用行为，用于安全和审计。
• API Gateway：记录每个 API 请求的路径、状态码、延迟和错误。
• Lambda：记录函数执行日志，包括内存、耗时和异常堆栈。

排障时，把指标和日志关联起来看。比如某 API 错误率上升，先查看对应时段 API Gateway 日志，再关联 Lambda 日志，往往能快速定位瓶颈。同时，要根据实际需求选择日志类别，避免全量长期保存。低频审计日志可缩短保留周期或归档，高频调试日志可在生产环境关闭或抽样记录，在保证分析能力的同时控制成本。

三、告警策略：只对可操作事项进行告警

很多团队“凡是异常都告警”，结果告警铺天盖地，真正的故障反而被淹没。好的告警体系应该“少而精”，每条告警都值得被处理。

从业务目标反向设计告警

不要从“这个指标有异常”出发，而要从“这个异常是否影响业务”出发。例如，网站响应时间超过 2 秒、用户明显卡顿，需要告警；某台 EC2 的 CPU 到 80%，但集群仍有余量、业务未受损，则不必立刻告警。只有当 CPU 持续升高导致请求延迟或失败时，才值得触发。

同源故障要聚合告警。数据库宕机时，所有依赖它的应用都会报错，如果每个 Web 服务器都单独发告警，运维会在同一时间收到几十条信息。更好的做法是只发一条数据库告警，外加一条聚合后的应用告警，处理起来更清晰。

告警状态与自动化

CloudWatch 告警有 OK、WARNING、ALERT、NO DATA 等状态，每种状态可触发不同行动：发送通知到 SNS，再通过邮件、短信或 Slack 触达相关人员；触发自动扩缩；与 ITSM 工具集成自动创建工单；调用 Lambda 执行重启服务、清理缓存等操作。

告警不能设计成“指标一恢复就发 OK 通知”，频繁的“一切正常”也是噪音。建议设置合理评估周期，比如连续 3 个周期超过阈值才告警，连续 3 个周期恢复正常才发 OK，避免瞬时抖动误报。

除固定阈值外，可使用 CloudWatch 异常检测功能。它基于历史数据动态计算正常范围，适合有周期性规律、不好用固定阈值衡量的指标。另外，别忘了为关键告警设置“无数据告警”，防止监控系统本身静默失效。

四、进阶：集中化运维与安全监控

熟练使用 CloudWatch 后，可逐步引入更高级的服务完善可观测性。

Container Insights

容器化应用运行在 ECS、EKS 或 Fargate 上时，推荐使用 Container Insights。它能自动采集容器实例、Pod、集群的指标和日志，并生成现成控制面板，无需手动创建即可看到 CPU、内存、网络和磁盘使用情况。当容器频繁重启或资源使用率异常时，可快速判断是应用还是基础设施问题。

Security Hub

Security Hub 聚合 AWS 账户中的高优先级安全告警和合规性状态，统一展示来自 GuardDuty、Inspector、IAM Access Analyzer 等安全服务的发现结果。与 CloudWatch 配合，可实现安全事件的集中告警与响应，例如发现安全组高危开放端口时，自动触发 CloudWatch 告警通知安全团队。

与其他 AWS 服务集成

• AWS Systems Manager：批量安装 CloudWatch 代理，采集 EC2 自定义日志和指标，如内存、磁盘或特定应用日志。
• AWS CloudTrail：审计 API 活动，通过 CloudWatch 告警捕获删除数据库、修改 IAM 策略等敏感操作。
• AWS Secrets Manager / KMS：与 CloudWatch Logs 集成，实现日志加密和密钥管理，满足安全合规要求。

通过这些组合，监控体系会从“看见问题”升级为“预防问题和发现安全风险”。

五、从零开始的行动路线图

尚未建立监控体系的团队，可按五步推进：

1. 启用 CloudWatch 基本监控：打开 CloudWatch，查看 EC2、Lambda、RDS 等核心服务的默认指标，在关键资源上设置控制面板，观察正常状态下的指标趋势。

2. 为关键业务指标创建告警：选择最影响用户和收入的指标，如 API 错误率、响应时间、订单失败数等，配置可操作阈值并通过 SNS 通知。起初 5～10 条即可。

3. 将应用和服务日志发送到 CloudWatch Logs：为 Lambda、API Gateway 启用日志，或在 EC2 上安装 CloudWatch 代理采集应用日志。用 Logs Insights 写几个查询，把常用查询保存为仪表盘。

4. 持续优化告警规则：每周回顾告警记录，清除从未触发或触发了却没人处理的告警。根据业务变化调整阈值，引入异常检测和自动化动作。

5. 逐步引入进阶服务：基础监控稳定后，再考虑 Container Insights 做容器监控、Security Hub 做安全集中管理、Systems Manager 做大规模代理部署。

这条路线不需要一次性铺开，每一步都能独立产生价值。关键是形成适合自己团队的处理流程：告警收到后谁来响应、如何排查、如何反馈改进。

六、结论

AWS 监控、告警和日志分析，并不需要凑齐“全家桶”。CloudWatch 就是一切的起点。它覆盖几乎所有 AWS 资源的默认监控，统一管理指标、日志和告警；配合 CloudWatch Logs Insights 做日志分析，足以应对大多数排障场景。告警设计上，始终坚持“只对可操作事项进行告警”，宁可少而精，不可多而滥。在此基础上，再根据实际需要引入 Container Insights、Security Hub 等进阶能力，逐步构建一个满足业务需求、不产生告警疲劳、可持续扩展的可观测性体系。

监控建设不是一次性的工程，而是一个不断迭代的过程。从最核心的服务开始，小步快跑，你的 AWS 环境会变得越来越透明、稳定和安全。