Elastic日报 第66期 (2017-10-11)

1.Elasticsearch Log日志文件的那些事儿(请自备梯子)
http://t.cn/ROJXBR1
2.还在为 Elasticsearch 集群规划发愁吗?来看看完美方案吧!
http://t.cn/ROJaPRo
3.来看看 Kibana 6 新增的 dashboard only 模式吧! 
http://t.cn/ROJaiqT

编辑:rockybean
归档:https://elasticsearch.cn/article/308
订阅:https://tinyletter.com/elastic-daily 
继续阅读 »
1.Elasticsearch Log日志文件的那些事儿(请自备梯子)
http://t.cn/ROJXBR1
2.还在为 Elasticsearch 集群规划发愁吗?来看看完美方案吧!
http://t.cn/ROJaPRo
3.来看看 Kibana 6 新增的 dashboard only 模式吧! 
http://t.cn/ROJaiqT

编辑:rockybean
归档:https://elasticsearch.cn/article/308
订阅:https://tinyletter.com/elastic-daily  收起阅读 »

Elastic日报 第65期 (2017-10-10)

1.一步一步教你如何保证elastic-stack数据的安全。
http://t.cn/ROqjpND 
2.数据分析师的探险之旅,X-Pack还是R?
http://t.cn/ROqjYzk 
3.深入分析如何使用ES中的父子文档。
http://t.cn/ROqjmzP 

编辑:叮咚光军
归档:https://elasticsearch.cn/article/307 
订阅:https://tinyletter.com/elastic-daily 

 
继续阅读 »
1.一步一步教你如何保证elastic-stack数据的安全。
http://t.cn/ROqjpND 
2.数据分析师的探险之旅,X-Pack还是R?
http://t.cn/ROqjYzk 
3.深入分析如何使用ES中的父子文档。
http://t.cn/ROqjmzP 

编辑:叮咚光军
归档:https://elasticsearch.cn/article/307 
订阅:https://tinyletter.com/elastic-daily 

  收起阅读 »

Elastic日报 第64期 (2017-10-09)

1、Elastic十年工程师老司机带你了解timelion的魔力
http://t.cn/Rowh1dl

2、即刻技术团队带来的的mongodb-elasticsearch 数据同步方案。
http://t.cn/RaOonLb

3、集群太多?数据不方便管理?来看看Netflix的es自动化管理运维工具:Raigad
http://t.cn/ROGTENC

编辑:cyberdak
归档:https://www.elasticsearch.cn/article/306
订阅:https://tinyletter.com/elastic-daily
继续阅读 »
1、Elastic十年工程师老司机带你了解timelion的魔力
http://t.cn/Rowh1dl

2、即刻技术团队带来的的mongodb-elasticsearch 数据同步方案。
http://t.cn/RaOonLb

3、集群太多?数据不方便管理?来看看Netflix的es自动化管理运维工具:Raigad
http://t.cn/ROGTENC

编辑:cyberdak
归档:https://www.elasticsearch.cn/article/306
订阅:https://tinyletter.com/elastic-daily 收起阅读 »

Elastic日报 第63期 (2017-09-30)

1、你知道es提取词干的算法原理吗?
http://t.cn/R0Y5CoA
2、利用机器学习来分析你的nginx日志吧
http://t.cn/R0Yc58j
3、如何最大程度地保证es集群安全?
http://t.cn/R0Y9vxc
4、Elastic线下活动已有5个主题,欢迎报名分享:
https://elasticsearch.cn/article/261
编辑:bsll
归档:https://www.elasticsearch.cn/article/305
订阅:https://tinyletter.com/elastic-daily
PS: 预祝大家国庆节快乐,然后中秋节快乐!节日里多吃多睡多玩多开心,日报编辑们也要去过节了,因此日报暂停更新8日,节日后再见啦!
 
继续阅读 »
1、你知道es提取词干的算法原理吗?
http://t.cn/R0Y5CoA
2、利用机器学习来分析你的nginx日志吧
http://t.cn/R0Yc58j
3、如何最大程度地保证es集群安全?
http://t.cn/R0Y9vxc
4、Elastic线下活动已有5个主题,欢迎报名分享:
https://elasticsearch.cn/article/261
编辑:bsll
归档:https://www.elasticsearch.cn/article/305
订阅:https://tinyletter.com/elastic-daily
PS: 预祝大家国庆节快乐,然后中秋节快乐!节日里多吃多睡多玩多开心,日报编辑们也要去过节了,因此日报暂停更新8日,节日后再见啦!
  收起阅读 »

一例Query Cache引起的性能问题分析

【携程旅行网  吴晓刚】

注:本文是针对社区问题 https://elasticsearch.cn/question/2484 的分析和总结。

问题概述:
一个线上集群,执行的Query DSL都是一样的,只是参数不同。 统计数据显示98-99%的查询响应速度都很快,只需要4 -6ms, 但有1%左右的查询响应时间在100ms - 200ms。 集群硬件配置较高,使用的SSD,系统可用内存远高于索引文件大小总和,并且线上已经运行有一段时间,数据应该已经充分预热。

诊断过程及结论:
比较巧的是,问题提出者刚好是我们自家公司的开发者,因此内部联系沟通了下,为问题的快速诊断提供了不少便利。

首先用公司的监控系统排查了一遍集群所有关键数据,未发现任何可能引起查询耗时高的性能瓶颈问题。 因此初步怀疑就是有查询本身比较慢。 幸好公司有应用埋点系统和日志系统,因此很方便的拿到了应用端发出的一些慢查询样例,包括请求体以及耗时。

以下是埋点系统里记录的一个耗时150ms的查询 (隐去了敏感信息,去掉了非关键部分):
POST /xxxindex/xxxdb/_search?routing=Mxxxxxxx
{
"from": 0,
"size": 100,
"query": {
"bool": {
"filter": [
{
"bool": {
"must": [
{
"bool": {
"must": [
{
"bool": {
"should": [
{
"match_phrase": {
"ord_orders_uid": {
"query": "Mxxxxxxx",
"slop": 0,
"boost": 1
}
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
},
{
"range": {
"ord_orders_orderdate": {
"from": "1405032032",
"to": "1504014193",
"include_lower": true,
"include_upper": true,
"boost": 1
}
}
},
{
"term": {
"ord_orders_ispackageorder": {
"value": 0,
"boost": 1
}
}
},
{
"bool": {
"must_not": [
{
"exists": {
"field": "ord_hideorder_orderid",
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
}
拿到查询后,自己手动执行了一下,0 hits,耗时1ms。  心里明白,命中了Query Cache,所以才会这么快。 
 
于是用clear api清掉Query Cache,然后再执行几次,有以下发现:
  1. 头两次查询耗时38ms左右。 这是因为没有cache,需要访问倒排索引,耗时符合预期。 之所以两次同样耗时,是因为索引有1个复制片,两次查询分别分配到主和副片上。
  2. 接下来两次查询耗时150ms左右。  这里要打一个大大的问号???
  3. 之后不管再查询多少次, 耗时全部是1ms,因为又开始命中Cache。

 
至此,大致明白,埋点系统里记录到的高耗时查询,是步骤2的两次操作。 什么操作耗时这么久呢? 根据经验,我判断主要是用于为range filter生成缓存,也就生成生成文档列表的bitmap,然后存放到Query Cache里。 

这个集群版本是5.1.1, 而我记得ES某个5版本开始,去掉了对term filter的cache,理由是term filter速度足够快,缓存term filter往往得不偿失。 查了官方release notes,证实这个改变正好是从5.1.1开始的(#21566),因此上面查询里的term filters被排除掉,注意力集中到了查询里唯一的一个range filter。 

单独执行了一下这个range filter,match的文档是千万数量级的。 询问用户,为何这个range filter会hit这么多文档,得知用户主要就是查询从当前时间开始至过去1年的数据,类似于做了一个now-1y  TO now这样的过滤。至此初步得出结论,因为这个range filter匹配的文档太多了,在Query Cache里为这个filter构建bitmap耗时会有些高,应该就是它带来了那额外的100多个ms。

但是还有一个待解释的问题,这种高耗时查询比例为何这么高? 再仔细想想也就明白了:因为这个集群的搜索并发量还是有点高,300 -400/s的样子,加上时间字段的精度是秒,所以,在某一秒刚开始的时候,头2次查询因为没有cache,耗时可能在38ms左右,之后会有2次查询因为需要缓存range filter,耗时会增加到150-200ms的样子,之后这1秒里剩余的查询都会命中cache,全部是几个ms, 直到下一秒开始, 周而复始。 因为每秒钟都产生2个这样需要构建缓存的查询,耗时较高,对比每秒几百次的查询量,换算成百分比就有点高了。

那么怎么解决这个问题? 对于大量含有从now-xxx TO now这样的range查询,实际上官方的文档有对应的加速技巧介绍:tune-for-search-speed.html#_search_rounded_dates 。也就是说,将查询时间的上下限round到整分钟,或者整小时,让range filter可以缓存得更久,避免出现这种过于频繁重建cache的情况。
{
"range": {
"my_date": {
"gte": "now-1y/h",
"lte": "now-1y/h"
}
}
}

在原始Query里,将range filter写成上述形式,手动测试证实可行,range filter有效期延长到1小时,从而每个小时里,只需要为range filter重建2次Cache,至此问题解决。
 
 
总结:
  1. Cache并非建得越多越好,因为Cache的生成和Evict会带来额外的开销。特别是结果集非常大的filter,缓存的代价相对查询本身可能非常高。
  2. ES 5.1.1开始取消了Terms filter Cache,因为Terms filter执行非常快,取消缓存多数情况下反而可以提高性能。
  3. 大量用到Now-xxxd To Now这样的Range filter时,可以借助round date技巧,提高Cache的有效期,减轻频繁重建Cache带来的性能问题。

继续阅读 »
【携程旅行网  吴晓刚】

注:本文是针对社区问题 https://elasticsearch.cn/question/2484 的分析和总结。

问题概述:
一个线上集群,执行的Query DSL都是一样的,只是参数不同。 统计数据显示98-99%的查询响应速度都很快,只需要4 -6ms, 但有1%左右的查询响应时间在100ms - 200ms。 集群硬件配置较高,使用的SSD,系统可用内存远高于索引文件大小总和,并且线上已经运行有一段时间,数据应该已经充分预热。

诊断过程及结论:
比较巧的是,问题提出者刚好是我们自家公司的开发者,因此内部联系沟通了下,为问题的快速诊断提供了不少便利。

首先用公司的监控系统排查了一遍集群所有关键数据,未发现任何可能引起查询耗时高的性能瓶颈问题。 因此初步怀疑就是有查询本身比较慢。 幸好公司有应用埋点系统和日志系统,因此很方便的拿到了应用端发出的一些慢查询样例,包括请求体以及耗时。

以下是埋点系统里记录的一个耗时150ms的查询 (隐去了敏感信息,去掉了非关键部分):
POST /xxxindex/xxxdb/_search?routing=Mxxxxxxx
{
"from": 0,
"size": 100,
"query": {
"bool": {
"filter": [
{
"bool": {
"must": [
{
"bool": {
"must": [
{
"bool": {
"should": [
{
"match_phrase": {
"ord_orders_uid": {
"query": "Mxxxxxxx",
"slop": 0,
"boost": 1
}
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
},
{
"range": {
"ord_orders_orderdate": {
"from": "1405032032",
"to": "1504014193",
"include_lower": true,
"include_upper": true,
"boost": 1
}
}
},
{
"term": {
"ord_orders_ispackageorder": {
"value": 0,
"boost": 1
}
}
},
{
"bool": {
"must_not": [
{
"exists": {
"field": "ord_hideorder_orderid",
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
}
拿到查询后,自己手动执行了一下,0 hits,耗时1ms。  心里明白,命中了Query Cache,所以才会这么快。 
 
于是用clear api清掉Query Cache,然后再执行几次,有以下发现:
  1. 头两次查询耗时38ms左右。 这是因为没有cache,需要访问倒排索引,耗时符合预期。 之所以两次同样耗时,是因为索引有1个复制片,两次查询分别分配到主和副片上。
  2. 接下来两次查询耗时150ms左右。  这里要打一个大大的问号???
  3. 之后不管再查询多少次, 耗时全部是1ms,因为又开始命中Cache。

 
至此,大致明白,埋点系统里记录到的高耗时查询,是步骤2的两次操作。 什么操作耗时这么久呢? 根据经验,我判断主要是用于为range filter生成缓存,也就生成生成文档列表的bitmap,然后存放到Query Cache里。 

这个集群版本是5.1.1, 而我记得ES某个5版本开始,去掉了对term filter的cache,理由是term filter速度足够快,缓存term filter往往得不偿失。 查了官方release notes,证实这个改变正好是从5.1.1开始的(#21566),因此上面查询里的term filters被排除掉,注意力集中到了查询里唯一的一个range filter。 

单独执行了一下这个range filter,match的文档是千万数量级的。 询问用户,为何这个range filter会hit这么多文档,得知用户主要就是查询从当前时间开始至过去1年的数据,类似于做了一个now-1y  TO now这样的过滤。至此初步得出结论,因为这个range filter匹配的文档太多了,在Query Cache里为这个filter构建bitmap耗时会有些高,应该就是它带来了那额外的100多个ms。

但是还有一个待解释的问题,这种高耗时查询比例为何这么高? 再仔细想想也就明白了:因为这个集群的搜索并发量还是有点高,300 -400/s的样子,加上时间字段的精度是秒,所以,在某一秒刚开始的时候,头2次查询因为没有cache,耗时可能在38ms左右,之后会有2次查询因为需要缓存range filter,耗时会增加到150-200ms的样子,之后这1秒里剩余的查询都会命中cache,全部是几个ms, 直到下一秒开始, 周而复始。 因为每秒钟都产生2个这样需要构建缓存的查询,耗时较高,对比每秒几百次的查询量,换算成百分比就有点高了。

那么怎么解决这个问题? 对于大量含有从now-xxx TO now这样的range查询,实际上官方的文档有对应的加速技巧介绍:tune-for-search-speed.html#_search_rounded_dates 。也就是说,将查询时间的上下限round到整分钟,或者整小时,让range filter可以缓存得更久,避免出现这种过于频繁重建cache的情况。
{
"range": {
"my_date": {
"gte": "now-1y/h",
"lte": "now-1y/h"
}
}
}

在原始Query里,将range filter写成上述形式,手动测试证实可行,range filter有效期延长到1小时,从而每个小时里,只需要为range filter重建2次Cache,至此问题解决。
 
 
总结:
  1. Cache并非建得越多越好,因为Cache的生成和Evict会带来额外的开销。特别是结果集非常大的filter,缓存的代价相对查询本身可能非常高。
  2. ES 5.1.1开始取消了Terms filter Cache,因为Terms filter执行非常快,取消缓存多数情况下反而可以提高性能。
  3. 大量用到Now-xxxd To Now这样的Range filter时,可以借助round date技巧,提高Cache的有效期,减轻频繁重建Cache带来的性能问题。

收起阅读 »

Elastic日报 第62期 (2017-09-29)

1、profiling 工具 | 一眼看透慢查询!
http://t.cn/RInoI4c 
2、ElasticSearch的实时日志系统架构与总结。
http://t.cn/RaX2lMm 
3、你早该知道的Elasticsearch性能指标!
http://t.cn/R0Nn3KK 
4、P2P领域ES实战经验分享!
http://t.cn/R0NmyhU 

编辑:laoyang360
归档:https://www.elasticsearch.cn/article/302 
订阅:https://tinyletter.com/elastic-daily 
 
继续阅读 »
1、profiling 工具 | 一眼看透慢查询!
http://t.cn/RInoI4c 
2、ElasticSearch的实时日志系统架构与总结。
http://t.cn/RaX2lMm 
3、你早该知道的Elasticsearch性能指标!
http://t.cn/R0Nn3KK 
4、P2P领域ES实战经验分享!
http://t.cn/R0NmyhU 

编辑:laoyang360
归档:https://www.elasticsearch.cn/article/302 
订阅:https://tinyletter.com/elastic-daily 
  收起阅读 »

中文值的字段是string的类型吗?我有一个字段类型一直显示unknown

我新增加了一个字段,对应的值是中文的

QQ图片20170928162123.png

 如上图 我的这个字段类型一直是unknown,下图是配置方式:

QQ图片20170928162329.png

 es 是5.4的
logstash 5.4
kibana 5.4
 
 
 
继续阅读 »
我新增加了一个字段,对应的值是中文的

QQ图片20170928162123.png

 如上图 我的这个字段类型一直是unknown,下图是配置方式:

QQ图片20170928162329.png

 es 是5.4的
logstash 5.4
kibana 5.4
 
 
  收起阅读 »

Kibana 插件开发教程

最近公司有开发kibana plugin 需求,正好有时间研究这块。现将自己学习过程及官方资源写成一个浅显易懂的kibana plugin 开发教程书籍
 
 
在线阅读地址
 
 
内容还在持续增加,欢迎有这方面经验的人加入我们。
 
 
 
案例一下 博客,欢迎follower,欢迎交流!
 
 
继续阅读 »
最近公司有开发kibana plugin 需求,正好有时间研究这块。现将自己学习过程及官方资源写成一个浅显易懂的kibana plugin 开发教程书籍
 
 
在线阅读地址
 
 
内容还在持续增加,欢迎有这方面经验的人加入我们。
 
 
 
案例一下 博客,欢迎follower,欢迎交流!
 
  收起阅读 »

Elastic日报 第61期 (2017-09-28)

1.将elasticsearch的数据自动metric到prometheus http://t.cn/R09JjJh
2.详解Elasticsearch的nested类型aggregations? http://t.cn/R0Nk3EA
3.社区热议:elasticsearch的中文打分到底是怎样的呢? https://elasticsearch.cn/question/2275

编辑:金桥
归档:https://elasticsearch.cn/article/299
订阅:https://tinyletter.com/elastic-daily
继续阅读 »
1.将elasticsearch的数据自动metric到prometheus http://t.cn/R09JjJh
2.详解Elasticsearch的nested类型aggregations? http://t.cn/R0Nk3EA
3.社区热议:elasticsearch的中文打分到底是怎样的呢? https://elasticsearch.cn/question/2275

编辑:金桥
归档:https://elasticsearch.cn/article/299
订阅:https://tinyletter.com/elastic-daily 收起阅读 »