Keep 告警管理 API 实战指南：从推送告警到自动化响应
Keep 告警管理 API 实战指南从推送告警到自动化响应【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep凌晨两点被一条 OOM 告警叫醒翻到屏幕前发现它被埋在同批推送的 30 条噪音里——这个场景做过运维的人都不陌生。Keep 是一个开源的 AIOps 告警管理自动化平台它把散落在各监控系统的告警汇总到一处做去重、分级再按你定义的工作流自动响应。它的 API 是整个平台真正的操作面UI 背后调用的就是这套 REST 接口所以用 API 集成和用界面操作拿到的是同一套能力。第一次调用API Key 怎么配Keep 的接口认证很简单在 UI 的设置页生成一个 API Key之后每个请求在请求头里带上它即可Authorization: Api-Key YOUR_API_KEY服务端对密钥的管理逻辑在 keep/identitymanager/ 模块里Key 会绑定到具体的实体和权限比如read:alert、write:alert所以可以给不同系统发不同权限范围的 Key而不是一发到底。配好之后一个典型的查询是取最近的高严重度告警。告警查询走POST /api/v1/alerts/query接口按条件过滤POST /api/v1/alerts/query Authorization: Api-Key YOUR_API_KEY Content-Type: application/json { start: 1728000000, // 时间范围unix 秒 severity: [critical], limit: 10 }响应里每条告警都有fingerprint指纹用来标识这是同一个告警、name、severity、status等字段。除了查询还有一批现成接口可以按需组合按指纹批量取告警详情用POST /api/v1/alerts/batch查单条告警的历史用GET /api/v1/alerts/{fingerprint}/history。具体参数以 docs/openapi.json 里的 OpenAPI 规范为准——这份文档是接口契约本地部署后 Swagger UI 也能直接看。告警怎么推进来通用事件端点这是整条链路里最值得记住的一个接口POST /api/v1/alerts/event。它定义在 keep/api/routes/alerts.py是一个通用 webhook 端点任何能发 HTTP 请求的系统都可以用它把告警推进 Keep不需要先接入某个特定 providerPOST /api/v1/alerts/event Authorization: Api-Key YOUR_API_KEY Content-Type: application/json { name: node-03 cpu high, severity: critical, status: firing, fingerprint: node03-cpu, source: [my-internal-monitor] }这个端点支持单条或批量传数组即可返回202加一个task_name——也就是说它是异步处理的接口先确认收下实际的解析、指纹计算、触发工作流都丢到后台执行配置了 Redis 时走 ARQ 队列否则走线程池。这里有个细节值得注意fingerprint决定了告警的归并行为。相同指纹的告警会被视为同一个问题的多次出现而不是新增告警这正是 Keep 收敛告警风暴的底层手段之一字段写不全也没关系Keep 会用默认规则补全。实际配置时建议把source和fingerprint固定下来否则同一问题换个字段值就会裂成两条告警。工作流让告警自己跑起来告警进来之后靠人盯是不现实的。Keep 的工作流workflow用 YAML 描述什么样的告警触发什么动作examples/workflows/目录里有 90 多个现成模板可以直接抄。一个转发 Slack 通知的最小例子workflow: id: cloudwatch-slack-notifier name: CloudWatch Slack Notifier triggers: - type: alert filters: - key: source value: cloudwatch # 只响应 cloudwatch 来源的告警 actions: - name: trigger-slack provider: type: slack config: {{ providers.slack-prod }} with: message: Got alarm! {{ alert.name }}triggers里可以叠 CEL 条件表达式做更复杂的过滤{{ }}是模板变量alert.name这类写法可以直接引用当前告警的字段。工作流的执行由 keep/workflowmanager/ 负责匹配到触发条件的告警会自动拉起对应工作流手动触发也可以GET /api/v1/workflows/{workflow_id}/run就能跑一次执行记录和失败日志同样有对应接口可查。平台没接我的系统自己写一个 Provider这是二次开发的主战场。Keep 把和某个第三方系统打交道的能力抽象成了 Provider一个 Python 类封装该系统的认证和具体方法查告警、发消息、建单之类。仓库里的keep/providers/下有 100 多个现成实现照着抄是最快的学习路径。一个 Provider 骨架长这样以 PagerDuty provider 的结构为参照# keep/providers/yourprovider_provider/yourprovider_provider.py import dataclasses import pydantic from keep.providers.base.base_provider import BaseProvider pydantic.dataclasses.dataclass class YourproviderProviderAuthConfig: api_key: str dataclasses.field( metadata{required: True, sensitive: True} # 敏感字段会在 UI 里打码 ) class YourproviderProvider(BaseProvider): PROVIDER_DISPLAY_NAME YourService def _query(self, query): # 实现数据查询 ...注意两点认证配置用 pydantic dataclass 描述metadata里标sensitive: True的字段在界面上会做脱敏处理类实现后在目录的__init__.py里导出Provider 工厂会自动加载它。字段定义、方法注册这些细节docs/providers/adding-a-new-provider.mdx 里有完整清单。接好 Provider 之后UI 的 Providers 页面可以统一配置、测试连通性下一步建议想快速跑起来把examples/workflows/里的模板改成自己的 provider 配置丢给 Keep比从头写代码省时间要深入定制优先读 docs/workflows/ 的语法文档和 CONTRIBUTING.md。仓库自带的 tests/ 目录里也有一批针对 API 和 provider 的测试用例是验证自己集成是否正确的活例子。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考