Shreya-516/incident-response-agent

# 自主事件响应 Agent 一个 AI 驱动的自主 Agent，可以检测生产环境事故、分析根本原因，并自动生成结构化的事件报告 —— 无需人工干预。 当生产环境警报触发时，该 Agent 会从受影响的服务获取日志，使用 RAG 搜索过往事件的知识库，利用 Gemini AI 推断根本原因，并输出包含逐步修复建议的结构化报告 —— 全程在 5 分钟内完成。 ## 解决的问题 每家大型科技公司都有网站可靠性工程 (SRE) 团队每天处理这个问题。当生产系统在凌晨 2 点崩溃时，值班工程师会被唤醒，手动逐行查阅数千行日志，检查仪表盘，交叉核对过往事件，并弄清楚哪里出了问题 —— 这个过程需要 30 分钟到几个小时。停机的每一分钟都会给公司造成数千美元的损失。该 Agent 彻底消除了这种手动调查工作。 ## 架构 ``` Schedule Trigger (n8n) ↓ Mock Alert Generator (Code Node) ↓ HTTP Request to Flask API (localhost:5000/analyze) ↓ Incident Response Agent (Python) ├── Fetch Logs (from affected service) ├── Fetch Metrics (CPU, memory, latency, connections) ├── Search Knowledge Base (ChromaDB semantic search) ├── Reasoning Loop (Gemini AI) └── Generate Structured Report ↓ Streamlit Dashboard (Visualization) ``` ## 各文件功能 | 文件 | 角色 | 描述 | |------|------|-------------| | `agent.py` | 核心 Agent | 获取日志和指标，在 ChromaDB 中搜索类似的过往事件，将所有信息发送给 Gemini 进行根本原因分析，生成结构化事件报告 | | `knowledge_base.py` | RAG 记忆 | 将 4 个过往事件作为向量嵌入存储在 ChromaDB 中。支持语义搜索 —— 根据含义而非仅靠关键词查找相似事件 | | `api_server.py` | Flask 后端 | 将 Agent 暴露为 REST 端点，以便 n8n 可以通过 HTTP 自动触发它 | | `app.py` | Streamlit 仪表盘 | 用于手动测试的可视化界面 —— 选择事件场景，点击运行，查看完整报告 | | `n8n_workflow.json` | 自动化配置 | n8n 工作流定义 —— 计划触发器每 5 分钟触发一次，生成模拟警报，调用 Flask API | ## 事件报告结构 生成的每份报告包含： - **事件 ID** — 带时间戳的唯一标识符 - **受影响服务** — 哪个服务触发了警报 - **严重程度** — CRITICAL / HIGH / MEDIUM - **检测到的根本原因** — 有日志和指标证据支持的具体诊断 - **置信度** — HIGH / MEDIUM / LOW - **修复步骤** — 3 个立即可行的修复步骤 - **预计恢复时间** — 恢复服务所需的时间 - **推理过程** — 解释诊断过程的完整思维链 - **状态** — OPEN / RESOLVED ## 技术栈 - **Python** — 核心应用程序语言 - **Google Gemini API** (`gemini-2.5-flash-lite`) — 根本原因分析和推理 - **ChromaDB** — 用于对过往事件进行语义搜索的向量数据库 (RAG) - **Flask** — 用于程序化访问的 REST API 后端 - **Streamlit** — 用于手动操作的交互式仪表盘 - **n8n** — 工作流编排和自动化调度 - **python-dotenv** — 安全的 API 密钥管理 ## RAG 在此的工作原理 RAG (检索增强生成) 用于赋予 Agent 对过往事件的制度记忆： 1. 4 个历史事件作为向量嵌入存储在 ChromaDB 中 2. 当新警报触发时，ChromaDB 语义搜索查找最相似的过往事件 3. 这些过往事件 —— 包括其解决方案 —— 被包含在 Gemini 提示词中 4. Gemini 综合推理当前日志 + 指标 + 过往事件模式 这意味着随着更多事件被添加到知识库中，Agent 会随着时间的推移变得更加智能。 ## 支持的事件场景 | 场景 | 服务 | 发生了什么 | |----------|---------|---------------| | 数据库内存不足 | database | OOM 异常，连接池耗尽，内存占用率达 98% | | 缓存层故障 | cache-layer | Redis 无法访问，缓存未命中率高达 95% | | API 超时级联 | api-service | 错误率 45%，延迟 5000ms，请求丢失 | ## 示例输出 ``` { "incident_id": "INC-20260307004622", "timestamp": "2026-03-07T00:46:22.634748", "affected_service": "database", "severity": "CRITICAL", "alert_message": "Database process killed due to out of memory exception", "detected_root_cause": "Out of Memory exception triggered by sustained high memory usage (98%) and exhausted connection pool (500/100)", "confidence": "HIGH", "remediation_steps": [ "Restart the database process to clear memory and reset connection limits", "Investigate and address the cause of sustained high memory usage", "Review and potentially increase connection pool size" ], "estimated_recovery_time": "15-30 minutes", "status": "OPEN" } ``` ## 已知局限与未来改进 - **模拟数据：** 日志和指标目前是硬编码的模拟。生产环境改进应连接到真实数据源 —— Datadog, Splunk, Prometheus 或 Grafana。 - **警报推送：** n8n 目前将报告存储在执行日志中。添加 Slack 或 PagerDuty 节点将自动通知值班工程师。 - **知识库增长：** 目前存储 4 个过往事件。建立一个反馈循环，将已解决的事件自动添加到 ChromaDB 中，将使 Agent 的准确性逐步提高。 - **单服务分析：** 当前实现一次分析一个服务。多服务关联 —— 检测跨服务的级联故障 —— 将是生产环境中的一个重大增强功能。 ## 项目结构 ``` incident-response-agent/ │ ├── agent.py # Core agent logic — reasoning and report generation ├── knowledge_base.py # ChromaDB RAG setup and semantic search ├── app.py # Streamlit dashboard — interactive frontend ├── api_server.py # Flask backend — exposes agent as REST endpoint ├── n8n_workflow.json # n8n workflow definition for automated scheduling ├── .env # API keys (not committed to version control) ├── .gitignore # Excludes venv, .env, chroma_data, __pycache__ └── README.md ``` ## 作者 Shreya | B.Tech CSE | [GitHub](https://github.com/Shreya-516)

标签：AIOps, ChromaDB, DLL 劫持, Flask, Gemini, Kubernetes, n8n, Python, RAG, Ruby, SRE, Streamlit, 人工智能, 偏差过滤, 向量数据库, 告警处理, 大语言模型, 工作流自动化, 故障排查, 无后门, 根因分析, 检索增强生成, 生产环境, 用户模式Hook绕过, 知识库, 站点可靠性工程, 自主代理, 自动化运维, 访问控制, 运维自动化, 逆向工具