AWS CloudWatch：云监控全面指南

在我多年的 AWS 基础设施实践中，我发现，对云资源的可见性决定了您是主动解决问题，还是被动“救火”。 

Amazon CloudWatch 正是为此而生：它相当于您 AWS 环境的“中枢神经系统”，为整个基础设施提供全面的监控、日志与可观测性。

我将带您逐步了解 CloudWatch 的能力，从基础度量监控到先进的 AI 驱动运维。读完本教程，您将掌握如何高效监控 AWS 资源、优化成本，并在问题影响用户之前将其解决。

如果您是 AWS 新手，建议先学习我们的 AWS 云技术与服务 课程。

什么是 AWS CloudWatch？

在进入实践之前，先了解 CloudWatch 是什么，以及它如何融入更广泛的 AWS 生态。

CloudWatch 是 AWS 的统一可观测平台，用于从云资源和应用收集、监控与分析数据。该服务可监控完整技术栈，如应用、基础设施、网络和服务，并基于告警、日志与事件数据执行自动化操作。

该平台适用于 AWS 原生与混合场景，支持跨 AWS、其他云提供商以及本地数据中心的工作负载。CloudWatch Agent 可从任何环境收集遥测数据，为所有监控需求提供统一视图。

AWS Cloudwatch

CloudWatch 的强大之处在于其与 AWS 的深度集成。每个主要 AWS 服务都会自动向 CloudWatch 发布度量：

• 计算服务：EC2、Lambda、ECS 和 EKS
• 数据库服务：RDS、DynamoDB 和 Aurora
• 存储服务：S3、EBS 和 EFS
• 网络服务：VPC、CloudFront 和 Route 53

这种原生集成意味着无需复杂配置即可立即开始监控。既然您已了解 CloudWatch 的定位，接下来看看使用这项强大服务的成本。

AWS CloudWatch 定价

在将 CloudWatch 引入基础设施前，了解成本至关重要。下面我来拆解其定价模型，并分享控费策略。

AWS CloudWatch 免费层与定价结构

该服务采用按需计费模式，无需预付承诺。大多数 AWS 服务会免费自动将度量发送到 CloudWatch。

免费层提供了覆盖基础监控需求的充足额度：

• 10 个自定义度量和不限量的基础监活动量
• 10 个标准分辨率度量的告警
• 每月 100 万次 API 请求
• 5GB 日志数据的写入与存储
• 3 个仪表板，每个最多 50 个度量
• Synthetics 每月 100 次金丝雀运行

超出免费层后，前 10,000 个自定义度量大约每个每月 $0.30，随用量增加享受批量折扣。仪表板按每个每月 $3 收费。

在美国东部区域（各区域略有差异），日志写入在免费层之后通常为每 GB $0.50。该价格仅适用于每月前 10 TB，之后会逐步下降。 

使用 低频访问（Infrequent Access） 日志可将写入成本降低 50%，在美国东部区域为每 GB $0.25。但需注意，它们不支持度量过滤（仅适用于标准日志）。此外，Logs-IA 不支持如度量过滤器等功能。

以下是超出免费层后的主要定价组件一览：

CloudWatch 成本管理策略

在优化 CloudWatch 成本的实践中，我总结出几条有效策略：

• 选择性发布度量：自定义度量是收费项，应聚焦业务关键指标，而非“能监控的都监控”。尽可能通过度量过滤从日志中提取洞见，而非另建自定义度量。
• 优化日志保留：实施与合规要求匹配的保留策略。CloudWatch Logs 低频访问 适用于需要长期保留但很少查询的日志。我通常配置：
• 调试日志保留 7 天
• 应用日志保留 30 天
• 合规所需审计日志保留 90 天以上

• 合理设置监控粒度：仅对需亚分钟粒度的资源启用详细监控。对大多数工作负载，5 分钟间隔的基础监控已足够且更省成本。
• 减少数据传输：优先使用 CloudWatch Logs Insights，避免不必要地将日志流式传输到外部工具，因数据传输成本会快速累积。

CloudWatch Logs Insights

如果您希望进一步利用 AWS 的定价结构并保障资源安全，建议学习我们的 AWS 安全与成本管理 课程。

AWS CloudWatch 的关键特性

CloudWatch 提供一整套协同工作的监控工具，为您的 AWS 环境提供完整可见性。下面我们来看看您最常用的核心功能。

通过度量、仪表板与告警实现实时监控

度量是 CloudWatch 监控的基础。CloudWatch 提供最短 1 秒的可见性，支持从 1 天到无限期的数据保留，并可进行计算。这种细粒度既支持实时监控，也利于做容量规划的历史分析。

您可以创建面向不同干系人的仪表板。运维团队关注实时资源利用率，财务团队则受益于成本跟踪。CloudWatch 还支持跨账户仪表板，便于在多账户架构中集中监控。

告警可在度量越过阈值时主动通知。我通常将告警与 Amazon SNS 集成以发送通知，或通过Lambda 函数触发自动修复。例如，当 CPU 利用率连续 5 分钟超过 80% 时，告警可自动触发 Auto Scaling。

接下来，看看 CloudWatch 如何超越基础度量，为应用与容器提供更全面的可观测性。

应用与容器可观测性

针对现代应用，CloudWatch Application Signals 可开箱即用地洞察延迟、错误与 AI 工作负载性能。它还支持自动插桩，无需手动改代码，并可创建与监控服务级目标（SLO）。

在容器化环境中，CloudWatch Container Insights 会收集容器化应用的计算资源使用信息。其支持：

• Amazon ECS：集群、任务与服务级别的度量
• Amazon EKS：集群、节点与 Pod 级可见性
• AWS Fargate：无服务器容器的完整可观测性
• 自管 Kubernetes：支持本地与混合场景

这些可观测能力会产生大量数据，需要有效管理。若想比较 AWS 的容器服务，请参阅我们关于ECS 与 EKS 对比的文章。

日志管理与分析

接下来看看 CloudWatch 的日志管理功能。

用于集中式日志存储，CloudWatch Logs 可统一管理来自 AWS 服务、应用与本地资源的日志。我会将不同应用的日志组织为不同日志组，单个来源为一条日志流。通过保留策略在合规与存储成本间取得平衡。

在需要分析日志数据时，CloudWatch Logs Insights 提供强大的查询语言。我常用其类 SQL 语法快速：

• 识别错误模式
• 追踪特定用户会话
• 从非结构化数据汇总度量

在安全审计方面，CloudWatch 可与 CloudTrail 集成以捕获并分析所有 API 调用。

AWS Cloudtrail

更进一步，近期推出的统一数据管理能力支持跨 AWS 账户与区域收集和聚合日志。它免去了复杂 ETL 流水线与多数据存储的需求，对全球分布式团队而言意义重大。

除后端监控外，理解真实用户体验同样关键。这正是 CloudWatch 终端用户监控能力的用武之地。

端到端用户与合成监控

为捕捉真实用户对应用的体验，CloudWatch RUM（真实用户监控）可从 Web 应用采集实际用户体验数据。我会借助 RUM 从用户视角理解应用性能，跟踪页面加载时间、JavaScript 错误与用户行为。

为在用户受影响前进行主动测试，CloudWatch Synthetics 可与 RUM 互补，主动测试应用端点。您可以创建金丝雀（模拟用户交互的脚本）持续监测可用性。这些测试按计划运行，在真实用户遇到问题之前发出告警。

RUM 与 Synthetics 提供的是表层监控，要理解分布式应用内部发生了什么，还需要更深入的可见性——这就需要分布式追踪。

借助 AWS X-Ray 的分布式追踪

要实现对请求的完整可视化，集成 AWS X-Ray 可进行分布式追踪，展示请求在微服务架构中的流动。追踪图可视化服务依赖并高亮延迟来源。我用 X-Ray 定位延迟瓶颈并理解服务依赖关系。

AWS X-Ray 

另一方面，为识别性能模式与瓶颈，Contributor Insights 会分析高基数数据，识别对系统行为贡献最大的因素。调查错误时，它可显示哪些端点、用户或资源产生最多问题。

当这些监控能力与 AWS 的自动化服务集成后，将成倍增强。精彩之处就在这里。

AWS 集成与自动化响应

CloudWatch 的能量通过与其他 AWS 服务的集成而倍增。对事件驱动自动化而言，Amazon EventBridge 可接收 CloudWatch 告警与事件，编排自动响应。您可以构建工作流，使 CloudWatch 告警触发 EventBridge 规则并调用 Lambda 函数来：

• 自动重启故障服务
• 按需扩缩资源
• 在修复前先创建快照
• 通过多渠道通知团队

对于复杂运维流程，与 Systems Manager 的集成可执行自动化运维操作。CloudWatch 告警可触发 Systems Manager Automation 文档，对多资源执行复杂的修复流程。

现已了解 CloudWatch 的特性，接下来探讨为何要在组织中落地这套平台。

AWS CloudWatch 使用场景

理解 CloudWatch 的功能是一方面，看到它如何转化为实际业务价值才是关键。以下是各行业组织依赖 CloudWatch 开展运维的原因。

运维可见性与性能监控

CloudWatch 提供对全部 AWS 资源的集中可见性。我尤其看重能在单一界面监控 EC2 实例、Lambda 函数、数据库查询与应用专属度量，从而快速关联基础设施行为与应用性能。

凭借全面的数据采集，平台可缩短平均修复时间（MTTR）。在调查事件时，我能同时查看度量、日志与追踪，不仅知道“出了问题”，还能明白“为何出问题”。

除运维可见性外，CloudWatch 在维护合规与支持取证调查方面也至关重要。

以日志为中心的合规与故障排查

对受监管行业，CloudWatch 充当审计轨迹与合规日志的集中存储库。我会按法规要求配置日志保留期。与 CloudTrail 的集成可捕获全部 API 活动，为安全调查提供完整审计轨迹。

在事件响应中，日志是根因分析的主要信息源。CloudWatch Logs Insights 能跨 TB 级日志快速查询，帮助识别错误模式并分析事件发生前的系统行为。

合规与排障能力自然而然通向另一项关键收益：成本优化。

成本优化与账单控制

CloudWatch 的账单度量支持主动的成本管理。我会为预计费用配置告警，第一时间发现异常上涨，便于迅速排查与纠正。

性能洞察也能驱动成本优化。通过分析资源利用度量，我可识别过度配置的资源以做“合理定型”，并理解导致资源需求升高的应用瓶颈。

混合与多云的可扩展性

CloudWatch 超越 AWS 本身，可监控混合与多云环境，支持基础设施多元化的组织。借助 CloudWatch Agent，您可从本地服务器收集度量，不论工作负载运行在哪里，都能实现统一可观测。

在我的实践中，这在云迁移期间尤为有用。我可以用同一套工具对比不同环境的性能，确保迁移不引入退化。

若您想了解这些功能与 Amazon CloudTrail 的对比，请阅读我们的AWS CloudTrail 与 AWS CloudWatch 对比。

设置 CloudWatch

准备好开始使用 CloudWatch 了吗？设置流程相当直接，我将带您完成开始监控基础设施所需的一切。

先决条件

在实施 CloudWatch 之前，请确保具备以下先决条件：

• AWS 账户及相应 IAM 权限
• 已安装并配置凭证的AWS CLI
• 用于初始设置的 CloudWatchFullAccess 策略
• EC2 实例具备互联网连通性或 VPC 终端节点
• 本地服务器具备出站 HTTPS 访问

在生产环境中，建议使用遵循最小权限原则的专用 IAM 角色，而非长期授予完全访问。

如果您已有账户，但需要命令行方面的帮助，我们的教程《如何使用 AWS CLI》将带您熟悉命令行本身。

确认先决条件后，开始初始设置流程。

访问 CloudWatch

通过 AWS 管理控制台进入 CloudWatch 服务。主视图可立即呈现所有命令、选项与集成。

AWS CloudWatch

例如，您可以在日志管理下查看正在运行服务的日志。这可能是最常用的视图之一，因为它可以帮助我们分析应用日志，并在运行异常时进行调试。

日志管理

使用 AWS CloudWatch 进行云监控

既然您已了解如何访问 CloudWatch，下面深入日常监控资源的实用工作流。我将展示一些必备监控技巧，帮助您熟能生巧。

使用度量进行监控

查看度量从 CloudWatch Metrics 控制台开始。操作如下：

步骤 1：访问 CloudWatch Metrics

1. 打开 AWS 管理控制台 并进入 CloudWatch
2. 在左侧导航中点击 Metrics → All metrics
3. 您将看到可用服务命名空间列表（AWS/Bedrock、AWS/EC2、AWS/Lambda 等）

CloudWatch 度量仪表板

步骤 2：选择并可视化度量

如上图所示，在“All metrics”下，您可访问不同服务。入门时，您可以点击任一服务进入自动仪表板。例如，点击 Bedrock 仪表板后，可查看其默认度量，如延迟、按模型统计的 Token 数、请求量或错误计数等标准指标。

AWS Bedrock 度量

步骤 3：为日志创建度量过滤器

除了可视化度量外，还可以从日志数据中提取度量。这可通过使用过滤器并设定模式来实现。按以下步骤从度量定义过滤模式：

1. 导航到 Logs → Log management
2. 选择日志组并点击 Actions → Create metric filter
3. 定义过滤模式（例如，用 [ERROR] 统计错误）
4. 分配度量名称与命名空间
5. 测试模式并创建过滤器

创建度量过滤器

这样即可在无需额外代码的情况下，从日志数据自动生成度量。

熟悉度量后，下一步是创建仪表板以高效可视化这些数据。

用自定义仪表板进行可视化

仪表板能集中展示最重要的度量。以下是为不同团队创建高效仪表板的方法。

步骤 1：创建新仪表板

1. 在 CloudWatch 左侧菜单进入 Dashboards
2. 点击 Create dashboard
3. 输入仪表板名称（如 "Production-Operations-Dashboard"）
4. 点击 Create dashboard

随后将跳转到“Add widget”页面，您可以自定义仪表板样式。

仪表板小组件

步骤 2：添加小组件

设计仪表板小组件的最佳方式，是根据团队需求进行定制。我通常对一些常见团队这样建议：

针对运维团队：

• 添加折线小组件展示 CPU 与内存利用率
• 添加数字小组件显示当前活动连接数
• 为关键服务添加告警状态小组件

针对财务团队：

• 添加折线小组件跟踪预计费用随时间的变化
• 添加数字小组件显示本月累计成本
• 添加来自 AWS Cost Explorer 的度量

针对产品团队：

• 添加应用专属度量（用户注册数、交易量）
• 添加日志洞察小组件显示错误率
• 添加自定义业务 KPI

牢记以上要点后，您可在 AWS 控制台按以下步骤创建：

1. 在仪表板中点击 Add widget
2. 选择小组件类型：Line、Number、Gauge、Bar、Pie 等
3. 选择命名空间：Bedrock、Lamba 等
4. 配置小组件：
1. 从可用命名空间选择度量
2. 设置时间范围与刷新间隔
5. 自定义颜色与标签
6. 点击 Create widget

完成后，您即可在自定义仪表板中查看所选度量。必要时可以修改，亦可私下或公开分享。

分享自定义仪表板

监控预计费用

除了应用度量和仪表板，控制成本也至关重要，以避免不必要的支出并优化整体系统。CloudWatch 可帮助您在费用失控前进行跟踪与控制。以下是设置账单监控的方法：

步骤 1：启用账单度量

1. 进入 Billing and Cost Management 控制台
2. 在左侧菜单点击 Billing preferences
3. 启用 Receive Billing Alerts
4. 点击 Save preferences

启用 CloudWatch 账单告警

请注意，账单度量可能需要最多 15 分钟才会出现在 CloudWatch 中。应用设置并等待后，回到 CloudWatch 控制台创建账单告警。

步骤 2：创建账单告警

启用账单度量后，可按以下步骤创建 CloudWatch 账单告警：

1. 返回 CloudWatch → Alarms → All alarms
2. 点击 Create alarm
3. 选择度量
4. 选择 Billing（如果未看到 Billing/Total Estimated Charge 度量，请先启用账单告警，并将区域切换为美国东部/弗吉尼亚北部）。 
5. 选择 Total Estimated Charge，然后选择 Select metric
6. 指定度量与条件。在此您可选择与成本相关的告警或成本异常检测
7. 配置操作：通知、Lambda、自动伸缩、EC2 与 Systems Manager
8. 添加告警详情
9. 预览并创建

告警的度量与条件

完成上述步骤后，您的账单告警即可生效。根据您的选择，费用或异常将触发并相应通知您。

但除了 AWS 内置度量外，您经常还需要跟踪与业务和应用紧密相关的指标。这意味着要创建并发布自定义度量。

发布自定义度量

自定义度量可监控 AWS 未自动跟踪的应用专属数据。您可通过 AWS CLI 或 API 发布自定义度量。下面用AWS CLI 演示一个简单示例。

以下命令可发布一个基础自定义度量：

aws cloudwatch put-metric-data \
  --namespace "MyApplication" \
  --metric-name "PageViews" \
  --value 1452 \
  --unit Count技术支持

您还可以定义维度来分类度量。每个度量最多可包含 30 个键/值对形式的维度。

aws cloudwatch put-metric-data \
  --namespace "MyApplication" \
  --metric-name "ResponseTime" \
  --value 245 \
  --unit Milliseconds \
  --dimensions Environment=Production,Service=API技术支持

这些自定义度量会出现在 AWS CloudWatch 控制台，您可将其添加到新建或现有仪表板中。

我见过的一些常见自定义度量用例如下：

• 业务度量：日活跃用户、转化率、每用户收入
• 应用 KPI：缓存命中率、队列深度、自定义错误类型
• 性能指标：自定义延迟测量、吞吐量度量
• 运维度量：批处理作业完成时间、数据处理量

掌握以上基础监控技巧后，您已具备处理日常运维的能力。

AWS CloudWatch 的高级 AI 功能

除了基础功能，CloudWatch 还提供突破传统监控工具的前沿能力。这些功能利用 AI 来应对现代云架构的独特挑战。

借助 AIOps 智能运维

CloudWatch Investigations 利用生成式 AI 自动化根因分析并提供引导式故障排查。事件发生时，Investigations 会自动关联：

• 度量：展示变化的性能数据
• 日志：详尽的应用与系统事件
• 追踪：分布式系统中的请求流
• 近期变更：部署与配置更新

除识别问题外，它还会生成事故报告，改变事后复盘的方式。一次点击即可启动全面数据采集，生成详细且具上下文的文档，免去手动收集证据。

CloudWatch Investigations

为防止误报干扰运维，基于模式识别的异常检测可区分真正异常与预期波动，从而降低告警疲劳。您可在关键度量上配置异常检测，让 CloudWatch 学习正常模式，仅在统计学上显著偏离时告警。

监控生成式 AI 工作流

生成式 AI 应用带来全新的监控需求。CloudWatch 使开发者能够分析 AI 应用组件的遥测：

• 内置工具中的代码执行模式
• 通过 Amazon API Gateway 的 API 转换成功率
• 内存存储与检索模式
• 跨模型调用的 Token 使用与成本
• 从提示到响应的延迟跟踪

对于监控如 Amazon Bedrock AgentCore 等 AI 应用的组织，CloudWatch 提供专为 GenAI 可观测性设计的内置仪表板，并兼容 Strands、CrewAI 与 LangGraph 等开源框架。

这使我们能够理解完整的用户旅程，覆盖关于调用、内存、网关或提示等相关度量，追踪请求如何在 AI 应用中流转。这样的可见性有助于优化 AI 应用性能，并识别复杂 Agent 工作流中的瓶颈。

结语

CloudWatch 已从基础度量服务发展为现代云运维所必需的综合可观测平台。其优势在于深度集成、自动化分析，以及从简单监控扩展到 AI 驱动运维智能的能力。

我建议您循序渐进地探索 CloudWatch：先从基础度量与告警开始，随着需求增长再采用高级功能。AWS CloudWatch 文档与Well-Architected 框架提供了详尽指南。

有效的监控在于产出能提升可靠性、性能与用户体验的信息。CloudWatch 提供了实现这一目标所需的全部工具，助您构建更稳健的系统。

如果您想获得 AWS 认证，建议学习我们的 AWS Cloud Practitioner 技能路径，涵盖通过 Amazon CLF-C02 认证所需的一切。