Day7: hangout 替代 logstash-input-kafka
用 Logstash 接收 Kafka 里的业务日志再写入 Elasticsearch 已经成为一个常见的选择。但是大多数人随后就会碰到一个问题：logstash-input-kafka 的性能上不去！
这个问题，主要是由于 Logstash 用 JRuby 实现，所以数据从 Kafka 下来到最后流转进 Logstash 里，要经过四五次 Ruby 和 Java 之间的数据结构转换，大大浪费和消耗了 CPU 资源。作为优化，我们可以通过修改默认的 logstash-input-kafka 的 codec 配置为 line，把 Jrjackson 处理流程挪到 logstash-filter-json 里多线程处理，但是也只能提高一倍性能而已。
Logstash 开发组目前也在实现纯 Java 版的 logstash-core-event，但是最终能提高多少，也是未知数。
那么在 Logstash 性能提上去之前，围绕 Kafka 还有什么办法能高效又不失灵活的做到数据处理并写入 Elasticsearch 呢？今天给大家推荐一下携程网开源的 hangout。
hangout 采用 YAML 格式配置语法，跟 Elasticsearch 一样，省去了 Logstash 解析 DSL 的复杂度。下面一段配置是 repo 中自带的 example 示例：
实际运行下来，hangout 比 Logstash 确实在处理能力，尤其是 CPU 资源消耗方面，性价比要高出很多。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
继续阅读 »
这个问题，主要是由于 Logstash 用 JRuby 实现，所以数据从 Kafka 下来到最后流转进 Logstash 里，要经过四五次 Ruby 和 Java 之间的数据结构转换，大大浪费和消耗了 CPU 资源。作为优化，我们可以通过修改默认的 logstash-input-kafka 的 codec 配置为 line，把 Jrjackson 处理流程挪到 logstash-filter-json 里多线程处理，但是也只能提高一倍性能而已。
Logstash 开发组目前也在实现纯 Java 版的 logstash-core-event，但是最终能提高多少，也是未知数。
那么在 Logstash 性能提上去之前，围绕 Kafka 还有什么办法能高效又不失灵活的做到数据处理并写入 Elasticsearch 呢？今天给大家推荐一下携程网开源的 hangout。
hangout 采用 YAML 格式配置语法，跟 Elasticsearch 一样，省去了 Logstash 解析 DSL 的复杂度。下面一段配置是 repo 中自带的 example 示例：
inputs:
- Kafka:
codec: plain
encoding: UTF8 # defaut UTF8
topic:
app: 2
consumer_settings:
group.id: hangout
zookeeper.connect: 192.168.1.200:2181
auto.commit.interval.ms: "1000"
socket.receive.buffer.bytes: "1048576"
fetch.message.max.bytes: "1048576"
num.consumer.fetchers: "4"
- Kafka:
codec: json
topic:
web: 1
consumer_settings:
group.id: hangout
zookeeper.connect: 192.168.1.201:2181
auto.commit.interval.ms: "5000"
filters:
- Grok:
match:
- '^(?<logtime>\S+) (?<user>.+) (-|(?<level>\w+)) %{DATA:msg}$'
remove_fields: ['message']
- Add:
fields:
test: 'abcd'
if:
- '<#if message??>true</#if>'
- '<#if message?contains("liu")>true<#elseif message?contains("warn")>true</#if>'
- Date:
src: logtime
formats:
- 'ISO8601'
remove_fields: ['logtime']
- Lowercase:
fields: ['user']
- Add:
fields:
me: 'I am ${user}'
- Remove:
fields:
- logtime
- Trim:
fields:
- user
- Rename:
fields:
me: he
user: she
- Gsub:
fields:
she: ['c','CCC']
he: ['(^\w+)|(\w+$)','XXX']
- Translate:
source: user
target: nick
dictionary_path: /tmp/app.dic
- KV:
source: msg
target: kv
field_split: ' '
value_split: '='
trim: '\t\"'
trimkey: '\"'
include_keys: ["a","b","xyz","12"]
exclude_keys: ["b","c"] # b in excluded
tag_on_failure: "KVfail"
remove_fields: ['msg']
- Convert:
fields:
cs_bytes: integer
time_taken: float
- URLDecode:
fields: ["query1","query2"]
outputs:
- Stdout:
if:
- '<#if user=="childe">true</#if>'
- Elasticsearch:
cluster: hangoutcluster
hosts:
- 192.168.1.200
index: 'hangout-%{user}-%{+YYYY.MM.dd}'
index_type: logs # default logs
bulk_actions: 20000 #default 20000
bulk_size: 15 # default 15 MB
flush_interval: 10 # default 10 seconds
concurrent_requests: 0 # default 0, concurrent_requests设置成大于0的数, 意思着多线程处理, 以我应用的经验,还有是一定OOM风险的,强烈建议设置为0
- Kafka:
broker_list: 192.168.1.200:9092
topic: test2实际运行下来，hangout 比 Logstash 确实在处理能力，尤其是 CPU 资源消耗方面，性价比要高出很多。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
用 Logstash 接收 Kafka 里的业务日志再写入 Elasticsearch 已经成为一个常见的选择。但是大多数人随后就会碰到一个问题：logstash-input-kafka 的性能上不去！
这个问题，主要是由于 Logstash 用 JRuby 实现，所以数据从 Kafka 下来到最后流转进 Logstash 里，要经过四五次 Ruby 和 Java 之间的数据结构转换，大大浪费和消耗了 CPU 资源。作为优化，我们可以通过修改默认的 logstash-input-kafka 的 codec 配置为 line，把 Jrjackson 处理流程挪到 logstash-filter-json 里多线程处理，但是也只能提高一倍性能而已。
Logstash 开发组目前也在实现纯 Java 版的 logstash-core-event，但是最终能提高多少，也是未知数。
那么在 Logstash 性能提上去之前，围绕 Kafka 还有什么办法能高效又不失灵活的做到数据处理并写入 Elasticsearch 呢？今天给大家推荐一下携程网开源的 hangout。
hangout 采用 YAML 格式配置语法，跟 Elasticsearch 一样，省去了 Logstash 解析 DSL 的复杂度。下面一段配置是 repo 中自带的 example 示例：
实际运行下来，hangout 比 Logstash 确实在处理能力，尤其是 CPU 资源消耗方面，性价比要高出很多。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
这个问题，主要是由于 Logstash 用 JRuby 实现，所以数据从 Kafka 下来到最后流转进 Logstash 里，要经过四五次 Ruby 和 Java 之间的数据结构转换，大大浪费和消耗了 CPU 资源。作为优化，我们可以通过修改默认的 logstash-input-kafka 的 codec 配置为 line，把 Jrjackson 处理流程挪到 logstash-filter-json 里多线程处理，但是也只能提高一倍性能而已。
Logstash 开发组目前也在实现纯 Java 版的 logstash-core-event，但是最终能提高多少，也是未知数。
那么在 Logstash 性能提上去之前，围绕 Kafka 还有什么办法能高效又不失灵活的做到数据处理并写入 Elasticsearch 呢？今天给大家推荐一下携程网开源的 hangout。
hangout 采用 YAML 格式配置语法，跟 Elasticsearch 一样，省去了 Logstash 解析 DSL 的复杂度。下面一段配置是 repo 中自带的 example 示例：
inputs:
- Kafka:
codec: plain
encoding: UTF8 # defaut UTF8
topic:
app: 2
consumer_settings:
group.id: hangout
zookeeper.connect: 192.168.1.200:2181
auto.commit.interval.ms: "1000"
socket.receive.buffer.bytes: "1048576"
fetch.message.max.bytes: "1048576"
num.consumer.fetchers: "4"
- Kafka:
codec: json
topic:
web: 1
consumer_settings:
group.id: hangout
zookeeper.connect: 192.168.1.201:2181
auto.commit.interval.ms: "5000"
filters:
- Grok:
match:
- '^(?<logtime>\S+) (?<user>.+) (-|(?<level>\w+)) %{DATA:msg}$'
remove_fields: ['message']
- Add:
fields:
test: 'abcd'
if:
- '<#if message??>true</#if>'
- '<#if message?contains("liu")>true<#elseif message?contains("warn")>true</#if>'
- Date:
src: logtime
formats:
- 'ISO8601'
remove_fields: ['logtime']
- Lowercase:
fields: ['user']
- Add:
fields:
me: 'I am ${user}'
- Remove:
fields:
- logtime
- Trim:
fields:
- user
- Rename:
fields:
me: he
user: she
- Gsub:
fields:
she: ['c','CCC']
he: ['(^\w+)|(\w+$)','XXX']
- Translate:
source: user
target: nick
dictionary_path: /tmp/app.dic
- KV:
source: msg
target: kv
field_split: ' '
value_split: '='
trim: '\t\"'
trimkey: '\"'
include_keys: ["a","b","xyz","12"]
exclude_keys: ["b","c"] # b in excluded
tag_on_failure: "KVfail"
remove_fields: ['msg']
- Convert:
fields:
cs_bytes: integer
time_taken: float
- URLDecode:
fields: ["query1","query2"]
outputs:
- Stdout:
if:
- '<#if user=="childe">true</#if>'
- Elasticsearch:
cluster: hangoutcluster
hosts:
- 192.168.1.200
index: 'hangout-%{user}-%{+YYYY.MM.dd}'
index_type: logs # default logs
bulk_actions: 20000 #default 20000
bulk_size: 15 # default 15 MB
flush_interval: 10 # default 10 seconds
concurrent_requests: 0 # default 0, concurrent_requests设置成大于0的数, 意思着多线程处理, 以我应用的经验,还有是一定OOM风险的,强烈建议设置为0
- Kafka:
broker_list: 192.168.1.200:9092
topic: test2实际运行下来，hangout 比 Logstash 确实在处理能力，尤其是 CPU 资源消耗方面，性价比要高出很多。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
Day6：用logstash-input-http_poller模拟nginxbeat
Elastic 公司最近推出了 beats 系列，在官方的 packet/top/file{beat} 之外，社区也自发制作了一些比如 docker/nginx/
不过很可惜的是：nginxbeat 只支持两个数据来源：标准的 ngx_http_stub_status_module 和商业版 Nginx Plus 的ngx_http_status_module
我们都知道，ngx_http_stub_status_module 输出的信息太少，除了进程级别的连接数，啥都没有。那么，在使用开源版本 Nginx 的我们，还有别的办法么？
在官网的第三方模块列表里，发现了一个韩国人写的 nginx-module-vts。这个扩展可以做到 vhost 级别的状态信息输出。(我知道国人还有很多类似的统计扩展，但是没上官网，不便普及，就忽略吧)
但是，不懂 Golang 的话，没法自己动手实现一个 nginx-vts-beat 啊。怎么办？
其实我们可以用 logstash-input-http_poller 实现类似的功能。
首先，我们要给自己的 Nginx 加上 vts 扩展。编译方式这里就不讲了，和所有其他第三方模块一样。配置方式详见README。我们这里假设是按照核心和非核心接口来统计 URL 的状态：
注意，urls 是一个 Hash，所以他的执行顺序是根据 Hash.map 来的，为了确保我们是先获取数据再重置，这里干脆用 0, 1 来作为 Hash 的 key，这样顺序就没问题了。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
继续阅读 »
不过很可惜的是：nginxbeat 只支持两个数据来源：标准的 ngx_http_stub_status_module 和商业版 Nginx Plus 的ngx_http_status_module
我们都知道，ngx_http_stub_status_module 输出的信息太少，除了进程级别的连接数，啥都没有。那么，在使用开源版本 Nginx 的我们，还有别的办法么？
在官网的第三方模块列表里，发现了一个韩国人写的 nginx-module-vts。这个扩展可以做到 vhost 级别的状态信息输出。(我知道国人还有很多类似的统计扩展，但是没上官网，不便普及，就忽略吧)
但是，不懂 Golang 的话，没法自己动手实现一个 nginx-vts-beat 啊。怎么办？
其实我们可以用 logstash-input-http_poller 实现类似的功能。
首先，我们要给自己的 Nginx 加上 vts 扩展。编译方式这里就不讲了，和所有其他第三方模块一样。配置方式详见README。我们这里假设是按照核心和非核心接口来统计 URL 的状态：
http {
vhost_traffic_status_zone;
map $uri $filter_uri {
default 'non-core';
/2/api/timeline core;
~^/2/api/unread core;
}
server {
vhost_traffic_status_filter_by_set_key $filter_uri;
location /status {
auth_basic "Restricted";
auth_basic_user_file pass_file;
vhost_traffic_status_display;
vhost_traffic_status_display_format json;
}
}
}input {
http_poller {
urls => {
0 => {
method => get
url => "http://localhost:80/status/format/json"
headers => {
Accept => "application/json"
}
auth => {
user => "YouKnowIKnow"
password => "IKnowYouDonotKnow"
}
}
1 => {
method => get
url => "http://localhost:80/status/con ... up%3D*"
headers => {
Accept => "application/json"
}
auth => {
user => "YouKnowIKnow"
password => "IKnowYouDonotKnow"
}
}
}
request_timeout => 60
interval => 60
codec => "json"
}
}注意，urls 是一个 Hash，所以他的执行顺序是根据 Hash.map 来的，为了确保我们是先获取数据再重置，这里干脆用 0, 1 来作为 Hash 的 key，这样顺序就没问题了。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
Elastic 公司最近推出了 beats 系列，在官方的 packet/top/file{beat} 之外，社区也自发制作了一些比如 docker/nginx/
不过很可惜的是：nginxbeat 只支持两个数据来源：标准的 ngx_http_stub_status_module 和商业版 Nginx Plus 的ngx_http_status_module
我们都知道，ngx_http_stub_status_module 输出的信息太少，除了进程级别的连接数，啥都没有。那么，在使用开源版本 Nginx 的我们，还有别的办法么？
在官网的第三方模块列表里，发现了一个韩国人写的 nginx-module-vts。这个扩展可以做到 vhost 级别的状态信息输出。(我知道国人还有很多类似的统计扩展，但是没上官网，不便普及，就忽略吧)
但是，不懂 Golang 的话，没法自己动手实现一个 nginx-vts-beat 啊。怎么办？
其实我们可以用 logstash-input-http_poller 实现类似的功能。
首先，我们要给自己的 Nginx 加上 vts 扩展。编译方式这里就不讲了，和所有其他第三方模块一样。配置方式详见README。我们这里假设是按照核心和非核心接口来统计 URL 的状态：
注意，urls 是一个 Hash，所以他的执行顺序是根据 Hash.map 来的，为了确保我们是先获取数据再重置，这里干脆用 0, 1 来作为 Hash 的 key，这样顺序就没问题了。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
不过很可惜的是：nginxbeat 只支持两个数据来源：标准的 ngx_http_stub_status_module 和商业版 Nginx Plus 的ngx_http_status_module
我们都知道，ngx_http_stub_status_module 输出的信息太少，除了进程级别的连接数，啥都没有。那么，在使用开源版本 Nginx 的我们，还有别的办法么？
在官网的第三方模块列表里，发现了一个韩国人写的 nginx-module-vts。这个扩展可以做到 vhost 级别的状态信息输出。(我知道国人还有很多类似的统计扩展，但是没上官网，不便普及，就忽略吧)
但是，不懂 Golang 的话，没法自己动手实现一个 nginx-vts-beat 啊。怎么办？
其实我们可以用 logstash-input-http_poller 实现类似的功能。
首先，我们要给自己的 Nginx 加上 vts 扩展。编译方式这里就不讲了，和所有其他第三方模块一样。配置方式详见README。我们这里假设是按照核心和非核心接口来统计 URL 的状态：
http {
vhost_traffic_status_zone;
map $uri $filter_uri {
default 'non-core';
/2/api/timeline core;
~^/2/api/unread core;
}
server {
vhost_traffic_status_filter_by_set_key $filter_uri;
location /status {
auth_basic "Restricted";
auth_basic_user_file pass_file;
vhost_traffic_status_display;
vhost_traffic_status_display_format json;
}
}
}input {
http_poller {
urls => {
0 => {
method => get
url => "http://localhost:80/status/format/json"
headers => {
Accept => "application/json"
}
auth => {
user => "YouKnowIKnow"
password => "IKnowYouDonotKnow"
}
}
1 => {
method => get
url => "http://localhost:80/status/con ... up%3D*"
headers => {
Accept => "application/json"
}
auth => {
user => "YouKnowIKnow"
password => "IKnowYouDonotKnow"
}
}
}
request_timeout => 60
interval => 60
codec => "json"
}
}注意，urls 是一个 Hash，所以他的执行顺序是根据 Hash.map 来的，为了确保我们是先获取数据再重置，这里干脆用 0, 1 来作为 Hash 的 key，这样顺序就没问题了。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
Day5: Kibana4的rison序列化妙用
前几天，我们已经一步步搞定了一个业务日志从 mapping 设计到异常统计追踪上的用法。作为一个工程师，自评 100 分 —— But，领导找上门来说：你这个结构怎么搞的嘛，在 Kibana 上完全没法搜索！让客服和分析师怎么办？
因为 Kibana 上的输入框，默认使用 querystring 语法。这个里面压根没有对 nested object 的相关语法设计。
不过经过仔细查阅，发现原来 Kibana4 的搜索输入框，其实除了 querystring 以外，还支持 JSON 字符串的方式直接定义 query！其具体处理方式就是：把你输入的字符串判断一下是否是 JSON，如果是 JSON，直接替换进{"query": 这里}；如果不是，才生成一个 querystring query 放进 {"query":{"query_string":""}}
那我们来尝试一下把第三天写的那个 nested query 贴进搜索框里。内容是：
当然我很确定我的数据是没问题的。这时候 Kibana4 的另一个特性救了我：它默认会把所有可修改的状态都 rison 序列化了放在 URL 里！于是我尝试直接在浏览器地址栏里输入下面这段 URL：
感谢 Kibana 如此开放的设计原则！
ps: 目前 nested aggregation 还没法像这样简单的绕过，不过已经有相关 pull request 在 review 中，或许 Kibana4.3/4.4 的时候就会合并了。有兴趣的同学，也可以跟我一样先睹为快哟：https://github.com/elastic/kibana/pull/5411
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
继续阅读 »
因为 Kibana 上的输入框，默认使用 querystring 语法。这个里面压根没有对 nested object 的相关语法设计。
不过经过仔细查阅，发现原来 Kibana4 的搜索输入框，其实除了 querystring 以外，还支持 JSON 字符串的方式直接定义 query！其具体处理方式就是：把你输入的字符串判断一下是否是 JSON，如果是 JSON，直接替换进{"query": 这里}；如果不是，才生成一个 querystring query 放进 {"query":{"query_string":""}}
那我们来尝试一下把第三天写的那个 nested query 贴进搜索框里。内容是：
{
"nested" : {
"path" : "video_time_duration",
"query" : {
"match" : {
"video_time_duration.type" : "1"
}
}
}
}当然我很确定我的数据是没问题的。这时候 Kibana4 的另一个特性救了我：它默认会把所有可修改的状态都 rison 序列化了放在 URL 里！于是我尝试直接在浏览器地址栏里输入下面这段 URL：
http://kibana:5601/#/discover?_g=()&_a=(columns:!(_source),index:%5Blogstash-mweibo-%5DYYYY.MM.DD,interval:auto,query:(nested:(path:video_time_duration,query:(term:(video_time_duration.type:1)))),sort:!('@timestamp',desc))感谢 Kibana 如此开放的设计原则！
ps: 目前 nested aggregation 还没法像这样简单的绕过，不过已经有相关 pull request 在 review 中，或许 Kibana4.3/4.4 的时候就会合并了。有兴趣的同学，也可以跟我一样先睹为快哟：https://github.com/elastic/kibana/pull/5411
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
前几天，我们已经一步步搞定了一个业务日志从 mapping 设计到异常统计追踪上的用法。作为一个工程师，自评 100 分 —— But，领导找上门来说：你这个结构怎么搞的嘛，在 Kibana 上完全没法搜索！让客服和分析师怎么办？
因为 Kibana 上的输入框，默认使用 querystring 语法。这个里面压根没有对 nested object 的相关语法设计。
不过经过仔细查阅，发现原来 Kibana4 的搜索输入框，其实除了 querystring 以外，还支持 JSON 字符串的方式直接定义 query！其具体处理方式就是：把你输入的字符串判断一下是否是 JSON，如果是 JSON，直接替换进{"query": 这里}；如果不是，才生成一个 querystring query 放进 {"query":{"query_string":""}}
那我们来尝试一下把第三天写的那个 nested query 贴进搜索框里。内容是：
当然我很确定我的数据是没问题的。这时候 Kibana4 的另一个特性救了我：它默认会把所有可修改的状态都 rison 序列化了放在 URL 里！于是我尝试直接在浏览器地址栏里输入下面这段 URL：
感谢 Kibana 如此开放的设计原则！
ps: 目前 nested aggregation 还没法像这样简单的绕过，不过已经有相关 pull request 在 review 中，或许 Kibana4.3/4.4 的时候就会合并了。有兴趣的同学，也可以跟我一样先睹为快哟：https://github.com/elastic/kibana/pull/5411
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
收起阅读 »
因为 Kibana 上的输入框，默认使用 querystring 语法。这个里面压根没有对 nested object 的相关语法设计。
不过经过仔细查阅，发现原来 Kibana4 的搜索输入框，其实除了 querystring 以外，还支持 JSON 字符串的方式直接定义 query！其具体处理方式就是：把你输入的字符串判断一下是否是 JSON，如果是 JSON，直接替换进{"query": 这里}；如果不是，才生成一个 querystring query 放进 {"query":{"query_string":""}}
那我们来尝试一下把第三天写的那个 nested query 贴进搜索框里。内容是：
{
"nested" : {
"path" : "video_time_duration",
"query" : {
"match" : {
"video_time_duration.type" : "1"
}
}
}
}当然我很确定我的数据是没问题的。这时候 Kibana4 的另一个特性救了我：它默认会把所有可修改的状态都 rison 序列化了放在 URL 里！于是我尝试直接在浏览器地址栏里输入下面这段 URL：
http://kibana:5601/#/discover?_g=()&_a=(columns:!(_source),index:%5Blogstash-mweibo-%5DYYYY.MM.DD,interval:auto,query:(nested:(path:video_time_duration,query:(term:(video_time_duration.type:1)))),sort:!('@timestamp',desc))感谢 Kibana 如此开放的设计原则！
ps: 目前 nested aggregation 还没法像这样简单的绕过，不过已经有相关 pull request 在 review 中，或许 Kibana4.3/4.4 的时候就会合并了。有兴趣的同学，也可以跟我一样先睹为快哟：https://github.com/elastic/kibana/pull/5411
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
收起阅读 »
Day4: significant_terms聚合
昨天我们通过 nested aggregation 计算出来，视频卡顿次数最多的是北京。不过这个结论似乎也没有什么奇怪的，北京的网民本身就多嘛。
Elasticsearch 还有一个有趣的聚合方式，叫 significant_terms。这时候就可以派上用场了！
我们把昨天的 query JSON 中，最后一段 sub agg 改成这样：
而且每个结果后面，还多出来了 score 和 bg_count 两个数据。这个 bg_count 是怎么回事呢？
这就是 significant_terms 的作用了。这个 agg 的大概计算步骤是这样：
由于两个作分母的总数其实大家都是相等的，其实比较的就是各 term 的 doc_count / bg_count 了。
当然，实际的 score 不只是这么简单，还有其他综合因素。毕竟也不能给出来本身就没啥关注度的数据嘛。
我们还可以来验证一下『武汉』的 bg_count 是不是这个意思：
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
继续阅读 »
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 的大概计算步骤是这样：
- 计算一个 term 在整个索引中的比例，作为背景计数(background)，这里是 15347191 / 2353406423；
- 计算一个 term 在 parent agg 中的比例，作为前景计数(foreground)，这里是 85980 / 2521720；
- 用 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
}
}想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
昨天我们通过 nested aggregation 计算出来，视频卡顿次数最多的是北京。不过这个结论似乎也没有什么奇怪的，北京的网民本身就多嘛。
Elasticsearch 还有一个有趣的聚合方式，叫 significant_terms。这时候就可以派上用场了！
我们把昨天的 query JSON 中，最后一段 sub agg 改成这样：
而且每个结果后面，还多出来了 score 和 bg_count 两个数据。这个 bg_count 是怎么回事呢？
这就是 significant_terms 的作用了。这个 agg 的大概计算步骤是这样：
由于两个作分母的总数其实大家都是相等的，其实比较的就是各 term 的 doc_count / bg_count 了。
当然，实际的 score 不只是这么简单，还有其他综合因素。毕竟也不能给出来本身就没啥关注度的数据嘛。
我们还可以来验证一下『武汉』的 bg_count 是不是这个意思：
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
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 的大概计算步骤是这样：
- 计算一个 term 在整个索引中的比例，作为背景计数(background)，这里是 15347191 / 2353406423；
- 计算一个 term 在 parent agg 中的比例，作为前景计数(foreground)，这里是 85980 / 2521720；
- 用 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
}
}想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
Day3：nested object的查询和聚合示例
话接上回，我们只是解决了写数据的问题，这种格式不太符合常规的数据怎么读，也需要我们相应的做出点改变。
今天以一个实际的例子来讲。我曾经处理过一份数据，记录的是视频播放的卡顿情况。其中有一个数组，每次卡顿就新增一个对象元素。所以设计的 mapping 如下：
出现了播放卡顿的用户，单次卡顿时长在10到200ms的，最常见于哪些城市？
下面是我们最终的查询请求 JSON：
大家可能注意到，我同时在 query 和 aggFilter 中重复了一场 term 过滤。其中这次 nested query 是不必要的，除了作为语法展示以外，也有一个减少 hits 数的作用。但是和一般的请求不同的是，这里不可以去掉 nested agg 里的 term filter，因为 nested query 只是拿到『有过卡顿』的数据 id。不加 filter，聚合 duration 的时候，会把卡过但也流畅过的那部分都计算在内。
另一个要点：当我们过滤好 nested 数据的时候，要取顶层其他字段的内容，在 sub agg 里是无法直接获取的，需要额外使用一次 reverse_nested 来跳出这个 nested path，才可以恢复正常的 agg 路径。
最终得到的响应如下：
数据蛮有意思吧。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
}
}
},出现了播放卡顿的用户，单次卡顿时长在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"
}
}
}
}
}
}
}
}
}
}
}
}大家可能注意到，我同时在 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
}
]
}
}
} ]
}
}
}
}
}- 一共命中了『有过卡顿』的视频播放次数：9560309；
- 其中记录下来的播放间隔 33713503 次；
- 里面有 25441559 次是卡顿(减一下即 8271944 次是流畅咯)；
- 里面卡顿时长在 10-200 ms 的是 2521720 次；
- 这些卡顿出现最多的在北京，发生了 142761 次。
数据蛮有意思吧。ES 能告诉你的还不止这点。更有趣的，明天见。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
话接上回，我们只是解决了写数据的问题，这种格式不太符合常规的数据怎么读，也需要我们相应的做出点改变。
今天以一个实际的例子来讲。我曾经处理过一份数据，记录的是视频播放的卡顿情况。其中有一个数组，每次卡顿就新增一个对象元素。所以设计的 mapping 如下：
出现了播放卡顿的用户，单次卡顿时长在10到200ms的，最常见于哪些城市？
下面是我们最终的查询请求 JSON：
大家可能注意到，我同时在 query 和 aggFilter 中重复了一场 term 过滤。其中这次 nested query 是不必要的，除了作为语法展示以外，也有一个减少 hits 数的作用。但是和一般的请求不同的是，这里不可以去掉 nested agg 里的 term filter，因为 nested query 只是拿到『有过卡顿』的数据 id。不加 filter，聚合 duration 的时候，会把卡过但也流畅过的那部分都计算在内。
另一个要点：当我们过滤好 nested 数据的时候，要取顶层其他字段的内容，在 sub agg 里是无法直接获取的，需要额外使用一次 reverse_nested 来跳出这个 nested path，才可以恢复正常的 agg 路径。
最终得到的响应如下：
数据蛮有意思吧。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
}
}
},出现了播放卡顿的用户，单次卡顿时长在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"
}
}
}
}
}
}
}
}
}
}
}
}大家可能注意到，我同时在 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
}
]
}
}
} ]
}
}
}
}
}- 一共命中了『有过卡顿』的视频播放次数：9560309；
- 其中记录下来的播放间隔 33713503 次；
- 里面有 25441559 次是卡顿(减一下即 8271944 次是流畅咯)；
- 里面卡顿时长在 10-200 ms 的是 2521720 次；
- 这些卡顿出现最多的在北京，发生了 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 个字段的定义。
这时候，我们修改一下 mapping 定义：
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
继续阅读 »
我们都知道，Elasticsearch 宣传中是 schemaless 的。但实际使用中，并不是完全的随意。比如过多的 kv 切割，会导致 mapping 大小暴涨，对集群稳定性是个不小的挑战。
以 urlparams 为例，下面这段 urlparams 直接通过 logstash-filter-kv 切割得到的结果，需要在 mapping 中占用 4 个字段的定义。
"urlparams" : {
"uid" : "1234567890",
"action" : "payload",
"t" : "1449053032000",
"pageid" : "v6"
}这时候，我们修改一下 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 }
}
}
}
}
}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" ]
}
}"urlargs": [
{ "key": "uid", "value": "1234567890" },
{ "key": "action", "value": "payload" },
{ "key": "1449053032000", "value": "t" },
{ "key": "pageid", "value": "v6" }
]想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
Elasticsearch 中有些高级特性，可能不太常用，但是在恰当场景下，又非常有效果。今天，我们来说说 nested object。
我们都知道，Elasticsearch 宣传中是 schemaless 的。但实际使用中，并不是完全的随意。比如过多的 kv 切割，会导致 mapping 大小暴涨，对集群稳定性是个不小的挑战。
以 urlparams 为例，下面这段 urlparams 直接通过 logstash-filter-kv 切割得到的结果，需要在 mapping 中占用 4 个字段的定义。
这时候，我们修改一下 mapping 定义：
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
我们都知道，Elasticsearch 宣传中是 schemaless 的。但实际使用中，并不是完全的随意。比如过多的 kv 切割，会导致 mapping 大小暴涨，对集群稳定性是个不小的挑战。
以 urlparams 为例，下面这段 urlparams 直接通过 logstash-filter-kv 切割得到的结果，需要在 mapping 中占用 4 个字段的定义。
"urlparams" : {
"uid" : "1234567890",
"action" : "payload",
"t" : "1449053032000",
"pageid" : "v6"
}这时候，我们修改一下 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 }
}
}
}
}
}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" ]
}
}"urlargs": [
{ "key": "uid", "value": "1234567890" },
{ "key": "action", "value": "payload" },
{ "key": "1449053032000", "value": "t" },
{ "key": "pageid", "value": "v6" }
]想了解更全面的 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 中，也就是配置这样一段：
这是因为：Logstash 会记录自己读取文件内容的偏移量到一个隐藏文件里，默认情况下，下次启动，他会从这个偏移量继续往后读，避免重复读取数据。
这个隐藏文件，叫做 $HOME/.sincedb_****。过去很多文档，在解释了这个原理后，都会告诉大家解决办法：每次重新运行 logstash 命令之前，删除掉家目录下的 sincedb 隐藏文件。
但是这种办法很笨，不是么？
今天告诉大家一个更方便的办法，改用下面这段 Logstash 配置：
好了，第一天就是这样。更多内容，敬请期待。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
继续阅读 »
今天是 12 月 1 日，第一天，开天辟地，让我们也从最简单而又容易被忽略的一个小技巧开始吧！
每个上手 ELK 的新用户，肯定都需要测试一下读取文件输出到终端这步。在 Logstash 中，也就是配置这样一段：
input {
file {
path => ["/data/test.log"]
}
}
output {
stdout {
codec => rubydebug
}
}这是因为：Logstash 会记录自己读取文件内容的偏移量到一个隐藏文件里，默认情况下，下次启动，他会从这个偏移量继续往后读，避免重复读取数据。
这个隐藏文件，叫做 $HOME/.sincedb_****。过去很多文档，在解释了这个原理后，都会告诉大家解决办法：每次重新运行 logstash 命令之前，删除掉家目录下的 sincedb 隐藏文件。
但是这种办法很笨，不是么？
今天告诉大家一个更方便的办法，改用下面这段 Logstash 配置：
input {
file {
path => ["/data/test.log"]
start_position => "beginning"
sincedb_path => "/dev/null"
}
}
output {
stdout {
codec => rubydebug
}
}好了，第一天就是这样。更多内容，敬请期待。
想了解更全面的 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 中，也就是配置这样一段：
这是因为：Logstash 会记录自己读取文件内容的偏移量到一个隐藏文件里，默认情况下，下次启动，他会从这个偏移量继续往后读，避免重复读取数据。
这个隐藏文件，叫做 $HOME/.sincedb_****。过去很多文档，在解释了这个原理后，都会告诉大家解决办法：每次重新运行 logstash 命令之前，删除掉家目录下的 sincedb 隐藏文件。
但是这种办法很笨，不是么？
今天告诉大家一个更方便的办法，改用下面这段 Logstash 配置：
好了，第一天就是这样。更多内容，敬请期待。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
今天是 12 月 1 日，第一天，开天辟地，让我们也从最简单而又容易被忽略的一个小技巧开始吧！
每个上手 ELK 的新用户，肯定都需要测试一下读取文件输出到终端这步。在 Logstash 中，也就是配置这样一段：
input {
file {
path => ["/data/test.log"]
}
}
output {
stdout {
codec => rubydebug
}
}这是因为：Logstash 会记录自己读取文件内容的偏移量到一个隐藏文件里，默认情况下，下次启动，他会从这个偏移量继续往后读，避免重复读取数据。
这个隐藏文件，叫做 $HOME/.sincedb_****。过去很多文档，在解释了这个原理后，都会告诉大家解决办法：每次重新运行 logstash 命令之前，删除掉家目录下的 sincedb 隐藏文件。
但是这种办法很笨，不是么？
今天告诉大家一个更方便的办法，改用下面这段 Logstash 配置：
input {
file {
path => ["/data/test.log"]
start_position => "beginning"
sincedb_path => "/dev/null"
}
}
output {
stdout {
codec => rubydebug
}
}好了，第一天就是这样。更多内容，敬请期待。
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
elasticsearch logstash kibana beats 资料分享
ELK系列文章推荐 http://www.ttlsa.com/log-system/elk/ 写的还不错。
ELK系列文章推荐 http://www.ttlsa.com/log-system/elk/ 写的还不错。
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)。
操作过程和记录的内容或许有很多地方不合理不恰当，和我一样的新手可以一起交流，请大神多给予指导。
继续阅读 »
我把在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)。
操作过程和记录的内容或许有很多地方不合理不恰当，和我一样的新手可以一起交流，请大神多给予指导。 收起阅读 »
我把在Windows平台上的ElasticSearch2.0安装，1.7.2升级的全过程的步骤、经验、教训记录下来，如文档(http://pan.baidu.com/s/1qWOTpz2)。
操作过程和记录的内容或许有很多地方不合理不恰当，和我一样的新手可以一起交流，请大神多给予指导。 收起阅读 »
sammysong 发表于 : 2015-11-26 15:52
评论 (10)
常用链接及资源索引
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
社区微信公众号
Elastic 官方公众号
交流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://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
社区微信公众号
Elastic 官方公众号
交流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
社区微信公众号
Elastic 官方公众号
交流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://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
社区微信公众号
Elastic 官方公众号
交流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)
分享者简介：查超，瀚思安信基础平台部 研究人员
更多讲师及分享主题介绍陆续添加中...
鸣谢:
感谢 货车帮对这次活动的大力支持
继续阅读 »
地点:四川成都市高新区天府大道中段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)
分享者简介：查超，瀚思安信基础平台部 研究人员
更多讲师及分享主题介绍陆续添加中...
鸣谢:
感谢 货车帮对这次活动的大力支持 收起阅读 »
地点:四川成都市高新区天府大道中段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
继续阅读 »
第四届Elasticsearch国内开发者大会站 成都站 是的 ,下一站是在成都,并且马上就要开始了,
报名的速度了,
紧急征集讲师和志愿者中!!!!
报名地址;
http://form.mikecrm.com/f.php?t=mOUa1M
相信前面大家都知道在北京和上海已经举办了2场线下活动了,下一站是哪里呢??
第四届Elasticsearch国内开发者大会站 成都站 是的 ,下一站是在成都,并且马上就要开始了,
报名的速度了,
紧急征集讲师和志愿者中!!!!
报名地址;
http://form.mikecrm.com/f.php?t=mOUa1M
收起阅读 »
第四届Elasticsearch国内开发者大会站 成都站 是的 ,下一站是在成都,并且马上就要开始了,
报名的速度了,
紧急征集讲师和志愿者中!!!!
报名地址;
http://form.mikecrm.com/f.php?t=mOUa1M
收起阅读 »
