prudhviponnada/Automated-Incident-Response-System-FOR-WSL2
GitHub: prudhviponnada/Automated-Incident-Response-System-FOR-WSL2
一款运行在 WSL2 上的 Python 自动化网络监控与事件响应系统，通过持续轮询检测基础设施故障并自动触发 Ansible 修复流程，大幅缩短事件平均恢复时间。
Stars: 0 | Forks: 0
# WSL2 自动化事件响应系统
一个自动化、轻量级的网络运营中心 (NOC) 编排器，旨在检测基础设施故障、生成标准 JSON 警报，并执行 L1（一线）自动化分诊。
该项目模拟了一个企业级警报 pipeline，弥合了基础设施监控与自动化修复之间的差距，显著降低了关键网络事件的平均恢复时间 (MTTR)。
## 🚀 核心功能
* **实时状态监控：** 使用内部 Docker 网络 IP 动态持续轮询目标节点。
* **JSON 警报生成：** 自动将故障数据结构化为标准 JSON payload，模拟企业级 webhook 警报。
* **零接触分诊：** 在检测到警报的瞬间执行 L1 诊断检查（例如，系统电源状态验证），从而消除人工 NOC 调查时间。
* **解耦架构：** 采用微服务方法，其中检测 (`detector.py`) 和编排 (`incident_manager.py`) 通过基于文件的队列独立运行。
* **审计日志：** 维护包含所有事件状态和自动操作的专业且带有时间戳的日志。
## 🛠️ 技术栈
* **语言：** Python 3
* **基础设施：** Docker & Docker Compose
* **系统自动化：** `subprocess` 模块，用于原生 OS 和 Container Engine 交互
* **日志记录：** 标准 Python `logging` 库
## 📂 项目结构
```
├── docker-compose.yml # Provisions the simulated network nodes
├── detector.py # The Watchdog: monitors nodes, CPU, and latency
├── incident_manager.py # The Master Orchestrator: routes alerts to Ansible
├── remediate.yml # Playbook: Fixes complete node outages
├── remediate_app.yml # Playbook: Fixes HTTP 500 / Config corruption
├── remediate_cpu.yml # Playbook: Fixes 100% Resource Exhaustion
├── remediate_network.yml # Playbook: Fixes Latency/QoS degradation
├── active_alert.json # The dynamic alert payload (generated dynamically)
└── incident_response.log # The system audit trail (generated dynamically)
```
## ⚙️ ** 安装与前置条件**
* 您的系统上需要安装 Python 3.x 和 Docker。
* 将此仓库克隆到您的本地计算机。
* 导航到项目目录：
# **Bash**
```
cd Automated-Incident-Response-System-for-WSL2
```
启动模拟网络环境：
# **Bash**
```
docker compose up -d
```
## 💻 **使用与演示**
要查看运行中的自动化事件生命周期，您需要打开三个独立的终端窗口。
* 终端 1：启动 Orchestrator
此脚本充当自动化 NOC agent，等待警报。
# 终端 1：启动 Master Orchestrator **Bash**
```
python3 incident_manager.py
```
# 终端 2：启动 watchdog
启动 Detector。
此脚本持续监控网络环境。
```
python3 detector.py
```
# 终端 3：**Bash**
触发模拟中断。
场景 1：节点离线 (硬宕机)。使模拟路由器崩溃以触发事件响应 pipeline：
```
docker stop failing_router
```
场景 2：应用错误 (灰度故障)
模拟开发者推送了损坏的 Nginx 配置，导致 HTTP 500 错误。
```
docker exec failing_router sh -c "echo 'events {} http { server { listen 80; location / { return 500; } } }' > /etc/nginx/nginx.conf && nginx -s reload"
```
场景 3：资源耗尽 (CPU 飙升)
注入无限循环以将容器的 CPU 满载至 100%。
```
docker exec -d failing_router sh -c "while true; do true; done"
```
场景 4：高延迟 (WSL2 替代方案)
架构说明：由于 WSL2 内核缺乏用于三层网络整形的 netem 流量控制模块，此场景通过注入一个故意将响应延迟 3 秒的自定义 Python HTTP 服务器，在七层模拟网络拥塞，从而触发 1.5 秒的 SLA 违规。
```
docker exec -d failing_router sh -c "apk add --no-cache python3 && nginx -s quit && python3 -c 'import time, http.server; class S(http.server.SimpleHTTPRequestHandler): \n def do_GET(self): time.sleep(3); self.send_response(200); self.end_headers()\nhttp.server.HTTPServer((\"\", 80), S).serve_forever()'"
```
## **预期输出与报告**
一旦触发故障：
1. detector.py 会立即识别掉线情况，对故障类型进行分类，写入 active_alert.json，然后停止运行。
2. incident_manager.py 检测到 JSON payload，读取 failure_type，并触发相应的 Ansible playbook。
3. Ansible 修复节点。
4. Orchestrator 生成特定的事后分析报告 (Post-Mortem Report)（例如，report_INC-123456.txt），记录确切的平均恢复时间 (MTTR)。
留下您宝贵的反馈，我乐于接受建议
标签：Ansible, Docker, Python, 安全防御评估, 无后门, 版权保护, 系统提示词, 自动化运维, 请求拦截