企业官网建设流程全解析

5 分钟把第一条告警接进 Keep：AIOps 告警自动化实战指南

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

凌晨三点，一条数据库磁盘告警引发 200 条关联告警连环弹出，值班工程师在四个监控面板之间来回切换，最后才定位到源头。这就是典型的告警风暴：数据散落在不同工具里，没人说得清哪条是根因、哪条是噪音。Keep 是一个开源的 AIOps 告警平台，它把所有来源的告警汇进同一个池子，再用工作流和 AI 把自动化跑起来。

Keep 能替你做什么

统一聚合。Keep 内置了 130 多个监控工具的 Provider（提供者），可以理解为每个监控系统的"翻译官"，把各家原始告警格式统一转成 Keep 能处理的结构。所有告警进来之后，你拿到的是一个可搜索、可去重、可筛选的告警列表，而不是五套后台。

工作流自动化。用 YAML 写清"什么条件触发、执行什么动作"，告警到达后 Keep 自动跑动作：发 Slack、开 Jira 工单、调 HTTP 接口，都不用再写胶水代码。

AI 关联分析。AI 关联引擎把相关告警聚成一簇，并标出最可能的根因。上面那种 200 条的告警风暴，可能会被收敛成 1 个事件加 1 条根因告警，响应时间跟着缩短。

5 分钟跑通第一条告警链路

整条链路四步：起服务、建密钥、推一条告警、看结果。

第 1 步：把 Keep 跑起来。仓库里带了现成的 Compose 文件，一条命令拉起 API、Web UI 和依赖（PostgreSQL、Redis）：

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

UI 在http://localhost:3000，API 在http://localhost:3300。

第 2 步：建 API Key。登录 UI 后在 Settings 里创建，后面每次 API 调用都要带Authorization: Api-Key YOUR_API_KEY。

第 3 步：推第一条告警。告警从/api/alerts/event接口进入，请求体包含 Provider 类型和原始告警内容：

curl -X POST http://localhost:3300/api/alerts/event \ -H "Authorization: Api-Key YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"provider":"mock","value":{"name":"checkout 服务错误率飙升","severity":"critical","service":"checkout"}}'

第 4 步：确认入库。刷新 UI，告警出现在列表里。也可以调GET /api/alerts拉取列表和历史，或用POST /api/alerts/enrich往告警上补充字段。

把告警变成自动化动作：CEL + 工作流

Keep 工作流的核心是触发器（什么时候跑）加动作（跑什么）。触发条件用 CEL（Common Expression Language，一种轻量表达式语言，可以直接写severity == "critical"这种判断）表达，写法可以参考示例工作流库。下面这段是"checkout 出现 critical 告警就发到 Slack"：

workflow: id: high-severity-notify triggers: - type: alert cel: 'alert.severity == "critical" && alert.service == "checkout"' actions: - name: notify-slack provider: type: slack config: "{{ providers.slack-prod }}"

在 UI 里上传这个文件，触发→动作的完整链路就闭合了：监控系统推告警 → Keep 去重入库 → 匹配 CEL 条件 → Slack Provider 发消息，全程不需要人盯着。

接入没见过的数据源：Provider 四步走

如果你的内部系统或小众工具不在内置的 130 多个里，就自己写一个 Provider，参照 Provider 基类 的四步流程：

1. 继承：继承BaseProvider，新建自己的 Provider 类。
2. 认证：用数据类定义 token、密钥、endpoint 等参数，并在validate_config()里校验。
3. 核心方法：实现_query()（拉数据）或_notify()（发消息），在dispose()里清理连接。
4. 注册：按目录约定放到keep/providers/your_system_provider/，由 ProvidersFactory 自动发现加载。

from keep.providers.base.base_provider import BaseProvider class MyAlertsProvider(BaseProvider): FINGERPRINT_FIELDS = ["alert_id", "host"] # 去重指纹字段 def _query(self, **kwargs): # 调用自家告警接口，返回 Keep 统一结构的告警 ...

更多字段约定和模板见Provider 开发文档，写完之后这个数据源就和内置的一样可用。

上生产前必看的 5 个细节

• 认证方式：生产环境用 API Key 并定期轮换；多人协作时打开 RBAC，按角色分配读、写、执行权限。
• 去重指纹：告警去重由FINGERPRINT_FIELDS决定的指纹字段计算，字段选得少去重更狠，但太激进会把不同告警吞掉，按数据源逐个调。
• 维护窗口：按服务或 CEL 表达式设置时间窗，窗口内匹配的告警自动静默，发版前不用再手动消音群聊。
• 批量接口：一次性灌入大量历史告警时用批量接口，别在循环里逐条 POST。
• Metrics 端点：/api/metrics以 Prometheus 格式暴露alerts_total、workflows_executions_total等指标，把 Keep 本身也纳入监控（实现见 metrics 端点）。

落地路径：从试点到全量

1. 第 1 周，接一个数据源：挑告警量最大的那个工具（比如 Prometheus 或 Datadog），先跑通"进得来、看得见"。
2. 第 2~3 周，调去重和富化：配指纹字段和提取规则，把列表调成能直接用于排查的样子。
3. 第 3~4 周，上 3 个高频工作流：自动通知、自动开单、自动分派，这三个场景覆盖日常响应的大部分。
4. 列表干净后再开 AI 关联和拓扑映射：在噪音大的列表上开关联，结果只会更难读。
5. 上量前加可观测：把自己的 Prometheus 指到 Keep 的 metrics 端点，盯工作流成功率和告警量曲线。

把 Keep 架在每类告警的入口之后，"这条告警归谁、该怎么处理"从此有了确定的答案，告警自动化的价值也就落在这句话里。

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