miloplacid7-cloud/monitoring-alerting-incident-response-AWS
GitHub: miloplacid7-cloud/monitoring-alerting-incident-response-AWS
一个基于 AWS 的监控、告警与事件响应实践项目，解决故障发现滞后与手动响应的问题。
Stars: 0 | Forks: 0
# 监控、告警与事件响应
# AWS 上的响应
_A practical DevOps project using Amazon CloudWatch and SNS_
## 概述
### 场景
一家快速发展的 SaaS 公司已经将其应用程序部署在 AWS 上，基础设施运行稳定。
但系统上线后，一个新问题出现了：在生产环境中运行。
目前，团队面临以下差距：
- 故障只有在用户投诉后才会被发现
- 对应用程序健康状况缺乏清晰的可视性
- 日志存在，但分散且难以使用
- 发生问题时没有触发告警
- 事件响应缓慢且多为手动操作
随着使用量增长，这些差距会导致停机、恢复延迟以及糟糕的客户体验。要
妥善运行生产系统，团队需要一种方法来持续监控健康状态、自动接收告警并更快地响应事件。
### 解决方案
目标是构建一个专注于 DevOps 工作的生产监控和告警设置。
- 应用程序和基础设施产生 **指标和日志**
- **Amazon CloudWatch** 收集并集中它们
- **CloudWatch 告警** 跟踪关键健康信号
- 告警通过 **Amazon SNS** 路由
- 工程师在问题发生时立即收到通知
- 使用日志和指标调查并解决事件
这将帮助团队从被动响应故障转变为主动检测问题并自信地响应。
## 执行步骤
- 识别要监控的关键指标和日志
- 在 CloudWatch 中启用并集中日志
- 为可见性创建 CloudWatch 仪表板
- 为故障场景配置 CloudWatch 告警
- 使用 Amazon SNS 发送告警通知
- 模拟故障并验证告警是否正确触发
- 使用日志和指标调查事件
## 使用的服务
- **Amazon CloudWatch Metrics** - 监控基础设施和应用程序健康
- **Amazon CloudWatch Logs** - 用于故障排查的集中式日志
- **Amazon CloudWatch Alarms** - 检测故障和异常行为
- **Amazon SNS** - 向工程师发送事件告警
- **AWS IAM** - 为监控和告警提供安全权限
## 项目设置
这个项目是关于监控、告警和事件响应的。但在创建 CloudWatch
告警或测试事件场景之前，我们只需要一件事：一个运行中的应用程序，能够产生日志并以可控方式失败。
在本节中，我们将在 EC2 上部署一个小型 Python 应用程序，作为本项目的“生产工作负载”。
本节将创建：
- 一个 EC2 实例（我们的监控服务器）
- 一个安全组，允许 SSH 访问和 5000 端口的应用程序访问
- 一个简单的 Python（Flask）监控演示应用
- 一个后台服务，使应用程序在断开连接后仍保持运行
这为我们提供了一个稳定的基线，以便在后续页面中使用 CloudWatch 进行监控。
### 步骤 1：为演示应用启动 EC2 实例
- 打开 **AWS 控制台 → EC2**
- 点击 **启动实例**
- 命名：monitoring-demo-ec
- AMI：**Amazon Linux 2**
- 实例类型：t3.micro（或免费层等效）
- 密钥对：创建/选择现有的密钥对
- 转到 **网络设置 → 点击编辑**
- 创建一个新的安全组并添加入站规则 - 安全组名称：monitoring-demo-sg
- 在入站安全组规则中，仅保留/添加以下规则：
◦ SSH (22) → 来源：我的 IP
```
◦ Custom TCP (5000) → Source: My IP
```
- 启动实例
- 复制并保存：**公有 IPv4 地址** 和 **实例 ID**
### 步骤 2：将 IAM 角色附加到 EC2 实例
为了让我们的 EC2 实例能够向 Amazon CloudWatch 发送日志和指标，必须附加 IAM 角色。
- 转到 **IAM → 角色 → 创建角色**
- 选择 **AWS 服务** 并选择 **EC2**
- 附加策略 CloudWatchAgentServerPolicy
- 命名角色：EC2-CloudWatch-Agent-Role 并创建
- 转到 **EC2 → 实例**，选择你的实例
- 点击 **操作 → 安全 → 修改 IAM 角色** 并附加新创建的角色
### 步骤 3：连接到实例
从终端通过 SSH 连接：
ssh -i ec2-user@
连接成功后，你现在进入了我们将在整个项目中监控的服务器。
### 步骤 4：安装 Python 并创建应用
更新实例并安装 Python：
sudo yum update -y
sudo yum install -y python
创建项目文件夹：
mkdir monitoring-demo-app
cd monitoring-demo-app
创建 requirements.txt 并添加以下内容：
Flask
保存文件（Ctrl + O，回车保存，Ctrl + X 退出）。
安装 Flask：
sudo yum install -y python3-pip
pip3 install --user -r requirements.txt
创建应用文件 app.py 并保存（Ctrl + O，回车，Ctrl + X）。
授予日志文件写入权限：
sudo touch /var/log/monitoring-demo-app.log
sudo chown ec2-user:ec2-user /var/log/monitoring-demo-app.log
### 步骤 5：运行应用并验证其工作
启动应用：
python3 app.py
通过浏览器或 curl 测试：[http://:](http://:)
同时测试事件端点（后续会用到）：
- [http://:5000/health](http://:5000/health) → 检查健康状态
- [http://:5000/error](http://:5000/error) → 返回错误信息
- [http://:5000/slow](http://:5000/slow) → 约 10 秒后响应
- [http://:5000/crash](http://:5000/crash) → 杀死应用进程
此时，应用已可运行，但它是以前台方式运行的。接下来我们将让它可靠地以后台方式运行。
### 步骤 6：以后台服务方式运行应用
这使设置更接近真实服务器。创建一个 systemd 服务文件：
sudo nano /etc/systemd/system/monitoring-demo.service
粘贴以下配置（保持原样）：
[Unit]
Description=Monitoring Demo Flask App
After=network.target
[Service]
User=ec2-user
WorkingDirectory=/home/ec2-user/monitoring-demo-app
ExecStart=/usr/bin/python3 /home/ec2-user/monitoring-demo-app/app.py
Restart=always
RestartSec=
[Install]
WantedBy=multi-user.target
重新加载 systemd 并启动服务：
sudo systemctl daemon-reload
sudo systemctl start monitoring-demo.service
sudo systemctl enable monitoring-demo.service
验证其运行状态：
sudo systemctl status monitoring-demo.service
一旦应用由 systemd 管理，它将在后台持续运行。
### 步骤 7：最终基线检查
在继续之前，确认：
- EC2 实例正在运行
- /health 返回成功
- /error 调用返回 500
- /crash 停止应用（用于后续事件模拟）
- 服务在崩溃后自动重启
这个基线很重要，因为接下来的章节将专注于使用监控和告警检测这些故障。
## 理解监控与关键指标
现在应用已运行，下一个问题是什么？我们应该在生产环境中监控什么？
监控不是收集所有信息。而是收集能告诉我们系统是否健康的正确信号。
本节将在接触 AWS 工具之前，建立对监控的清晰思维模型。
### 本项目将监控的关键指标
对于我们的监控演示应用，我们将关注一组小但现实的指标：
- **CPU 利用率**：指示 EC2 实例负载
- **应用可用性**：指示服务是否可访问
- **错误响应（HTTP 5xx）**：指示应用层故障
- **响应延迟**：指示性能下降
这反映了 DevOps 团队开始监控新服务或小型服务的方式。
### 这如何与事件响应关联
监控不是最终目标。它用于支持事件响应。流程如下：
- 指标变化
- 告警触发
- 工程师调查日志
- 识别根本原因
- 系统恢复
每一步都依赖于**良好的监控信号**。
## 使用 Amazon CloudWatch 设置监控
现在应用已运行，并且我们理解了应监控的内容，是时候在 AWS 上设置监控了。
本节将使用 Amazon CloudWatch 来观察我们的 EC2 实例及其上运行的 Python 应用。
我们将从简单开始：首先查看默认指标，然后启用应用日志监控。
运行 EC2 实例时，AWS 会自动将基本系统指标发送到 CloudWatch。这些
包括 CPU 利用率、网络流量和磁盘活动。我们的工作是知道在哪里找到这些指标，理解其含义，并为应用级可见性扩展监控。
### 步骤 1：在 CloudWatch 中查看 EC2 指标
- 打开 **AWS 管理控制台**
- 导航至 **CloudWatch**
- 在左侧菜单中点击 **指标**
- 选择 **EC2 → 每实例指标 → 所有指标 → 每实例指标**
- 按实例 ID 选择你的 EC2 实例
你将看到如下指标图表：
- **CPUUtilization**
- **NetworkIn / NetworkOut**
理解你看到的内容：
- CPU 使用率的峰值通常表示负载
- 平直线条通常表示系统空闲
- 突然下降可能表示崩溃或重启
此时，CloudWatch 已经告诉我们服务器的行为表现。
### 步骤 2：安装 CloudWatch 代理
系统指标很有用，但它们无法告诉我们应用在做什么。要监控应用行为，我们需要将应用日志发送到 CloudWatch。
在 EC2 实例上安装 CloudWatch 代理：
sudo yum install -y amazon-cloudwatch-agent
CloudWatch 代理负责：
- 将日志发送到 CloudWatch
- 在配置后发送额外指标
### 步骤 3：配置应用日志收集
我们的 Python 应用作为 **systemd 服务** 运行，这意味着其日志写入系统日志。
为可靠收集应用日志，我们配置 CloudWatch 直接从 systemd 读取日志。
创建配置目录（如果不存在）：
sudo mkdir -p /opt/aws/amazon-cloudwatch-agent/etc
创建 CloudWatch 代理配置文件：
sudo nano /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
粘贴以下配置：
{
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/monitoring-demo-app.log",
"log_group_name": "monitoring-demo-app-logs",
"log_stream_name": "{instance_id}",
"timezone": "UTC"
} ] } } } }
保存并退出文件（Ctrl + O → 回车 → Ctrl + X）。
此配置告诉 CloudWatch 收集由我们的 Python
服务写入的应用日志文件。应用将日志写入 /var/log/monitoring-demo-app.log，CloudWatch
代理将持续读取此文件并将日志条目发送到 CloudWatch。
#### 启动 CloudWatch 代理
使用配置文件启动代理：
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config \
-m ec2 \
-c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \
-s
### 步骤 4：验证 CloudWatch 中的日志
- 返回 **CloudWatch 控制台**
- 点击 **日志 → 日志组**
- 查找名为：monitoring-demo-app-logs 的日志组
- 打开你的 EC2 实例对应的日志流
你应该现在看到：
- 应用访问日志
- 错误信息
- 访问 /error、/slow 或 /crash 时生成的日志
这确认了 CloudWatch 代理正在工作，应用日志正在被收集，并且
CloudWatch 正在接收实时数据。
此时，EC2 系统指标和应用日志已流入 CloudWatch。
监控始于可见性
- 告警产生于**之后**
- 理解正常行为先于定义阈值
我们采用相同的方法。
## 创建告警与通知
我们已有可见性——可以看到 EC2 指标和应用日志。我们知道在检查 CloudWatch 后何时出错。本节将配置在出现问题时自动通知我们的告警。
### 什么是告警？
告警是一个**信号**，表示：“某重要内容刚刚越过了限制。你应该查看它。” 告警由指标触发，自动发送，旨在引起注意。
为保持真实且简单，我们将创建以下告警：
- **高 CPU 使用率** → 表示负载或失控进程
- **应用错误** → 表示用户可见的故障
这反映了真实系统中监控的引入方式。
### 步骤 1：创建用于通知的 SNS 主题
CloudWatch 不能直接发送通知。它使用 **Amazon SNS（简单通知服务）**。
- 转到 **AWS 控制台 → SNS**
- 点击 **主题 → 创建主题**
- 主题类型：**标准**
- 命名主题：monitoring-alerts
- 创建主题
### 步骤 2：将你的邮箱订阅到 SNS 主题
- 打开新创建的 SNS 主题
- 点击 **创建订阅**
- 协议：**Email**
- 端点：_(你的邮箱地址)_
- 创建订阅
- 你将收到确认邮件；点击确认订阅再继续
⚠ **在订阅确认前，告警不会送达。**
### 步骤 3：创建 CPU 使用率告警
现在我们将基于 **CloudWatch 指标** 创建第一个告警。
- 转到 **CloudWatch → 告警**
- 点击 **创建告警 → 选择指标**
- 选择：**EC2 → 每实例指标** → 选择你的实例 → **CPUUtilization**
- 点击 **选择指标
配置告警** - 设置以下值：
- 统计：**平均值**
- 周期：**5 分钟**
- 阈值类型：**静态**
- 条件：CPUUtilization > 70
这意味着：CPU 必须持续高 10 分钟——短时峰值不会触发告警。
**配置通知：** 告警状态触发：**In alarm**，选择 SNS 主题：monitoring-alerts
- 命名告警：high-cpu-usage
- 审核并创建告警
### 步骤 4：触发告警（测试）
为正确理解告警，我们必须看到其触发。在 EC2 实例上模拟 CPU 负载：
yes > /dev/null &
此命令消耗 CPU。几分钟后，CPU 使用率将上升，告警将进入
ALARM 状态。你将收到电子邮件通知。
停止负载：
killall yes
此时：
- 监控已完全设置
- 日志已集中收集
- 告警自动通知我们
- 我们不再需要“监视”系统
## 事件调查与响应
我们已完成：部署运行中的应用、设置监控与日志、创建告警、验证通知。
现在通过处理真实事件完成闭环。我们将模拟一个问题，使用 CloudWatch 进行调查，并以 DevOps 工程师在真实生产环境中的方式响应。
**事件** 是任何影响系统可靠性、性能或可用性的事件，触发告警并需要调查和行动。事件并不罕见，重要的是**处理的速度与冷静程度**。
### 场景：高 CPU 告警触发
假设发生以下情况：你收到一封告警邮件：
ALARM: high-cpu-usage
该告警表明 EC2 实例上持续高 CPU 使用率。用户可能开始体验响应缓慢。
你的目标是：确认问题、理解原因、采取纠正措施并验证恢复。
### 步骤 1：确认告警
对任何告警的第一反应是**确认**，而非立即操作。这意味着：你已看到告警，了解触发它的指标，并开始调查。
在真实团队中，这通常通过 Slack、PagerDuty 或值班轮班完成。对于本项目，告警邮件即足够。
### 步骤 2：查看 CloudWatch 中的告警详情
- 打开 **CloudWatch → 告警**
- 选择 high-cpu-usage 告警
查看：指标名称、阈值、时间范围及图表行为。
你应该看到：CPU 使用率高于定义阈值，并且持续时间较长。这确认告警是真实的，而非噪音。
### 步骤 3：关联系统指标
接下来扩展视图。
- 打开 **CloudWatch → 指标**
- 查看：CPUUtilization、NetworkIn、NetworkOut
观察：
- 突然的峰值
- 持续的负载
- 告警时间附近的模式
这有助于回答：_“这是系统范围的问题还是短时峰值？”_
### 步骤 4：调查应用日志
**指标告诉你** 哪里 **出错了。日志告诉你** 为什么。
- 转到 **CloudWatch → 日志 → 日志组**
- 打开：monitoring-demo-app-logs
- 选择你的 EC2 实例对应的日志流
- 关注告警时间戳附近的日志
查找：错误信息、重复请求、慢响应、异常行为。这将指标与应用行为联系起来。
### 步骤 5：识别根本原因
根据调查，你可能得出：
- 一个进程消耗了过多
- 一种请求模式导致负载
- 测试命令（yes > /dev/null）正在运行
- 应用处于压力之下
此时，你应该能明确表述：_“告警是由持续 CPU 使用率高引起的，原因是某个资源密集型进程。”_
### 步骤 6：采取纠正措施
纠正措施取决于原因。对于本项目，纠正措施包括：
- 停止 CPU 密集型进程
- 如需要，重启应用服务
- 验证系统稳定性
示例：
killall yes
纠正操作后：CPU 使用率应下降，应用响应应恢复。
### 步骤 7：验证恢复
始终确认恢复。
- 返回 **CloudWatch 告警**
- 确认状态从 ALARM 变为 OK
- 检查指标确保 CPU 已稳定
- 验证应用正常响应
恢复确认与检测同样重要。
### 步骤 8：关闭事件
关闭事件意味着：系统稳定、根本原因已理解、无进一步行动必要。
在真实团队中，这可能包括：
- 编写简短的 incident 记录
- 分享经验教训
- 如需要，调整告警阈值
## 结论
在整个项目中，我们：
- 在 EC2 上部署并管理了一个**生产风格的 Python 应用程序**
- 使用 Amazon CloudWatch 实现了**基础设施与应用监控**
- 集中了**应用日志**，实现实时可见性与调试
- 创建了**CloudWatch 告警**，检测异常系统行为
- 配置了**SNS 通知**，自动接收告警
- 模拟了真实事件并实践了**端到端事件调查与响应**
- 验证了系统恢复并负责任地关闭了事件
## 清理步骤
为避免持续产生 AWS 费用并保持账户整洁，请完成以下清理步骤。
### 1. 终止 EC2 实例
- 转到 **EC2 控制台 → 实例**
- 选择本项目中使用的 EC2 实例
- 点击 **实例状态 → 终止实例**
### 2. 删除 CloudWatch 告警
- 转到 **CloudWatch 控制台 → 告警**
- 选择创建的告警（例如 high-cpu-usage）
- 点击 **操作 → 删除**
### 3. 删除 CloudWatch 日志组
- 转到 **CloudWatch 控制台 → 日志 → 日志组**
- 选择：monitoring-demo-app-logs
- 点击 **操作 → 删除日志组**
这将移除存储的应用日志并防止日志存储费用。
### 4. 删除 SNS 主题
- 转到 **SNS 控制台 → 主题**
- 选择主题：monitoring-alerts
- 点击 **删除**（这也会移除所有相关的邮件订阅）
### 5. 删除 IAM 角色（可选）
如果该 IAM 角色仅为本项目创建：
- 转到 **IAM 控制台 → 角色**
- 选择角色：EC2-CloudWatch-Agent-Role
- 分离 CloudWatchAgentServerPolicy
- 删除角色
如果你计划将来重用它，可以保留。
## 备注
- **监控** 应被视为必需项，而非可选项
- **告警** 必须可操作，而非噪声
- **日志** 是根本原因分析的关键
- 始终在信任告警前进行测试
- **事件响应** 关乎流程与清晰，而非恐慌
标签：Amazon CloudWatch, Amazon SNS, AWS, CloudWatch Alarms, CloudWatch Logs, CloudWatch Metrics, DPI, SaaS运维, 云监控, 互联网扫描, 代理支持, 可视化仪表盘, 告警, 告警路由, 告警通知, 客户体验, 快速恢复, 指标监控, 故障检测, 日志聚合, 日志采集, 模拟故障, 漏洞利用检测, 生产环境监控, 监控, 自动恢复, 运维监控, 逆向工具, 通知推送