Keep API实战指南：4个接口搞定告警集成，3步写出自定义Provider-北京尧图网络

Keep API实战指南4个接口搞定告警集成3步写出自定义Provider【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keepKeep 是一个开源 AIOps 与告警管理平台核心是Provider对接第三方系统的适配器 Workflow告警触发后的自动化动作两套机制。读完全文你可以直接调用 Keep 的 REST API 拉取和批量处理告警、用接口创建并调试工作流并照着一个目录约定扩展出官方未支持的集成。它解决什么问题告警入口太多格式各异Prometheus、Datadog、Cloudwatch 各推各的告警。Keep 统一收口POST /api/v1/alerts/event/{provider_type}接收各来源的 webhookGET /api/v1/alerts给你一份标准化列表含fingerprint、status、severity字段。处理动作靠人肉谁来判断严重告警该通知值班群、一般告警只记录工作流引擎把触发条件 → 条件分支 → 通知/开单/执行命令变成一份 YAML可用 API 创建、试运行、启停。自家内部系统没法接入公司自研的运维平台不在官方 130 个 Provider 里。写一个继承BaseProvider的子类按目录命名规则放好即被自动发现无需注册。从数据面切入先看告警相关的 API 怎么用。用 REST API 管理告警查询、富化、批量操作一句话告警的读、写、批量操作都有对应端点全部定义在告警路由中接口契约见 OpenAPI 规范。谁会用SRE 想在自己的工具里内嵌 Keep 告警视图或定时任务需要给一批告警打标签。所有请求需在 Header 携带x-api-key: 你的APIKeyAPI Key 从 UI 生成认证逻辑在中间件。最常用的两个操作——查告警、批量富化# 1. 拉取最近告警分页参数 limit/offset 可调 curl -H x-api-key: $KEEP_KEY http://localhost:8080/api/v1/alerts?limit20 # 2. 批量富化按指纹列表或 CEL 表达式选中告警追加自定义字段 curl -X POST -H x-api-key: $KEEP_KEY -H Content-Type: application/json \ -d {enrichments: {team: payments}, cel: severity \critical\} \ http://localhost:8080/api/v1/alerts/batch_enrichbatch_enrich的请求体支持fingerprints指纹列表或cel如name.contains(CPU) labels.region us-east-1二选一来圈定范围请求模型定义在 AlertDto。查单条告警用GET /api/v1/alerts/{fingerprint}它的变更时间线走/api/v1/alerts/{fingerprint}/audit。告警只是数据真正产生价值的是告警触发之后的动作这就轮到工作流 API 出场了。工作流API创建、试运行、查执行日志一句话工作流以 YAML 定义API 负责它的生命周期管理引擎实现在 workflowmanager。谁会用平台管理员通过 CMDB 或配置中心统一下发工作流不想让工程师进 UI 逐个粘贴。几个高频端点均在 workflows 路由操作端点说明创建/更新POST /api/v1/workflows返回 201YAML 文本或 JSON 均可试运行POST /api/v1/workflows/test不真正触发只验证定义能否跑通手动执行POST /api/v1/workflows/{workflow_id}/run立即执行一次执行日志GET /api/v1/workflows/runs/{workflow_execution_id}查状态、结果、日志启停PUT /api/v1/workflows/{workflow_id}/toggle灰度下线用全量导出GET /api/v1/workflows/export备份所有 YAML适合纳入 Git工作流的语法细节triggers、if条件、steps在工作流文档和 110 个现成样例 examples/workflows/ 里先抄样例再改是最快的上手方式。工作流里的每个provider字段都指向一个具体 Provider。如果它对接的系统还没人写过 Provider就需要进入二次开发了。三步完成自定义 Provider 开发一句话Provider 是 Keep 与外部系统交互的唯一通道一个 Provider 类同时具备查询数据_query和发送动作notify两种能力基类定义在 BaseProvider。谁会用需要把自研平台、内部工单系统接进 Keep 的开发者。开发规范详见新增 Provider 指南。三步走建目录 → 写类 → 被自动发现。ProvidersFactory扫描keep/providers/下所有*_provider目录从类名推导 Provider 类型如YourserviceProvider→yourservice不需要手动注册。第一步在keep/providers/下新建yourservice_provider/目录放__init__.py和yourservice_provider.py。第二步写 Provider 类最小实现如下from keep.providers.base.base_provider import BaseProvider class YourserviceProvider(BaseProvider): PROVIDER_DISPLAY_NAME YourService PROVIDER_CATEGORY [Monitoring] def notify(self, **kwargs): # kwargs 来自工作流中 provider.with 的配置如 message、url resp self._session.post(self.api_endpoint, jsonkwargs) resp.raise_for_status() def _query(self, **kwargs): resp self._session.get(self.api_endpoint, paramskwargs) return [dict(resp.json())]notify负责推发通知、调接口_query负责拉查数据回填告警二选一或都实现self._session是基类提供的带超时和日志的 requests 会话self.logger可直接用。第三步把 API Key 等配置声明为AuthConfig数据类基类要求实现validate_config解析self.config.authentication标记metadata{sensitive: True}的字段会在 UI 中脱敏密钥落库走 secretmanager。至此新 Provider 就能在工作流里以type: yourservice被引用整个链路闭环到下面的完整案例。端到端小案例告警进来 → 分级判断 → Slack 通知把前面的能力串起来Prometheus 告警经 webhook 推入 Keep工作流按事件类型触发用if条件分级critical 走 PagerDuty 开事件其余走 Slack 通知。完整可运行的类似样例见 incident-tier-escalation.yml骨架如下workflow: id: tier-escalation name: 告警分级通知 triggers: - type: alert filters: - key: source value: prometheus actions: - name: critical-to-pagerduty if: {{ alert.severity critical }} provider: type: pagerduty with: incident_key: create - name: else-to-slack if: {{ alert.severity ! critical }} provider: type: slack with: channel: #ops message: 非紧急告警: {{ alert.name }}部署方式POST /api/v1/workflows提交这份 YAML或GET /api/v1/workflows/export反向取出存量做 Git 化管理。上线前先用POST /api/v1/workflows/test试跑再从runs/{id}确认日志无异常。富化字段如enrich_incident写入的current_tier会随告警/事件流转供后续动作引用。进阶提示吞吐告警入口默认用 5 个线程的线程池同步处理事件KEEP_EVENT_WORKERS环境变量可调见 alerts.py高并发场景建议把队列切到 ARQ/RedisREDIStrue配置在 arq_pool避免 webhook 超时。安全API Key 权限按 scope 划分如read:alert、read:workflows鉴权逻辑在 identitymanager工作流级密钥单独走POST /api/v1/workflows/{id}/secrets接口写入不要明文写进 YAML 提交到 Git。Keep 的二次开发边界很清晰数据面靠 REST API行为面靠 YAML 工作流扩展面靠 Provider 目录约定三者都可以脱离 UI 用纯接口驱动。延伸阅读新增 Provider 完整指南含 OAuth2、测试与最佳实践工作流语法文档triggers、CEL 条件、steps 全语法现成工作流样例库110 个按场景命名的 YAML【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Keep API实战指南：4个接口搞定告警集成，3步写出自定义Provider

相关推荐

GDevelop无代码游戏引擎：事件驱动架构与商业落地实践

从EasyExcel到Apache Fesod：稳定Excel导入导出迁移实战

.NET构建发布体系革新：提升效率与容器化部署

更多资讯

Go协程池实现与性能优化全解析

WLED 怎么给 HUB75 矩阵屏选择并烧录对应的构建环境？

如何在 Python 或 TypeScript 应用中直接调用 Cua Driver SDK 而不经守护进程？

LangChain Agent构建指南：从核心原理到实战应用

从 RFC 看 deck.gl 的仓库瘦身方案：数据外迁、历史重写与发布节奏设计

Keep API实战指南：4个接口搞定告警集成，3步写出自定义Provider

今日更新

51单片机开环控制磁阻传感器的硬件匹配与代码实现

AI Agent安全操作数据库：SQL注入防御与参数化查询实战

Android逆向实战：还原激励类App签到接口的签名算法

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？