AI 赋能的业务监控：从被动告警到基于 LLM 的主动异常检测
一、传统监控的"告警疲劳"困境
如果用一个词形容我们团队 2024 年的监控状态，那一定是"告警疲劳"。Prometheus + Grafana + Alertmanager 这套经典组合，每天产生的告警数量在 200~400 条之间波动。值班同事的工作模式逐渐变成了"收到告警 → 看一眼 Grafana 面板 → 如果看起来没什么大问题就关闭"。
统计数据显示，2024 年 Q3 的告警中，真正需要人工介入处理的有效告警仅占 7.3%。其余 92.7% 的告或是阈值设置过于敏感产生的噪音（如 CPU 瞬时飙升至 85% 又立即回落），或是关联告警的重复通知（同一磁盘故障触发了 12 条不同维度的告警），或是已知的周期性波动（每天凌晨 2 点的批处理任务导致数据库连接数峰值）。
告警系统的核心问题不是"告得不够多"，而是"告得不够聪明"——它只能做简单的阈值比较，完全不具备对系统行为的理解能力。
二、分层异常检测的架构设计
我们设计了一套分层异常检测架构，从下到上分为三层。
第一层：统计异常检测。保留传统的阈值和同比/环比检测，但将阈值从"固定值"升级为"动态基线"。通过统计过去 30 天的指标分布，计算 P5/P95 分位数，仅在指标突破分位数范围时触发。这消除了由于固定阈值设置不合理导致的大多数误报。
第二层：向量化异常检测。这是引入 AI 的核心创新点。我们将系统的"正常状态"编码为高维向量。具体做法是：以每分钟为粒度，采集当前系统的 Top-50 指标（CPU、内存、GC 频率、接口 P99 延迟、QPS、错误率、数据库连接池使用率、MQ 积压数量等），组成一个 50 维的特征向量。通过 Isolation Forest 算法训练无监督异常检测模型，发现偏离"正常状态簇"的异常时刻。
异常检测不是简单地告诉你"某个指标超了"，而是告诉你"当前系统的整体状态与过去 30 天同一时段有显著差异"。这一层的告警质量远高于单纯的阈值告警。
第三层：LLM 根因分析。当异常被检测到时，系统自动收集异常发生前后 5 分钟的指标快照、日志关键信息、调用链异常节点等上下文数据，格式化为结构化的 Prompt 提交给 LLM 进行分析。
/**
* 分层异常检测引擎
*/
@Service
public class AnomalyDetectionEngine {
@Resource
private MetricCollector metricCollector;
@Resource
private IsolationForestModel anomalyModel;
@Resource
private RootCauseAnalyzer rootCauseAnalyzer;
/**
* 每分钟触发一次的异常检测主流程
*/
public void detect() {
// 采集当前时刻的系统多维指标
double[] currentVector = metricCollector.collectCurrentVector();
if (currentVector == null || currentVector.length == 0) {
log.warn("指标采集为空，跳过异常检测");
return;
}
// 动态基线检测（第一层）
List<String> thresholdAlerts = checkDynamicThresholds(currentVector);
// 向量异常检测（第二层）
AnomalyScore score;
try {
score = anomalyModel.predict(currentVector);
} catch (ModelException e) {
log.error("异常检测模型预测失败", e);
score = AnomalyScore.normal(); // 降级为正常
}
if (!score.isAnomalous() && thresholdAlerts.isEmpty()) {
return; // 系统正常，无需处理
}
// 异常确认：收集上下文信息
AnomalyContext context = AnomalyContext.builder()
.timestamp(LocalDateTime.now())
.anomalyScore(score)
.thresholdAlerts(thresholdAlerts)
.metricSnapshot(metricCollector.snapshot(5)) // 前后5分钟快照
.recentLogs(logCollector.collect(5))
.traceAnomalies(traceCollector.detectAnomalies(5))
.build();
// LLM根因分析（第三层）
try {
RootCauseReport report = rootCauseAnalyzer.analyze(context);
// 根据严重程度决定告警策略
if (report.getSeverity() == Severity.CRITICAL) {
alertService.sendUrgent(report);
} else {
alertService.sendWarning(report);
}
log.info("异常检测完成: severity={}, summary={}",
report.getSeverity(), report.getSummary());
} catch (AnalyzerException e) {
log.error("LLM根因分析失败，降级为传统告警", e);
alertService.sendFallbackAlert(thresholdAlerts);
}
}
private List<String> checkDynamicThresholds(double[] vector) {
List<String> alerts = new ArrayList<>();
DynamicBaseline baseline = baselineService.getBaseline();
for (int i = 0; i < vector.length; i++) {
double value = vector[i];
BaselineStats stats = baseline.getStats(i);
if (stats == null) continue;
if (value > stats.getP95() * 1.2 || value < stats.getP5() * 0.8) {
alerts.add(String.format("指标[%d]异常: 当前值=%.2f, 基线P5-P95=[%.2f, %.2f]",
i, value, stats.getP5(), stats.getP95()));
}
}
return alerts;
}
}
三、LLM 根因分析的 Prompt 工程
根因分析是整个系统中 Prompt 设计要求最高的环节。输入信息包含多种格式的结构化数据：时序指标、日志片段、调用链图谱。如何让 LLM 从这些异构数据中推理出正确的根因？
我们的 Prompt 设计分为三个区块。上下文简报：用不超过 200 字的自然语言概括当前异常的整体情况（哪些维度异常、异常严重程度、是否有已知的关联事件）。结构化数据：以 Markdown 表格形式呈现关键指标的当前值与基线对比（值偏高用 ↑ 标记，偏低用 ↓ 标记）；以列表形式呈现最近的异常日志（仅保留 ERROR 和 WARN 级别，去重后不超过 10 条）；以文本形式描述调用链中的异常节点和对应的下游服务。历史关联：检索过去 90 天内相似异常的工单和处理记录，作为参考。
最后，通过一个严格的输出格式约束，要求 LLM 按"最可能的根因 → 置信度 → 关联证据 → 建议操作 → 是否需要立即处理"五段式输出。
/**
* LLM根因分析服务
*/
@Service
public class RootCauseAnalyzer {
@Resource
private LLMClient llmClient;
@Resource
private HistoricalTicketSearcher ticketSearcher;
/**
* 分析异常上下文，生成根因报告
*/
public RootCauseReport analyze(AnomalyContext context) throws AnalyzerException {
// 检索历史相似异常工单
List<Ticket> similarTickets = ticketSearcher.searchSimilar(
context.getMetricSnapshot(), 5);
String prompt = buildAnalysisPrompt(context, similarTickets);
String response;
try {
response = llmClient.chat(prompt);
} catch (LLMException e) {
throw new AnalyzerException("LLM调用失败", e);
}
try {
return parseRootCauseReport(response);
} catch (ParseException e) {
log.error("根因报告解析失败: {}", response);
// 解析失败时构建一个基础的降级报告
return buildDegradedReport(context);
}
}
private String buildAnalysisPrompt(AnomalyContext context,
List<Ticket> similarTickets) {
StringBuilder prompt = new StringBuilder();
prompt.append("你是一个资深的系统运维专家。请分析以下异常检测结果，找出根因。\\n\\n");
// 异常概况
prompt.append("## 异常概况\\n");
prompt.append(String.format("检测时间: %s\\n", context.getTimestamp()));
prompt.append(String.format("异常评分: %.2f (阈值0.7)\\n", context.getAnomalyScore().getValue()));
prompt.append(String.format("触发阈值告警数: %d\\n\\n", context.getThresholdAlerts().size()));
// 关键指标对比（表格形式）
prompt.append("## 关键指标对比\\n");
prompt.append("| 指标 | 当前值 | 基线均值 | 偏差 |\\n");
prompt.append("|——|——–|———-|——|\\n");
for (MetricSnapshot metric : context.getMetricSnapshot().getMetrics()) {
String deviation = metric.getDeviationPercent() > 0 ?
"↑" + String.format("%.0f%%", metric.getDeviationPercent()) :
"↓" + String.format("%.0f%%", Math.abs(metric.getDeviationPercent()));
prompt.append(String.format("| %s | %.2f | %.2f | %s |\\n",
metric.getName(), metric.getCurrentValue(),
metric.getBaselineMean(), deviation));
}
// 异常日志
prompt.append("\\n## 异常日志\\n");
for (String logLine : context.getRecentLogs()) {
prompt.append("- ").append(logLine).append("\\n");
}
// 历史相似工单
if (!similarTickets.isEmpty()) {
prompt.append("\\n## 历史相似工单\\n");
for (Ticket ticket : similarTickets) {
prompt.append(String.format("- [%s] %s (处理方案: %s)\\n",
ticket.getResolvedTime(), ticket.getTitle(),
ticket.getResolution()));
}
}
// 输出格式要求
prompt.append("\\n请严格按以下格式输出分析结果：\\n");
prompt.append("根因: <最可能的根因描述>\\n");
prompt.append("置信度: <0~100的数值>\\n");
prompt.append("关联证据: <支持该结论的具体证据>\\n");
prompt.append("建议操作: <具体的处理步骤>\\n");
prompt.append("紧急度: <critical/high/medium/low>\\n");
return prompt.toString();
}
private RootCauseReport parseRootCauseReport(String response) {
// 解析LLM返回的五段式结构化报告
RootCauseReport report = new RootCauseReport();
String[] lines = response.split("\\n");
for (String line : lines) {
if (line.startsWith("根因:")) {
report.setRootCause(line.substring(3).trim());
} else if (line.startsWith("置信度:")) {
String value = line.substring(4).trim().replace("%", "");
report.setConfidence(Integer.parseInt(value));
} else if (line.startsWith("建议操作:")) {
report.setSuggestedAction(line.substring(5).trim());
} else if (line.startsWith("紧急度:")) {
report.setSeverity(Severity.fromString(line.substring(4).trim()));
}
}
return report;
}
private RootCauseReport buildDegradedReport(AnomalyContext context) {
RootCauseReport report = new RootCauseReport();
report.setRootCause("LLM分析结果解析失败，请人工排查");
report.setConfidence(0);
report.setSuggestedAction("请查看原始监控数据和日志进行人工分析");
report.setSeverity(Severity.MEDIUM);
return report;
}
}
四、告警聚合与降噪
引入异常检测和根因分析后，单条告警的质量大幅提升。但随之而来的新问题是：根因分析的报告数量仍然不少，高峰时每小时仍有 15~20 条报告。值班同事反馈"信息质量提高了，但信息量还是太大"。
我们引入了一个轻量级的告警聚合引擎，从两个维度聚合：一是时间维度，将 5 分钟窗口内的多条根因报告合并，取置信度最高的一条作为代表，其余的作为补充细节；二是拓扑维度，通过服务依赖关系图（基于调用链数据自动生成），将有关联的服务告警聚合成一条"影响链报告"，明确展示异常传播路径（如"Redis 连接超时 → 订单服务降级 → 支付服务队列堆积"）。
五、效果评估与下一步方向
系统上线 4 个月后的对比如下：有效告警占比从 7.3% 提升至 62%；平均故障发现时间（MTTD）从 23 分钟降至 3.2 分钟；平均故障修复时间（MTTR）从 87 分钟降至 41 分钟；值班同事反馈的告警疲劳感从 8.5 分降至 3.2 分（10 分满分制）。
下一步的优化方向包括：一是引入预测性异常检测，在故障发生前 5~10 分钟预警（已在小规模实验中取得 72% 的提前预警率）；二是构建自动化修复决策，对于置信度超过 90% 且修复方案明确的告警（如"重启 Pod"、"扩容 HPA"），自动触发修复操作；三是将异常检测场景从后端监控拓展到业务指标（如订单量异常下降、支付成功率异常波动），实现从技术监控到业务监控的全面覆盖。
AI 赋能监控的核心价值不是替代运维工程师，而是让机器处理那些"确定性的、重复性的、低价值的"判断工作，将人的精力集中在真正需要经验和创造力的疑难问题上。
作者：李然（程序员鸭梨），Java 架构师，专注可观测性与智能运维体系建设。
