我在写workflow，但是不知道每个provider都有哪些方法可以调用，请问在哪里可以找到对应的文档

[nsdsb123]

我在写workflow，但是不知道每个provider都有哪些方法可以调用，请问在哪里可以找到对应的文档

[dosubot[bot]]

你好！关于 provider 可调用方法的文档，可以参考以下几个地方：

1. 官方文档网站 — docs.keephq.dev 上有 100+ 个 provider 的专属文档页面，包含认证配置和 workflow 示例 [1]。你可以在左侧导航栏找到对应 provider 的页面。

2. Provider 方法参考 — 除了基础的 _query（用于 workflow 的 steps）和 _notify（用于 workflow 的 actions）之外，很多 provider 还定义了自定义方法（如关闭告警、添加评论等），这些记录在 Provider Methods 文档 中 [2]。

3. 直接看源码 — 每个 provider 类中都有一个 PROVIDER_METHODS 列表，定义了所有可调用的方法及其参数 [3]。例如 OpsGenie provider 定义了 close_alert、comment_alert 等方法 [4]。

简单总结 workflow 中使用 provider 的方式 [5]：

• steps 中使用 provider 来查询数据（调用 _query）
• actions 中使用 provider 来执行操作/发送通知（调用 _notify）
• 通过 with 字段传递 provider 特定的参数

如果你在找某个具体 provider 的方法列表，可以告诉我是哪个 provider，我可以帮你查一下。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[nsdsb123]

workflow:
id: alert-status-resolver
name: Alert Status Resolver
description: Automatically resolves alerts that have status 'ok'.
triggers:
- type: manual
- type: interval
value: 60
steps:
# 1. 获取所有告警（或者只获取 status == 'ok' 的告警）
- name: get-alerts
provider:
type: keep
with:
version: 2
filter: "status == 'ok'" # 直接在这里过滤，只拿状态为 ok 的

# 2. 批量更新这些告警的状态为 RESOLVED
- name: resolve-alerts
  # 遍历上一步的结果
  foreach: "{{ steps.get-alerts.results }}"
  provider:
    type: keep
    with:
      # 核心：告诉 Keep 我们要更新这个指纹的告警
      # 注意：这里不再使用 if 和 alert 块，而是直接传递更新参数
      fingerprint: "{{ foreach.value.fingerprint }}"
      status: "RESOLVED"
      # 如果 Keep Provider 需要指定操作类型，可能需要加 action: update
      # 但通常直接传 fingerprint 和 status 就会触发更新
      
   我这个workflow提示

2 validation errors
27:11
Property fingerprint is not allowed.
28:11
Property status is not allowed.

请问我想修改告警状态应该用哪个provider的哪个方法

[dosubot[bot]]

你好！修改告警状态不能直接在 Keep provider 的 with 里传 fingerprint 和 status，正确的做法是使用 enrich_alert 参数。通常搭配 mock provider 使用：

workflow:
  id: alert-status-resolver
  name: Alert Status Resolver
  description: Automatically resolves alerts that have status 'ok'.
  triggers:
    - type: manual
    - type: interval
      value: 60
  steps:
    - name: get-alerts
      provider:
        type: keep
        with:
          version: 2
          filter: "status == 'ok'"

  actions:
    - name: resolve-alerts
      foreach: "{{ steps.get-alerts.results }}"
      provider:
        type: mock
        with:
          enrich_alert:
            - key: status
              value: resolved
              disposable: true

[1]

几个要点：

1. 用 actions 而不是 steps 来执行状态更新操作，steps 用于查询数据，actions 用于执行变更。
2. 用 mock provider + enrich_alert 来更新告警属性（如 status、severity 等）[2]。mock provider 本身不做外部操作，仅作为载体触发 enrichment。
3. disposable: true 表示这个 enrichment 是临时的，当新的告警数据到达时会被清除 [3]。如果你希望状态变更是永久的，可以设为 false 或不设置。
4. 注意：通过 enrichment 修改状态会追溯更新同一 fingerprint 下的所有历史告警记录 [4]。

可用的告警状态值包括：FIRING、RESOLVED、ACKNOWLEDGED、SUPPRESSED、PENDING [5]。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[nsdsb123]

请问我配置了Extractions，怎么让他对所有告警自动触发，现在每次都要手动执行，还有我上面这个workflow，怎么让他自动触发

[dosubot[bot]]

你好！分两部分回答你的问题：

1. Extractions 自动触发

Extractions 设计上是自动对所有进入的告警生效的，不需要手动执行 [1]。如果你发现只能手动执行，可以排查以下几点：

• 规则是否启用 — 确认你的 extraction rule 没有被 disabled [2]。
• CEL 条件是否匹配 — 如果配置了条件表达式（如 source.contains("xxx")），需要确认条件能匹配到你的告警 [3]。如果没有配置条件，则默认对所有告警生效 [4]。
• 正则表达式是否匹配 — 检查你的 regex pattern 是否能正确匹配告警中对应字段的内容。
• 版本问题 — 如果你使用的是 v0.46.1，存在一个 UUID 序列化的 bug 会导致 extraction 规则无法运行，建议升级版本 [5]。

目前 Keep 还没有内置的 extraction 执行日志功能，所以较难直接观察规则是否被触发 [6]。你可以通过查看告警是否新增了提取字段来验证。

2. Workflow 自动触发

你当前配置的是 type: manual（手动）和 type: interval（定时），如果想在告警进入时自动触发，需要使用 type: alert 触发器 [7]：

triggers:
  - type: alert                          # 告警进入时自动触发
    cel: status == 'ok'                  # 可选：用 CEL 过滤只对 status=ok 的告警触发
  - type: manual                         # 保留手动触发，方便测试

这样每当有符合条件的告警进入 Keep 时，workflow 就会自动执行，不需要依赖定时轮询了。

Keep 支持的触发器类型 [7]：

• alert — 收到告警时触发（支持 CEL 过滤）
• incident — 事件创建/更新/解决时触发
• interval — 定时执行（单位秒）
• manual — 手动执行

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[nsdsb123]

我还想请问一下，怎么启动这个AI功能，以及一些常见用法

[dosubot[bot]]

你好！Keep 的 AI 功能启用和常见用法如下：

启用 AI 功能

最核心的一步是设置 AI Provider 的环境变量，且需要在 前端和后端容器中都配置 [1]：

OpenAI（最常用）：

# 前端和后端都需要设置
OPENAI_API_KEY=sk-your-api-key
OPENAI_MODEL_NAME=gpt-4o-2024-08-06   # 可选，这是默认值

也支持其他 Provider [2]：

• Anthropic Claude：设置 ANTHROPIC_API_KEY
• Google Gemini：设置 GOOGLE_API_KEY
• DeepSeek：设置 DEEPSEEK_API_KEY

本地部署/私有化（LiteLLM） — 如果不想把数据发送到外部 [3]：

OPENAI_BASE_URL=http://your-litellm:4000/v1   # 注意必须有 /v1 后缀！
OPEN_AI_API_KEY=your-litellm-key

⚠️ OPENAI_BASE_URL 缺少 /v1 后缀会导致 405 错误 [1]。

常见 AI 功能和用法

1. AI 告警关联 / 创建事件 — 在告警列表中选择多条告警，点击 "Create Incidents With AI"，AI 会根据告警描述、时间、拓扑关系等分析并建议事件分组 [4]。

2. 事件摘要生成 — 在 Incident 页面自动生成事件摘要，帮助快速了解上下文 [1]。

3. AI 事件助手 — Incident 页面内嵌的聊天功能，帮助 on-call 工程师做根因分析、收集上下文 [5]。

4. AI Workflow Builder — 用自然语言描述你想要的 workflow，AI 帮你生成 [6]。

5. Workflow 中使用 AI — 将 AI provider 作为 workflow 的一个 step，用于告警分类、严重级别判定、内容摘要等 [7]。

6. AI 事件报告 — 生成包含根因分析、频率统计、MTTD/MTTR 等指标的事件报告 [8]。

常见问题排查

• 页面提示 "No AI enabled" → 检查环境变量是否在前后端都设置了 [9]
• AI Summary 返回 500 → 通常是前端容器缺少 OPENAI_API_KEY
• 功能静默失败 → 检查后端日志，确认 API Key 有效 [10]

注意：AI Correlation（全自动关联） 是企业版功能，开源版可以使用半自动的 "Create Incidents With AI" 以及上面提到的其他 AI 功能 [11]。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[nsdsb123]

请告诉我都支持哪些AI模型，以及他们对应的环境变量需要怎么配置

[dosubot[bot]]

你好！Keep 目前支持 9 个 AI Provider，分为云服务和本地自托管两类。下面是完整的配置信息：

云服务 Provider

Provider	环境变量 / 认证	默认模型
OpenAI	OPENAI_API_KEY	gpt-3.5-turbo（workflow 中）/ gpt-4o-2024-08-06（核心 AI 功能）
Anthropic	ANTHROPIC_API_KEY	claude-3-sonnet-20240229
Google Gemini	GOOGLE_API_KEY	gemini-pro
DeepSeek	DEEPSEEK_API_KEY	deepseek-reasoner
Grok (X.AI)	GROK_API_KEY	grok-1

[1] [2] [3] [4] [5]

本地 / 自托管 Provider

Provider	认证配置	默认模型	默认地址
Ollama	host（无需 API Key）	llama3.1:8b-instruct-q6_K	http://localhost:11434
vLLM	api_url + 可选 api_key	Qwen/Qwen1.5-1.8B-Chat	自定义
LiteLLM	api_url + 可选 api_key	gpt-3.5-turbo	http://localhost:4000
Llama.cpp	host（无需 API Key）	无默认值	http://localhost:8080

[6] [7] [8] [9]

核心 AI 功能的环境变量（事件摘要、AI 关联等）

这些是 Keep 内置 AI 功能（非 workflow provider）使用的配置，需要在前端和后端容器中都设置 [10]：

OPENAI_API_KEY=sk-xxx                        # 必需
OPENAI_MODEL_NAME=gpt-4o-2024-08-06          # 可选，默认值如左
OPEN_AI_ORGANIZATION_ID=org-xxx              # 可选
OPENAI_BASE_URL=http://your-proxy:4000/v1    # 可选，用于代理或 LiteLLM

⚠️ 注意：Keep 的核心 AI 功能（事件摘要、AI 建议事件等）目前仅支持 OpenAI 接口，其他 provider（Anthropic、Gemini 等）只能在 workflow 中作为 step 使用 [11]。如果你想用非 OpenAI 的模型来驱动核心 AI 功能，可以通过 LiteLLM 代理将其他模型包装成 OpenAI 兼容接口，然后设置 OPENAI_BASE_URL 指向你的 LiteLLM 服务。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[nsdsb123]

我配置上了OPENAI_API_KEY, OPENAI_BASE_URL，OPENAI_MODEL_NAME,但是点击AI界面还是No AI enabled,请问我可以从容器启动日志确认这个AI环境变量是否生效吗

[dosubot[bot]]

你好！这个问题很常见，关键在于 Keep 有两套独立的 AI 系统，你看到的 "No AI enabled" 很可能是指向了错误的那一套：

"No AI enabled" 的原因

如果你是在 AI Plugins 页面看到这个提示，那它检查的是 KEEP_EXTERNAL_AI_TRANSFORMERS_URL 这个环境变量，而不是 OPENAI_API_KEY [1] [2]。这是企业版/云版的 AI Correlation 功能，需要一个专门的 ML 服务，在开源自部署环境中无法使用。

你配置的 OPENAI_API_KEY 等变量是用于另一套 AI 功能的，比如：AI 事件建议（"Create Incidents With AI"）、事件摘要生成等 [3]。

关于启动日志验证

Keep 在启动时不会验证 OpenAI 配置，它使用的是懒加载机制——只有在你实际使用 AI 功能时才会初始化 OpenAI 客户端 [3]。所以启动日志中看不到相关信息。

验证方法：

1. 直接检查容器环境变量（最可靠）：

# 后端容器
docker exec <backend-container> env | grep -i openai

# 前端容器（也必须设置！）
docker exec <frontend-container> env | grep -i openai

2. 尝试使用 AI 功能，然后查看后端日志是否有错误：

Failed to initialize OpenAI client: <error details>

这是 OpenAI 初始化失败时唯一会打印的日志 [4]。

重要提醒

• OPENAI_API_KEY 需要在前端和后端容器中都设置 [5]，前端缺少会导致 AI 摘要等功能返回 500 错误。
• 如果使用代理，OPENAI_BASE_URL 必须包含 /v1 后缀（如 http://your-proxy:4000/v1），否则会报 405 错误 [5]。

总结：如果你想使用 AI 事件建议和摘要功能，直接去告警页面选择告警点击 "Create Incidents With AI" 来测试。AI Plugins 页面的 "No AI enabled" 是另一个功能，和你配置的 OpenAI 变量无关。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[nsdsb123]

{"worker_type": "uvicorn", "asctime": "2026-04-01 10:35:24,756", "message": "AI incident creation failed: 4 validation errors for IncidentClustering\nincidents -> 0 -> reasoning\n field required (type=value_error.missing)\nincidents -> 1 -> reasoning\n field required (type=value_error.missing)\nincidents -> 2 -> reasoning\n field required (type=value_error.missing)\nincidents -> 3 -> reasoning\n field required (type=value_error.missing)", "levelname": "ERROR", "name": "keep.api.bl.ai_suggestion_bl", "filename": "ai_suggestion_bl.py", "otelTraceID": "8b255d36f96a399d60952c4f22e93ff1", "otelSpanID": "952fa1e68fdab5a8", "otelTraceSampled": true, "otelServiceName": "keep-api", "threadName": "MainThread", "process": 18, "module": "ai_suggestion_bl", "taskName": "starlette.middleware.base.BaseHTTPMiddleware.call..call_next..coro"}
{"worker_type": "uvicorn", "asctime": "2026-04-01 10:35:24,763", "message": "Request finished: POST /incidents/ai/suggest 500 in 21.39s", "levelname": "INFO", "name": "keep.api.middlewares", "filename": "middlewares.py", "otelTraceID": "8b255d36f96a399d60952c4f22e93ff1", "otelSpanID": "952fa1e68fdab5a8", "otelTraceSampled": true, "otelServiceName": "keep-api", "threadName": "MainThread", "process": 18, "module": "middlewares", "taskName": "starlette.middleware.base.BaseHTTPMiddleware.call..call_next..coro", "tenant_id": null, "status_code": 500}

我点击Create Incidents With AI，日志报错

[dosubot[bot]]

你好！从日志来看，错误原因是 AI 模型返回的结果中缺少 reasoning 字段，而 Keep 的 IncidentCandidate 模型要求这个字段必须存在 [1]。

最可能的原因是你使用的模型不支持 OpenAI 的 Structured Output（JSON Schema 强制输出格式）。

Keep 的 AI 事件建议功能使用了 json_schema 格式来要求模型严格按照指定结构返回数据 [2]。只有特定的模型才支持这个功能。

解决方法：

1. 检查你的 OPENAI_MODEL_NAME：

docker exec <backend-container> env | grep OPENAI_MODEL_NAME

2. 确保使用支持 Structured Output 的模型，推荐：

   • gpt-4o-2024-08-06（默认值，推荐）[3]
   • gpt-4o
   • gpt-4o-mini

   不兼容的模型：gpt-3.5-turbo、早期的 gpt-4 等不支持 JSON Schema 强制输出 [4]。

3. 如果你使用 LiteLLM 或其他代理，需要确认后端实际转发到的模型也支持 structured output，并且代理正确传递了 json_schema response format 参数。

4. 最简单的修复 — 如果不确定，直接去掉 OPENAI_MODEL_NAME 的自定义设置，让它使用默认的 gpt-4o-2024-08-06。

你方便告诉我你设置的是哪个模型吗？这样可以更准确地帮你定位问题。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[nsdsb123]

我用的gpt5.4模型