Day4: significant_terms聚合

昨天我们通过 nested aggregation 计算出来,视频卡顿次数最多的是北京。不过这个结论似乎也没有什么奇怪的,北京的网民本身就多嘛。

Elasticsearch 还有一个有趣的聚合方式,叫 significant_terms。这时候就可以派上用场了!

我们把昨天的 query JSON 中,最后一段 sub agg 改成这样:
    "city_terms" : {
"significant_terms" : {
"field" : "geoip.city",
"size" : "4"
}
}
重新运行请求,得到的响应结果是这样的:
"city_terms" : {
"doc_count" : 2521720,
"buckets" : [ {
"key" : "武汉",
"doc_count" : 85980,
"score" : 0.1441705001066121,
"bg_count" : 15347191
}, {
"key" : "北京",
"doc_count" : 142761,
"score" : 0.11808069152203737,
"bg_count" : 43176384
}, {
"key" : "广州",
"doc_count" : 104677,
"score" : 0.10716870365361204,
"bg_count" : 27274482
}, {
"key" : "郑州",
"doc_count" : 59234,
"score" : 0.09915501610550795,
"bg_count" : 10587590
} ]
}
大家一定发现了:第一名居然变成了武汉!

而且每个结果后面,还多出来了 score 和 bg_count 两个数据。这个 bg_count 是怎么回事呢?

这就是 significant_terms 的作用了。这个 agg 的大概计算步骤是这样:
  1. 计算一个 term 在整个索引中的比例,作为背景计数(background),这里是 15347191 / 2353406423;
  2. 计算一个 term 在 parent agg 中的比例,作为前景计数(foreground),这里是 85980 / 2521720;
  3. 用 fgpercent 除以 bgpercent,得到这个 term 在 parent agg 的条件下比例凸显的可能性。


由于两个作分母的总数其实大家都是相等的,其实比较的就是各 term 的 doc_count / bg_count 了。

当然,实际的 score 不只是这么简单,还有其他综合因素。毕竟也不能给出来本身就没啥关注度的数据嘛。

我们还可以来验证一下『武汉』的 bg_count 是不是这个意思:
curl -XPOST 'http://10.19.0.67:9200/logstash-mweibo-2015.12.02/_count?pretty' -d '{
"query" : {
"match" : {
"geoip.city" : "武汉"
}
}
}'
结果如下:
{
"count" : 15347191,
"_shards" : {
"total" : 100,
"successful" : 100,
"failed" : 0
}
}
数值完全对上了。没错,bg_count 就是『武汉』在整个索引里的总数。

想了解更全面的 ELK Stack 知识和细节,欢迎购买我的《ELK Stack权威指南》,也欢迎加 QQ 群:315428175 哟。
继续阅读 »
昨天我们通过 nested aggregation 计算出来,视频卡顿次数最多的是北京。不过这个结论似乎也没有什么奇怪的,北京的网民本身就多嘛。

Elasticsearch 还有一个有趣的聚合方式,叫 significant_terms。这时候就可以派上用场了!

我们把昨天的 query JSON 中,最后一段 sub agg 改成这样:
    "city_terms" : {
"significant_terms" : {
"field" : "geoip.city",
"size" : "4"
}
}
重新运行请求,得到的响应结果是这样的:
"city_terms" : {
"doc_count" : 2521720,
"buckets" : [ {
"key" : "武汉",
"doc_count" : 85980,
"score" : 0.1441705001066121,
"bg_count" : 15347191
}, {
"key" : "北京",
"doc_count" : 142761,
"score" : 0.11808069152203737,
"bg_count" : 43176384
}, {
"key" : "广州",
"doc_count" : 104677,
"score" : 0.10716870365361204,
"bg_count" : 27274482
}, {
"key" : "郑州",
"doc_count" : 59234,
"score" : 0.09915501610550795,
"bg_count" : 10587590
} ]
}
大家一定发现了:第一名居然变成了武汉!

而且每个结果后面,还多出来了 score 和 bg_count 两个数据。这个 bg_count 是怎么回事呢?

这就是 significant_terms 的作用了。这个 agg 的大概计算步骤是这样:
  1. 计算一个 term 在整个索引中的比例,作为背景计数(background),这里是 15347191 / 2353406423;
  2. 计算一个 term 在 parent agg 中的比例,作为前景计数(foreground),这里是 85980 / 2521720;
  3. 用 fgpercent 除以 bgpercent,得到这个 term 在 parent agg 的条件下比例凸显的可能性。


由于两个作分母的总数其实大家都是相等的,其实比较的就是各 term 的 doc_count / bg_count 了。

当然,实际的 score 不只是这么简单,还有其他综合因素。毕竟也不能给出来本身就没啥关注度的数据嘛。

我们还可以来验证一下『武汉』的 bg_count 是不是这个意思:
curl -XPOST 'http://10.19.0.67:9200/logstash-mweibo-2015.12.02/_count?pretty' -d '{
"query" : {
"match" : {
"geoip.city" : "武汉"
}
}
}'
结果如下:
{
"count" : 15347191,
"_shards" : {
"total" : 100,
"successful" : 100,
"failed" : 0
}
}
数值完全对上了。没错,bg_count 就是『武汉』在整个索引里的总数。

想了解更全面的 ELK Stack 知识和细节,欢迎购买我的《ELK Stack权威指南》,也欢迎加 QQ 群:315428175 哟。 收起阅读 »

Day3:nested object的查询和聚合示例

话接上回,我们只是解决了写数据的问题,这种格式不太符合常规的数据怎么读,也需要我们相应的做出点改变。

今天以一个实际的例子来讲。我曾经处理过一份数据,记录的是视频播放的卡顿情况。其中有一个数组,每次卡顿就新增一个对象元素。所以设计的 mapping 如下:
         "video_time_duration" : {
"type": "nested",
"properties" : {
"duration" : {
"type" : "long",
"doc_values" : true
},
"type" : {
"type" : "long",
"doc_values" : true
}
}
},
其中 type 只有 0 或 1 两个可能,0 表示播放正常,1 表示卡顿。所以下面我们发一个请求,要求是计算这样的结果:

出现了播放卡顿的用户,单次卡顿时长在10到200ms的,最常见于哪些城市?

下面是我们最终的查询请求 JSON:
{
"size" : 0,
"query" : {
"nested" : {
"path" : "video_time_duration",
"query" : {
"match" : {
"video_time_duration.type" : "1"
}
}
}
},
"aggs" : {
"video" : {
"nested" : {
"path" : "video_time_duration"
},
"aggs" : {
"filter_type" : {
"filter" : {
"term" : {
"video_time_duration.type" : "1"
}
},
"aggs" : {
"duration_ranges" : {
"range" : {
"field" : "video_time_duration.duration",
"ranges" : [
{ "from" : 10, "to" : 200 }
]
},
"aggs" : {
"city" : {
"reverse_nested": {},
"aggs" : {
"city_terms" : {
"terms" : {
"field" : "geoip.city"
}
}
}
}
}
}
}
}
}
}
}
}
很明显的可以看到对 nested object 里存的数据,不管是做 query 还是 agg,都需要显式的加上"nested": {"path" : "video_time_duration" 的声明。这样,才能保证我们取到的 duration 数值是对应 type 为卡顿的,而不是流畅播放的。

大家可能注意到,我同时在 query 和 aggFilter 中重复了一场 term 过滤。其中这次 nested query 是不必要的,除了作为语法展示以外,也有一个减少 hits 数的作用。但是和一般的请求不同的是,这里不可以去掉 nested agg 里的 term filter,因为 nested query 只是拿到『有过卡顿』的数据 id。不加 filter,聚合 duration 的时候,会把卡过但也流畅过的那部分都计算在内。

另一个要点:当我们过滤好 nested 数据的时候,要取顶层其他字段的内容,在 sub agg 里是无法直接获取的,需要额外使用一次 reverse_nested 来跳出这个 nested path,才可以恢复正常的 agg 路径。

最终得到的响应如下:
{
"took" : 4672,
"timed_out" : false,
"_shards" : {
"total" : 100,
"successful" : 100,
"failed" : 0
},
"hits" : {
"total" : 9560309,
"max_score" : 0.0,
"hits" : [ ]
},
"aggregations" : {
"video" : {
"doc_count" : 33713503,
"filter_type" : {
"doc_count" : 25441559,
"duration_ranges" : {
"buckets" : [ {
"key" : "10.0-200.0",
"from" : 10.0,
"from_as_string" : "10.0",
"to" : 200.0,
"to_as_string" : "200.0",
"doc_count" : 2521720,
"city" : {
"doc_count" : 2521720,
"city_terms" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 2267886,
"buckets" : [ {
"key" : "北京",
"doc_count" : 142761
}, {
"key" : "广州",
"doc_count" : 104677
}
]
}
}
} ]
}
}
}
}
}
响应数据中,我们可以直接看这些 hits 和 doc_count 数据。他们表示:
  1. 一共命中了『有过卡顿』的视频播放次数:9560309;
  2. 其中记录下来的播放间隔 33713503 次;
  3. 里面有 25441559 次是卡顿(减一下即 8271944 次是流畅咯);
  4. 里面卡顿时长在 10-200 ms 的是 2521720 次;
  5. 这些卡顿出现最多的在北京,发生了 142761 次。


数据蛮有意思吧。ES 能告诉你的还不止这点。更有趣的,明天见。

想了解更全面的 ELK Stack 知识和细节,欢迎购买我的《ELK Stack权威指南》,也欢迎加 QQ 群:315428175 哟。
继续阅读 »
话接上回,我们只是解决了写数据的问题,这种格式不太符合常规的数据怎么读,也需要我们相应的做出点改变。

今天以一个实际的例子来讲。我曾经处理过一份数据,记录的是视频播放的卡顿情况。其中有一个数组,每次卡顿就新增一个对象元素。所以设计的 mapping 如下:
         "video_time_duration" : {
"type": "nested",
"properties" : {
"duration" : {
"type" : "long",
"doc_values" : true
},
"type" : {
"type" : "long",
"doc_values" : true
}
}
},
其中 type 只有 0 或 1 两个可能,0 表示播放正常,1 表示卡顿。所以下面我们发一个请求,要求是计算这样的结果:

出现了播放卡顿的用户,单次卡顿时长在10到200ms的,最常见于哪些城市?

下面是我们最终的查询请求 JSON:
{
"size" : 0,
"query" : {
"nested" : {
"path" : "video_time_duration",
"query" : {
"match" : {
"video_time_duration.type" : "1"
}
}
}
},
"aggs" : {
"video" : {
"nested" : {
"path" : "video_time_duration"
},
"aggs" : {
"filter_type" : {
"filter" : {
"term" : {
"video_time_duration.type" : "1"
}
},
"aggs" : {
"duration_ranges" : {
"range" : {
"field" : "video_time_duration.duration",
"ranges" : [
{ "from" : 10, "to" : 200 }
]
},
"aggs" : {
"city" : {
"reverse_nested": {},
"aggs" : {
"city_terms" : {
"terms" : {
"field" : "geoip.city"
}
}
}
}
}
}
}
}
}
}
}
}
很明显的可以看到对 nested object 里存的数据,不管是做 query 还是 agg,都需要显式的加上"nested": {"path" : "video_time_duration" 的声明。这样,才能保证我们取到的 duration 数值是对应 type 为卡顿的,而不是流畅播放的。

大家可能注意到,我同时在 query 和 aggFilter 中重复了一场 term 过滤。其中这次 nested query 是不必要的,除了作为语法展示以外,也有一个减少 hits 数的作用。但是和一般的请求不同的是,这里不可以去掉 nested agg 里的 term filter,因为 nested query 只是拿到『有过卡顿』的数据 id。不加 filter,聚合 duration 的时候,会把卡过但也流畅过的那部分都计算在内。

另一个要点:当我们过滤好 nested 数据的时候,要取顶层其他字段的内容,在 sub agg 里是无法直接获取的,需要额外使用一次 reverse_nested 来跳出这个 nested path,才可以恢复正常的 agg 路径。

最终得到的响应如下:
{
"took" : 4672,
"timed_out" : false,
"_shards" : {
"total" : 100,
"successful" : 100,
"failed" : 0
},
"hits" : {
"total" : 9560309,
"max_score" : 0.0,
"hits" : [ ]
},
"aggregations" : {
"video" : {
"doc_count" : 33713503,
"filter_type" : {
"doc_count" : 25441559,
"duration_ranges" : {
"buckets" : [ {
"key" : "10.0-200.0",
"from" : 10.0,
"from_as_string" : "10.0",
"to" : 200.0,
"to_as_string" : "200.0",
"doc_count" : 2521720,
"city" : {
"doc_count" : 2521720,
"city_terms" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 2267886,
"buckets" : [ {
"key" : "北京",
"doc_count" : 142761
}, {
"key" : "广州",
"doc_count" : 104677
}
]
}
}
} ]
}
}
}
}
}
响应数据中,我们可以直接看这些 hits 和 doc_count 数据。他们表示:
  1. 一共命中了『有过卡顿』的视频播放次数:9560309;
  2. 其中记录下来的播放间隔 33713503 次;
  3. 里面有 25441559 次是卡顿(减一下即 8271944 次是流畅咯);
  4. 里面卡顿时长在 10-200 ms 的是 2521720 次;
  5. 这些卡顿出现最多的在北京,发生了 142761 次。


数据蛮有意思吧。ES 能告诉你的还不止这点。更有趣的,明天见。

想了解更全面的 ELK Stack 知识和细节,欢迎购买我的《ELK Stack权威指南》,也欢迎加 QQ 群:315428175 哟。 收起阅读 »

Day2: 利用nested object缩减mapping大小

Elasticsearch 中有些高级特性,可能不太常用,但是在恰当场景下,又非常有效果。今天,我们来说说 nested object。

我们都知道,Elasticsearch 宣传中是 schemaless 的。但实际使用中,并不是完全的随意。比如过多的 kv 切割,会导致 mapping 大小暴涨,对集群稳定性是个不小的挑战。

以 urlparams 为例,下面这段 urlparams 直接通过 logstash-filter-kv 切割得到的结果,需要在 mapping 中占用 4 个字段的定义。
"urlparams" : {
"uid" : "1234567890",
"action" : "payload",
"t" : "1449053032000",
"pageid" : "v6"
}
如果哪个开发一时想不开(我真的碰到过),把 urlparams 写成 uid=123456789&action=payload&1449053032000=t&pageid=v6,那基本上整个 ES 集群就会被过于频繁的 mapping 更新搞挂了。

这时候,我们修改一下 mapping 定义:
{
"accesslog" : {
"properties" : {
"urlparams" : {
"type" : "nested",
"properties" : {
"key" : { "type" : "string", "index" : "not_analyzed", "doc_values" : true },
"value" : { "type" : "string", "index" : "not_analyzed", "doc_values" : true }
}
}
}
}
}
同时在 Logstash 的 filter 配置中添加一段:
if [urlargs] {
ruby {
init => "@kname = ['key','value']"
code => "event['urlparams'] = event['urlargs'].split('&').collect {|i| Hash[@kname.zip(i.split('='))]}"
remove_field => [ "urlargs","uri","request" ]
}
}
生成的 JSON 数据变成这个样子:
"urlargs": [
{ "key": "uid", "value": "1234567890" },
{ "key": "action", "value": "payload" },
{ "key": "1449053032000", "value": "t" },
{ "key": "pageid", "value": "v6" }
]
这样,再错乱的 urlparams,也不会发生 mapping 变更,导致集群故障了!

想了解更全面的 ELK Stack 知识和细节,欢迎购买我的《ELK Stack权威指南》,也欢迎加 QQ 群:315428175 哟。
继续阅读 »
Elasticsearch 中有些高级特性,可能不太常用,但是在恰当场景下,又非常有效果。今天,我们来说说 nested object。

我们都知道,Elasticsearch 宣传中是 schemaless 的。但实际使用中,并不是完全的随意。比如过多的 kv 切割,会导致 mapping 大小暴涨,对集群稳定性是个不小的挑战。

以 urlparams 为例,下面这段 urlparams 直接通过 logstash-filter-kv 切割得到的结果,需要在 mapping 中占用 4 个字段的定义。
"urlparams" : {
"uid" : "1234567890",
"action" : "payload",
"t" : "1449053032000",
"pageid" : "v6"
}
如果哪个开发一时想不开(我真的碰到过),把 urlparams 写成 uid=123456789&action=payload&1449053032000=t&pageid=v6,那基本上整个 ES 集群就会被过于频繁的 mapping 更新搞挂了。

这时候,我们修改一下 mapping 定义:
{
"accesslog" : {
"properties" : {
"urlparams" : {
"type" : "nested",
"properties" : {
"key" : { "type" : "string", "index" : "not_analyzed", "doc_values" : true },
"value" : { "type" : "string", "index" : "not_analyzed", "doc_values" : true }
}
}
}
}
}
同时在 Logstash 的 filter 配置中添加一段:
if [urlargs] {
ruby {
init => "@kname = ['key','value']"
code => "event['urlparams'] = event['urlargs'].split('&').collect {|i| Hash[@kname.zip(i.split('='))]}"
remove_field => [ "urlargs","uri","request" ]
}
}
生成的 JSON 数据变成这个样子:
"urlargs": [
{ "key": "uid", "value": "1234567890" },
{ "key": "action", "value": "payload" },
{ "key": "1449053032000", "value": "t" },
{ "key": "pageid", "value": "v6" }
]
这样,再错乱的 urlparams,也不会发生 mapping 变更,导致集群故障了!

想了解更全面的 ELK Stack 知识和细节,欢迎购买我的《ELK Stack权威指南》,也欢迎加 QQ 群:315428175 哟。 收起阅读 »

Day1: 怎样让Logstash每次都从头读文件?

Advent Calendar 是各大技术社区每年 12 月大多会举办的一个系列活动。原意是圣诞节前夕的小礼品,延伸为每天一篇技术小分享的意思。最常见的包括 Perl Advent、sysadmin advent、web advent、performance advent 等。个人从 2009 年开始每年都看,从2013 年开始偶尔会参加其他社区的 advent 写作。今年考虑自己在 ELK Stack 上专注较多,在历次技术大会和最终出版的《ELK Stack权威指南》之外,又有一些新的发现和收获,干脆尝试一把自己一个人的 advent,也算是对 ELK 小知识的一种查漏补缺。

今天是 12 月 1 日,第一天,开天辟地,让我们也从最简单而又容易被忽略的一个小技巧开始吧!

每个上手 ELK 的新用户,肯定都需要测试一下读取文件输出到终端这步。在 Logstash 中,也就是配置这样一段:
input {
file {
path => ["/data/test.log"]
}
}
output {
stdout {
codec => rubydebug
}
}
不过很多新人的测试随后就卡在第二步了:当你修改一下配置,准备添加一段 filter 配置再重复运行 logstash 命令时,发现终端一直停滞没有输出

这是因为:Logstash 会记录自己读取文件内容的偏移量到一个隐藏文件里,默认情况下,下次启动,他会从这个偏移量继续往后读,避免重复读取数据。

这个隐藏文件,叫做 $HOME/.sincedb_****。过去很多文档,在解释了这个原理后,都会告诉大家解决办法:每次重新运行 logstash 命令之前,删除掉家目录下的 sincedb 隐藏文件。

但是这种办法很笨,不是么?

今天告诉大家一个更方便的办法,改用下面这段 Logstash 配置:
input {
file {
path => ["/data/test.log"]
start_position => "beginning"
sincedb_path => "/dev/null"
}
}
output {
stdout {
codec => rubydebug
}
}
要点就在这行 sincedb_path => "/dev/null" 了!该参数用来指定 sincedb 文件名,但是如果我们设置为 /dev/null这个 Linux 系统上特殊的空洞文件,那么 logstash 每次重启进程的时候,尝试读取 sincedb 内容,都只会读到空白内容,也就会理解成之前没有过运行记录,自然就从初始位置开始读取了!

好了,第一天就是这样。更多内容,敬请期待。

想了解更全面的 ELK Stack 知识和细节,欢迎购买我的《ELK Stack权威指南》,也欢迎加 QQ 群:315428175 哟。
继续阅读 »
Advent Calendar 是各大技术社区每年 12 月大多会举办的一个系列活动。原意是圣诞节前夕的小礼品,延伸为每天一篇技术小分享的意思。最常见的包括 Perl Advent、sysadmin advent、web advent、performance advent 等。个人从 2009 年开始每年都看,从2013 年开始偶尔会参加其他社区的 advent 写作。今年考虑自己在 ELK Stack 上专注较多,在历次技术大会和最终出版的《ELK Stack权威指南》之外,又有一些新的发现和收获,干脆尝试一把自己一个人的 advent,也算是对 ELK 小知识的一种查漏补缺。

今天是 12 月 1 日,第一天,开天辟地,让我们也从最简单而又容易被忽略的一个小技巧开始吧!

每个上手 ELK 的新用户,肯定都需要测试一下读取文件输出到终端这步。在 Logstash 中,也就是配置这样一段:
input {
file {
path => ["/data/test.log"]
}
}
output {
stdout {
codec => rubydebug
}
}
不过很多新人的测试随后就卡在第二步了:当你修改一下配置,准备添加一段 filter 配置再重复运行 logstash 命令时,发现终端一直停滞没有输出

这是因为:Logstash 会记录自己读取文件内容的偏移量到一个隐藏文件里,默认情况下,下次启动,他会从这个偏移量继续往后读,避免重复读取数据。

这个隐藏文件,叫做 $HOME/.sincedb_****。过去很多文档,在解释了这个原理后,都会告诉大家解决办法:每次重新运行 logstash 命令之前,删除掉家目录下的 sincedb 隐藏文件。

但是这种办法很笨,不是么?

今天告诉大家一个更方便的办法,改用下面这段 Logstash 配置:
input {
file {
path => ["/data/test.log"]
start_position => "beginning"
sincedb_path => "/dev/null"
}
}
output {
stdout {
codec => rubydebug
}
}
要点就在这行 sincedb_path => "/dev/null" 了!该参数用来指定 sincedb 文件名,但是如果我们设置为 /dev/null这个 Linux 系统上特殊的空洞文件,那么 logstash 每次重启进程的时候,尝试读取 sincedb 内容,都只会读到空白内容,也就会理解成之前没有过运行记录,自然就从初始位置开始读取了!

好了,第一天就是这样。更多内容,敬请期待。

想了解更全面的 ELK Stack 知识和细节,欢迎购买我的《ELK Stack权威指南》,也欢迎加 QQ 群:315428175 哟。 收起阅读 »

ElasticSearch2.0安装 & 1.7.2升级-新手日志

才开始研究ElasticSearch不到两个月时间,准备把公司现在的基于hubble.net的搜索解决方案换成基于ElasticSearch的。本来用的1.7.2版本,刚进入到测试阶段,现在2.0发布了,就尝试直接升级到2.0吧。
 
我把在Windows平台上的ElasticSearch2.0安装,1.7.2升级的全过程的步骤、经验、教训记录下来,如文档(http://pan.baidu.com/s/1qWOTpz2)。
操作过程和记录的内容或许有很多地方不合理不恰当,和我一样的新手可以一起交流,请大神多给予指导。
继续阅读 »
才开始研究ElasticSearch不到两个月时间,准备把公司现在的基于hubble.net的搜索解决方案换成基于ElasticSearch的。本来用的1.7.2版本,刚进入到测试阶段,现在2.0发布了,就尝试直接升级到2.0吧。
 
我把在Windows平台上的ElasticSearch2.0安装,1.7.2升级的全过程的步骤、经验、教训记录下来,如文档(http://pan.baidu.com/s/1qWOTpz2)。
操作过程和记录的内容或许有很多地方不合理不恰当,和我一样的新手可以一起交流,请大神多给予指导。 收起阅读 »

11.22 ESCC#4成都站马上开始了

时间:

2015年11月22日 周日 下午1点开始

地点:

四川成都市高新区天府大道中段1366号天府软件园E3-1-11层   (感谢货车帮提供场地支持)

会议日程:

Snip20151118_26.png



请您提前到场,安排好时间,如因故不能参加,请提前发邮件告知: medcl*elastic.co ,谢谢合作.
继续阅读 »
时间:

2015年11月22日 周日 下午1点开始

地点:

四川成都市高新区天府大道中段1366号天府软件园E3-1-11层   (感谢货车帮提供场地支持)

会议日程:

Snip20151118_26.png



请您提前到场,安排好时间,如因故不能参加,请提前发邮件告知: medcl*elastic.co ,谢谢合作. 收起阅读 »

常用链接及资源索引

Elastic 社区: http://elasticsearch.cn 
 
社区活动:
 
Elastic 中国开发者大会:http://conf.elasticsearch.cn 
线下 Meetup【旧】: http://www.meetup.com/Elasticsearch-China-Users/ 
Meetup 发布: https://meetup.elasticsearch.cn 
社区电台:https://radio.elasticsearch.cn 
IT 大咖说社区分享视频:http://www.itdks.com/member/organizer/93
Apple iTunes: https://itunes.apple.com/cn/podcast/elastic-社区电台
喜马拉雅:https://www.ximalaya.com/zhubo/111156131/
蜻蜓 FM:https://www.qingting.fm/channels/244978/
Slack 讨论组:[url=https://join.slack.com/t/elastic-cn]https://join.slack.com/t/elastic-cn[/url]
Telegram 讨论组:http://t.cn/RksTb6I


Elastic 日报:
 
订阅:https://tinyletter.com/elastic-daily 
归档:https://elasticsearch.cn/explore/category-18

社区微信公众号

中文社区qrcode.png

 
Elastic 官方公众号

291562121879_.pic_.jpg



交流QQ群:

Elastic中文社区1 (190605846) 
Elastic中文社区2(211682609) 
Elastic中文社区3(258143901)
Elastic中文社区4  (456336484)
Elastic中文社区5  (223764502)
ELKstack交流1群(315428175)

官方资源:

Elastic 官方网站:http://elastic.co
Elastic 用户大会: http://elasticon.com 
Elastic 源代码:http://github.com/elastic 
Elastic 案例大全: https://github.com/elastic/examples/ 
Elastic@Speakdeck: https://speakerdeck.com/elastic 
Elastic@Vimeo: https://vimeo.com/elasticsearch 
Elastic@Youtube: https://www.youtube.com/user/elasticsearch
Elastic@Facebook: http://www.facebook.com/elastic.co
Elastic@Twitter: https://www.twitter.com/elastic
Elastic@Linkedin: https://www.linkedin.com/company/elastic-co
Elastic@Xing: https://www.xing.com/companies/elastic.co
 

相关书籍

[官方] Elasticsearch 权威指南: https://www.elastic.co/guide/cn/index.html
ELKStack中文指南:  http://elkguide.elasticsearch.cn/
Kibana 中文指南:http://chenryn.gitbooks.io/kibana-guide-cn/
Exploring elasticsearch: http://exploringelasticsearch.com/

其他资源

Elasticsearch Stackshare: https://stackshare.io/elasticsearch 
 
工具
Grok Debugger(国内镜像):http://grok.elasticsearch.cn 
Grokdebug:http://grokdebug.herokuapp.com 
Elastic情报局:https://index.elasticsearch.cn

欢迎补充完善!!
继续阅读 »
Elastic 社区: http://elasticsearch.cn 
 
社区活动:
 
Elastic 中国开发者大会:http://conf.elasticsearch.cn 
线下 Meetup【旧】: http://www.meetup.com/Elasticsearch-China-Users/ 
Meetup 发布: https://meetup.elasticsearch.cn 
社区电台:https://radio.elasticsearch.cn 
IT 大咖说社区分享视频:http://www.itdks.com/member/organizer/93
Apple iTunes: https://itunes.apple.com/cn/podcast/elastic-社区电台
喜马拉雅:https://www.ximalaya.com/zhubo/111156131/
蜻蜓 FM:https://www.qingting.fm/channels/244978/
Slack 讨论组:[url=https://join.slack.com/t/elastic-cn]https://join.slack.com/t/elastic-cn[/url]
Telegram 讨论组:http://t.cn/RksTb6I


Elastic 日报:
 
订阅:https://tinyletter.com/elastic-daily 
归档:https://elasticsearch.cn/explore/category-18

社区微信公众号

中文社区qrcode.png

 
Elastic 官方公众号

291562121879_.pic_.jpg



交流QQ群:

Elastic中文社区1 (190605846) 
Elastic中文社区2(211682609) 
Elastic中文社区3(258143901)
Elastic中文社区4  (456336484)
Elastic中文社区5  (223764502)
ELKstack交流1群(315428175)

官方资源:

Elastic 官方网站:http://elastic.co
Elastic 用户大会: http://elasticon.com 
Elastic 源代码:http://github.com/elastic 
Elastic 案例大全: https://github.com/elastic/examples/ 
Elastic@Speakdeck: https://speakerdeck.com/elastic 
Elastic@Vimeo: https://vimeo.com/elasticsearch 
Elastic@Youtube: https://www.youtube.com/user/elasticsearch
Elastic@Facebook: http://www.facebook.com/elastic.co
Elastic@Twitter: https://www.twitter.com/elastic
Elastic@Linkedin: https://www.linkedin.com/company/elastic-co
Elastic@Xing: https://www.xing.com/companies/elastic.co
 

相关书籍

[官方] Elasticsearch 权威指南: https://www.elastic.co/guide/cn/index.html
ELKStack中文指南:  http://elkguide.elasticsearch.cn/
Kibana 中文指南:http://chenryn.gitbooks.io/kibana-guide-cn/
Exploring elasticsearch: http://exploringelasticsearch.com/

其他资源

Elasticsearch Stackshare: https://stackshare.io/elasticsearch 
 
工具
Grok Debugger(国内镜像):http://grok.elasticsearch.cn 
Grokdebug:http://grokdebug.herokuapp.com 
Elastic情报局:https://index.elasticsearch.cn

欢迎补充完善!! 收起阅读 »

Elasticsearch China Conference #4 In Chengdu

时间:Sunday, November 22, 2015   1:00 PM
地点:四川成都市高新区天府大道中段1366号天府软件园E3-1-11层
 
报名地址: [/url]


ESCC#4全称:The 4th Elasticsearch China Conference,

是由elasticsearch中文社区每年定期举办的线下交流活动,今年已经是第四届了,会议围绕elasticsearch及周边产品和技术,如:kibana\logstash\beats\logging\nlp等相关领域及话题都可以进行讨论,只要是你认为可能会感兴趣的话题,都可以提交过来,分享嘉宾来自国内一线互联网公司,倡导干货接地气纯粹的技术交流.

分享主题

一,《What's New in Elasticsearch2.0?》

内容介绍:

Elasticsearch2.0新特性介绍! 

分享者简介:Medcl,Elastic开发工程师及布道师.

二,《基于es构建实时日志检索平台》

内容介绍:

2011年毕业后加入京东,作为项目技术负责人以及架构师参与了hadoop生态系统建设一期、云存储一期、统一日志、公有PAAS平台和基于容器技术的自动部署等项目。目前在京东成都研究院工具部主要负责工具部各个项目系统架构和产品优化和创新。作为一个技术极客希望组建一支一流的技术团队,同时希望和各位技术爱好者一起交流技术以及技术创新。 提纲:

1.系统整体架构介绍
2.日志采集方案以及实现原理介绍   

3.日志转发方案以及实现原理介绍
4.日志搜索实现
5.es优化简介。

分享者简介:吴友强 京东成都研究院工具部负责人兼系统架构师

三,《ElasticSearch:fast and slow》​

内容介绍:   
1,系统整体架构介绍
2,两个不同场景下的es查询入库优化方案
3,场景一:毫秒级低延迟入库加查询(fast)
4,场景二:依赖hadoop做pb级别以上查询(slow)
    
分享者简介:查超,瀚思安信基础平台部 研究人员

更多讲师及分享主题介绍陆续添加中...


鸣谢:

感谢 货车帮对这次活动的大力支持
继续阅读 »
时间:Sunday, November 22, 2015   1:00 PM
地点:四川成都市高新区天府大道中段1366号天府软件园E3-1-11层
 
报名地址: [/url]


ESCC#4全称:The 4th Elasticsearch China Conference,

是由elasticsearch中文社区每年定期举办的线下交流活动,今年已经是第四届了,会议围绕elasticsearch及周边产品和技术,如:kibana\logstash\beats\logging\nlp等相关领域及话题都可以进行讨论,只要是你认为可能会感兴趣的话题,都可以提交过来,分享嘉宾来自国内一线互联网公司,倡导干货接地气纯粹的技术交流.

分享主题

一,《What's New in Elasticsearch2.0?》

内容介绍:

Elasticsearch2.0新特性介绍! 

分享者简介:Medcl,Elastic开发工程师及布道师.

二,《基于es构建实时日志检索平台》

内容介绍:

2011年毕业后加入京东,作为项目技术负责人以及架构师参与了hadoop生态系统建设一期、云存储一期、统一日志、公有PAAS平台和基于容器技术的自动部署等项目。目前在京东成都研究院工具部主要负责工具部各个项目系统架构和产品优化和创新。作为一个技术极客希望组建一支一流的技术团队,同时希望和各位技术爱好者一起交流技术以及技术创新。 提纲:

1.系统整体架构介绍
2.日志采集方案以及实现原理介绍   

3.日志转发方案以及实现原理介绍
4.日志搜索实现
5.es优化简介。

分享者简介:吴友强 京东成都研究院工具部负责人兼系统架构师

三,《ElasticSearch:fast and slow》​

内容介绍:   
1,系统整体架构介绍
2,两个不同场景下的es查询入库优化方案
3,场景一:毫秒级低延迟入库加查询(fast)
4,场景二:依赖hadoop做pb级别以上查询(slow)
    
分享者简介:查超,瀚思安信基础平台部 研究人员

更多讲师及分享主题介绍陆续添加中...


鸣谢:

感谢 货车帮对这次活动的大力支持 收起阅读 »

第四届Elasticsearch国内开发者大会站 成都站 马上开始了

相信前面大家都知道在北京和上海已经举办了2场线下活动了,下一站是哪里呢??
 第四届Elasticsearch国内开发者大会站 成都站  是的 ,下一站是在成都,并且马上就要开始了,
报名的速度了,
紧急征集讲师和志愿者中!!!!
 
报名地址;
http://form.mikecrm.com/f.php?t=mOUa1M 
 
继续阅读 »
相信前面大家都知道在北京和上海已经举办了2场线下活动了,下一站是哪里呢??
 第四届Elasticsearch国内开发者大会站 成都站  是的 ,下一站是在成都,并且马上就要开始了,
报名的速度了,
紧急征集讲师和志愿者中!!!!
 
报名地址;
http://form.mikecrm.com/f.php?t=mOUa1M 
  收起阅读 »

10月北京es第4届国内开发者大会现在可以开始报名了.

第四届Elasticsearch国内开发者大会北京站马上就要开始了,目前已确定分享的主题有6篇了,有来自百度\新浪\芒果TV等公司同学们的精彩分享,有国内最大规模elasticsearch集群搭建的经验分享,有ELK的实践应用,有最新的Kibana4的插件开发,有安全领域的分析实战,干货多多,非常值得期待,报名地址(因为meetup不支持国内很多邮箱的注册,请大家使用下面的表单报名,辛苦已经报过名的同学了): [ http://t.cn/Ry2aVzr]( http://t.cn/Ry2aVzr)

ESCC#4全称:The 4th Elasticsearch China Conference,是由elasticsearch中文社区每年定期举办的线下交流活动,今年已经是第四届了,会议围绕elasticsearch及周边产品和技术,如:kibana\logstash\beats\logging\nlp等相关领域及话题都可以进行讨论,只要是你认为可能会感兴趣的话题,都可以提交过来,分享嘉宾来自国内一线互联网公司,倡导干货接地气纯粹的技术交流.​

北京地区:
地点:中国科学院软件研究所; 时间:2015年10月17日

其它城市正在筹划中,有愿意提供帮助和愿意分享你们和elasticsearch的经验或者故事的同学欢迎和Medcl联系.

关于活动最新动态请访问: http://www.meetup.com/Elasticsearch-China-Users/
继续阅读 »
第四届Elasticsearch国内开发者大会北京站马上就要开始了,目前已确定分享的主题有6篇了,有来自百度\新浪\芒果TV等公司同学们的精彩分享,有国内最大规模elasticsearch集群搭建的经验分享,有ELK的实践应用,有最新的Kibana4的插件开发,有安全领域的分析实战,干货多多,非常值得期待,报名地址(因为meetup不支持国内很多邮箱的注册,请大家使用下面的表单报名,辛苦已经报过名的同学了): [ http://t.cn/Ry2aVzr]( http://t.cn/Ry2aVzr)

ESCC#4全称:The 4th Elasticsearch China Conference,是由elasticsearch中文社区每年定期举办的线下交流活动,今年已经是第四届了,会议围绕elasticsearch及周边产品和技术,如:kibana\logstash\beats\logging\nlp等相关领域及话题都可以进行讨论,只要是你认为可能会感兴趣的话题,都可以提交过来,分享嘉宾来自国内一线互联网公司,倡导干货接地气纯粹的技术交流.​

北京地区:
地点:中国科学院软件研究所; 时间:2015年10月17日

其它城市正在筹划中,有愿意提供帮助和愿意分享你们和elasticsearch的经验或者故事的同学欢迎和Medcl联系.

关于活动最新动态请访问: http://www.meetup.com/Elasticsearch-China-Users/ 收起阅读 »

《Elasticsearch权威指南》中文版开始翻译

![cover](https://raw.githubusercontent. ... ll.jpg)

本来想自己翻译这本书的,但是发现章节的数量已经超出能力范围,每天时间也有限,在不断的努力以及几个热心人的参与下,完成了6章的翻译。如果你对Elasticsearch感兴趣或者在工作中有用,那就关注我们的翻译。有兴趣的也可以fork后提交Pull Request。当然,我觉得前6章入门已经够用,如果你想学习也可以关注我们的翻译。

Github地址: https://github.com/looly/elast ... de-cn

Git@OSC地址: http://git.oschina.net/loolly/ ... de-cn

GitBook阅读地址: http://es.xiaoleilu.com/

### PS:封面是我自己设计的哦~~
继续阅读 »
![cover](https://raw.githubusercontent. ... ll.jpg)

本来想自己翻译这本书的,但是发现章节的数量已经超出能力范围,每天时间也有限,在不断的努力以及几个热心人的参与下,完成了6章的翻译。如果你对Elasticsearch感兴趣或者在工作中有用,那就关注我们的翻译。有兴趣的也可以fork后提交Pull Request。当然,我觉得前6章入门已经够用,如果你想学习也可以关注我们的翻译。

Github地址: https://github.com/looly/elast ... de-cn

Git@OSC地址: http://git.oschina.net/loolly/ ... de-cn

GitBook阅读地址: http://es.xiaoleilu.com/

### PS:封面是我自己设计的哦~~ 收起阅读 »