用过 kibana 的都知道，kibana 的图表上，可以直接点击某个值，就能自动添加这个过滤条件到 filtering 里，然后整个 dashboard 上所有的图表都会刷新成在这个过滤条件下的新状态。但是如果你要想自己手动添加 filtering 的时候，就会发现，自己添加的，写法好像跟自动生成的长得不太一样。
而今天，我在同事的提醒下，发现更进一步的情况，即使都是通过点击图表添加上的 filtering，其实长得也不一样，如下图：
- 在 histogram 面板上拖拽鼠标，生成的是 range filtering
- 在 terms 面板上点击某个值，生成的是 term filtering
- 在 table 面板左侧列表上点击某个字段，浮出的小面板里点击某个值，生成的是 query filtering
- 在 filtering 手工添加，生成的是 query_string filtering
这几个页面上的不同，反应在实际的请求 JSON 里又有什么区别呢？
我们可以点开面板右上角的 inspect 按钮看生成的 curl 命令。其中 filtering 部分如下：
"filter": {
"bool": {
"must": [
{
"range": {
"@timestamp": {
"from": 1418009781101,
"to": "now"
}
}
},
{
"terms": {
"_type": [
"mweibo_webinf"
]
}
},
{
"fquery": {
"query": {
"query_string": {
"query": "host:(\"web093.mweibo.tc.sinanode.com\")"
}
},
"_cache": true
}
},
{
"fquery": {
"query": {
"query_string": {
"query": "host:\"web093.mweibo.tc.sinanode.com\""
}
},
"_cache": true
}
}
]
}
}
前面两个不出意外，都是很标准的 api 示例的样子。比较特殊的是后面两个：
第三个其实就是通过 table 左侧字段菜单点出来的，虽然通过鼠标点击操作，只可能生成一个单一的键值查询，但这里却给加上了一对小括号！这是完全没有必要的，简直可以怀疑是不是当初开发人员手抖了……
当然，并不是说这种生成完全没有用。比方说，其实你本来是打算查询来自两台机器的日志。如果没想到用括号，可能直接在 query_string 里就写 host:"web001" OR host:"web002" 了。但是在这个 query filtering 里，因为页面上已经有单独填字段的地方了。那就只用在 query 那栏写 "web001" OR "web002" 好了。
以上。不过我依然怀疑是开发人员手抖。
