ntopng-2018.01.02索引无法返回L7_PROTO_NAME分类数据求助

根据你提供的请求、响应以及索引对比情况，我整理了几个最可能导致ntopng-2018.01.02索引聚合无结果的原因：

1. 匹配查询条件的文档无有效L7_PROTO_NAME值 #

虽然你的查询命中了282条文档（hits.total:282），但这些文档的L7_PROTO_NAME字段可能是空值、null或者未被正确索引。你可以先执行一个简单查询验证这一点：

GET ntopng-2018.01.02/_search
{
  "size": 10,
  "query": {
    "bool": {
      "should": [
        { "term": { "IPV4_SRC_ADDR": "120.127.160.91" } },
        { "term": { "IPV4_DST_ADDR": "120.127.160.91" } }
      ],
      "minimum_should_match": 1,
      "must": [
        { "range": { "LAST_SWITCHED": { "gte": 1514800209 } } }
      ]
    }
  },
  "_source": ["L7_PROTO_NAME"]
}

如果返回的文档里L7_PROTO_NAME大多是空的，那就是这个原因——聚合只会统计有有效值的文档。

2. L7_PROTO_NAME.keyword字段映射存在差异 #

你提到两个索引字段类型“相同”，但可能存在细节差异：

• 先检查ntopng-2018.01.02索引中L7_PROTO_NAME.keyword的映射是否真的存在：

GET ntopng-2018.01.02/_mapping/field/L7_PROTO_NAME.keyword

如果返回结果显示该字段不存在，说明这个索引的L7_PROTO_NAME没有被配置为text+keyword类型，或者keyword子字段的名称不同（比如叫raw而非keyword）。

• 对比logstash-2018.01.02的映射，确认两者的L7_PROTO_NAME字段结构完全一致。

3. 数据索引时的处理逻辑不同 #

ntopng和logstash的数据源或数据处理流程可能存在差异：

• ntopng索引的日志可能在采集时没有正确识别应用层协议，导致L7_PROTO_NAME未被填充；
• 检查ntopng的日志输出配置，确认它是否真的会输出L7_PROTO_NAME字段，且字段值符合预期。

4. 查询时间范围过滤过严 #

虽然查询命中了282条文档，但这些文档可能都集中在L7_PROTO_NAME未被记录的时间段。你可以尝试放宽LAST_SWITCHED的范围（比如暂时去掉这个条件），再次执行聚合请求。如果能得到buckets结果，说明原时间范围内的数据确实没有有效L7_PROTO_NAME值。

内容的提问来源于stack exchange，提问作者張皓翔