Elasticsearch msearch调用报错：metadata section不支持size字段

问题本质 #

这个错误的核心是msearch请求格式不符合NDJSON规范：msearch要求每一组查询由单行元数据JSON和单行查询体JSON组成，两行以换行分隔。首次调用失败大概率是因为请求体的格式异常（比如多余缩进、换行错乱），导致Elasticsearch误将查询体中的size字段识别到了元数据区域，后续调用可能因客户端缓存了修正后的格式而恢复正常。

解决步骤 #

1. 严格修正请求格式 #

确保请求体严格遵循NDJSON格式：元数据和查询体各自为无缩进的单行JSON，两行用换行分隔。修正后的请求示例如下：

{"search_type":"query_then_fetch","ignore_unavailable":true,"index":"*****"}
{"size":0,"query":{"bool":{"filter":[{"range":{"@timestamp":{"gte":"1710391896481","lte":"1710413496481","format":"epoch_millis"}}},{"query_string":{"analyze_wildcard":true,"query":"*"}}]}},"aggs":{"2":{"date_histogram":{"fixed_interval":"30s","field":"@timestamp","min_doc_count":0,"extended_bounds":{"min":"1710391896481","max":"1710413496481"},"format":"epoch_millis"},"aggs":{}}}

2. 排查客户端序列化逻辑 #

首次失败后续正常的现象，通常是客户端（前端JS、后端HTTP工具）首次请求时未正确序列化NDJSON：

• 去掉查询体的所有缩进和多余换行，确保元数据和查询体都是纯单行JSON；
• 避免在发送请求前对JSON进行格式化处理，直接使用压缩后的单行格式；
• 检查客户端是否存在缓存机制，确认后续调用是否复用了已修正的请求体。

3. 用curl验证格式正确性 #

可以通过curl直接测试修正后的请求，排除格式问题：

curl -X POST "http://你的ES地址:9200/_msearch" -H "Content-Type: application/x-ndjson" -d '
{"search_type":"query_then_fetch","ignore_unavailable":true,"index":"*****"}
{"size":0,"query":{"bool":{"filter":[{"range":{"@timestamp":{"gte":"1710391896481","lte":"1710413496481","format":"epoch_millis"}}},{"query_string":{"analyze_wildcard":true,"query":"*"}}]}},"aggs":{"2":{"date_histogram":{"fixed_interval":"30s","field":"@timestamp","min_doc_count":0,"extended_bounds":{"min":"1710391896481","max":"1710413496481"},"format":"epoch_millis"},"aggs":{}}}
'

4. 检查可视化工具配置（若适用） #

如果是Kibana或其他工具生成的请求，确认工具的「索引/元数据设置」中没有误添加size参数——size属于查询体参数，绝对不能放在元数据区域。

内容的提问来源于stack exchange，提问作者Varun Saxena