用 AI 给运维告警降噪：从理想到现实

用 AI 给运维告警降噪：从理想到现实

标签：运维 / AIOps / 监控 / DevOps / 开源
分类：运维
摘要：AIOps 产品都在说"减少 90% 噪音"，但真实情况如何？本文不讲营销话术，分享在开源项目 VigilOps 中用 DeepSeek LLM 做告警降噪的实际做法：什么有效（根因关联、日志解读）、什么没效（延迟、幻觉、成本），以及 4 层告警降噪方法论。

"AI 降噪"听起来很美

打开任何一个 AIOps 产品的官网，你都会看到类似的承诺：“AI 驱动的告警降噪，减少 90% 噪音”。这些数字看起来令人激动，但在真实运维环境中，事情远没那么简单。

这篇文章不讲营销话术。我们会分享在 VigilOps 中使用 AI（DeepSeek LLM）做告警降噪的实际做法、遇到的坑，以及什么有效、什么没效。

先搞清楚"噪音"是什么

运维告警中的噪音大致分几类：

重复告警。同一个问题在一分钟内触发了 10 条告警（比如 10 个 Pod 同时报内存高）。AlertManager 的分组功能可以处理大部分情况，但前提是告警的标签要设计得好。

自恢复告警。CPU 突然飙到 95%，一分钟后降回正常，触发了告警但恢复得太快来不及处理。这类告警对值班人员来说基本是噪音，但完全屏蔽又怕漏掉持续性问题。

关联告警。一个上游服务挂了，导致下游 5 个服务同时报错。本质上只有一个根因，但你收到了 6 条告警。

阈值不合理告警。磁盘使用率告警设在 80%，但你的服务器一直稳定在 78-82% 之间。这个告警每周都会触发几次，每次都不需要处理。