Keep 开源 AIOps 平台实战指南：从接入监控警报到自动化处理的完整流程

Keep 开源 AIOps 平台实战指南：从接入监控警报到自动化处理的完整流程

【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep

凌晨三点，一台数据库挂掉，Prometheus、Datadog、Grafana 各自往值班群里甩了十几条格式不一的警报，而真正的问题只有一个。Keep 就是为这种场景设计的开源 AIOps 平台：它把分散在各监控工具里的警报收进一个统一的警报管理界面，做去重、关联，再按你定义的规则自动执行响应动作，比如发通知、开工单、调服务。

一句话定位：Keep 是一个"警报的瑞士军刀"——单点查看所有告警、双向集成监控工具、用 YAML 工作流做自动化，并内置 AI 辅助能力。它填补了"有 Prometheus 看指标、有 Grafana 看面板，但没有开源工具统一管告警"的空白，且所有配置都可以作为代码管理。

一条命令部署 Keep

仓库提供了现成的 Docker Compose 编排，三个服务（FastAPI 后端、Next.js 前端、Soketi 实时推送服务）全部容器化：

git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker compose up -d

第一条命令拉取代码，第二条进入目录，第三条启动全部容器。起来之后浏览器打开前端地址即可进入告警列表页，官方部署细节见 docs/deployment/docker.mdx，生产环境还支持 Kubernetes、AWS ECS 和 OpenShift 部署。

告警表格是 Keep 的主界面，所有监控源的警报汇聚到这里。左侧可按来源、服务、严重级别等维度切片，搜索栏支持 CEL 表达式做复杂过滤，过滤条件还能保存为可复用的预设；列和主题都可以自定义，适合不同值班场景各存一套视图。

接入第一个监控源：Push 与 Pull 两种方式

Keep 用 Provider（提供商）的概念对接外部系统，已内置 100 多个：Prometheus、Datadog、CloudWatch、Sentry、Zabbix 这类观测工具，Slack、Telegram、SMTP 这类通知渠道，以及 Jira、ServiceNow 这类工单系统，完整清单见 docs/providers/overview.md。

接入后警报进入 Keep 有两条路：

• Push（推荐）：在 Provider 设置里勾选Install Webhook，Keep 会自动去对方系统里配好 webhook。比如连接 Grafana 时，它会自动创建一个 Webhook contact point 和通知策略，把告警实时推给 Keep。官方文档明确建议优先用 Push，因为只有推送链路能完整走通工作流自动化。
• Pull（拉取）：勾选Pulling Enabled后，Keep 按KEEP_PULL_INTERVAL设定的间隔主动拉取历史告警（默认回看 7 天）。适合先快速把存量告警搬进来看看，不适合当主链路。

降噪：去重规则把 20 条警报压成 1 条

警报进表之后，第一步通常是降噪。Keep 的去重分两种模式，机制见 docs/overview/deduplication.mdx：

• 部分去重：指定"指纹字段"（fingerprint fields），字段值相同的警报归并为一条，字段差异会做更新合并。每个 Provider 都自带针对其告警格式预设好的指纹字段，接入即生效。
• 完全去重：除忽略字段外所有字段完全相同的警报直接丢弃，防止同一条告警反复刷进来拖垮系统。

在去重之上，Keep 还有一个关联引擎（Correlation Engine），用条件规则把多条相关警报合并成一个 incident。例如"来源是 Prometheus 且严重级别为 critical"的警报自动归入高优先级事件，事件名还支持模板变量，像Service Issue on {{alert.labels.host}}这样自动拼出受影响的主机列表。

写第一个工作流：让警报自己跑起来响应

Keep 的工作流是声明式 YAML 文件，官方把它比作"监控工具的 GitHub Actions"。一个最小可用的例子，来自 examples/workflows/：

workflow: id: cloudwatch-slack-notifier triggers: - type: alert filters: - key: source value: cloudwatch actions: - name: trigger-slack provider: type: slack config: " {{ providers.slack-prod }} " with: message: "Got alarm from aws cloudwatch! {{ alert.name }}"

这段配置的意思是：只要有一条来源是 CloudWatch 的警报进来，就往指定 Slack 频道发一条带警报名的消息。触发器支持 alert、incident、定时（interval）和手动四种类型；动作可以用if条件分支和foreach循环控制流向，还能通过enrich_alert把动作结果（比如 Jira 工单号）回写到警报上。仓库的 examples/workflows/ 目录里有 100 多个可直接照抄的样例，语法细节在 docs/workflows/overview.mdx。

如果不想手写 YAML，开源版带有一个实验性的 AI 工作流助手：在 Workflows 页面点"+ Create Workflow"进入聊天界面，用自然语言描述需求，它生成草稿、你确认后再应用，属于"人在回路"的模式，改完可以落回标准 YAML 继续维护。

进阶：拓扑图、维护窗口与多团队管控

跑顺之后，值得关注的几个方向：

• 服务拓扑：基于 Datadog、PagerDuty、Cilium、Grafana 等数据源画出服务依赖图，故障发生时能快速看出一个节点挂了会波及哪些下游，辅助定位根因。
• 维护窗口：窗口期内来自指定源的警报自动静默，避免发布窗口被误报吵醒。
• 告警富化（Enrichment）：用 HTTP、Bash、Python、OpenAI 等 Provider 给警报补充上下文，比如查一次 CMDB、让大模型摘要一下故障背景。
• 企业能力：SSO（SAML/OIDC/LDAP）、RBAC 权限、审计，以及面向水平扩展的压力测试文档，小团队用单机 Compose，大团队走 K8s 部署，同一套代码库。

接下来看哪里

文档站以docs/目录为主，建议按这个顺序读：项目介绍与理念 → 使用场景合集 → Provider 总览，再按自己接的第一个监控工具找到对应 provider 文档（docs/providers/documentation/ 下每个工具一篇，含配置截图）。需要写复杂工作流时，examples/workflows/ 里的真实样例比语法文档更直观；对告警评估、事件管理等专项概念，docs/overview/ 下也有对应的专题页面。Keep 的源码结构同样清晰：keep/providers/ 放全部 Provider 实现，keep/api/ 是后端路由，keep-ui/ 是前端，想给某个 Provider 提补丁时可以直接从对应目录入手。

【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep