Elasticsearch + Kibana，对 uri 进行排序不会产生任何结果。 （不分析uri）

Posted 2023-03-22

【中文标题】Elasticsearch + Kibana，对 uri 进行排序不会产生任何结果。 （不分析uri）

【英文标题】：Elasticsearch + Kibana, sorting on uri yields no results. (uri isn't analyzed)

【发布时间】：2017-01-31 22:54:36

【问题描述】：

我有一个 HTTP 请求日志，其中一个字段是 URI 字段。我想获得每个 URI 的平均持续时间（以毫秒为单位）。我将 Kibana 中的 y 轴设置为 "Aggregation: Average , Field: durationInMs"。

对于x轴我有

"Aggregation: terms, Field uri, Order by: metric average durationInMs, Order: descending: 5"

图片澄清：

这给了我一个结果，但它不使用 整个 URI。相反，它会拆分 URI 并匹配其中的一部分。快速谷歌后，我找到了“Multi-fields”，并在我的索引中添加了一个 URI.raw 字段。分析的字段警告消失了，但我根本没有得到 no 结果。

任何提示或提示？

lsc-logs2 映射：

  "lsc-logs2": 
    "mappings": 
      "httplogentry": 
        "properties": 
          "context": 
            "type": "string"
          ,
          "durationInMs": 
            "type": "double"
          ,
          "id": 
            "type": "long"
          ,
          "method": 
            "type": "string"
          ,
          "source": 
            "type": "string"
          ,
          "startTime": 
            "type": "date",
            "format": "strict_date_optional_time||epoch_millis"
          ,
          "status": 
            "type": "long"
          ,
          "uri": 
            "type": "string",
            "fields": 
              "raw": 
                "type": "string",
                "index": "not_analyzed"
              
            
          ,
          "username": 
            "type": "string"
          ,
          "version": 
            "type": "long"
          
        
      
    
  

示例文档：

    "_index": "lsc-logs2",
    "_type": "httplogentry",
    "_id": "1148440",
    "_score": 1,
    "_source": 
        "startTime": "2016-08-22T10:30:57.2298086+02:00",
        "context": "contexturi",
        "method": "GET",
        "uri": "http://uri/plannings/unassigned?date=2016-08-22T03:58:57.168Z&page=1&pageSize=9999",
        "username": "user",
        "source": "192.168.1.82",
        "durationInMs": 171.83710000000002,
        "status": 200,
        "id": 1148440,
        "version": 1
    

【问题讨论】：

添加原始字段后您是否重新索引数据？

我也在网上偶然发现了这个，但是我们唯一能找到的重新索引是 /_reindex 并像这样更改源和目​​标：“source”：“index”：“ lsc-logs" , "dest": "index": "lsc-logs2" 这花了大约 5 个小时，但仍然没有产生结果。我也刷新了 kibana 中的字段列表。有什么想法吗？

但是您在 Kibana 中拥有的索引模式仍在处理源索引，即 lsc-logs 而不是您的新索引 lsc-logs2 对吗？

不，我将 Kibana 切换到了 lsc-logs2，甚至将其设置为默认值，在创建可视化时我可以选择我想要的，我选择了 lsc-logs2。 url 中的 indexPattern 也设置为 lsc-logs2：imgur.com/a/4lvhT

你能运行这个查询并告诉我你是否得到了一些结果吗？ curl -XPOST localhost:9200/lsc-logs2/_search -d '"size":0, "aggs":"uris":"terms":"field":"uri.raw"'

【参考方案1】：

重新索引数据时，httplogentry 映射不会从lsc-logs 移植到lsc-logs2，您需要先创建目标索引+映射，然后才能重新索引。

先删除当前目标索引

curl -XDELETE localhost:9200/lsc-logs2

然后通过指定正确的映射重新创建它

curl -XPUT localhost:9200/lsc-logs2 -d '
    "mappings": 
      "httplogentry": 
        "properties": 
          "context": 
            "type": "string"
          ,
          "durationInMs": 
            "type": "double"
          ,
          "id": 
            "type": "long"
          ,
          "method": 
            "type": "string"
          ,
          "source": 
            "type": "string"
          ,
          "startTime": 
            "type": "date",
            "format": "strict_date_optional_time||epoch_millis"
          ,
          "status": 
            "type": "long"
          ,
          "uri": 
            "type": "string",
            "fields": 
              "raw": 
                "type": "string",
                "index": "not_analyzed"
              
            
          ,
          "username": 
            "type": "string"
          ,
          "version": 
            "type": "long"
          
        
      
    
'

然后你可以重新索引你的数据：

curl -XPOST localhost:9200/_reindex -d '
  "source": 
    "index": "lsc-logs"
  ,
  "dest": 
    "index": "lsc-logs2"
  
'

然后在 Kibana 中刷新索引模式中的字段，它应该可以工作。

【讨论】：

它现在正在运行这些东西，可能需要一段时间：P 已经在 Kibana 中确认原始字段显示在新索引上：D

您是否在索引新文档之前使用正确的映射预先创建了lsc-logs3 索引？

您确保在任何地方都将2 替换为3，对吗？可以分享lsc-logs3的映射吗？

好的，我认为问题在于您在同一个索引中有两种映射类型（httplogentry 和 elasticlogentry）都有一个名为 uri 的字段，但一个有原始子字段而另一个没有。那是个问题。您通过 C# 索引哪一个？我敢打赌是elasticlogentry

完成了，考虑到这个问题的悠久历史，我最终可能会忘记 ;-)