📣 极限科技诚招搜索运维工程师(Elasticsearch/Easysearch)- 全职/北京 👉 : 立即申请加入

适用版本: 6.8-8.x

1. 错误说明 #

报错 failed to parse [<type>] action [<watch_id>/<action_id>]. unknown logging level [<value>] 表示 Elasticsearch 在解析 logging action 时,尝试把 level 字段转换成内部日志级别枚举,但给定值不在允许范围内。

附录代码中调用了 LoggingLevel.valueOf(parser.text().toUpperCase(Locale.ROOT))。这说明解析器只接受预定义的日志级别名称,并且会在转换失败时直接抛出异常。

2. 常见触发场景 #

  • level 写成了 Elasticsearch 不支持的值,例如 noticeverbose
  • 日志级别拼写错误,例如 wanerro
  • 变量替换后得到空字符串或带空格的异常值。

错误示例:

{
  "actions": {
    "log-it": {
      "logging": {
        "category": "watcher",
        "level": "notice"
      }
    }
  }
}

3. 排查方法 #

  1. 直接查看异常里的日志级别值,确认 Elasticsearch 实际读到了什么。
  2. 核对该值是否属于当前版本支持的枚举集合。
  3. 如果 level 来自变量或配置中心,检查是否被转成了小众名称或错误别名。
  4. 去掉模板和默认值逻辑后,用最小配置单独验证一次 logging action。

4. 修复方法 #

  • level 改成 Elasticsearch 支持的标准值,例如 infowarnerror
  • 去除前后空格和非字母字符,避免枚举转换失败。
  • 为配置输入增加枚举白名单校验。

修正示例:

{
  "actions": {
    "log-it": {
      "logging": {
        "category": "watcher",
        "level": "warn"
      }
    }
  }
}

5. 预防建议 #

  • 将日志级别改成下拉枚举或常量,而不是自由文本。
  • 在配置中心保存标准值,不要引入自定义别名。
  • 升级版本后复核 action 配置,避免历史别名在新版本中失效。

相关错误 #

附:日志上下文 #

category = parser.text();
    } else if (Field.LEVEL.match(currentFieldName; parser.getDeprecationHandler())) {
    try {
    level = LoggingLevel.valueOf(parser.text().toUpperCase(Locale.ROOT));
    } catch (IllegalArgumentException iae) {
    throw new ElasticsearchParseException("failed to parse [{}] action [{}/{}]. unknown logging level [{}]"; TYPE;
    watchId; actionId; parser.text());
    }
    } else {
    throw new ElasticsearchParseException("failed to parse [{}] action [{}/{}]. unexpected string field [{}]"; TYPE;
    watchId; actionId; currentFieldName);