aminuiliyasu/Self-Healing-Infrastructure-with-AI-Driven-Incident-Response
GitHub: aminuiliyasu/Self-Healing-Infrastructure-with-AI-Driven-Incident-Response
一个基于规则引擎的 Kubernetes 自愈基础设施项目,通过 Prometheus 指标自动检测故障并执行重启或扩缩容等修复操作。
Stars: 0 | Forks: 0
# 具备事件响应能力的自愈基础设施
一个用于 Kubernetes 的监控和自动修复设置。Prometheus 抓取一个演示 Web 服务,一个 Python 引擎监控各项指标,通过一个轻量级的基于规则的根因分析步骤对事件进行分类,并通过重启或扩缩容 deployment 来自行修复常见问题。发生的所有操作都会被写入事件日志,并显示在 Web dashboard 上。
**技术栈:** Python、Kubernetes (Minikube)、Prometheus、Terraform、Docker、Bash、GitHub Actions
## 工作原理

1. 演示应用(`app/`)通过 `/metrics` 路径暴露请求、错误和延迟指标。
2. Prometheus(通过 Terraform 使用 Helm 安装)会在 `dev` 和 `staging` 命名空间中进行抓取。
3. 引擎(`engine/`)会轮询 Prometheus 并评估以下三条规则:
| 信号 | 根本原因 | 执行操作 |
|---|---|---|
| 目标宕机 (`up == 0`) | pod 不可达 | 重启 deployment |
| 高错误率 + 高 p95 延迟 | 过载 | 扩容 deployment |
| 高错误率,正常延迟 | 疑似应用 bug | 标记以供调查(扩容无济于事) |
| 仅高 p95 延迟 | 临近过载 | 扩容 deployment |
4. 修复操作通过 `automation/` 中的 Bash 脚本执行,并带有冷却时间(确保其不会陷入不断重启/扩容的死循环)、副本上限以及一个**默认开启**的 dry-run(空转)模式。
5. 每个事件在发生和指标恢复时各记录一次,因此日志可以提供真实的数据:事件总数、自动修复的数量以及平均恢复时间。
## 仓库布局
```
app/ demo Flask service with Prometheus metrics (+ /error and /slow test endpoints)
engine/ monitoring loop, rules, incident log, unit tests
dashboard/ read-only web UI: live metrics, incidents, remediations, MTTR
automation/ kubectl scale/restart scripts (dry-run by default)
k8s/ kustomize base + dev/staging overlays
terraform/ namespaces (dev, staging, monitoring) + Prometheus Helm release
monitoring/ Prometheus Helm values (scrape configs, NodePort)
scripts/ deploy.sh, inject_errors.sh
```
## 运行说明
需要 Docker、Minikube、kubectl、Terraform 和 Python 3.10+。
**1. 集群 + 基础设施**
```
minikube start
cd terraform && terraform init && terraform apply && cd ..
```
这将创建 `dev`、`staging` 和 `monitoring` 命名空间,并安装 Prometheus(NodePort 30090)。
**2. 部署应用**
```
./scripts/deploy.sh dev # or: ./scripts/deploy.sh staging
minikube service self-healing-app -n dev --url
```
**3. 启动引擎**
```
cd engine
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
export PROMETHEUS_URL=http://$(minikube ip):30090
export REMEDIATE=1 # actually run remediation scripts
export REMEDIATE_DRY_RUN=false # false = real kubectl commands
python3 main.py
```
引擎会为每个事件打印一行 JSON 数据,并将所有信息追加到 `data/incidents.jsonl` 中。
**4. Dashboard(可选)**
```
cd dashboard
pip install -r requirements.txt
export PROMETHEUS_URL=http://$(minikube ip):30090
python3 app.py # http://localhost:8080
```
## 演示:破坏并观察其自愈过程
```
# terminal 1:engine 在 REMEDIATE=1 下运行(见上文)
# terminal 2:针对 dev app 生成错误
./scripts/inject_errors.sh http://$(minikube ip):30051 200
```
在一两次轮询内,引擎就会触发一个 `high_error_rate` 事件,决定修复方案并运行相应的脚本。当错误率回落到阈值以下时,它会将该事件记录为已解决,并附上恢复时间。
你可以在 dashboard 上观察整个过程,或者使用以下命令查看总数:
```
cd engine && python3 summarize.py
```
若要模拟崩溃,请将应用扩缩容至零
(`kubectl scale deployment/self-healing-app -n dev --replicas=0`)——
`target_down` 规则会触发一次 rollout 重启。
这是演示运行后的 dashboard 状态——检测到了一个 `target_down` 事件,并通过 rollout 重停进行了自动修复;此外还有几个 `high_error_rate` 事件被正确分类为“扩容无济于事,请检查日志”并保持原样未作改动:

## 配置
所有引擎设置均为环境变量(默认值见 `engine/config.py`):
| 变量 | 默认值 | 含义 |
|---|---|---|
| `PROMETHEUS_URL` | `http://127.0.0.1:9090` | Prometheus 基础 URL |
| `APP_JOB` | `self-healing-app-dev` | 监控的抓取任务(对应 staging 环境使用 `-staging`) |
| `POLL_INTERVAL_SECONDS` | `15` | 规则评估频率 |
| `ERROR_RATE_THRESHOLD` | `0.05` | 触发事件的错误率/秒阈值 |
| `LATENCY_P95_THRESHOLD_SECONDS` | `0.5` | p95 延迟阈值 |
| `REMEDIATE` | `0` | `1` = 引擎可以运行修复脚本 |
| `REMEDIATE_DRY_RUN` | `true` | `true` = 仅打印 kubectl 命令 |
| `REMEDIATE_COOLDOWN_SECONDS` | `120` | 同一操作两次执行之间的最小间隔 |
| `SCALE_TARGET_REPLICAS` / `SCALE_MAX_REPLICAS` | `3` / `5` | 扩容目标数量和硬性上限 |
## 测试和 CI
```
cd engine && python3 -m unittest -v
```
GitHub Actions 会在每次推送/PR 时运行:引擎单元测试、带有 endpoint 冒烟测试的 Docker 构建、两个 overlay 的 `kubectl kustomize` 构建,以及 `terraform fmt`/`validate`(无需云厂商凭证)。
## 设计说明
- **默认 Dry-run。** 任何涉及集群的操作除非你明确选择开启,否则只会打印命令。能够进行扩缩容或重启的自动化操作即使在被误触发的状态下也应该是安全的。
- **冷却和上限。** 引擎不会在冷却窗口内触发两次相同的操作,并且扩容脚本会拒绝超过 `MAX_REPLICAS` 的限制。
- **基础设施用 Terraform,应用用 kustomize。** 命名空间和 Prometheus 是长期的基础设施;应用部署的频率要高得多,因此它们会通过一条独立的、更快的路径来执行。
- **基于规则,而非 ML。** 这里的“AI 驱动”是一个刻意简化的规则引擎。对于它所覆盖的故障模式,规则是易于调试且可预测的;如果未来要替换成更智能的方案,也只需修改 `engine/rules.py` 即可。
## 局限性 / 设想
- 规则仅关注瞬时值;没有趋势检测或在重启之间进行去重。
- 没有日志关联(Loki/ELK)—— 根因分析仅依赖指标。
- 告警集成(Slack webhook)将是下一个实用的添加功能。
## 许可证
MIT — 查看 [LICENSE](LICENSE)。
标签:AIOps, API集成, Python, 可观测性, 子域名突变, 应用安全, 无后门, 自动化运维, 自定义请求头, 自愈基础设施, 请求拦截, 逆向工具