生产环境的日志量早已超出人工巡检的极限，而基于规则的告警有个致命盲区：它只能捕捉你预先定义过的故障模式。新型攻击手法、级联服务降级、隐蔽的配置漂移——这些往往在演变成事故前根本触发不了任何警报。大语言模型的不同之处在于，它能像资深工程师那样阅读日志，理解上下文、时间序列和语义含义，然后标记出异常。
规则告警的困境几乎每个运维团队都经历过：如果"ERROR"在M分钟内出现N次，就触发分页。这套逻辑在初期有效，但很快会遇到三类失效场景：规则对噪音过度敏感（比如一次重试风暴），却对真正的信号视而不见（比如一小时内分散发生的五起可疑认证事件）；新服务上线意味着要写新规则，而写规则的前提是你在事故前就预知了故障形态；高严重性异常拆分成单个事件时，往往伪装成低优先级日志。
统计方法（错误率的Z-score、孤立森林算法）扩大了覆盖范围，但仍需标注训练数据，且不理解日志语义——它们看到的是数字和token，而非含义。大语言模型则将日志批次视为结构化文本，像人一样进行推理。
这套系统的架构分为三个阶段：采集阶段将日志聚合成时间窗口批次（例如5分钟窗口）；分析阶段将每个批次连同结构化提示词发送给语言模型，要求返回JSON格式输出；路由阶段在检测到异常时向通知渠道（Slack、PagerDuty等）推送。整个管道以异步方式按调度运行，并非逐行实时过滤，而是在现有日志基础设施之上叠加的第二层分析。与流式检测相比的权衡：牺牲几分钟延迟，换取显著更优的信噪比。
日志采集与批处理的核心是一个解析函数，从日志文件读取并按时间窗口分组。代码通过正则表达式提取时间戳、日志级别、服务名和消息内容，生成器函数则产出不重叠的时间窗口批次，默认窗口为5分钟、每批次最多200行。这种设计让模型每次处理的是有完整上下文的日志片段，而非孤立的单行记录。
热门跟贴