Keep 告警降噪指南:如何把一堆重复告警压成一个事件【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep凌晨两点,手机第 17 次弹出同一个 Pod restart 告警,手头的四个监控控制台全在闪红。Keep 想终结的就是这种夜晚:它是一个开源的 AIOps 告警管理与降噪平台,把散落在各监控工具里的告警收拢到一处,用去重、关联和自动化工作流,把几十条重复告警压缩成一个真正需要处理的事件。它替你挡掉了什么没有 Keep 之前,一次故障往往触发几十条告警:Prometheus 报 CPU 高,Datadog 报延迟,CloudWatch 报磁盘满。值班的人要在几个控制台之间来回切,自己拼出到底发生了什么。现在这些告警会先进入同一个列表,由 Keep 做几层处理。它挡掉的第一层是同一告警重复 N 次。每条告警都会按关键字段算出一个指纹,重复到达的告警不会新增条目,只刷新最近一次接收的时间。你在列表里只看到一条 Pod restart,底下标注它两分钟前又响了一次。规则怎么配,可以查去重文档。它挡掉的第二层是一个事件,几十条告警。你可以按关键字或服务名写关联规则,也可以打开内置的 AI 关联:它用你的历史告警数据训练一个 Transformer 模型,新告警进来时先和已有事件比对,足够相似就并进原事件,判断结果和执行日志都留痕可查。它挡掉的第三层是凌晨三点的手工操作。告警富化(自动补全环境、实例信息)、条件过滤、通知路由,这些都能用 YAML 描述,不用改数据库也不用发版。拆开一条告警,看它怎么走拿一条 Prometheus 的 CPU 告警,跟着它在 Keep 里走一遍。入口:Alertmanager 把告警 POST 给 Prometheus provider 的 webhook,后端(FastAPI Uvicorn)接收后写入告警 feed。拉取同理,Keep 也能定时从 Datadog、CloudWatch 这类工具里拉告警,双向都通。去重与关联:新告警先经过告警去重模块算指纹,命中已有告警就合并;再匹配关联规则,命中就归入对应事件,不另起炉灶。触发与执行:工作流用 CEL 表达式做触发判断,比如source.contains(prometheus) severity critical。命中后,工作流引擎按顺序执行 actions,每步调用一个 provider。仓库里 keep/providers/ 下有 120 多个 provider,每个都是实现同一套接口的独立模块,这就是它什么都能接的原因。落点:耗时动作会丢进 Redis ARQ 任务队列异步跑,不阻塞 API。流程走到最后一步,调用 Slack、Teams 或 SMTP 把消息发出去,前端(Next.js TypeScript)通过 websocket 实时刷新,整个过程不用手动刷新。跑起来有多快✅ 四步,五分钟以内能看到界面:拿到代码并启动:git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker compose up浏览器打开http://localhost:3000,后端 API 在 8080,默认用本地 SQLite 存数据,开箱即用。在 Providers 里接入你用的一两个监控源,比如 Prometheus 或 Datadog。导入一条工作流验证效果:workflow: id: cloudwatch-slack-notifier-cel triggers: - type: alert cel: source.contains(cloudwatch) actions: - name: trigger-slack provider: type: slack with: message: Got alarm from aws cloudwatch! {{ alert.name }}匹配的告警一进来,Slack 频道就会出现带告警名的消息。工作流完整语法可以看工作流自动化文档。接得住什么,接不住什么内置的 120 多个 provider 覆盖了日常大部分工具:类别内置示例监控与可观测Prometheus、Datadog、Grafana、CloudWatch、Elastic、New Relic、Zabbix、Dynatrace值班与事件PagerDuty、Opsgenie、Grafana OnCall、iLert、Flashduty协作与通知Slack、Microsoft Teams、Discord、Telegram、SMTP、Pushover云与数据Kubernetes、OpenShift、MySQL/PostgreSQL、ClickHouse、Snowflake、S3AI 模型(关联与富化)OpenAI、Anthropic、DeepSeek、Ollama、vLLM(本地)说句实话:Keep 本身不是监控数据源,它是告警中枢,指标采集仍要靠 Prometheus、Datadog 们完成;AI 关联则需要你自己配一个模型 API(或用 Ollama、vLLM 跑本地),不是开箱即用的。给谁用、怎么开始一句话画像:任何同时跑着三个以上监控工具、又被告警吵醒过夜的团队,从五人创业公司到大厂运维组都合适。上手三步:先用 docker compose 在本地跑起来,接入噪声最大的两个工具;再配一两条去重规则和一条通知工作流,别贪多,别急着全自动化;等跑了一周、积累下告警历史,再开 AI 关联,看它能把告警压掉几成。 最后提醒一句:先别上生产,让它在测试环境影子跑一周,确认去重规则没误合并,再正式接入值班流程。如果你的 oncall 还在被重复告警吵醒,Keep 值得花一个晚上试试。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Keep 告警降噪指南:如何把一堆重复告警压成一个事件
Keep 告警降噪指南:如何把一堆重复告警压成一个事件【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep凌晨两点,手机第 17 次弹出同一个 Pod restart 告警,手头的四个监控控制台全在闪红。Keep 想终结的就是这种夜晚:它是一个开源的 AIOps 告警管理与降噪平台,把散落在各监控工具里的告警收拢到一处,用去重、关联和自动化工作流,把几十条重复告警压缩成一个真正需要处理的事件。它替你挡掉了什么没有 Keep 之前,一次故障往往触发几十条告警:Prometheus 报 CPU 高,Datadog 报延迟,CloudWatch 报磁盘满。值班的人要在几个控制台之间来回切,自己拼出到底发生了什么。现在这些告警会先进入同一个列表,由 Keep 做几层处理。它挡掉的第一层是同一告警重复 N 次。每条告警都会按关键字段算出一个指纹,重复到达的告警不会新增条目,只刷新最近一次接收的时间。你在列表里只看到一条 Pod restart,底下标注它两分钟前又响了一次。规则怎么配,可以查去重文档。它挡掉的第二层是一个事件,几十条告警。你可以按关键字或服务名写关联规则,也可以打开内置的 AI 关联:它用你的历史告警数据训练一个 Transformer 模型,新告警进来时先和已有事件比对,足够相似就并进原事件,判断结果和执行日志都留痕可查。它挡掉的第三层是凌晨三点的手工操作。告警富化(自动补全环境、实例信息)、条件过滤、通知路由,这些都能用 YAML 描述,不用改数据库也不用发版。拆开一条告警,看它怎么走拿一条 Prometheus 的 CPU 告警,跟着它在 Keep 里走一遍。入口:Alertmanager 把告警 POST 给 Prometheus provider 的 webhook,后端(FastAPI Uvicorn)接收后写入告警 feed。拉取同理,Keep 也能定时从 Datadog、CloudWatch 这类工具里拉告警,双向都通。去重与关联:新告警先经过告警去重模块算指纹,命中已有告警就合并;再匹配关联规则,命中就归入对应事件,不另起炉灶。触发与执行:工作流用 CEL 表达式做触发判断,比如source.contains(prometheus) severity critical。命中后,工作流引擎按顺序执行 actions,每步调用一个 provider。仓库里 keep/providers/ 下有 120 多个 provider,每个都是实现同一套接口的独立模块,这就是它什么都能接的原因。落点:耗时动作会丢进 Redis ARQ 任务队列异步跑,不阻塞 API。流程走到最后一步,调用 Slack、Teams 或 SMTP 把消息发出去,前端(Next.js TypeScript)通过 websocket 实时刷新,整个过程不用手动刷新。跑起来有多快✅ 四步,五分钟以内能看到界面:拿到代码并启动:git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker compose up浏览器打开http://localhost:3000,后端 API 在 8080,默认用本地 SQLite 存数据,开箱即用。在 Providers 里接入你用的一两个监控源,比如 Prometheus 或 Datadog。导入一条工作流验证效果:workflow: id: cloudwatch-slack-notifier-cel triggers: - type: alert cel: source.contains(cloudwatch) actions: - name: trigger-slack provider: type: slack with: message: Got alarm from aws cloudwatch! {{ alert.name }}匹配的告警一进来,Slack 频道就会出现带告警名的消息。工作流完整语法可以看工作流自动化文档。接得住什么,接不住什么内置的 120 多个 provider 覆盖了日常大部分工具:类别内置示例监控与可观测Prometheus、Datadog、Grafana、CloudWatch、Elastic、New Relic、Zabbix、Dynatrace值班与事件PagerDuty、Opsgenie、Grafana OnCall、iLert、Flashduty协作与通知Slack、Microsoft Teams、Discord、Telegram、SMTP、Pushover云与数据Kubernetes、OpenShift、MySQL/PostgreSQL、ClickHouse、Snowflake、S3AI 模型(关联与富化)OpenAI、Anthropic、DeepSeek、Ollama、vLLM(本地)说句实话:Keep 本身不是监控数据源,它是告警中枢,指标采集仍要靠 Prometheus、Datadog 们完成;AI 关联则需要你自己配一个模型 API(或用 Ollama、vLLM 跑本地),不是开箱即用的。给谁用、怎么开始一句话画像:任何同时跑着三个以上监控工具、又被告警吵醒过夜的团队,从五人创业公司到大厂运维组都合适。上手三步:先用 docker compose 在本地跑起来,接入噪声最大的两个工具;再配一两条去重规则和一条通知工作流,别贪多,别急着全自动化;等跑了一周、积累下告警历史,再开 AI 关联,看它能把告警压掉几成。 最后提醒一句:先别上生产,让它在测试环境影子跑一周,确认去重规则没误合并,再正式接入值班流程。如果你的 oncall 还在被重复告警吵醒,Keep 值得花一个晚上试试。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考