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 收敛的升级核心是把发告警的思维转变为告诉正确的人正确的信息。指标采集要标准化告警要收敛和聚类根因要辅助推理衡量指标要从告警数量转向人工处理成本。监控系统的成功不是告警多而是需要人工处理的少。
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 收敛的升级核心是把发告警的思维转变为告诉正确的人正确的信息。指标采集要标准化告警要收敛和聚类根因要辅助推理衡量指标要从告警数量转向人工处理成本。监控系统的成功不是告警多而是需要人工处理的少。
