适用版本： 6.8-7.15
1. 错误说明 #
could not parse [input] for watch [<id>]. failed to parse [<field>]. must be a string value 是 Elasticsearch Watcher 在解析 watch 定义时抛出的异常。该错误表示 Watcher 的 input 配置中某个字段（常见于 dynamic_name_timezone 等时区相关字段）被赋予了非字符串类型的值，而解析器只接受字符串格式的时区标识符（如 UTC、+08:00、Asia/Shanghai）。
常见现象 #
- 创建或更新 Watcher 时返回
400 Bad Request，请求失败。 - Kibana 的 Watcher 管理界面中保存 watch 配置时报错，提示解析失败。
- Elasticsearch 日志中出现类似如下的错误信息：
{
"error": {
"root_cause": [
{
"type": "parse_exception",
"reason": "could not parse [input] for watch [my-watch]. failed to parse [dynamic_name_timezone]. must be a string value (e.g. 'UTC' or '+01:00')."
}
],
"type": "parse_exception",
"reason": "could not parse [input] for watch [my-watch]. failed to parse [dynamic_name_timezone]. must be a string value (e.g. 'UTC' or '+01:00')."
},
"status": 400
}
2. 原因分析 #
从 Elasticsearch Watcher 源码可见，当解析 input 中的时区字段时，解析器只接受 VALUE_STRING 类型的 token。如果传入的是数字、布尔值、对象或数组，解析器会直接抛出 ElasticsearchParseException。
常见触发原因包括：
- 字段类型错误：将
dynamic_name_timezone等字段写成了数字（如8）或布尔值（如true），而非字符串（如"+08:00"）。 - JSON 结构错误：字段值被错误地包装成了对象或数组，例如写成
{ "timezone": "UTC" }而非直接写"UTC"。 - 模板渲染问题：使用 Mustache 模板或脚本动态生成 watch 配置时，变量类型未正确转换为字符串。
- 版本差异：不同版本的 Watcher 对某些字段的类型要求不同，升级后旧配置可能不再兼容。
- 人为误操作：手动编辑 watch JSON 时，字符串值漏写了引号，导致 JSON 解析后类型发生变化。
3. 解决方案 #
步骤一：定位报错的字段名 #
从异常信息中提取字段名，例如 dynamic_name_timezone，确认是哪个字段的类型不符合要求。
步骤二：检查当前 watch 定义 #
使用以下 API 获取当前 watch 的完整配置：
GET _watcher/watch/<watch_id>
检查报错字段的值类型，确认是否为字符串。
步骤三：修正字段类型 #
将报错的字段改为合法的字符串值。以下是常见时区字段的正确写法：
{
"trigger": {
"schedule": {
"cron": "0 0 * * * ?"
}
},
"input": {
"search": {
"request": {
"search_type": "query_then_fetch",
"indices": ["my-index"],
"body": {}
}
}
},
"condition": {
"compare": {
"ctx.payload.hits.total": {
"gt": 0
}
}
},
"transform": {
"script": {
"source": "return [ 'time': Instant.ofEpochMilli(ctx.trigger.triggered_time.getMillis()).atZone(ZoneId.of(params.tz)).toString() ]",
"params": {
"tz": "Asia/Shanghai"
}
}
},
"actions": {
"send_email": {
"email": {
"to": ["admin@example.com"],
"subject": "Watch Alert - {{ctx.watch_id}}",
"body": {
"text": "Triggered at: {{ctx.trigger.triggered_time}}"
}
}
}
},
"dynamic_name_timezone": "Asia/Shanghai"
}
步骤四：重新创建或更新 watch #
修正后，使用以下命令更新 watch：
PUT _watcher/watch/<watch_id>
{
"trigger": { ... },
"input": { ... },
"dynamic_name_timezone": "UTC"
}
步骤五：验证 watch 是否正常执行 #
POST _watcher/watch/<watch_id>/_execute
{
"ignore_condition": true
}
4. 预防措施 #
- 使用强类型配置管理：在生成 watch JSON 时，确保时区等字段的值显式声明为字符串类型，避免动态语言（如 Python、JavaScript）自动进行类型推断。
- 在测试环境验证：Watcher 配置变更前，先在测试环境通过
_executeAPI 验证，确认不会因类型问题导致创建失败。 - 统一时区规范：团队内部约定时区表示方式，推荐使用
Asia/Shanghai、UTC等标准时区 ID，避免混用数字偏移量。 - 配置校验脚本：在 CI/CD 流程中加入 watch 配置的 JSON Schema 校验，提前发现类型错误。
- 监控 Watcher 状态：定期通过
GET _watcher/watch/_status检查 watch 运行状态，及时发现配置异常。
5. 小结 #
could not parse [input] for watch ... must be a string value 是一个典型的 Watcher 配置类型错误。其根因几乎总是某个字段被赋予了非字符串类型的值，修正方法是将对应字段改为合法的字符串格式。通过规范化 watch 配置的编写方式、引入配置校验以及在测试环境充分验证，可以有效避免此类问题再次发生。
相关错误 #
附：日志上下文 #
if (token == XContentParser.Token.VALUE_STRING) {
dynamicNameTimeZone = DateUtils.of(parser.text());
} else {
throw new ElasticsearchParseException("could not parse [{}] input for watch [{}]. failed to parse [{}]. must be a " +
"string value (e.g. 'UTC' or '+01:00').", TYPE, watchId, currentFieldName);
}
