prudhviponnada/Automated-Incident-Response-System-FOR-LINUX
GitHub: prudhviponnada/Automated-Incident-Response-System-FOR-LINUX
该系统通过实时监控基础设施状态，自动检测故障、分类事件并通过 Ansible 执行零接触修复，旨在降低关键网络事件的平均恢复时间。
Stars: 0 | Forks: 0
# 自动化事件响应系统（Linux 版）
一个自动化、轻量级的网络运营中心（NOC）编排器，旨在检测基础设施故障、生成标准 JSON 警报，并执行一级自动分类和零接触修复。
该项目模拟了企业级的 SRE/NOC pipeline，弥合了基础设施监控与自动修复之间的鸿沟，显著降低了关键网络事件的平均恢复时间（MTTR）。
## 🚀 核心功能
* **实时状态监控：** 使用内部 Docker 网络 IP 动态持续轮询目标节点，监控 HTTP 响应、CPU 使用率和网络延迟。
* **智能决策引擎：** 自动将事件分类为四种不同的故障类型（节点离线、应用错误、CPU 飙升、高延迟），并将它们路由到正确的修复 playbook。
* **JSON 警报生成：** 自动将故障数据结构化为标准 JSON payload，模拟企业级 webhook 警报。
* **零接触修复：** 集成 Ansible，在确认故障的那一刻立即执行特定的恢复 playbook，消除了手动 NOC 调查时间。
* **自动化事后报告：** 为每个已解决的事件生成带有时间戳的文本报告，计算精确的平均恢复时间（MTTR）以满足 SLA 合规性。
## 🛠️ 技术栈
* **语言：** Python 3
* **基础设施：** Docker Engine & Docker Compose
* **配置管理：** Ansible
* **系统自动化：** `subprocess` 模块，用于原生操作系统和容器引擎交互
## 📂 项目结构
```
├── docker-compose.yml # Provisions the simulated network nodes
├── detector_linux.py # The Watchdog: monitors nodes, CPU, and latency
├── incident_manager_linux.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_linux.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-LINUX
```
启动模拟的网络环境：
# **Bash**
```
docker compose up -d
```
## 💻 **使用与演示**
要查看自动化事件生命周期的实际运行情况，您需要打开三个独立的终端窗口。
* 终端 1：启动编排器
此脚本充当自动化的 NOC 代理，等待警报。
# 终端 1：启动主编排器 **Bash**
```
python3 incident_manager_linux.py
```
# 终端 2：启动 watchdog
启动检测器。
此脚本持续监测网络环境。
```
python3 detector_linux.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 的替代方案）
高延迟（原生 Linux 三层流量整形）架构说明：由于我们运行在原生 Linux 内核上，我们可以利用原生的 netem（网络模拟器）流量控制模块。此命令直接操纵容器的虚拟网络接口，将所有传出数据包延迟 3 秒，从而自然触发 1.5 秒的 SLA 违规。（注意：要求容器以 NET_ADMIN 权限运行）。
```
docker exec --privileged failing_router sh -c "apk add --no-cache iproute2 && tc qdisc add dev eth0 root netem delay 3000ms"
```
## **预期输出与报告**
一旦触发故障：
1. detector-linux.py 立即识别出性能下降，对故障类型进行分类，写入 active_alert.json，然后停止运行。
2. incident_manager_linux.py 检测到 JSON payload，读取 failure_type，并触发相应的 Ansible playbook。
3. Ansible 修复节点。
4. 编排器生成具体的事后报告（例如：report_INC-123456.txt），记录确切的平均恢复时间（MTTR）。
留下您宝贵的反馈，我乐于接受建议
标签：Ansible, Docker, NOC, SRE, 偏差过滤, 安全防御评估, 版权保护, 系统提示词, 自动化响应, 自动化运维, 请求拦截, 运维