Elasticsearch查询CRITICAL级重复日志无结果问题求助

我之前也碰到过类似的问题，大概率是**message_description.keyword字段的长度限制**在搞鬼——这是Elasticsearch里很容易踩的一个坑！

问题根源拆解 #

Elasticsearch中默认的keyword类型字段自带一个ignore_above参数，默认值是256字符。如果字段内容长度超过这个值，Elasticsearch会直接忽略该内容，不会将其索引到keyword子字段中。

• 你成功查到的WARNING日志消息"AuthToken not found [ ]"很短，远小于256字符，所以keyword字段能正常被索引和聚合；
• 而你提供的CRITICAL级message_description内容很长，明显超过了256字符，导致对应的keyword字段没有被索引，自然聚合不到结果。

第一步：验证猜测 #

先执行以下命令查看message_description字段的映射，确认ignore_above的设置：

GET /filebeat-2019.09.17/_mapping/field/message_description

如果返回结果里keyword子字段的ignore_above是256，那就坐实了这个问题。

解决方案 #

方案1：修改字段映射并重新索引（长期方案） #

这个方案适合长期使用，需要调整映射并重新导入数据：

1. 创建自定义索引模板，把message_description.keyword的ignore_above设置为更大的值（比如10000，可根据你的实际日志长度调整）：

PUT /_template/filebeat-custom
{
  "index_patterns": ["filebeat-*"],
  "mappings": {
    "properties": {
      "message_description": {
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword",
            "ignore_above": 10000
          }
        }
      }
    }
  }
}

2. 重新索引现有数据到新索引（或者删除旧索引后重新采集日志）：

POST _reindex
{
  "source": {
    "index": "filebeat-2019.09.17"
  },
  "dest": {
    "index": "filebeat-2019.09.17-new"
  }
}

3. 之后用新索引执行你的聚合查询，就能正常查到CRITICAL级的重复日志统计了。

方案2：使用Runtime Field临时聚合（无需修改映射） #

如果不想重新索引数据，可以用Runtime Field在查询时临时将message_description转换为可聚合的keyword类型：

GET /_all/_search
{
  "runtime_mappings": {
    "message_description_long_keyword": {
      "type": "keyword",
      "script": {
        "source": "emit(doc['message_description'].value)"
      }
    }
  },
  "query": {
    "bool": {
      "must": [
        { "match": { "beat.hostname": "server-x" } },
        { "match": { "log_level": "CRITICAL" } },
        { "range": { "@timestamp" : { "gte" : "now-48h", "lte" : "now" } } }
      ]
    }
  },
  "aggs": {
    "duplicateNames": {
      "terms": {
        "field": "message_description_long_keyword",
        "min_doc_count": 2,
        "size": 10000
      }
    }
  }
}

这个查询会在运行时生成一个临时的keyword字段，直接聚合它就能得到你要的重复日志结果。

额外排查点 #

如果上面的方法还是不行，可以再检查这两点：

• 确认时间范围now-48h是否包含目标日志的@timestamp（虽然你说Kibana能看到，但偶尔会有时区匹配问题）；
• 检查log_level字段的映射，确保是keyword类型，避免匹配时的分词问题（不过你能查到WARNING，这点大概率没问题）。

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