Keep API 集成指南3 步把告警风暴变成自动化响应【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep凌晨三点值班群同时弹出 40 多条告警Datadog 两条、CloudWatch 三条、Prometheus 十几条散落在四个平台的四个界面里你得手动判断哪条是真问题、该拉谁、做什么。Keep 是一套用 API 驱动的告警管理与自动化平台——所有告警先收敛到一个视图再由可编程的工作流决定后续动作。这篇文章带你从第一条 API 调用开始到最终把告警进来 → 自动分级 → 通知/修复整条链路跑通。Keep API 能替你干的三类事与其罗列接口清单不如先框定能力边界。Keep 的 API 围绕三件事展开1. 把分散的告警收进一个池子。各监控平台通过 Provider 挂进来支持 130 第三方服务告警按 fingerprint 去重聚合你可以用GET /api/v1/alerts按状态、严重度、时间窗拉取也可以把新告警 POST 进/api/v1/alerts主动写入——自建脚本产生的非平台告警同样能进池子参与后续自动化。2. 让外部系统读写告警数据。比如你的 BI 报表想统计每天的告警量或 CMDB 想按指纹回查告警历史直接调/api/v1/alerts/{fingerprint}/history即可不用自己对接每个监控后端。3. 用代码触发自动化。POST /api/v1/workflows/{id}/run支持带上下文手动执行工作流POST /api/v1/workflows可以把 YAML 工作流直接下发到平台。也就是说Keep 的工作流引擎本身就是一个可被外部驱动的 API 资源。Keep API 认证怎么配拿到 Key发出第一条请求这段要解决最小可运行问题拿到一个能用的 key发出一个有响应的请求两件事就验证了整条链路。做法在 Keep UI 的 Settings 页生成 API Key或用 CLIkeep key new创建。所有 Provider 凭据与 key 一样都落在 secretmanager 统一保管敏感字段落库前加密。第一条请求只需要一个请求头——注意 Keep 读的是x-api-key不是常见的AuthorizationGET /api/v1/alerts?limit10 HTTP/1.1 Host: keep-api:8080 x-api-key: k_xxxxxxxx返回一个 JSON 数组每个元素包含fingerprint、name、status、severity、lastReceived等字段。拿到 200 加一个合法数组就算打通了。后续所有接口的契约在 docs/openapi.json 里本地起服务后直接访问/api/docs看 Swagger 交互文档。把告警变成自动化动作一条工作流 YAML 怎么写告警入池只是起点价值在于告警之后怎么办。Keep 的工作流是 YAML 声明式的三段结构triggers声明什么事件触发steps负责取数actions执行通知、工单、修复。仓库里 examples/workflows/ 有 100 个可直接抄的模板。这段示例要解决不同团队、不同环境的告警分流问题来自 examples/workflows/ifelse.yml 的骨架workflow: id: alert-routing-policy triggers: - type: alert actions: - name: business-hours-check if: keep.is_business_hours(timezoneAmerica/New_York) continue: false # 命中即停止后续 action 不再执行 provider: type: console with: message: 工作日告警走人工渠道 - name: infra-prod-slack if: {{ alert.team }} infra and {{ alert.env }} prod provider: type: slack with: channel: prod-infra-alerts message: Prod 告警: {{ alert.name }} / {{ alert.description }}两个要点顺序即逻辑actions 从上往下执行continue: false表示这个分支处理完了后面的跳过等于一个显式的拦截器比嵌套 if-else 好读得多条件表达式支持 Jinja 模板加内置函数如is_business_hours复杂条件可改用 CEL写法见 docs/overview/cel.mdx。触发器不止type: alert还有severity_changed: true只在严重度变化时触发见 examples/workflows/severity_changed.yml、定时 interval 等。验证把 YAML POST 到/api/v1/workflows后等一条匹配告警进来调GET /api/v1/workflows/{id}/runs看执行记录——有记录说明触发成功点开能看到每个 action 的入参和结果。平台没覆盖的系统怎么接自定义 Provider 的注册三步你的告警源是一个内部自研的监控系统Keep 没有现成 Provider 怎么办整个扩展模型很规整记住三个关键接口1. 认证配置是一个 pydantic dataclass。每个字段用metadata声明是否必填、是否敏感Keep UI 会自动据此生成配置表单pydantic.dataclasses.dataclass class MyproviderAuthConfig: api_endpoint: str dataclasses.field(metadata{required: True}) api_key: str dataclasses.field(metadata{required: True, sensitive: True})2. Provider 类继承 BaseProvider。声明PROVIDER_DISPLAY_NAME、PROVIDER_CATEGORY实现validate_config把self.config.authentication装进 dataclass 并存到self.authentication_config然后按需实现_query拉数据和_notify发通知——这两个方法名就是工作流里with参数的入口。3. 注册靠目录约定不需要改工厂。Provider 放在keep/providers/name_provider/下__init__.py导出 Provider 和 AuthConfig 两个类服务启动时 Provider 工厂按约定扫描目录自动注册/api/v1/providers接口即可看到它。一个提醒如果目标系统只是暴露 HTTP API优先考虑现成的 http_provider多数自定义需求一个通用 Provider 就解决了。验证方式UI 的 Providers 页出现你的 Provider 且能通过连接测试或调/api/v1/providers查列表确认已加载。高频踩坑与排查集成时最常碰到的三类问题按现象 → 定位列出1. 认证 401/403。几乎都是请求头写错Keep 只认x-api-key小写带横线写成Authorization: Api-Key会直接被拒。另一个隐蔽点无鉴权部署模式下任意 key 都通过见 docs/deployment/authentication/no-auth.mdx本地调通了上线却 401往往就是联调环境没开校验。2. Provider 未加载。现象是工作流执行时 provider 报 unknown 或连接失败。先查两点目录名是否严格符合name_provider约定、__init__.py是否导出了两个类再看 API 容器启动日志里的 import 报错。快速确认用GET /api/v1/providers列表里没有就是注册失败。3. 工作流没触发。三个常见原因workflow 处于禁用状态UI 里有开关API 侧有 toggle 接口trigger 的 conditions 和真实告警字段对不上拿一条线上告警在 Playground 里手动试触发特殊 trigger 如severity_changed要求告警至少收到过一次才有上一次严重度可比。定位入口是GET /api/v1/workflows/{id}/runs没有任何执行记录 根本没触发有记录但某步失败 去看该 action 的报错。排障时可设KEEP_STORE_PROVIDER_LOGStrue让 Provider 日志落库配合 otel-shared 里的 OpenTelemetry collector 配置能把每次 Provider 调用接进完整 trace。Keep 在告警技术栈里的生态位与进阶方向Keep 不替代 Prometheus、Datadog它坐在这些平台之上做告警的聚合、去重、富化、分派和自动化这一层。130 内置 Provider 决定它的接入广度工作流引擎 API 决定它的可编程性——这也是二次开发的主战场。往下走有两个方向值得提前布局AI 辅助分析Keep 已内置一组 AI ProviderOpenAI、Anthropic、本地 vLLM 等可以把告警摘要、根因分析、自动生成工作流写成 action 挂进工作流自动关联告警到 incident 的能力文档在 docs/overview/ 的 ai-correlation 系列里跨云统一监控平面把 AWS、GCP、Azure 的 monitoring Provider 同时挂进来用 fingerprint 字段与去重规则做归一再结合服务拓扑topology把告警映射到依赖图上——多集群、多云环境里同一故障被三方各报一次的问题在这一层就能消掉。延伸阅读docs/workflows/ —— 工作流完整语法与示例docs/providers/adding-a-new-provider.mdx —— 新增 Provider 的官方指南docs/cli/ —— CLI 命令参考本地调试 Provider 和工作流很方便【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Keep API 集成指南：3 步把告警风暴变成自动化响应
Keep API 集成指南3 步把告警风暴变成自动化响应【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep凌晨三点值班群同时弹出 40 多条告警Datadog 两条、CloudWatch 三条、Prometheus 十几条散落在四个平台的四个界面里你得手动判断哪条是真问题、该拉谁、做什么。Keep 是一套用 API 驱动的告警管理与自动化平台——所有告警先收敛到一个视图再由可编程的工作流决定后续动作。这篇文章带你从第一条 API 调用开始到最终把告警进来 → 自动分级 → 通知/修复整条链路跑通。Keep API 能替你干的三类事与其罗列接口清单不如先框定能力边界。Keep 的 API 围绕三件事展开1. 把分散的告警收进一个池子。各监控平台通过 Provider 挂进来支持 130 第三方服务告警按 fingerprint 去重聚合你可以用GET /api/v1/alerts按状态、严重度、时间窗拉取也可以把新告警 POST 进/api/v1/alerts主动写入——自建脚本产生的非平台告警同样能进池子参与后续自动化。2. 让外部系统读写告警数据。比如你的 BI 报表想统计每天的告警量或 CMDB 想按指纹回查告警历史直接调/api/v1/alerts/{fingerprint}/history即可不用自己对接每个监控后端。3. 用代码触发自动化。POST /api/v1/workflows/{id}/run支持带上下文手动执行工作流POST /api/v1/workflows可以把 YAML 工作流直接下发到平台。也就是说Keep 的工作流引擎本身就是一个可被外部驱动的 API 资源。Keep API 认证怎么配拿到 Key发出第一条请求这段要解决最小可运行问题拿到一个能用的 key发出一个有响应的请求两件事就验证了整条链路。做法在 Keep UI 的 Settings 页生成 API Key或用 CLIkeep key new创建。所有 Provider 凭据与 key 一样都落在 secretmanager 统一保管敏感字段落库前加密。第一条请求只需要一个请求头——注意 Keep 读的是x-api-key不是常见的AuthorizationGET /api/v1/alerts?limit10 HTTP/1.1 Host: keep-api:8080 x-api-key: k_xxxxxxxx返回一个 JSON 数组每个元素包含fingerprint、name、status、severity、lastReceived等字段。拿到 200 加一个合法数组就算打通了。后续所有接口的契约在 docs/openapi.json 里本地起服务后直接访问/api/docs看 Swagger 交互文档。把告警变成自动化动作一条工作流 YAML 怎么写告警入池只是起点价值在于告警之后怎么办。Keep 的工作流是 YAML 声明式的三段结构triggers声明什么事件触发steps负责取数actions执行通知、工单、修复。仓库里 examples/workflows/ 有 100 个可直接抄的模板。这段示例要解决不同团队、不同环境的告警分流问题来自 examples/workflows/ifelse.yml 的骨架workflow: id: alert-routing-policy triggers: - type: alert actions: - name: business-hours-check if: keep.is_business_hours(timezoneAmerica/New_York) continue: false # 命中即停止后续 action 不再执行 provider: type: console with: message: 工作日告警走人工渠道 - name: infra-prod-slack if: {{ alert.team }} infra and {{ alert.env }} prod provider: type: slack with: channel: prod-infra-alerts message: Prod 告警: {{ alert.name }} / {{ alert.description }}两个要点顺序即逻辑actions 从上往下执行continue: false表示这个分支处理完了后面的跳过等于一个显式的拦截器比嵌套 if-else 好读得多条件表达式支持 Jinja 模板加内置函数如is_business_hours复杂条件可改用 CEL写法见 docs/overview/cel.mdx。触发器不止type: alert还有severity_changed: true只在严重度变化时触发见 examples/workflows/severity_changed.yml、定时 interval 等。验证把 YAML POST 到/api/v1/workflows后等一条匹配告警进来调GET /api/v1/workflows/{id}/runs看执行记录——有记录说明触发成功点开能看到每个 action 的入参和结果。平台没覆盖的系统怎么接自定义 Provider 的注册三步你的告警源是一个内部自研的监控系统Keep 没有现成 Provider 怎么办整个扩展模型很规整记住三个关键接口1. 认证配置是一个 pydantic dataclass。每个字段用metadata声明是否必填、是否敏感Keep UI 会自动据此生成配置表单pydantic.dataclasses.dataclass class MyproviderAuthConfig: api_endpoint: str dataclasses.field(metadata{required: True}) api_key: str dataclasses.field(metadata{required: True, sensitive: True})2. Provider 类继承 BaseProvider。声明PROVIDER_DISPLAY_NAME、PROVIDER_CATEGORY实现validate_config把self.config.authentication装进 dataclass 并存到self.authentication_config然后按需实现_query拉数据和_notify发通知——这两个方法名就是工作流里with参数的入口。3. 注册靠目录约定不需要改工厂。Provider 放在keep/providers/name_provider/下__init__.py导出 Provider 和 AuthConfig 两个类服务启动时 Provider 工厂按约定扫描目录自动注册/api/v1/providers接口即可看到它。一个提醒如果目标系统只是暴露 HTTP API优先考虑现成的 http_provider多数自定义需求一个通用 Provider 就解决了。验证方式UI 的 Providers 页出现你的 Provider 且能通过连接测试或调/api/v1/providers查列表确认已加载。高频踩坑与排查集成时最常碰到的三类问题按现象 → 定位列出1. 认证 401/403。几乎都是请求头写错Keep 只认x-api-key小写带横线写成Authorization: Api-Key会直接被拒。另一个隐蔽点无鉴权部署模式下任意 key 都通过见 docs/deployment/authentication/no-auth.mdx本地调通了上线却 401往往就是联调环境没开校验。2. Provider 未加载。现象是工作流执行时 provider 报 unknown 或连接失败。先查两点目录名是否严格符合name_provider约定、__init__.py是否导出了两个类再看 API 容器启动日志里的 import 报错。快速确认用GET /api/v1/providers列表里没有就是注册失败。3. 工作流没触发。三个常见原因workflow 处于禁用状态UI 里有开关API 侧有 toggle 接口trigger 的 conditions 和真实告警字段对不上拿一条线上告警在 Playground 里手动试触发特殊 trigger 如severity_changed要求告警至少收到过一次才有上一次严重度可比。定位入口是GET /api/v1/workflows/{id}/runs没有任何执行记录 根本没触发有记录但某步失败 去看该 action 的报错。排障时可设KEEP_STORE_PROVIDER_LOGStrue让 Provider 日志落库配合 otel-shared 里的 OpenTelemetry collector 配置能把每次 Provider 调用接进完整 trace。Keep 在告警技术栈里的生态位与进阶方向Keep 不替代 Prometheus、Datadog它坐在这些平台之上做告警的聚合、去重、富化、分派和自动化这一层。130 内置 Provider 决定它的接入广度工作流引擎 API 决定它的可编程性——这也是二次开发的主战场。往下走有两个方向值得提前布局AI 辅助分析Keep 已内置一组 AI ProviderOpenAI、Anthropic、本地 vLLM 等可以把告警摘要、根因分析、自动生成工作流写成 action 挂进工作流自动关联告警到 incident 的能力文档在 docs/overview/ 的 ai-correlation 系列里跨云统一监控平面把 AWS、GCP、Azure 的 monitoring Provider 同时挂进来用 fingerprint 字段与去重规则做归一再结合服务拓扑topology把告警映射到依赖图上——多集群、多云环境里同一故障被三方各报一次的问题在这一层就能消掉。延伸阅读docs/workflows/ —— 工作流完整语法与示例docs/providers/adding-a-new-provider.mdx —— 新增 Provider 的官方指南docs/cli/ —— CLI 命令参考本地调试 Provider 和工作流很方便【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考