vipin612/smart-autoscale-incident-response
GitHub: vipin612/smart-autoscale-incident-response
一个展示应用性能自愈与事件响应的端到端演示系统,解决在本地与云端如何联动监控、扩缩容与自动恢复的问题。
Stars: 0 | Forks: 0
[](https://smart-autoscale-incident-response.onrender.com)






[Live Demo](https://smart-autoscale-incident-response.onrender.com) | [Quick Start](#quick-start-docker-compose) | [Render Deploy](#deploy-to-render) | [Kubernetes Lab](#kubernetes-lab-minikube) | [Monitoring](#monitoring) | [CI/CD](#cicd-pipeline)
## Live Demo
生产应用:
`https://smart-autoscale-incident-response.onrender.com`
尝试以下端点:
- `/` 用于仪表板 UI
- `/healthz` 用于健康检查
- `/status` 用于查看内存和运行时间
- `/api/info` 用于服务元数据
- `/load?duration=5000&intensity=100` 用于模拟 CPU 压力
## 本项目展示内容
| 领域 | 展示内容 |
|---|---|
| 应用 | 带有健康、就绪、指标和负载模拟端点的 Express 服务 |
| 可观测性 | 通过 `prom-client` 提供 Prometheus 指标,使用 `winston` 记录结构化日志,并配备 Grafana 仪表板 |
| 容器 | 多阶段 Docker 构建,目标是生产运行时 |
| 本地平台实验室 | Minikube 部署、服务暴露、基于 HPA 的自动伸缩、自我修复探针 |
| CI/CD | GitHub Actions 流水线,用于测试、Docker 镜像构建、Docker Hub 推送以及 Render 部署触发 |
| 项目组合价值 | 一个展示应用工程、运维思维和生产交付流程的单一仓库 |
## 架构
### 生产路径
```
Browser
-> Render web service
-> Node.js / Express app
-> /metrics, /healthz, /status, /api/info, /load
```
### 本地可观测性 + 自动伸缩实验室
```
Browser
-> Node.js app or Minikube service
-> Prometheus scrapes /metrics
-> Grafana visualizes dashboards
-> Alertmanager forwards alerts to local webhook receiver
-> HPA scales pods in Minikube during load tests
```
### CI/CD 流程
```
git push
-> GitHub Actions test job
-> Docker image build
-> Docker Hub push
-> Render deploy hook
```
## 项目结构
```
smart-autoscale-project/
├── app/
│ ├── src/
│ │ ├── __tests__/app.test.js
│ │ ├── public/index.html
│ │ └── index.js
│ ├── Dockerfile
│ ├── package.json
│ └── package-lock.json
├── k8s/
│ ├── deployment.yaml
│ ├── hpa.yaml
│ ├── namespace.yaml
│ └── service.yaml
├── monitoring/
│ ├── grafana/
│ ├── prometheus/
│ └── webhook/
├── .github/workflows/ci-cd.yml
├── docker-compose.yml
├── load-test.sh
└── README.md
```
## 先决条件
运行核心应用需要:
- Node.js 20+
- npm
- Docker Desktop
可选完整本地平台实验室需要:
- Minikube
- `kubectl`
快速版本检查:
```
node --version
npm --version
docker --version
minikube version
kubectl version --client
```
## 快速启动(Docker Compose)
这是运行包含应用、Prometheus、Grafana、Alertmanager 和 Webhook 接收器的完整本地堆栈的最快方式。
```
git clone https://github.com/YOUR_USERNAME/smart-autoscale-incident-response.git
cd smart-autoscale-incident-response
docker-compose up -d
docker-compose ps
```
本地服务:
| 服务 | URL | 说明 |
|---|---|---|
| 应用 UI | http://localhost:3000 | 主仪表板 |
| Prometheus | http://localhost:9090 | 指标浏览器 |
| Grafana | http://localhost:3001 | `admin / smartscale123` |
| Alertmanager | http://localhost:9093 | 告警路由 |
| 告警 Webhook 历史 | http://localhost:5001/history | 告警负载查看器 |
停止堆栈:
```
docker-compose down
```
同时重置卷:
```
docker-compose down -v
```
## 部署到 Render
生产应用已在 Render 上部署,该仓库与此设置非常契合,因为 Express 应用是自包含的,并在 3000 端口提供服务。
### 选项 1:从 Render 仪表板部署
1. 在 Render 中创建一个新的 Web 服务。
2. 连接你的 GitHub 仓库。
3. 使用以下设置:
| 字段 | 值 |
|---|---|
| 根目录 | `app` |
| 运行时 | `Node` |
| 构建命令 | `npm ci` |
| 启动命令 | `node src/index.js` |
| 环境变量 | `NODE_ENV=production` |
| 环境变量 | `PORT=3000` |
4. 部署并打开生成的 Render URL。
### 选项 2:通过 GitHub Actions 自动部署
你期望的部署流程如下:
```
push to main -> GitHub Actions -> Docker Hub image push -> Render deploy hook
```
在仓库设置中添加以下 GitHub 密钥:
| 密钥 | 用途 |
|---|---|
| `RENDER_DEPLOY_HOOK_URL` | 在 CI 通过后触发新的 Render 部署 |
获取方式:
`Render 仪表板 -> 你的服务 -> 设置 -> 部署钩子`
## Kubernetes 实验室(Minikube)
Render 托管生产应用,但本仓库中的 Kubernetes 清单仍然使该项目作为一个本地自动伸缩和自我修复演示非常强大。
### 1. 构建并推送镜像
```
docker login
docker build -t YOUR_DOCKERHUB_USERNAME/smartscale-app:latest ./app
docker push YOUR_DOCKERHUB_USERNAME/smartscale-app:latest
```
### 2. 更新部署镜像
编辑 `k8s/deployment.yaml` 并将镜像设置为你自己的 Docker Hub 仓库:
```
image: YOUR_DOCKERHUB_USERNAME/smartscale-app:latest
imagePullPolicy: Always
```
### 3. 启动 Minikube
```
minikube start --cpus=4 --memory=4096 --driver=docker
minikube addons enable metrics-server
```
### 4. 应用清单
```
kubectl apply -f k8s/namespace.yaml
kubectl apply -f k8s/deployment.yaml
kubectl apply -f k8s/service.yaml
kubectl apply -f k8s/hpa.yaml
```
### 5. 观察 rollout
```
kubectl get pods -n smartscale -w
```
### 6. 打开服务
```
minikube service smartscale-app-svc -n smartscale
```
## API 端点
| 端点 | 描述 |
|---|---|
| `GET /` | 仪表板 UI |
| `GET /healthz` | 健康探针 |
| `GET /ready` | 就绪探针 |
| `GET /api/info` | 服务元数据 |
| `GET /status` | 运行时、内存和运行时间信息 |
| `GET /load?duration=5000&intensity=100` | CPU 负载模拟 |
| `GET /metrics` | Prometheus 指标 |
## 负载测试
对于 Kubernetes 演示,打开多个终端并观察自动伸缩时的流量情况。
观察 HPA:
```
kubectl get hpa -n smartscale -w
```
观察 Pod:
```
kubectl get pods -n smartscale -w
```
运行 Linux 或 macOS 负载:
```
chmod +x load-test.sh
./load-test.sh http://$(minikube ip):30080 20 120
```
运行 Windows PowerShell 负载:
```
$IP = minikube ip
1..15 | ForEach-Object {
Start-Job -ScriptBlock {
param($ip)
for ($i = 0; $i -lt 20; $i++) {
try {
Invoke-WebRequest -Uri "http://$ip`:30080/load?duration=5000&intensity=100" -UseBasicParsing | Out-Null
} catch {}
}
} -ArgumentList $IP
}
Write-Host "Load running. Watch HPA and pods in the other terminals."
```
## 监控
### Prometheus
打开:
`http://localhost:9090`
常用查询:
```
sum(rate(http_requests_total{job="smartscale-app"}[1m]))
```
```
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
```
```
active_connections{job="smartscale-app"}
```
### Grafana
打开:
`http://localhost:3001`
登录:
`admin / smartscale123`
仪表板从 `monitoring/grafana/` 中的文件自动配置。
### 告警 Webhook
打开:
`http://localhost:5001/history`
这显示从 Alertmanager 接收到的告警负载。
## CI/CD 流水线
README 现在反映了更新的部署方向:Render 用于生产应用,Docker Hub 用于容器发布,Minikube 作为本地实验室而非 CI 部署目标。
预期阶段:
```
test -> build Docker image -> push to Docker Hub -> trigger Render deploy
```
你使用的仓库密钥:
| | 用途 |
|---|---|
| `SECRET` | Docker Hub 用户名 |
| `DOCKERTOKEN` | Docker Hub 访问令牌 |
| `KUBECONFIGSECRET` | 可选的 kubeconfig,用于手动或实验性的基于集群的部署 |
| `RENDER_DEPLOY_HOOK_URL` | Render 部署触发器 |
如果在流水线中保留 Kubernetes 部分,请仅用于真实的远程集群,而不是本地 Minikube kubeconfig。
## 故障排除
ESLint 在 CI 中失败
`app/package.json` 包含 lint 脚本,但 `eslint` 当前未列在 `devDependencies` 中。要么正确添加 ESLint,要么在流水线中移除 lint 步骤,直到你希望强制执行 lint 检查。
Minikube 镜像拉取失败
确保 `k8s/deployment.yaml` 指向你已推送的精确 Docker Hub 镜像,并且 `imagePullPolicy` 为 `Always`。
Render 部署在本地有效但在 CI 中无效
双重检查 `RENDER_DEPLOY_HOOK_URL` 是否已添加到 GitHub Actions 密钥中,并且服务配置为以 `app` 作为根目录。
GitHub Actions 在工作流解析时立即失败
不要在作业级 `if:` 表达式中直接引用 `secrets.*`。在步骤中验证密钥。
本地 kubeconfig 在 GitHub Actions 中失败
Minikube 的 kubeconfig 在 Windows 上通常包含本地证书文件路径,这些路径在 GitHub 托管的 Linux 运行器上不存在。如果向 CI 添加集群部署,请使用真实的远程集群配置。
## 技术栈
| 层级 | 技术 |
|---|---|
| 后端 | Node.js 20,Express |
| 指标 | `prom-client` |
| 日志 | `winston` |
| 测试 | Jest |
| 容器 | Docker |
| 编排实验室 | Kubernetes、Minikube、HPA |
| 监控 | Prometheus、Grafana、Alertmanager |
| 自动化 | GitHub Actions |
| 托管 | Render |
| 注册表 | Docker Hub |
### 作为一个 DevOps 组合项目构建
Node.js | Docker | Kubernetes | Prometheus | Grafana | GitHub Actions | Render
如果这个项目对你有帮助,请在仓库中点个星。
标签:API集成, Docker, GitHub Actions, GNU通用公共许可证, Grafana, Minikube, MITM代理, Mutation, NIDS, Node.js, WSL, 云端原生, 代理支持, 可观测性, 可视化, 后端开发, 告警, 子域名突变, 安全防御评估, 实时仪表盘, 容器化, 度量, 开发环境, 开源框架, 持续交付, 持续集成, 智能自动扩容, 本地测试, 特权提升, 生产环境, 监控, 自动伸缩, 自动化部署, 自动笔记, 自定义请求头, 自愈, 请求拦截