YatishChhatrapati/AWS-CloudWatch-Monitoring-Alerting-Incident-Response

# AWS CloudWatch — 监控、告警与事件响应 在 AWS Free Tier 上实践的 CloudWatch 监控和事件响应实操场景 — 我向云支持工程师转型的实践之一。 ## 环境 - Amazon CloudWatch — 指标、控制面板、告警、日志 - Amazon SNS — 邮件通知 - Amazon EC2 — Ubuntu Server (Free Tier) - Ubuntu Linux CLI — stress, top, ps, kill - AWS 管理控制台 ## 场景 1 — CloudWatch 控制面板设置 **执行步骤：** 1. 打开 CloudWatch 控制台 → 控制面板 → 创建控制面板 2. 命名控制面板：`EC2-Monitoring-Dashboard` 3. 添加小部件： | 小部件 | 指标 | 目的 | |---|---|---| | 折线图 | CPUUtilization | 随时间跟踪 CPU | | 折线图 | NetworkIn / NetworkOut | 监控网络流量 | | 数字 | StatusCheckFailed | 一目了然的实例健康状况 | | 折线图 | DiskReadOps / DiskWriteOps | 磁盘活动监控 | 4. 将时间范围设置为过去 3 小时 5. 保存控制面板并将其设为默认视图 **主要收获：** CloudWatch 控制面板提供了实例健康状况的统一视图。 自定义控制面板对于云支持监控至关重要。 小部件可以混合搭配使用 — 图表、数字、告警 — 都在同一屏幕上。 ## 场景 2 — 创建带有 SNS 通知的 CPU 告警 **执行步骤：** 1. 打开 CloudWatch 控制台 → 告警 → 创建告警 2. 选择指标： - 命名空间：AWS/EC2 - 指标：CPUUtilization - 实例：选定的目标 EC2 实例 3. 配置告警条件： - 阈值类型：静态 - 条件：大于 80% - 周期：5 分钟 - 触发告警的数据点：1 个中的 1 个 4. 配置通知操作： - 创建新的 SNS 主题：`cpu-alert-topic` - 添加电子邮件端点 — 从收件箱确认订阅 5. 命名告警：`High-CPU-Alert` 6. 成功创建告警 **告警状态：** | 状态 | 含义 | |---|---| | OK | 指标在阈值范围内 | | In Alarm | 指标突破了阈值 | | Insufficient Data | 数据点尚不足 | **主要收获：** CloudWatch 告警需要 SNS 主题来传递通知。 必须确认电子邮件订阅才能接收告警。 周期和数据点设置控制着告警的敏感度。 ## 场景 3 — CPU 超载模拟与告警验证 **问题：** 需要验证当 CPU 阈值被突破时， CloudWatch 告警是否能正确触发。 **执行步骤：** 1. 通过 SSH 登录到 Ubuntu EC2 实例 ``` ssh -i "my-key.pem" ubuntu@ ``` 2. 安装 stress 工具 ``` sudo apt update sudo apt install stress -y ``` 3. 模拟 CPU 负载 — 将 CPU 推至 100% ``` stress --cpu 4 --timeout 120 ``` 4. 在单独的终端中监控实时 CPU ``` top -c ``` 5. 等待 5 分钟 — CloudWatch 告警进入 In Alarm 状态 6. 收到 SNS 电子邮件通知 ✅ 7. 停止 stress 进程 — CPU 恢复正常 8. CloudWatch 告警返回 OK 状态 ✅ **结果：** 在 CPU > 80% 时告警正确触发。 在预期时间内收到了 SNS 通知。 CPU 降至阈值以下后，告警自动解除。 **主要收获：** CloudWatch 指标每 5 分钟更新一次（基础监控）。 启用详细监控可获取 1 分钟粒度的数据。 stress 工具对于在测试期间模拟负载非常有用。 ## 场景 4 — 事件响应与 RCA 文档 **事件：** 生产环境的 EC2 实例触发了 CloudWatch CPU 告警。 实例响应缓慢 — 报告了客户受到影响。 **响应步骤：** 1. 收到 CloudWatch SNS 告警通知 2. 检查 CloudWatch 控制面板 — 确认 CPU 达到 95% 3. 通过 SSH 登录到 Ubuntu EC2 实例 ``` ssh -i "my-key.pem" ubuntu@ ``` 4. 识别失控进程 ``` top -c ps aux --sort=-%cpu | head -10 ``` 5. 记录异常进程的 PID 6. 终止进程 ``` kill -9 ``` 7. 确认 CPU 恢复正常 ``` top -c ``` 8. 监控 CloudWatch — 告警在 2 分钟内解除 9. 以 SOP 格式记录事件 ## 事件 SOP — CPU 使用率过高 ``` ======================================== SOP: High CPU Utilization — EC2 Instance ======================================== Incident ID : INC-001 Severity : High Service : EC2 Ubuntu — Web Server Alarm : High-CPU-Alert (CloudWatch) TIMELINE: T+00 — CloudWatch alarm triggered (CPUUtilization > 80%) T+01 — SNS email notification received T+02 — CloudWatch dashboard reviewed — CPU at 95% T+03 — SSH into EC2 instance T+04 — Ran: top -c and ps aux — identified runaway process T+05 — Executed: kill -9 T+06 — CPU dropped to 12% T+08 — CloudWatch alarm returned to OK state T+10 — Apache status verified — service healthy T+15 — Incident resolved — SOP documented ROOT CAUSE: Uncontrolled background process consuming 95% CPU. Process was not part of any scheduled job or application workflow. RESOLUTION: Runaway process identified via top and ps aux. Process terminated via kill -9 command. CPU normalized within 2 minutes of termination. IMPACT: Website response was slow for approximately 8 minutes. No data loss. Apache service remained running throughout. PREVENTION: 1. CloudWatch CPU alarm at 80% threshold — already active 2. Enable detailed monitoring (1-minute intervals) on EC2 3. Review cron jobs and background processes periodically 4. Consider Auto Scaling to distribute load in future ITSM ALIGNMENT: Detection — CloudWatch Alarm + SNS Diagnosis — CloudWatch Metrics + Linux CLI (top, ps) Resolution — Process kill via SSH Review — RCA documented in SOP ======================================== ``` ## CloudWatch 告警 — 配置参考 | 参数 | 使用值 | |---|---| | 指标 | CPUUtilization | | 命名空间 | AWS/EC2 | | 阈值 | 大于 80% | | 周期 | 5 分钟 | | 触发告警的数据点 | 1 个中的 1 个 | | 通知 | SNS 电子邮件告警 | | 告警名称 | High-CPU-Alert | ## 展示技能 | 技能 | 场景 | |---|---| | CloudWatch 控制面板创建 | 1 | | CPU 告警配置 | 2 | | SNS 主题和电子邮件通知 | 2 | | CPU 突破模拟 | 3 | | 告警验证 | 3 | | 事件响应工作流 | 4 | | 根因分析 (RCA) | 4 | | SOP 文档编写 | 4 | | 符合 ITSM 标准的事件处理 | 4 | | Linux 进程管理 | 3, 4 | ## 关于 在 Accenture 和 Genpact 拥有 6 年以上的运营与支持经验 — 正在向 AWS 云支持工程师转型。 所有场景均使用 Ubuntu Server 在 AWS Free Tier 上实践。

标签：ASM汇编, AWS, AWS Free Tier, Cloud Support Engineering, CloudWatch, CPU监控, DPI, EC2, IaC, IT支持, SNS, Ubuntu Linux, 云监控, 云运维, 仪表盘, 压力测试, 告警配置, 异常检测, 指标监控, 运维, 邮件通知