Marico's space
最近在项目中重度使用了 AWS CloudWatch（亚马逊云监控服务），踩了不少坑，这篇把核心概念和实战用法讲清楚。
现代云架构里，监控已经成了基础设施的一部分。你可能部署了最牛的应用、Kubernetes 集群、无服务器系统或微服务，但如果看不清里面发生了什么，生产事故就会变成噩梦。
CloudWatch 就是来解决这个问题的。
AWS CloudWatch 是 AWS 生态里的核心监控与可观测性平台。
它帮助工程师：
无论你是：
CloudWatch 都是你必须深入掌握的 AWS 服务之一。
https://github.com/17J/30-Days-Cloud-DevSecOps-Journey
https://aws-command.vercel.app/
AWS CloudWatch 是 AWS 提供的监控与可观测性服务。
它收集和追踪：
来自 AWS 资源和你自己的应用。
可以把 CloudWatch 理解为 AWS 基础设施的眼睛和耳朵。
没有监控的话：
CloudWatch 帮助团队从：
被动运维 → 主动监控
CloudWatch 主要由四大支柱组成：
| 组件 | 用途 |
|---|---|
| 日志（Logs） | 存储和分析日志 |
| 指标（Metrics） | 数值型性能数据 |
| 告警（Alarms） | 自动化告警 |
| 仪表盘（Dashboards） | 可视化和监控 |
CloudWatch 日志允许你收集、存储和分析来自以下来源的日志：
由应用程序生成。
示例：
用户登录成功
支付失败
数据库超时
由操作系统生成。
示例：
磁盘空间已满
内核崩溃
SSH 登录
由 AWS 服务生成。
示例：
CloudWatch 日志的组织结构是：
日志组（Log Group） ↓
日志流（Log Stream） ↓
日志事件（Log Events）
应用和服务器通过以下方式发送日志：
sudo yum install amazon-cloudwatch-agent
启动 agent：
sudo systemctl start amazon-cloudwatch-agent
CloudWatch Logs Insights 用查询语句来搜索日志。
查询示例：
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20
这在以下场景特别有用：
日志流程架构图
EC2 / Lambda / 容器 ↓ CloudWatch 日志 ↓ Logs Insights
指标是随时间收集的数值型数据点。
示例：
| 资源 | 指标 |
|---|---|
| EC2 | CPU 利用率 |
| RDS | 可用存储空间 |
| Lambda | 调用次数 |
| ALB | 请求数 |
| ECS | 内存使用量 |
指标帮助回答这些问题：
一个指标包含：
| 组成部分 | 描述 |
|---|---|
| 命名空间（Namespace） | AWS 服务类别 |
| 指标名称（Metric Name） | 测量项名称 |
| 维度（Dimensions） | 资源标识符 |
| 时间戳（Timestamp） | 指标时间 |
| 值（Value） | 实际测量值 |
Namespace: AWS/EC2
Metric: CPUUtilization Value: 82%
AWS 会自动推送很多指标。
示例：
| 服务 | 指标 |
|---|---|
| EC2 | CPU 利用率 |
| Lambda | 错误数 |
| RDS | 数据库连接数 |
| API Gateway | 4XX 错误 |
| S3 | 存储桶大小 |
你也可以推送自定义指标。
示例：
aws cloudwatch put-metric-data \
--namespace "Payments" \
--metric-name Transactions \
--value 150
这适用于：
CloudWatch 告警监控指标，并在超过阈值时触发动作。
示例：
如果 CPU > 80% 持续 5 分钟 → 触发告警
没有告警的话：
有告警的话：
CloudWatch 告警有三种状态：
| 状态 | 含义 |
|---|---|
| OK | 一切正常 |
| ALARM | 阈值被触发 |
| INSUFFICIENT_DATA | 数据不足 |
告警可以触发：
告警工作流示意图
指标阈值被触发 ↓ CloudWatch 告警 ↓ SNS 通知 ↓ 邮件 / Slack
CloudWatch 告警 ↓ SNS Topic ↓
邮件 / Slack / 短信
场景：
如果 EC2 CPU 超过 80% 持续 10 分钟：
→ 发送邮件告警
→ 触发自动伸缩
| 场景 | 告警 |
|---|---|
| CPU 过高 | CPU > 80% |
| 磁盘满了 | 可用空间 < 10% |
| Lambda 失败 | 错误数 > 5 |
| DDoS 攻击 | 请求量突增 |
| 数据库压力大 | 高连接数 |
仪表盘提供集中化的可视化监控。
你可以把：
组合到一个监控界面里。
仪表盘帮助团队：
常用小组件包括：
| 小组件 | 用途 |
|---|---|
| 折线图 | 时间趋势 |
| 数字组件 | 单个指标值 |
| 堆叠面积图 | 资源对比 |
| 文本组件 | 备注/文档 |
| 告警状态 | 告警可见性 |
一个真实的生产仪表盘可能包含：
CPU 使用率
内存使用率
请求数量
错误率
延迟
数据库连接数
网络流量
应用 / AWS 服务 ↓ CloudWatch ↙ ↓ ↘
日志 指标 事件 ↓ ↓ ↓
Insights 告警 自动化 ↓ 仪表盘
CloudWatch 架构图
CloudWatch 在 DevOps 工作流中应用广泛。
| 领域 | 用途 |
|---|---|
| CI/CD | 部署监控 |
| Kubernetes | 容器监控 |
| 自动伸缩 | 伸缩决策 |
| 事件响应 | 告警通知 |
| 安全 | 威胁检测 |
CloudWatch 也支持安全运维。
示例：
结合：
它就成为完整云安全体系的一部分。
很多新手会搞混这两个服务。
| CloudWatch | CloudTrail |
|---|---|
| 监控 | 审计 |
| 指标和日志 | API 活动 |
| 性能 | 合规 |
| 实时可见性 | 历史追踪 |
CloudWatch 的费用取决于：
重要提示：
大量的日志摄入可能会让账单很难看。
不要无限制保留日志。
示例：
开发环境日志 → 7 天
生产环境日志 → 30-90 天
合规日志 → 更长保留期
避免发送噪音日志。
提取指标而不是存储大量日志。
如有需要，把旧日志转到 S3。
优先使用 JSON 格式日志。
不好：
Error happened
好：
{ "service": "payment-api", "status": "failed", "error": "database timeout"
}
避免告警疲劳。
每个生产服务都应该有对应的仪表盘。
不只是基础设施指标。
示例：
聚合所有系统的日志。
CloudWatch 在以下场景重度使用：
因为可观测性现在是可靠性工程的关键。
AWS CloudWatch 不只是一个监控工具。
它是 AWS 基础设施的运维神经系统。
如果你真的想成为：
你必须深入理解：
因为在现代云系统中：
"如果你无法观测它，
你就无法可靠地运行它。"