ES的”莫衷一是“
诡异的filter结果
之前的黑产又找到我们一个服务的漏洞来上传视频伪装图片,这次上传的数据可以在ES查到,从ES按时间维度查询出来结果导出csv,取出对象ID后进行鉴别和删除处理。按理说应该很快就处理完成了,但是发现删完CDN的带宽流量并没有下降到正常标准,用CDN访问日志和ES导出的结果对比,发现ES导出的结果缺少了很多黑产记录,怀疑是ES这边查询的”姿势“不对。

找了一个1分钟的时间段进行查询,在filter中指定product、@timestamp、url为条件,其中url=png(黑产传的图片都是png格式的),结果出来两条,如下图:

去掉url=png,查询的结果有9条,包含上面的两条结果。

看来就是filter加了url=png后的查询结果不完整导致的,头大~~

哪里出的问题
日常使用kinbana不是很多,查询的时候主要也是基于web界面中添加filter条件来查询,刚开始怀疑是不是写入的数据格式有差异,.png字符上有区别,对比两种结果发现没有任何区别。

加了filter url=png查询的结果是有黄色高亮的,网上有人说高亮插件导致的查询不准确,怀疑这个是不是高亮条件导致的,

在inspector中修改一下构建的查询语句,去掉高亮条件,

结果还是两条,那就不是高亮条件导致的。

”歪打正着“解决了
在Google查询问题的时候发现有人提出should(elasticsearch查询数据结果不全面?)这块的bug,细看查询的语句格式,url:png这个match_phrase在filter下面,如下图

将url这个放到should中,再次查询,结果就全部出来了,惊不惊喜

写在最后
在ES查询中must、should、must_not含义如下:
must:必须满足的条件—and
should:可以满足也可以不满足的条件–or
must_not:不需要满足的条件—not
目前用should解决了查询问题,但是为什么ES形成这样的情况还不得而知,不负责ES组件,目前能观察到的ES部分索引节点的load不一致,反馈给对应负责的同事。