YogithaIshwaryaMoganti/ai-incident-copilot

# AI 事件响应 Copilot 一个真实的、自我监控的 Spring Boot 服务。它暴露了真实的业务 endpoint、真实的 Micrometer 指标，以及会导致真实性能下降的真实混沌注入 endpoint。一个定时监控器会读取其自身的 真实指标，检测真实的异常，并将其移交给一个 **Java 原生** 的 LLM 工具调用 agent 进行调查并提出建议行动—— 该行动只会在明确的人类批准点击下才会执行。 这是四个作品集项目中的第四个，也是最后一个——刻意填补了前三个项目（全为 Python）留下的 Java 空白。 有关完整设计，请参阅 [`docs/architecture.md`](docs/architecture.md)，包括关于“监控其内部包含的真实服务”的决策，以及在此过程中 发现并修复的真实数据质量 bug；有关评估状态，请参阅 [`docs/eval-report.md`](docs/eval-report.md)。 ## 为什么做这个项目 - **Agent 推理所基于的一切都是真实的**，而非捏造的：真实的 HTTP endpoint、 真实的由 Thread.sleep 引发的延迟、真实的抛出异常、真实的 Micrometer 指标、 真实的 Logback 日志行、来自 GitHub 和 Cloudflare 公共状态页面的真实历史事件。 - **Agent 本身就是 Java**，而不是“Java 负责基础管道，而 Python 负责处理 AI 部分”——它通过 HTTP 直接调用 Anthropic 的 API（Maven Central 上不存在官方的 Java SDK）， 这正是本项目真正的核心所在。 - **真实的批准关卡**：建议的行动只能通过明确的 `/approve` endpoint 到达。不存在任何会自动执行该操作的代码路径。 - **真实的公司网络坑，已记录在案而非隐藏**：这台开发机器的 网络会拦截 TLS（Zscaler）——请参阅下文的“在公司网络上运行”。 ## 当前状态 与项目 2 和 3 存在相同的诚实差距——agent 的核心机制需要进行实时的 LLM 调用， 且没有回退层级。在没有任何 API key 的情况下验证如下： - 混沌注入确实导致了真实测量指标的性能下降（实时确认：延迟 混沌将真实的最大延迟从约 20ms 变为约 307ms；错误率混沌产生了真实的 47 个 失败请求对比 106 个成功请求）。 - 异常检测器能正确地对真实的注入混沌做出反应，并在 健康的基线上保持安静——已实时确认，包括观察到滚动基线的自适应过程。 - 历史事件客户端从 GitHub 和 Cloudflare 的公共 状态页面获取真实数据（实时确认：缓存了 100 个真实事件）。 - Agent 循环的控制流（工具调用后报告、不报告、针对同一持续问题防止重复触发的 60 秒冷却时间）已通过 脚本化的虚假 LLM 客户端确定性地验证——23 个后端测试通过，其中任何一个都不需要实时 API。 - 后端（Maven/JUnit）和前端（Next.js）均能干净地构建/lint/测试；整个 系统可以端到端运行，并且在未设置 API key 触发时，会优雅地报告“ANTHROPIC_API_KEY is not set”，而不会崩溃。 等待个人的 `ANTHROPIC_API_KEY`：一个真实的已调查事件，以及来自 `evals/run_evals.py` 的真实根本原因分类准确度。 ## 在本地运行 ### 后端 ``` cd backend cp ../.env.example .env # add your OWN personal Anthropic API key export ANTHROPIC_API_KEY=... # Spring reads it directly from the environment mvn test # unit tests — no live API needed mvn spring-boot:run # starts on :8423 ``` ### 前端 ``` cd frontend npm install npm run dev ``` 打开 http://localhost:3000，点击“Inject 400ms latency”或“Inject 70% error rate”， 在仪表板上观察，大约 10-20 秒内会出现一个新事件。 ### 运行评估 在后端运行的情况下（并且配置了真实的 key）： ``` python3 evals/run_evals.py ``` 通过 HTTP 驱动正在运行的服务：注入六个具有已知真实情况的受控真实故障，轮询 agent 的报告，并检查根本原因分类准确度。 ### 在公司网络上运行 如果您的网络存在拦截 TLS 的安全软件（Zscaler 等），Java 的 默认 trust store 将不信任其 root CA，并且实时调用（Statuspage API、Anthropic） 将失败并报错 `PKIX path building failed`。解决方法：导出您的公司 root CA 并 将其导入 Java trust store，然后让 JVM 指向它： ``` keytool -importcert -noprompt -alias corp-root -file corp-root.pem \ -keystore ~/.local/java-truststore/cacerts-with-corp-root -storepass changeit export JAVA_TOOL_OPTIONS="-Djavax.net.ssl.trustStore=$HOME/.local/java-truststore/cacerts-with-corp-root -Djavax.net.ssl.trustStorePassword=changeit" ``` 在普通网络或 CI 中不需要（GitHub Actions runner 不在这样的代理之后）。 ## API - `GET /api/status` — 当前指标窗口、混沌状态、历史事件缓存大小。 - `POST /api/chaos/latency` `{"ms": 400}` / `POST /api/chaos/error-rate` `{"rate": 0.7}` / `POST /api/chaos/reset` - `GET /api/incidents` / `GET /api/incidents/{id}` - `POST /api/incidents/{id}/approve` — 唯一能执行真实操作的路径。 - `POST /api/incidents/{id}/dismiss` ## 项目布局 ``` docs/ architecture.md, eval-report.md backend/src/main/java/.../ orders/, chaos/ real business endpoints + real chaos injection monitoring/ MetricsReader, AnomalyDetector, ScheduledMonitor, log ring buffer incidents/ Statuspage client + cache (GitHub/Cloudflare) llm/ raw-HTTP Anthropic client (no SDK exists) agent/ the tool-calling loop, tools, approval-gated executor tracing/ OpenTelemetry Java SDK setup backend/src/test/ unit tests, incl. a fake-LLM-client agent loop test evals/ controlled real fault-injection scenarios + Python eval driver frontend/ Next.js dashboard ``` ## 许可证 MIT

标签：AIOps, API集成, JS文件枚举, Spring Boot, 可观测性, 域名枚举, 应急处置, 故障演练, 用户代理, 逆向工具