sbolla-ai/log-triage-agent

# Log Triage Agent [](LICENSE) [](pyproject.toml) [](#路线图) ## 为什么开发此项目 每个值班工程师都在凌晨 3 点做过同样的事情：将一行日志粘贴到 Slack 中，跨五个服务 grep "error"，然后滚动屏幕、胡乱猜测。分诊所需的信息几乎总是*存在于日志中*——只是分散在数百万行代码中，以及十几个没人记录下来的团队隐性知识模式里。这个 Agent 将这种肌肉记忆代码化：检索正确的日志切片，对异常进行聚类，与过往事件进行交叉比对，最后交给你一份附带证据的排序假设清单。 它的范围被刻意缩小了。它不会呼叫任何人，不会进行修复，也不会假装去根除代码 Bug。它缩短了事件响应中的*阅读*步骤——这是人类在压力下最不擅长的环节。 ## 功能特性 - **摄取**：通过可插拔的适配器从 Loki、Elasticsearch、CloudWatch 或普通文件中提取日志 - **检索**：使用混合搜索检索相关时间窗口：BM25 用于精确匹配 token（错误代码、堆栈帧），加上 embedding 用于语义召回（"connection reset" ≈ "peer closed"） - **聚类**：通过日志模板挖掘（Drain3）对异常进行聚类，将数百万行嘈杂的日志压缩成少数几个模式 - **交叉比对**：与包含过往复盘和手册的事件知识库进行对比 - **推理**：通过有限的工具调用循环进行——LLM 针对日志存储发出后续查询，而不是凭空捏造“可能”发生的事情 - **输出**：排序后的假设列表：每个假设都包含置信度得分、引用的日志行、关联的过往事件以及建议的后续查询 ## 结果 | 指标 | 基线（人工 grep） | 使用 Agent | 差值 | |---|---|---|---| | 首次得出假设的中位时间 | _待填写_ | _待填写_ | _待填写_ | | 前 3 名中的正确原因 | _待填写_ | _待填写_ | _待填写_ | | 人工必须阅读的日志行数 | _待填写_ | _待填写_ | _待填写_ | | 单次分诊成本 (USD) | — | _待填写_ | — | ## 架构 ``` log store ──▶ adapter ──▶ retriever (BM25 + embeddings) ──┐ ├─▶ bounded tool-use loop ──▶ ranked hypotheses Drain3 template miner ─────────────────────────────────────┤ │ + cited evidence incident KB (past post-mortems, runbooks) ─────────────────┘ │ + suggested next query └─ tools: search_logs, fetch_template, related_incidents ``` 详情请参阅 [`ARCHITECTURE.md`](ARCHITECTURE.md)。 ### 设计原则 1. **检索而非捏造。** LLM 如果没有引用的日志行，绝不会提出任何假设。 2. **模板优先于原始行。** 推理过程基于 Drain3 模板，而不是数百万行的日志洪流——让 LLM 看到信号，而不是噪音。 3. **有限推理。** 每次运行都有挂钟时间、token 和工具调用的上限。拒绝失控的 Agent。 4. **可插拔的日志后端。** 今天是 Loki，明天是 Elasticsearch/CloudWatch。适配器仅需约 100 行代码。 5. **评估框架即契约。** 每一个针对检索或 prompt 的修改都会通过回放的事件进行衡量。 ## 快速开始 ``` git clone https://github.com/sbolla-ai/log-triage-agent.git cd log-triage-agent uv sync cp .env.example .env # OPENAI_API_KEY, log-store endpoint uv run log-triage demo # runs against the bundled synthetic outage ``` 对真实的时间窗口进行分诊： ``` uv run log-triage run \ --service checkout-api \ --from "2026-07-12T14:00Z" \ --to "2026-07-12T14:20Z" ``` 运行评估框架： ``` uv run log-triage eval --suite basic --model gpt-4o ``` ## 路线图 - [x] Loki 适配器 + 混合检索器 - [x] Drain3 模板挖掘器 - [x] 带有证据引用的有限工具调用循环 - [x] 带有可回放事件的评估框架 - [ ] Elasticsearch 和 CloudWatch 适配器 - [ ] Slack 机器人：`/triage ` - [ ] 反馈循环：值班人员将某假设标记为正确 → 转化为黄金评估用例 ## 关于作者 我是 **Sreenivas Bolla** —— 拥有 16 年以上经验的 Principal SRE & Platform Engineer，曾在 **JPMorgan Chase、Capital One 和 SMBC** 搭建生产级平台。我交付过内部开发者平台、SLO 治理系统以及生产环境中的 Agentic AI —— 同时，我也是全球不到 50 名在真实的面向客户系统中运行 MCP 的工程师之一，该举措将 MTTR 降低了 75%。 `log-triage-agent` 是该技术栈中专注、不起眼但具有高杠杆效应的一环——它能为值班工程师在凌晨 3 点节省二十分钟的滚动屏幕时间。 - 🌐 [sbolla.dev](https://sbolla.dev) - 💼 [linkedin.com/in/sreenivas-bolla](https://linkedin.com/in/sreenivas-bolla) - ✉️ sbolla.tx@gmail.com ## 许可证 MIT — 详见 [LICENSE](LICENSE)。

标签：DLL 劫持, LLM Agent, Python, 大语言模型, 库, 应急响应, 无后门, 逆向工具