解析 Watch Input 时该内容类型不支持 key extraction - 如何解决此 Elasticsearch 异常

适用版本： 6.8-7.15

1. 错误异常的基本描述 #

could not parse [TYPE] input for watch [watchId]. key extraction is not supported for content type [contentType] 表示在解析 Watcher 的 HTTP Input 时，当前配置的内容类型（Content Type）不支持 extract 键提取功能。

该异常只会发生在 HTTP Input 场景中。当 expected_response_body_type 被设置为 text（即把响应当作纯文本处理）时，Watcher 不支持再对响应内容做键路径提取（extract），因此会直接抛出解析异常。

常见现象 #

• 创建或更新 Watch 时返回 400 Bad Request，错误信息中包含 key extraction is not supported for content type。
• Kibana 的 Watcher 管理界面中可能提示 Watch 解析失败，无法正常保存。
• Elasticsearch 日志中会在 _execute 或 _put Watch 时记录 ElasticsearchParseException。
• 如果 Watch 是通过脚本或 API 批量部署的，可能导致多个 Watch 同时创建失败。

典型报错与异常栈 #

ElasticsearchParseException: could not parse [http] input for watch [my_watch].
    key extraction is not supported for content type [TEXT]
    at org.elasticsearch.xpack.watcher.input.http.HttpInput$HttpInputParser.parse(HttpInput.java:...)

2. 为什么会发生这个错误 #

Elasticsearch Watcher 的 HTTP Input 支持两种响应体解析模式：

extract 的作用是从结构化响应（JSON / XML）中按路径提取指定字段的值，例如从 {"status": "ok", "code": 200} 中提取 status。当响应被声明为 text 时，响应体只是一个无结构的字符串，不存在"键路径"的概念，因此 extract 在这个场景下没有被支持的基础。

核心判断逻辑如下（简化自 Elasticsearch 源码）：

if (expectedResponseBodyType == HttpContentType.TEXT && extract != null) {
    throw new ElasticsearchParseException(
        "could not parse [{}] input for watch [{}]. key extraction is not supported for content type [{}]",
        TYPE, watchId, expectedResponseBodyType
    );
}

也就是说，只要这两个条件同时满足就会报错：

1. expected_response_body_type 为 text（或等效值）
2. 同时配置了 extract 字段

3. 如何排查这个异常 #

建议按以下步骤定位问题：

1. 获取完整报错信息：从 API 响应或 Elasticsearch 日志中确认 watchId、contentType 的具体值。
2. 检查 Watch 定义：通过 GET _watcher/watch/<watchId> 查看该 Watch 的 HTTP Input 完整配置。
3. 确认 HTTP Input 配置：重点检查 expected_response_body_type 和 extract 两个字段是否同时存在。
4. 确认目标接口响应格式：用 curl 直接请求 Watch 中配置的 URL，确认响应到底是 JSON 还是纯文本。
5. 判断需求类型：
   • 如需提取结构化字段 → 响应必须是 JSON，且 expected_response_body_type 应为 json。
   • 如只需判断响应是否包含某段文字 → 不需要 extract，使用 text 类型即可。

排查时需要注意的问题 #

• expected_response_body_type 在未显式设置时默认为 json，但如果之前手动改过，可能遗留 text 配置。
• 某些旧版 Elasticsearch 文档中示例可能混用了两种配置，直接复制粘贴容易触发此异常。
• 如果 HTTP Input 的目标是健康检查接口（如 /health），返回格式可能是纯文本，此时不应使用 extract。

4. 如何解决这个错误 #

方案一：移除 extract（适用于纯文本响应） #

如果目标接口返回的是纯文本（如 OK、pong、200），不需要也不应该使用 extract：

{
  "trigger": { "schedule": { "interval": "1m" } },
  "input": {
    "http": {
      "request": {
        "scheme": "https",
        "host": "example.com",
        "port": 443,
        "method": "get",
        "path": "/health"
      },
      "expected_response_body_type": "text"
    }
  },
  "condition": {
    "compare": {
      "ctx.payload": { "eq": "OK" }
    }
  }
}

方案二：改用 json 类型并保留 extract（适用于结构化响应） #

如果目标接口返回的是 JSON，需要将 expected_response_body_type 设为 json（或省略该字段，默认即为 json），并正确配置 extract：

{
  "trigger": { "schedule": { "interval": "1m" } },
  "input": {
    "http": {
      "request": {
        "scheme": "https",
        "host": "api.example.com",
        "port": 443,
        "method": "get",
        "path": "/status"
      },
      "expected_response_body_type": "json",
      "extract": ["status", "code"]
    }
  },
  "condition": {
    "compare": {
      "ctx.payload.status": { "eq": "ok" }
    }
  }
}

方案三：使用 transform 替代 extract #

如果响应是 JSON 但 extract 不能满足需求，可以改用 transform 做更灵活的数据处理：

{
  "input": {
    "http": {
      "request": { ... },
      "expected_response_body_type": "json"
    }
  },
  "transform": {
    "script": "return [ 'result': ctx.payload.status, 'ts': new Date().toString() ]"
  }
}

后续注意事项与推荐建议 #

• 对 Watcher 的 HTTP Input 建立配置规范：明确哪些接口用 text、哪些用 json，避免混用。
• 在 CI/CD 中部署 Watch 时，对 Watch JSON 做基本的 schema 校验，提前发现 extract + text 的非法组合。
• 对关键 Watch 建立测试用例，在合并前用 _execute API 验证 Watch 是否能正常解析和执行。

借助 INFINI 产品提升排障效率 #

• INFINI Console 可以集中查看所有 Watch 的执行状态、失败原因和历史记录，快速定位哪些 Watch 因配置问题未能正常触发。
• INFINI Gateway 可以代理 Watcher 发出的 HTTP Input 请求，记录请求/响应详情，帮助确认第三方接口的实际返回格式，避免仅靠猜测配置 expected_response_body_type。
• 建议将 Watcher 的执行日志与 Gateway 的请求日志关联分析，形成从"触发→请求→响应→条件判断→执行动作"的完整可观测链路。

5. 小结 #

key extraction is not supported for content type 的本质是 配置组合冲突：extract 只能用于结构化响应类型（json），不能用于纯文本响应类型（text）。修复的核心思路是：先确认目标接口的响应格式，再决定是移除 extract 还是将响应类型改为 json。只要理解"extract 依赖结构化数据"这一原则，这类问题很容易避免。

相关错误 #

• 解析 Watch Input 时数组项应为字符串却读到其他类型
• 解析 Watch Input 时 HTTP 请求模板解析失败

附：日志上下文 #

下面保留当前页面中的源码片段，便于结合异常调用栈定位问题：

if (expectedResponseBodyType == HttpContentType.TEXT && extract != null ) {
    throw new ElasticsearchParseException("could not parse [{}] input for watch [{}]. key extraction is not supported for content" +
        " type [{}]", TYPE, watchId, expectedResponseBodyType);
}
return new HttpInput(request, expectedResponseBodyType, extract);