AI告警调查拆分
3 steps0 pieces3 Sources
LINEヤフー实习生霍永豪在开发AI Alert Watcher时,确立了将Kafka告警调查拆分为“确定性固定查询”与“探索性LLM分析”的架构范式。初期让LLM全权负责数据源识别、指标获取及报告生成,因超时、幻觉及格式错误导致调查整体失败;后期重构为Watcher通过Prometheus固定查询4项核心指标(Traffic, HOST, Critical Issues, Consumer Lag),仅将日志解读等灵活线索挖掘交给LLM。这一设计确保了即使AI部分失效,基础事实仍能送达Slack,解决了LLM在运维场景中可靠性不足的问题。【背景】该案例呼应了业界对AI Agent在关键基础设施中“代码做计算、AI做判断”的职责边界共识。
How it got here
霍永豪开始实习,接手基于Webhook触发LLM通过Grafana MCP进行全权调查的Watcher雏形。
techblog.lycorp.co.jp ↗结合测试发现LLM推测数据源ID、误用工具参数及JSON格式崩溃等问题,导致调查链条断裂。
techblog.lycorp.co.jp ↗剩余5天实稼动日时,确立新架构:Watcher固定执行4项核心指标查询,LLM仅负责追加调查与日志关联。
techblog.lycorp.co.jp ↗
What is still unsettled
- 固定查询的4项指标是否适用于所有类型的Kafka集群告警场景?
- LLM在第二阶段的追加调查中,如何量化其对最终优先度判定的实际贡献权重?