AI 驱动的监控告警平台升级——从 Nagios 到大模型智能收敛的架构演进
一、旧体系的问题：告警风暴让值班人员对告警麻木
公司早期的监控体系建立在 Nagios 上，通过自定义脚本做 HTTP 探测、进程检测和日志关键字匹配。单看每个检测脚本的覆盖度，似乎都还够用。但当微服务数量从 20 个增长到 200 多个后，Nagios 的架构缺陷就暴露了：缺乏多维标签体系，一个 MySQL 故障会触发几十条无关联的告警；告警规则和检查逻辑耦合在 Python/Shell 脚本里，改规则需要上机器；缺乏告警聚合能力，值班人员一晚上收到 300 条告警，无法区分哪些是根因、哪些是关联症状。引入大模型做告警智能收敛，是这次升级的核心方向。
一次核心交换机故障导致 80 个服务不可达，Nagios 在两分钟内发出了 600 多条告警，值班人员根本处理不过来，事后复盘发现故障从发生到定位又过了 15 分钟。这次事故后，团队决定全面升级监控体系。
二、新监控架构：分层采集 + 智能收敛
新架构的核心思路是分层采集、中心聚合、智能收敛。基础设施层用 Node Exporter 和 cAdvisor 采集主机和容器指标；中间件层使用社区 Exporter 采集 MySQL、Redis、Kafka 的指标；应用层通过 Micrometer 和 Spring Actuator 暴露 JVM 和业务指标。所有指标统一由 Prometheus 集群拉取，Grafana 做可视化。
AlertManager 负责告警路由和静默，但告警收敛是单独的一层。因为 AlertManager 的抑制规则是静态的，只能解决"已知服务依赖"下的告警屏蔽，无法处理未知的级联影响。我们在 AlertManager 之后加了一层告警收敛引擎，接收所有原始告警，按服务拓扑、时间窗口和指标关联性做聚类，识别根因告警和关联告警。
三、Java 告警收敛的核心实现
应用层的指标暴露通过 Micrometer 统一封装，避免每个服务自定义埋点方式不一致。
@Component
public class BusinessMetricsExporter {
private final Counter orderCreateCounter;
private final Timer orderProcessTimer;
private final Gauge pendingTaskGauge;
public BusinessMetricsExporter(MeterRegistry registry) {
this.orderCreateCounter = Counter.builder("business.orders.created")
.description("订单创建计数")
.tag("env", System.getenv("ENV"))
.register(registry);
this.orderProcessTimer = Timer.builder("business.orders.processing_time")
.description("订单处理耗时分布")
.publishPercentiles(0.5, 0.95, 0.99)
.register(registry);
this.pendingTaskGauge = Gauge.builder("business.tasks.pending",
this::getPendingTaskCount)
.description("待处理任务堆积数")
.register(registry);
}
public void recordOrderCreated(String orderType, String channel) {
orderCreateCounter.increment();
}
public void recordOrderProcessTime(long millis) {
orderProcessTimer.record(millis, TimeUnit.MILLISECONDS);
}
private double getPendingTaskCount() {
// 从任务队列获取当前堆积量
try {
return taskQueueService.getPendingCount();
} catch (Exception e) {
return -1.0; // -1 表示采集异常，可在告警规则中单独处理
}
}
}
告警收敛引擎的原理是基于时间窗口和拓扑关联做聚类。当同一分钟内收到 50 条告警，引擎先从 CMDB 中查询发出告警的服务拓扑关系，将属于同一调用链或同一集群的告警归为一组，再根据服务依赖图判断根因方向。例如当 MySQL 节点告警和 10 个依赖服务的"DB 连接失败"告警同时到达，引擎会识别 MySQL 是根因，只发出 1 条收敛后的告警，附上影响的 10 个服务列表。
AI 推理节点在此之上做了一层补充。对于无法通过拓扑直接判断的复杂场景——例如某一台机器的 CPU 飙高但网络进出流量正常、内存使用率正常——AI 推理会结合历史告警模式、变更记录和同类主机的行为对比，给出可能原因的分类和置信度。注意 AI 给出的是辅助分类，最终通知内容仍然由工程师审核。
四、告警质量的衡量与持续改进
告警系统升级后，衡量指标也变了。不再是"多少条告警被触发"，而是"多少条告警需要人工处理"。我们跟踪四个关键指标：告警总量（升级后下降了 73%）、告警准确率（误报率从 35% 降到 6%）、MTTA（平均确认时间，从 12 分钟降到 3 分钟）和 MTTR（平均恢复时间，从 45 分钟降到 18 分钟）。
Prometheus 集群本身也需要监控。我们部署了两套 Prometheus 做互备，各自采集相同的目标，通过 Thanos 做全局视图聚合。每套 Prometheus 的存储限制了 15 天的本地数据，通过远程写存入 ClickHouse 做长期归档。这样既保证了短期查询性能，又满足了合规审计对历史数据的要求。
告警规则的治理是持续性的工作。每个季度做一次告警规则审计，标记出从未触发的规则（可能是阈值设置不当）和频繁误报的规则（需要调高阈值或改变判定逻辑）。告警规则库从最初的 200 多条精简到 80 条，减少了 60%。不是删掉就好，而是要保证每条规则都有明确的文档说明——为什么设这个阈值、谁负责处理、升级策略是什么。
五、总结
监控告警平台从 Nagios 向 Prometheus + AlertManager + AI 收敛的升级，核心是把"发告警"的思维转变为"告诉正确的人正确的信息"。指标采集要标准化，告警要收敛和聚类，根因要辅助推理，衡量指标要从告警数量转向人工处理成本。监控系统的成功不是告警多，而是需要人工处理的少。
