Keep 介绍与选型指南

目标：说清 Keep（keephq/keep，开源 AIOps 告警管理平台）的定位、架构、功能边界，并给出与 Alertmanager、Alerta、Grafana OnCall 及 PagerDuty（闭源 SaaS）的量化选型对比。本文认知内容均溯源官方仓库与文档站（查询日期 2026-10-23），部署与命令细节已在 Ubuntu 22.04 服务器上以 0.54.3 版本实测验证。

一、环境信息

本文为认知与选型篇，信息来源与取证口径如下（全部于 2026-10-23 查询）：

• GitHub 仓库：keephq/keep，仓库标题「The open-source AIOps and alert management platform」（仓库页 HTML 实查）
• 星数取证：shields.io 徽章 12k（2026-10-23）
• 许可证取证：仓库 LICENSE 文件实读——正文 MIT；ee/ 目录（企业版功能）另有专属许可
• 版本取证：GitHub Releases 最新稳定版 v0.54.3（releases/latest 重定向实查），发布于 2026-09-09（Releases Atom Feed）
• 官方文档站：docs.keephq.dev（Configuration / Authentication / CLI / Workflows / Providers 各页）
• 实测口径：0.54.3 版本已在 Ubuntu 22.04 服务器部署验证，本文引用的命令与回显均出自该实测（部署细节见本专栏《Keep Docker Compose 部署指南》）
• 说明：GitHub 名称空间下另有一个知名项目 Keepalived（LVS 高可用组件），与本文的 Keep 毫无关系，检索时注意区分

二、软件概述

Keep 是一个开源的 AIOps（Artificial Intelligence for IT Operations，智能运维）与告警管理平台，官方一句话定位为「The open-source AIOps and alert management platform」。它解决的核心问题是：监控源太多、告警太散、值班太累——把 Prometheus、Grafana、Datadog、Sentry、CloudWatch 等数十种监控工具的告警统一收进一个平台，做去重、关联、富化，再通过 Workflow 自动化完成通知与处置，最终降低告警噪声、缩短故障响应时间。

关键事实速览：

💡 说明：Keep 的版本号跨度大（0.x 阶段），但发布节奏稳定、单版本增量清晰。生产引入时建议锁定明确的版本号并关注 Release Notes，避免盲目跟随 latest。

三、核心架构

Keep 采用「单后端 + 单前端 + 实时推送 + 可插拔数据库」的紧凑架构，一条命令栈即可跑起来，也能按规模替换存储组件：

告警数据流（自观测侧到处置侧）：

监控源（Prometheus/Datadog/CloudWatch/...，124 种 provider）
      │  webhook 推送 / API 拉取 / 手动注入（POST /alerts/event）
      ▼
  告警摄入（Alert Ingestion）
      ▼
  去重 Deduplication → 富化 Extraction / Mapping → 维护窗口过滤
      ▼
  关联 Correlation（规则或 AI）→ 生成 Incident（事故）
      ▼
  Workflow 引擎触发（CEL 表达式过滤）→ 通知 / 工单 / 自动处置动作
      ▼
  值班视图（告警表格 / 事故列表 / 服务拓扑）

💡 技术拓展：告警「降噪」不是一个单一技术，而是一组机制的组合，主流平台普遍包含以下几类——

机制	原理	典型场景
去重 Deduplication	同一指纹（fingerprint）的重复告警只保留一条并累加计数	同一磁盘反复报警刷屏
关联 Correlation	把多条相关告警聚合成一个事故（Incident）	交换机故障引发下游一片告警
抑制 Inhibition / 分组 Routing	按 A 告警存在而静默 B 告警；或按标签分组路由	Alertmanager 的经典模型
富化 Enrichment	补齐告警缺失的上下文（负责人、CMDB、runbook）	告警里只有 IP，看不出归属
维护窗口 Maintenance Window	计划内停机期间自动压住告警	发版窗口不想被轰炸

Keep 同时内置这五类机制（官方文档 Key Concepts 目录可查），且把「Workflow 自动化」作为串联所有机制的粘合剂；Alertmanager 侧重抑制与分组路由，Alerta 侧重去重与相关性，选型时按需求权重取舍。本平台的实测路径以「去重 + 富化 + Workflow」为主线。

Workflow 引擎是 Keep 的特色能力：用一份 YAML 声明「什么时候触发（triggers）→ 做什么（steps/actions）」，触发器支持手动、定时（interval）、告警（alert，可用 CEL 表达式过滤）、事故（incident）；动作由 provider 驱动，也可以直接对告警执行 enrich_alert 富化。CEL（Common Expression Language，Google 提出的一种表达式求值语言）用于告警过滤条件，例如 source.contains("prometheus") && severity == "critical"。

数据库形态的取舍说明：单机与小规模场景直接用默认 SQLite（零依赖，数据落 /state 目录）；多人团队或高写入量场景把 DATABASE_CONNECTION_STRING 指向 MySQL/PostgreSQL 即可，应用层无差别（SQLAlchemy 屏蔽方言差异）。

四、功能特性

以下功能均可在 0.54.3 版本中实测或从官方文档逐项对应：

1. 全量告警接入：124 种 provider 类型（0.54.3 keep provider list -a 实测计数），覆盖 Prometheus、Grafana、Datadog、Sentry、CloudWatch、GCP Monitoring、Azure Monitor、Zabbix、Nagios、OpenSearch、ClickHouse、GitHub、GitLab、Jira、ServiceNow、Slack、Discord、Teams、Webhook 等；大多数监控源通过 webhook 推送接入，查询类 provider（如 ClickHouse、Datadog）用于 workflow 中反向拉数据。
2. 告警降噪全家桶：去重（实测告警对象自带 isFullDuplicate/isPartialDuplicate/duplicateReason 字段）、规则与 AI 两种关联（Correlation）、提取（Extraction）、映射（Mapping）、维护窗口（Maintenance Window）。
3. 事故管理（Incidents）：多条告警聚合成事故，支持生命周期管理，是告警到「故障」的组织层。
4. Workflow 自动化：YAML 声明式工作流，官方文档给出 triggers（manual/interval/alert/incident）、steps/actions、conditions、functions、context、foreach、enrichment 完整语法；本文档实测了「告警触发 → console 记录 → 自动富化」与「手动触发 → bash 执行命令 → 结果回填」两条链路（见本专栏《Keep 0.54.3 配置参数详解》与《Keep 0.54.3 常用 CLI 命令与工具详解》）。
5. AI 能力：可接入 OpenAI（默认模型 gpt-4o-2024-08-06，可经 OPENAI_BASE_URL 指向 LiteLLM 代理）、Anthropic、Gemini、DeepSeek 等 provider，用于 AI 告警关联与辅助；不配置任何 AI Key 时平台全部核心功能可用（本次实测即零 AI Key 环境）。
6. API 与 CLI 双通道：完整 REST API（FastAPI 自动暴露 OpenAPI 文档）+ keep CLI（provider/workflow/alert/config 等子命令），便于 CI/CD 与脚本化运维。
7. 认证与多租户：NOAUTH（默认，免登录）、DB（用户名密码入库，内置 RBAC 预定义角色）为开源版能力；Auth0、Keycloak、AzureAD 等 SSO 属于 ee/ 企业目录（另有许可）；另有 OAUTH2PROXY、Okta、OneLogin 等开源可用方式。
8. 可观测自身：内置 Prometheus 指标（KEEP_METRICS=true）与 OpenTelemetry 导出（OTLP 端点可配）。

五、快速开始（最小可用示例）

按官方 Docker Compose 路径，最小栈由 keep-api + keep-ui + Soketi 三个服务组成（完整参数与逐项解释见本专栏《Keep Docker Compose 部署指南》）。在已装 Docker 的 Ubuntu 22.04 服务器上：

# 1. 拉起最小栈（官方镜像，前后端 + 实时推送）
docker compose up -d

# 2. 打开浏览器访问 http://<服务器IP>:3000（本专栏实测映射为 8150 端口），无需登录即可进入告警台

# 3. 手动注入一条测试告警（NOAUTH 模式也需 API Key，可通过
#    KEEP_DEFAULT_API_KEYS 环境变量在启动时预置，见配置篇）
curl -s -X POST http://localhost:8080/alerts/event \
  -H "Content-Type: application/json" \
  -H "x-api-key: <你的APIKey>" \
  -d '{"id":"demo-alert-001","name":"disk usage on web-prod-01 above 90%",
       "severity":"critical","status":"firing","source":["demo"],
       "message":"Disk usage on /var of web-prod-01 is 93%",
       "fingerprint":"disk-web-prod-01"}'

实测回显（0.54.3，注入为异步处理，返回任务名；数秒后可在 UI 告警台看到该条告警）：

{"task_name":"131606376315024"}

用 CLI 查看刚注入的告警（CLI 安装与配置见本专栏《Keep 0.54.3 常用 CLI 命令与工具详解》）：

$ keep alert list
+----------------+------------------+--------------------------------+----------+--------+-------------+---------+----------+--------------------------+
|       ID       |   Fingerprint    |              Name              | Severity | Status | Environment | Service |  Source  |      Last Received       |
+----------------+------------------+--------------------------------+----------+--------+-------------+---------+----------+--------------------------+
| demo-alert-001 | disk-web-prod-01 |   disk usage on web-prod-01    | critical | firing |     None    |   None  | ['demo'] | 2026-10-23T01:19:30.581Z |
+----------------+------------------+--------------------------------+----------+--------+-------------+---------+----------+--------------------------+

从零到看见这条告警，全部步骤在实测中约 10 分钟完成。

六、适用场景与限制

适合的场景：

1. 多源告警统一值班台：已有 3 种以上监控工具、告警分散在多个控制台，需要一个聚合入口与统一去重富化。
2. 自托管替代 PagerDuty/Opsgenie：数据不出内网的合规要求下，用 Keep + 通知渠道（Slack/钉钉类 webhook）承担 on-call 告警分发。
3. 告警自动化处置：用 Workflow 把「高危告警 → 自动跑修复脚本 → 回填结果 → 通知」串成无人值守链路（bash/localhost provider 支持在 Keep 服务器本地执行命令）。
4. AIOps 起步：想用 AI 做告警关联但不想采购商业 AIOps 平台，Keep 的 AI 关联（可选接入自建 LLM 代理）是低成本起点。

当前的限制（据官方文档与实测）：

1. 大多数监控源 provider 需要凭据：Pull 型 provider（Datadog、ClickHouse 等）与通知型 provider（Slack 等）连接时需要对应系统的 API 凭据；无凭据可用的 provider 为数不多（console、mock、bash、localhost、webhook 等可零凭据实测）。
2. 高级 SSO 属企业许可：Keycloak/Auth0/AzureAD 认证在 ee/ 目录，开源版的多用户认证用 DB 模式（内置预定义角色 RBAC）。
3. 默认单机形态：官方 Compose 默认单副本 keep-api + SQLite；横向扩展需自行替换 MySQL/PostgreSQL、开启 Redis 并管理多副本调度（SCHEDULER/CONSUMER 环境变量可拆分角色）。
4. 界面为英文：无官方中文界面。
5. 版本迭代快：0.x 阶段 API/CLI 偶有与文档不同步之处（实测中 keep workflow runs list 在 0.54.3 命中不存在的 API 端点返回 404，需用 REST API 兜底，详见 CLI 篇排障实录）。

七、同类选型对比

对比对象与口径（星数与许可证均取自 shields.io 徽章，2026-10-23 查询；Grafana OnCall 仓库状态取自其 GitHub 仓库页）：

「如果…则…」选型建议：

• 如果你的痛点是告警分散、噪声高、要自动化处置——选 Keep，它是五者中唯一把「聚合+降噪+Workflow+AI」做在一个开源平台里的。
• 如果你只用 Prometheus 且只需要分组、抑制、静默、接管路由——Alertmanager 更轻，不必引入完整平台。
• 如果你只需要一个多源告警聚合的看板（看得到、标得了已读已认领），不需要工作流——Alerta 够用且更简单。
• 如果你需要完整的 on-call 排班与升级策略且必须自托管——Keep + 外挂排班（如 Grafana OnCall 存量、或自建日历集成）是目前现实组合；注意 Grafana OnCall OSS 仓库已归档，不建议新项目引入。
• 如果组织允许 SaaS 且需要企业级 on-call 全托管——PagerDuty 仍是商业标杆，Keep 常作为其自托管替代或前置降噪层。

八、参考链接

• GitHub 仓库：https://github.com/keephq/keep
• 官方文档站：https://docs.keephq.dev
• 官方 docker-compose 部署文件：https://github.com/keephq/keep/blob/main/docker-compose.yml
• Workflow 语法文档：https://docs.keephq.dev/workflows/overview
• Provider 列表文档：https://docs.keephq.dev/providers/overview
• 配置参数文档：https://docs.keephq.dev/deployment/configuration
• 本专栏部署实测篇：见《Keep Docker Compose 部署指南》