亚马逊云海外版 AWS CloudWatch 监控指南：EC2、RDS 与应用日志的可观测性配置实践
如果需要更深入咨询了解可以联系全球代理上TG: @cloudcup 他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，微软云开户充值。oss防风控上传加密系统。客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。用户搜索“AWS CloudWatch 监控指南”时，通常不是想了解 CloudWatch 是什么，而是想解决几个具体问题：实例已经上线，但 CPU、内存、磁盘和日志分散在不同位置；告警经常误报，半夜收到通知却发现业务正常；EC2、RDS 和应用日志无法放到同一个排障链路里，导致定位慢。本文直接围绕这些操作问题展开，给出控制台配置、Agent 安装、告警参数设置和故障排查方法。
为什么很多团队部署了 CloudWatch，仍然看不清问题
在实际运维中，最常见的卡点不是“不会开监控”，而是“监控数据不完整”或“看到了数据却不知道怎么用”。例如：
- EC2 默认只有 CPU、网络和磁盘基础指标，看不到内存使用率。
- 系统日志在实例本地，没有集中到 CloudWatch Logs，告警触发后无法追踪异常时间点。
- RDS 指标很多，但阈值设置过于激进，CPU 短时升高也会反复触发告警。
- 不同 Region 的资源分散，Dashboard 没有统一视图。
如果你的目标是构建计算资源可观测性体系，至少要覆盖 4 类数据：主机指标、数据库指标、系统/应用日志、异常通知。缺一项，排障效率都会明显下降。
操作前准备：账号、权限、实例和前置条件
亚马逊云海外版 账号和权限要求
建议使用具备以下权限的 IAM 用户或角色，而不是直接用 root 账号操作：
| 权限类型 | 用途 |
| CloudWatchFullAccess 或精细化 CloudWatch 权限 | 创建告警、Dashboard、查看指标 |
| CloudWatchAgentServerPolicy | 允许 EC2 上的 Agent 写入指标和日志 |
| AmazonSSMManagedInstanceCore | 可通过 SSM 管理实例和下发 Agent 配置 |
| RDS 只读或监控相关权限 | 查看数据库监控指标 |
所需资源
- 至少 1 台 EC2 实例，建议 Amazon Linux 2、Amazon Linux 2023、Ubuntu 20.04+/22.04 或 Windows Server。
- 如需数据库监控，准备 1 个 RDS MySQL/PostgreSQL 实例。
- 已绑定 IAM Role 的 EC2 实例，避免手动保存 Access Key。
- 用于接收通知的 SNS Topic，以及邮箱或企业 IM Webhook 中转。
前置检查
- 实例能访问 CloudWatch、Logs、SSM 相关 AWS API。若在私网子网，需配置 NAT 或 VPC Endpoint。
- 安全组和本机防火墙允许你的 SSH 或 RDP 管理连接。
- 系统时间同步正常，日志时间戳错乱会影响排障。
步骤一：先把 EC2 基础监控和告警建起来
亚马逊云海外版 这一部分先解决“实例存活状态、CPU、网络异常没人知道”的问题。
1. 在控制台确认实例监控状态
进入 AWS 控制台后，打开 EC2 控制台，点击目标实例，查看“Monitoring”页签。这里默认能看到 CPUUtilization、NetworkIn、NetworkOut、StatusCheckFailed 等指标。
如果是生产实例，建议开启 Detailed Monitoring。操作路径为：
- EC2 控制台
- 亚马逊云海外版 选择实例
- Actions
- Monitor and troubleshoot
- 亚马逊云海外版 Manage detailed monitoring
开启后指标粒度通常从 5 分钟缩短到 1 分钟，更适合快速定位突发抖动。
2. 创建 CPU 和状态检查告警
进入 CloudWatch 控制台，点击 Alarms，选择 Create alarm。
| 配置项 | 建议填写 |
| Metric | EC2 > Per-Instance Metrics > CPUUtilization |
| Statistic | Average |
| Period | 5 minutes |
| Threshold type | Static |
| 条件示例 | 连续 3 个周期 > 80% |
| 通知方式 | 发送到 SNS Topic |
然后再单独创建一个 StatusCheckFailed 告警。这个指标对实例宿主机异常、系统故障更敏感，优先级通常高于 CPU 告警。
注意：不要一上来就把 CPU 阈值设为 60%。很多业务在发布、缓存预热、备份期间会短时升高，这种设置很容易制造无效告警。
3. 网络和磁盘基础指标怎么判断异常
EC2 默认能看到网络吞吐，但是否异常要结合实例类型和业务特征判断。通用经验如下：
- NetworkIn/Out 突增但 CPU 不高，优先检查爬虫、下载流量或异常请求。
- CPU 不高但页面变慢，往往不是算力问题，而是磁盘 IO、数据库等待或外部接口阻塞。
- 如果实例使用 EBS，还要关注 VolumeReadOps、VolumeWriteOps、VolumeQueueLength。
基础监控阶段先把实例健康、CPU 和网络趋势看住，下一步再补足内存、磁盘和日志缺口。
步骤二：安装 CloudWatch Agent，补齐内存、磁盘和日志
这是很多用户真正卡住的地方。CloudWatch 默认不直接提供 EC2 的内存使用率和磁盘使用率，需要安装 CloudWatch Agent。
1. Linux 安装 CloudWatch Agent
以 Amazon Linux / CentOS / RHEL 为例：
<code>sudo yum install amazon-cloudwatch-agent -y</code>
Ubuntu / Debian：
<code>sudo apt-get update && sudo apt-get install amazon-cloudwatch-agent -y</code>
安装后执行向导：
<code>sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard</code>
向导里建议采集以下内容：
| 采集项 | 建议 |
| mem_used_percent | 必须开启，判断实例是否需要扩容 |
| disk_used_percent | 至少监控 / 和数据盘挂载点 |
| swap_used_percent | 有 swap 的实例建议开启 |
| procstat | 监控 nginx、java、docker 等关键进程存活 |
| 日志文件 | /var/log/messages、/var/log/secure、应用日志目录 |
配置完成后启动 Agent：
<code>sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s</code>
2. Windows 安装与日志采集
Windows 场景下，常见需求是采集内存、逻辑磁盘使用率和 IIS/应用日志。操作方式：
- 登录 Windows Server
- 安装 AmazonCloudWatchAgent.msi
- 使用 CloudWatch Agent Configuration Wizard 生成配置
- 采集 Performance Counter 和 Windows Event Log
建议重点采集：
- Memory % Committed Bytes In Use
- LogicalDisk % Free Space
- System/Application 安全事件日志
- IIS 日志目录
3. 常见失败点
| 问题 | 原因 | 解决办法 |
| Agent 启动失败 | 配置 JSON 语法错误 | 先用向导生成，再手工微调 |
| 指标不上报 | 实例未绑定 IAM Role | 挂载含 CloudWatchAgentServerPolicy 的角色 |
| 日志组未创建 | 权限不足或 Region 写错 | 检查 logs:CreateLogGroup、logs:PutLogEvents |
| 私网实例无法发送数据 | 无公网或无 Endpoint | 补 NAT 或创建 CloudWatch/Logs VPC Endpoint |
步骤三：把 RDS、日志与 Dashboard 串起来，形成排障链路
仅靠主机指标很难解释“为什么服务变慢”。接下来要把数据库和日志接入统一视图。
亚马逊云海外版 1. 创建 RDS 关键告警
进入 RDS 控制台，选择实例，在 Monitoring 页签确认指标。建议优先建立以下告警：
| 指标 | 建议阈值 | 适用场景 |
| CPUUtilization | 连续 15 分钟 > 75% | 计算型数据库 |
| FreeStorageSpace | 低于 15%-20% | 避免自动扩容前写入失败 |
| DatabaseConnections | 接近实例上限的 70%-80% | 连接池泄漏排查 |
| FreeableMemory | 持续走低 | 查询缓存、排序、并发压力过大 |
| ReadLatency/WriteLatency | 高于业务基线 | SQL 慢查询和 IO 压力分析 |
如果你的业务是 MySQL，建议把 CloudWatch 告警与慢查询日志结合。仅看到 CPU 高，不代表一定要升级实例，很多时候是某条 SQL 缺索引。
2. 采集应用日志并建立 Metric Filter
进入 CloudWatch Logs，找到你的日志组。如果应用日志已通过 Agent 上报，可以直接创建 Metric Filter，把错误关键词转成指标。
亚马逊云海外版 示例：统计 Nginx 5xx 或 Java 应用中的 ERROR。
- 打开日志组
- 选择 Create metric filter
- 输入过滤模式，例如 ERROR 或 5xx
- 指定命名空间，如 App/Errors
- 设置 Metric Name，如 ErrorCount
这样你就可以基于日志错误数创建告警，而不是等用户反馈后才知道应用异常。
3. 建立 Dashboard，避免排障时来回切页面
一个实用的 Dashboard 至少要包含：
- EC2：CPU、内存、磁盘使用率、网络吞吐
- RDS：CPU、连接数、可用内存、延迟
- 日志指标：5xx、ERROR、登录失败次数
- 告警状态：当前 ALARM 资源列表
创建路径：
- CloudWatch 控制台
- Dashboards
- Create dashboard
建议按“业务系统”而不是按“资源类型”组织图表。比如“订单系统生产环境”一个 Dashboard，里面同时放 Web、API、RDS 和日志错误。这样在故障发生时，不需要在 EC2、RDS、Logs 之间来回切换。
怎么选配置和阈值：不同场景的监控建议
个人开发者
优先监控实例健康、CPU、内存、磁盘和 SSH 登录失败日志。告警数量控制在 5 个以内，避免信息过载。单机站点建议增加磁盘剩余空间告警，防止日志打满。
企业用户
亚马逊云海外版 建议按环境拆分：生产、预发布、测试使用不同 SNS Topic。生产环境告警要接入值班通知，测试环境只发邮箱。对核心实例开启 1 分钟监控，对普通批处理节点保留标准监控以控制成本。
跨境业务
重点关注 Region 选择和网络延迟。CloudWatch 本身不解决网络路径问题，但可以把不同 Region 的 ELB、EC2 和 Route 53 健康检查结果汇总。若用户在海外访问慢，需同时观察源站 CPU、带宽、CDN 回源错误和 SSL 证书过期情况。
网站应用
至少覆盖 Nginx 5xx、PHP-FPM/Java 进程存活、磁盘空间和 RDS 连接数。对 HTTPS 站点，还应加入证书有效期巡检，避免误判为服务器故障。
数据库业务
如果是连接型高并发业务，不要只盯 CPU。更有价值的顺序通常是：连接数、慢查询、读写延迟、可用内存、磁盘空间。Redis 场景则应重点监控内存使用率、连接数、网络流量和淘汰数。
常见故障排查：哪些地方最容易踩坑
告警创建了，但没有收到通知
先检查 SNS Topic 是否已确认订阅邮箱；再看告警状态是否真的进入 ALARM；最后确认是否配置了错误的 Region。CloudWatch 告警和 SNS Topic 不在同一区域时，用户经常误以为通知失效。
CPU 正常，但业务明显卡顿
优先检查内存、磁盘队列、数据库延迟和应用日志。很多 Java、Node.js、Python 服务卡顿不是 CPU 打满，而是线程池阻塞、连接池耗尽或外部 API 超时。
CloudWatch 里没有内存数据
不是服务异常，而是实例未安装 CloudWatch Agent，或者 Agent 仅采集了日志未采集 metrics。检查配置文件中的 metrics_collected 段。
日志上报延迟很大
通常与实例网络、日志文件轮转策略或 Agent 缓冲设置有关。如果日志量很大，建议拆分日志组，避免单个日志流过热；同时检查应用是否频繁 rename 日志文件导致采集断点异常。
RDS 告警频繁误报
多数是阈值设置脱离业务基线。例如每天 10:00 有固定报表任务，CPU 短时升高是正常现象。解决方式不是关闭告警，而是改为“连续 3-5 个周期触发”，或者按业务时间段设不同响应策略。
进一步优化：安全、性能、成本和稳定性怎么平衡
安全优化
- EC2 使用 IAM Role，不在实例内保存 Access Key。
- 亚马逊云海外版 日志中避免直接上报明文密码、Token 和身份证号等敏感字段。
- 开启登录失败、sudo、RDP 安全事件采集，便于审计。
性能优化
- 监控项不要无节制增加，优先保留能指导决策的指标。
- 核心进程使用 procstat，比单纯看 CPU 更容易发现服务假死。
- 给 Dashboard 加上业务基线时间段，便于比对发布前后差异。
成本优化
- 不是所有实例都需要 1 分钟详细监控，开发测试环境可以保留标准粒度。
- 日志保留期不要无限制，常见做法是 7 天、30 天、90 天分层。
- 高频且价值低的告警要合并，否则通知噪声会拖垮值班效率。
稳定性优化
- 对关键服务同时配置“资源类告警”和“日志类告警”，减少漏报。
- 将 CloudWatch 与 Auto Scaling 联动时，阈值要保守，避免反复扩缩容。
- 每次发布后回看 Dashboard 30 分钟，确认错误日志、延迟和资源指标没有异常抬升。
如果你是第一次搭建 AWS CloudWatch 监控，推荐的落地顺序是：先做 EC2 基础告警，再装 Agent 补齐内存和磁盘，随后接入 RDS 与应用日志，最后通过 Dashboard 和 SNS 通知形成完整闭环。这样最容易在真实故障中发挥作用，而不是只停留在“图表很多，但没人用”的状态。
