keep告警管理5分钟上手指南:降噪+自动化闭环

发布时间:2026/9/14 11:48:12
keep告警管理5分钟上手指南:降噪+自动化闭环 keep告警管理5分钟上手指南降噪自动化闭环【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep一次数据库慢查询30分钟里涌进值班群127条告警而真正需要人看的只有一组。keep 是一个开源的 AIOps 告警管理平台负责把散落在各监控工具里的告警统一汇聚、去重、聚合成事件再交给自动化工作流处理。问题在于怎么把一条告警洪流收敛成几个可执行的工单谁会被告警淹没3个典型场景场景一一次故障百条告警关键服务挂掉时每台实例、每个依赖各报各的30分钟里出现上百条告警但根因其实是一条慢查询。本质原因监控工具只汇报自己看到了什么中间缺一个聚合层。场景二谁该处理说不清告警只落到公共群里多个值班的人都在等对方认领5分钟过去没人动手。本质原因告警没有路由和 owner 指派机制责任自然被稀释。场景三从告警到工单全靠手确认告警后要手动打开 Jira、贴描述、粘链接一旦忘了告警就永远挂在 Firing 状态。本质原因告警系统和工单系统之间没有双向状态同步。keep 能做什么一张表看懂核心能力keep 是一个开源的 AIOps 与告警管理平台把各监控源Prometheus、Datadog、Grafana 等的告警汇聚到一个面板完成降噪、分组和自动处置。核心能力解决什么问题适合谁指纹去重与告警分组同因告警反复刷屏被告警风暴困住的团队关联规则生成 Incident几十条告警找不到主线多监控源并存的企业YAML 工作流自动化手动确认、建工单、通知太慢想自动化 on-call 的 SRE 团队与 Jira、Slack 等双向同步告警与工单状态对不上已使用工单系统的团队它凭什么降噪指纹去重 关联聚合keep 降噪的关键是指纹每个数据源声明一组字段比如告警名 服务 实例keep 对它们做哈希得到一个固定字符串。两条告警指纹相同就被视为同一件事——重复到达只更新计数不重复通知工作流也只触发一次。类比身份证号名字可以重号码不会重。在指纹之上是关联规则按服务 告警类型这类条件把一段时间内的一组告警归进同一个 Incident。值班的人处理的是 1 个事件而不是 30 条记录。去重规则可以在界面上按数据源单独调整关联规则的创建界面也能实时显示当前有多少条告警命中该条件5分钟上手本地跑起 keep 的最小步骤克隆仓库并启动compose 已包含前端、后端和 websocket 三个服务git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker-compose up -d打开 http://localhost:3000 默认配置免登录直接可用。在 Providers 页面配置一个数据源如 Prometheus选择推送webhook 指向 keep 的告警 API或拉取keep 定时从数据源拉告警两种模式之一。上传一段工作流 YAML或把文件放进本地state/workflows/目录。发一条测试告警在 Feed 里确认它被接收、去重、触发工作流。推送与拉取两种接收入口在告警页面有明确的 Tab 区分一个完整例子从慢查询告警到工单闭环以数据库慢查询引发一组告警为例走一遍触发→处理→通知→闭环触发慢查询导致多台实例、多个依赖接连报警共 127 条告警推送到 keep。处理指纹相同的告警合并为 1 条并累计计数关联规则按 service 分组把它们归入同一个 Incident。通知Incident 触发工作流Slack #ops 收到一条消息附带 Incident 链接和告警明细。闭环查询修复后源告警自动转 ResolvedIncident 结束工作流同步把关联的 Jira 工单置为完成工单号已回写到告警字段。workflow: id: db-incident-notify triggers: - type: incident actions: - name: notify provider: type: slack config: {{ providers.slack }} with: message: Incident: {{ incident.name }}工作流以卡片形式管理在 Workflows 页面可手动运行、可上传模板上线后你会看到什么4个量化对照指标接入前接入后一次故障产生的可见通知100 条左右约 1 个 Incident关键告警首次响应5-15 分钟等有人看到约 1 分钟工作流推送每条告警的人工动作3-5 步确认、建工单、通知约 0 步工作流完成重复 Firing 通知逐条全量指纹合并约 1 条新手常见疑问3个真实顾虑需要替换 Prometheus 或 Grafana 吗不需要。Prometheus 继续负责采集和判定keep 放在告警产生之后的汇聚与处置层。告警可以 webhook 推送也可以由 keep 主动拉取Grafana 面板不受影响。工作流 YAML 学习成本高吗一段工作流就是触发器 动作的十来行 YAML动作直接引用已配置好的 provider。UI 里内置 servicenow、resolve old alerts 等模板复制后改字段即可语法可参考 docs/workflows/overview.mdx。已有 Jira / ServiceNowkeep 会不会重复建设不重复。keep 替你把告警→工单这段链路自动化按规则建工单、状态双向同步工单关闭时告警也标记解决。工单系统本身仍是你现有的那套。今天就能做的三步行动清单① 今天docker-compose up -d启动本地 keep打开 localhost:3000 逛一遍告警页面。 ② 本周接一个真实数据源把最近一周的告警推进来看看去重后的数量差多少。 ③ 下次故障前写好通知 建工单的工作流让 keep 处理第一次值班。到这里一个告警管理的最小闭环就跑起来了。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考