使用 POST 与 GET 时,ELK 查询在 Sense 中给出不同的结果
ELK query gives different results in Sense when using POST vs. GET
使用 Sense 工具,我有两个非常简单的查询。除了方法(GET 或 POST)之外,查询是相同的。当 运行 一次查询一个查询时,我看到的结果虽然非常相似,但不同之处似乎与查询本身无关(例如,max_score)并且变得不那么相似我把范围扩大了。
例如,这些 return 与我预期的结果相同:
我的 GET 查询:
GET syslog-*/_search
{
"size": 5,
"query" : {
"bool": {
"must":
{
"term":{"@hostname":"MyServer"}
}
}
}
}
我的POST查询:
POST syslog-*/_search
{
"size": 5,
"query" : {
"bool": {
"must":
{
"term":{"@hostname":"MyServer"}
}
}
}
}
当更改为 "size": 50
时,它们开始时相同,但大约 1/3 的输出开始漂移;最终达到 PUT 中存在的时间戳在 GET 结果中无处可寻的地步。当我转到 "size": 5000
之类的内容时,结果变得截然不同,以至于我开始怀疑根据这些查询构建的任何报告数据的准确性。
我才刚刚开始将 ELK 与 Sense 结合使用,所以这可能是正常现象。高级开发人员向我保证,在使用 Sense 从 Elasticsearch 数据库中获取信息时,GET 与 PUT 在功能上没有区别,但我可能误解了他。无论如何,我想 post 这个问题,看看我是否理解正确。
发现另一个似乎解决了这个问题的问题 ()。但是在阅读细节时,这让我更加困惑,因为根据关于 post 的公认答案,POST 实际上是一个 GET。
The explanation is related to GET vs. POST http methods. Behind the
scene Sense actually converts a GET request to a HTTP POST....even if
you write GET, the actual http request is a POST.
在与其他开发人员进行更多交谈并更加热情地深入研究 Elasticsearch 文档后找到了答案。简而言之,问题是缺乏定义的排序方法。 This 是文档中关于不排序时行为的关键位:
...we are indicating that we just want the documents that match...with no attempt to determine relevance. Documents will be returned in effectively random order...
所以整个 GET 与 POST 的事情是无关紧要的。我越来越不一致的结果与更大的尺寸的原因是由于结果 'randomness' 随着查询变得更大的机会增加。所以这两个查询(现在按日期排序)...
GET syslog-*/_search
{
"size": 1000,
"query" : {
"bool": {
"must":
{
"term":{"@hostname":"MyServer"}
}
}
},
"sort":{"@timestamp":{"order":"desc"}}
}
"hits":{"total":7554334,....
...return 完全一样的结果。请注意,即使将大小设置为 1000,命中数也是相同的。
POST syslog-*/_search
{
"size": 1000,
"query" : {
"bool": {
"must":
{
"term":{"@hostname":"MyServer"}
}
}
},
"sort":{"@timestamp":{"order":"desc"}}
}
"hits":{"total":7554334,....
理智恢复。 :D
使用 Sense 工具,我有两个非常简单的查询。除了方法(GET 或 POST)之外,查询是相同的。当 运行 一次查询一个查询时,我看到的结果虽然非常相似,但不同之处似乎与查询本身无关(例如,max_score)并且变得不那么相似我把范围扩大了。
例如,这些 return 与我预期的结果相同:
我的 GET 查询:
GET syslog-*/_search
{
"size": 5,
"query" : {
"bool": {
"must":
{
"term":{"@hostname":"MyServer"}
}
}
}
}
我的POST查询:
POST syslog-*/_search
{
"size": 5,
"query" : {
"bool": {
"must":
{
"term":{"@hostname":"MyServer"}
}
}
}
}
当更改为 "size": 50
时,它们开始时相同,但大约 1/3 的输出开始漂移;最终达到 PUT 中存在的时间戳在 GET 结果中无处可寻的地步。当我转到 "size": 5000
之类的内容时,结果变得截然不同,以至于我开始怀疑根据这些查询构建的任何报告数据的准确性。
我才刚刚开始将 ELK 与 Sense 结合使用,所以这可能是正常现象。高级开发人员向我保证,在使用 Sense 从 Elasticsearch 数据库中获取信息时,GET 与 PUT 在功能上没有区别,但我可能误解了他。无论如何,我想 post 这个问题,看看我是否理解正确。
发现另一个似乎解决了这个问题的问题 (
The explanation is related to GET vs. POST http methods. Behind the scene Sense actually converts a GET request to a HTTP POST....even if you write GET, the actual http request is a POST.
在与其他开发人员进行更多交谈并更加热情地深入研究 Elasticsearch 文档后找到了答案。简而言之,问题是缺乏定义的排序方法。 This 是文档中关于不排序时行为的关键位:
...we are indicating that we just want the documents that match...with no attempt to determine relevance. Documents will be returned in effectively random order...
所以整个 GET 与 POST 的事情是无关紧要的。我越来越不一致的结果与更大的尺寸的原因是由于结果 'randomness' 随着查询变得更大的机会增加。所以这两个查询(现在按日期排序)...
GET syslog-*/_search
{
"size": 1000,
"query" : {
"bool": {
"must":
{
"term":{"@hostname":"MyServer"}
}
}
},
"sort":{"@timestamp":{"order":"desc"}}
}
"hits":{"total":7554334,....
...return 完全一样的结果。请注意,即使将大小设置为 1000,命中数也是相同的。
POST syslog-*/_search
{
"size": 1000,
"query" : {
"bool": {
"must":
{
"term":{"@hostname":"MyServer"}
}
}
},
"sort":{"@timestamp":{"order":"desc"}}
}
"hits":{"total":7554334,....
理智恢复。 :D