设置参数 `node.name` 可以自定义 Elasticsearch 节点的名字。 此条 Tips 由 medcl 贡献。

Day12: siren-join简介

很多从 MySQL 转过来的 Elasticsearch 用户总是很习惯的问一个问题：『怎么在 ES 里实现 join 操作？』过去，我们的回答一般都是：通过类似宽表的思路，将数据平铺在一个索引里。不过，最近另一家 Lucene 开发商给出了另一个方案，他们开发了一个 Elasticsearch 插件，实现了 filter 层面的 join，GitHub 项目地址见：https://github.com/sirensolutions/siren-join

不过需要提醒一下的是：filter 层面的意思，就是只相当于是 SQL 里的 exists 操作。所以目前对这个插件也不要抱有太大期望。今天我们来稍微演示一下。

安装和其他 ES 插件一样：
# bin/plugin -i solutions.siren/siren-join/1.0
注意 siren-join v1.0 只支持 ES 1.7 版本，2.0 版本支持据说正在开发中。

我们 bulk 上传这么一段数据：
{"index":{"_index":"index1","_type":"type","_id":"1"}}

{"id":1, "foreign_key":"13"}

{"index":{"_index":"index1","_type":"type","_id":"2"}}

{"id":2}

{"index":{"_index":"index1","_type":"type","_id":"3"}}

{"id":3, "foreign_key": "2"}

{"index":{"_index":"index1","_type":"type","_id":"4"}}

{"id":4, "foreign_key": "14"}

{"index":{"_index":"index1","_type":"type","_id":"5"}}

{"id":5, "foreign_key": "2"}

{"index":{"_index":"index2","_type":"type","_id":"1"}}

{"id":"1", "tag": "aaa"}

{"index":{"_index":"index2","_type":"type","_id":"2"}}

{"id":"2", "tag": "aaa"}

{"index":{"_index":"index2","_type":"type","_id":"3"}}

{"id":"3", "tag": "bbb"}

{"index":{"_index":"index2","_type":"type","_id":"4"}}

{"id":"4", "tag": "ccc"}
注意，siren-join 要求用来 join 的字段必须数据类型一致。所以，当我们要用 index2 的 id 和 index1 的foreign_key 做 join 的时候，这两个字段就要保持一致，这里为了演示，特意都改成字符串。那么我们发起一个请求如下：
# curl -s -XPOST 'http://localhost:9200/index1/_coordinate_search?pretty' -d '

{

    "query":{

        "filtered":{

            "query":{

                "match_all":{}

            },

            "filter":{

                "filterjoin":{

                    "foreign_key":{

                        "index":"index2",

                        "type":"type",

                        "path":"id",

                        "query":{

                            "terms":{

                                "tag":["aaa"]

                            }

                        }

                    }

                }

            }

        }

    },

    "aggs":{

        "avg":{

            "avg":{

                "field":"id"

            }

        }

    }

}'
意即：从 index2 中搜索 q=tag:aaa 的数据的 id，查找 index1 中对应 foreign_key 的文档的 id 数据平均值。响应结果如下：
{

    "coordinate_search" : {

        "actions" : [ {

            "relations" : {

                "from" : {

                    "indices" : [ ],

                    "types" : [ ],

                    "field" : "id"

                },

                "to" : {

                    "indices" : null,

                    "types" : null,

                    "field" : "foreign_key"

                }

            },

            "size" : 2,

            "size_in_bytes" : 20,

            "is_pruned" : false,

            "cache_hit" : true,

            "took" : 0

        } ]

    },

    "took" : 2,

    "timed_out" : false,

    "_shards" : {

        "total" : 5,

        "successful" : 5,

        "failed" : 0

    },

    "hits" : {

        "total" : 2,

        "max_score" : 1.0,

        "hits" : [ {

            "_index" : "index1",

            "_type" : "type",

            "_id" : "5",

            "_score" : 1.0,

            "_source":{"id":5, "foreign_key": "2"}

        }, {

            "_index" : "index1",

            "_type" : "type",

            "_id" : "3",

            "_score" : 1.0,

            "_source":{"id":3, "foreign_key": "2"}

        } ]

    },

    "aggregations" : {

        "avg" : {

            "value" : 4.0

        }

    }

}
响应告诉我们：从 index2 中搜索到 2 条参与 join 的文档，在 index1 中命中 2 条数据，最后求平均值为 4.0。

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
继续阅读 »
很多从 MySQL 转过来的 Elasticsearch 用户总是很习惯的问一个问题：『怎么在 ES 里实现 join 操作？』过去，我们的回答一般都是：通过类似宽表的思路，将数据平铺在一个索引里。不过，最近另一家 Lucene 开发商给出了另一个方案，他们开发了一个 Elasticsearch 插件，实现了 filter 层面的 join，GitHub 项目地址见：https://github.com/sirensolutions/siren-join

不过需要提醒一下的是：filter 层面的意思，就是只相当于是 SQL 里的 exists 操作。所以目前对这个插件也不要抱有太大期望。今天我们来稍微演示一下。

安装和其他 ES 插件一样：
# bin/plugin -i solutions.siren/siren-join/1.0
注意 siren-join v1.0 只支持 ES 1.7 版本，2.0 版本支持据说正在开发中。

我们 bulk 上传这么一段数据：
{"index":{"_index":"index1","_type":"type","_id":"1"}}

{"id":1, "foreign_key":"13"}

{"index":{"_index":"index1","_type":"type","_id":"2"}}

{"id":2}

{"index":{"_index":"index1","_type":"type","_id":"3"}}

{"id":3, "foreign_key": "2"}

{"index":{"_index":"index1","_type":"type","_id":"4"}}

{"id":4, "foreign_key": "14"}

{"index":{"_index":"index1","_type":"type","_id":"5"}}

{"id":5, "foreign_key": "2"}

{"index":{"_index":"index2","_type":"type","_id":"1"}}

{"id":"1", "tag": "aaa"}

{"index":{"_index":"index2","_type":"type","_id":"2"}}

{"id":"2", "tag": "aaa"}

{"index":{"_index":"index2","_type":"type","_id":"3"}}

{"id":"3", "tag": "bbb"}

{"index":{"_index":"index2","_type":"type","_id":"4"}}

{"id":"4", "tag": "ccc"}
注意，siren-join 要求用来 join 的字段必须数据类型一致。所以，当我们要用 index2 的 id 和 index1 的foreign_key 做 join 的时候，这两个字段就要保持一致，这里为了演示，特意都改成字符串。那么我们发起一个请求如下：
# curl -s -XPOST 'http://localhost:9200/index1/_coordinate_search?pretty' -d '

{

    "query":{

        "filtered":{

            "query":{

                "match_all":{}

            },

            "filter":{

                "filterjoin":{

                    "foreign_key":{

                        "index":"index2",

                        "type":"type",

                        "path":"id",

                        "query":{

                            "terms":{

                                "tag":["aaa"]

                            }

                        }

                    }

                }

            }

        }

    },

    "aggs":{

        "avg":{

            "avg":{

                "field":"id"

            }

        }

    }

}'
意即：从 index2 中搜索 q=tag:aaa 的数据的 id，查找 index1 中对应 foreign_key 的文档的 id 数据平均值。响应结果如下：
{

    "coordinate_search" : {

        "actions" : [ {

            "relations" : {

                "from" : {

                    "indices" : [ ],

                    "types" : [ ],

                    "field" : "id"

                },

                "to" : {

                    "indices" : null,

                    "types" : null,

                    "field" : "foreign_key"

                }

            },

            "size" : 2,

            "size_in_bytes" : 20,

            "is_pruned" : false,

            "cache_hit" : true,

            "took" : 0

        } ]

    },

    "took" : 2,

    "timed_out" : false,

    "_shards" : {

        "total" : 5,

        "successful" : 5,

        "failed" : 0

    },

    "hits" : {

        "total" : 2,

        "max_score" : 1.0,

        "hits" : [ {

            "_index" : "index1",

            "_type" : "type",

            "_id" : "5",

            "_score" : 1.0,

            "_source":{"id":5, "foreign_key": "2"}

        }, {

            "_index" : "index1",

            "_type" : "type",

            "_id" : "3",

            "_score" : 1.0,

            "_source":{"id":3, "foreign_key": "2"}

        } ]

    },

    "aggregations" : {

        "avg" : {

            "value" : 4.0

        }

    }

}
响应告诉我们：从 index2 中搜索到 2 条参与 join 的文档，在 index1 中命中 2 条数据，最后求平均值为 4.0。

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
 advent
三斗室 发表于 : 2015-12-16 23:03 评论 (0)

Day11: timelion请求语法

ES2.0 开始提供了一个崭新的 pipeline aggregation 特性，但是 Kibana 似乎并没有立刻跟进这方面的意思，相反，Elastic 公司推出了另一个实验室产品：Timelion。
timelion 的用法在官博里已经有介绍。尤其是最近两篇如何用 timelion 实现异常告警的文章，更是从 ES 的 pipeline aggregation 细节和场景一路讲到 timelion 具体操作，我这里几乎没有再重新讲一遍 timelion 操作入门的必要了。不过，官方却一直没有列出来 timelion 支持的请求语法的文档，而是在页面上通过点击图标的方式下拉帮助。

timelion 页面设计上，更接近 Kibana3 而不是 Kibana4。比如 panel 分布是通过设置几行几列的数目来固化的；query 框是唯一的，要修改哪个 panel 的 query，鼠标点选一下 panel，query 就自动切换成这个 panel 的了。

为了方便大家在上手之前了解 timelion 能做到什么，今天特意把 timelion 的请求语法所支持的函数分为几类，罗列如下：

可视化效果类：
    .bars($width): 用柱状图展示数组

    .lines($width, $fill, $show, $steps): 用折线图展示数组

    .points(): 用散点图展示数组

    .color("#c6c6c6"): 改变颜色

    .hide(): 隐藏该数组

    .label("change from %s"): 标签

    .legend($position, $column): 图例位置

    .yaxis($yaxis_number, $min, $max, $position): 设置 Y 轴属性，.yaxis(2) 表示第二根 Y 轴

数据运算类：
    .abs(): 对整个数组元素求绝对值

    .precision($number): 浮点数精度

    .testcast($count, $alpha, $beta, $gamma): holt-winters 预测

    .cusum($base): 数组元素之和，再加上 $base

    .derivative(): 对数组求导数

    .divide($divisor): 数组元素除法

    .multiply($multiplier): 数组元素乘法

    .subtract($term): 数组元素减法

    .sum($term): 数组元素加法

    .add(): 同 .sum()

    .plus(): 同 .sum()

    .first(): 返回第一个元素

    .movingaverage($window): 用指定的窗口大小计算移动平均值

    .mvavg(): .movingaverage() 的简写

    .movingstd($window): 用指定的窗口大小计算移动标准差

    .mvstd(): .movingstd() 的简写
数据源设定类：
    .elasticsearch(): 从 ES 读取数据

    .es(q="querystring", metric="cardinality:uid", index="logstash-*", offset="-1d"): .elasticsearch() 的简写

    .graphite(metric="path.to.*.data", offset="-1d"): 从 graphite 读取数据

    .quandl(): 从 quandl.com 读取 quandl 码

    .worldbank_indicators(): 从 worldbank.org 读取国家数据

    .wbi(): .worldbank_indicators() 的简写

    .worldbank(): 从 worldbank.org 读取数据

    .wb(): .worldbanck() 的简写
以上所有函数，都在 series_functions 目录下实现，每个 js 文件实现一个 TimelionFunction 功能。

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
继续阅读 »
ES2.0 开始提供了一个崭新的 pipeline aggregation 特性，但是 Kibana 似乎并没有立刻跟进这方面的意思，相反，Elastic 公司推出了另一个实验室产品：Timelion。
timelion 的用法在官博里已经有介绍。尤其是最近两篇如何用 timelion 实现异常告警的文章，更是从 ES 的 pipeline aggregation 细节和场景一路讲到 timelion 具体操作，我这里几乎没有再重新讲一遍 timelion 操作入门的必要了。不过，官方却一直没有列出来 timelion 支持的请求语法的文档，而是在页面上通过点击图标的方式下拉帮助。

timelion 页面设计上，更接近 Kibana3 而不是 Kibana4。比如 panel 分布是通过设置几行几列的数目来固化的；query 框是唯一的，要修改哪个 panel 的 query，鼠标点选一下 panel，query 就自动切换成这个 panel 的了。

为了方便大家在上手之前了解 timelion 能做到什么，今天特意把 timelion 的请求语法所支持的函数分为几类，罗列如下：

可视化效果类：
    .bars($width): 用柱状图展示数组

    .lines($width, $fill, $show, $steps): 用折线图展示数组

    .points(): 用散点图展示数组

    .color("#c6c6c6"): 改变颜色

    .hide(): 隐藏该数组

    .label("change from %s"): 标签

    .legend($position, $column): 图例位置

    .yaxis($yaxis_number, $min, $max, $position): 设置 Y 轴属性，.yaxis(2) 表示第二根 Y 轴

数据运算类：
    .abs(): 对整个数组元素求绝对值

    .precision($number): 浮点数精度

    .testcast($count, $alpha, $beta, $gamma): holt-winters 预测

    .cusum($base): 数组元素之和，再加上 $base

    .derivative(): 对数组求导数

    .divide($divisor): 数组元素除法

    .multiply($multiplier): 数组元素乘法

    .subtract($term): 数组元素减法

    .sum($term): 数组元素加法

    .add(): 同 .sum()

    .plus(): 同 .sum()

    .first(): 返回第一个元素

    .movingaverage($window): 用指定的窗口大小计算移动平均值

    .mvavg(): .movingaverage() 的简写

    .movingstd($window): 用指定的窗口大小计算移动标准差

    .mvstd(): .movingstd() 的简写
数据源设定类：
    .elasticsearch(): 从 ES 读取数据

    .es(q="querystring", metric="cardinality:uid", index="logstash-*", offset="-1d"): .elasticsearch() 的简写

    .graphite(metric="path.to.*.data", offset="-1d"): 从 graphite 读取数据

    .quandl(): 从 quandl.com 读取 quandl 码

    .worldbank_indicators(): 从 worldbank.org 读取国家数据

    .wbi(): .worldbank_indicators() 的简写

    .worldbank(): 从 worldbank.org 读取数据

    .wb(): .worldbanck() 的简写
以上所有函数，都在 series_functions 目录下实现，每个 js 文件实现一个 TimelionFunction 功能。

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
 advent
三斗室 发表于 : 2015-12-16 23:01 评论 (0)

Day10: 如何处理数组形式的JSON日志

ELK 收集业务日志的来源，除了应用服务器以外，还有很大一部分来自客户端。考虑到客户端网络流量的因素，一般实现上都不会要求实时上报数据，而是攒一批，等到手机连上 WIFI 网络了，再统一发送出来。所以，这类客户端日志一般都有几个特点：
  1. 预先已经记录成 JSON 了；
  2. 日志主体内容是一个巨大无比的数组，数据元素才是实际的单次日志记录；
  3. 一次 POST 会有几 MB 到几十 MB 大小。


在处理这类数据的时候，第一关是别让数据超长直接给丢弃了（说的就是你啊，Rsyslog）；第二关就是拆分 JSON 数组，把几十 MB 数据扔 ES 字段里，显然是不利于搜索和统计需求的。今天我们就来说说怎么拆分 JSON 数组。

假设收到的是这么一段日志：
{"uid":123456,"upload_datetime":"2015-12-10 11:38:11","logs":[{"type":"crash","timestamp":"2015-12-10 17:55:00","reason":"****"},{"type":"network_error","timestamp":"2015-12-10 17:56:12","tracert":"****"}]}
首先我们知道可以在读取的时候把 JSON 数据解析成 LogStash::Event 对象：
input {

    tcp {

        codec => json

    }

}
但是怎么把解析出来的 logs 字段拆分成多个 event 呢？这里我们可以用一个已有插件：logstash-filter-split。
filter {

    split {

        field => "logs"

    }

    date {

        match => ["timestamp", "yyyy-MM-dd HH:mm:ss"]

        remove_fields => ["logs", "timestamp"]

    }

}
这样，就可以得到两个 event 了：
{"uid":123456,"upload_datetime":"2015-12-10 11:38:11","type":"crash","@timestamp":"2015-12-10T09:55:00Z","reason":"****"}

{"uid":123456,"upload_datetime":"2015-12-10 11:38:11","type":"network_error","@timestamp":"2015-12-10T09:56:12Z","tracert":"****"}
看起来可能跟这个插件的文档描述不太一样。文档上写的是通过 terminator 字符，切割 field 字符串成多个 event。但实际上，field 设置是会自动判断的，如果 field 内容是字符串，就切割字符串成为数组再循环；如果内容已经是数组了，直接循环：
    original_value = event[@field]



    if original_value.is_a?(Array)

        splits = original_value

    elsif original_value.is_a?(String)

        splits = original_value.split(@terminator, -1)

    else

        raise LogStash::ConfigurationError, "Only String and Array types are splittable. field:#{@field} is of type = #{original_value.class}"

    end



    return if splits.length == 1



    splits.each do |value|

        next if value.empty?



        event_split = event.clone

        @logger.debug("Split event", :value => value, :field => @field)

        event_split[(@target || @field)] = value

        filter_matched(event_split)



        yield event_split

    end

    event.cancel
顺带提一句：这里 yield 在 Logstash 1.5.0 之前，实现有问题，生成的新事件，不会继续执行后续 filter，直接进入到 output 阶段。也就是说，如果你用 Logstash 1.4.2 来执行上面那段配置，生成的两个事件会是这样的：
{"@timestamp":"2015-12-10T09:38:13Z","uid":123456,"upload_datetime":"2015-12-10 11:38:11","type":"crash","timestamp":"2015-12-10 17:55:00","reason":"****","logs":[{"type":"crash","timestamp":"2015-12-10 17:55:00","reason":"****"},{"type":"network_error","timestamp":"2015-12-10 17:56:12","tracert":"****"}]}

{"@timestamp":"2015-12-10T09:38:13Z","uid":123456,"upload_datetime":"2015-12-10 11:38:11","type":"network_error","@timestamp":"2015-12-10 17:56:12","tracert":"****","logs":[{"type":"crash","timestamp":"2015-12-10 17:55:00","reason":"****"},{"type":"network_error","timestamp":"2015-12-10 17:56:12","tracert":"****"}]}
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
继续阅读 »
ELK 收集业务日志的来源，除了应用服务器以外，还有很大一部分来自客户端。考虑到客户端网络流量的因素，一般实现上都不会要求实时上报数据，而是攒一批，等到手机连上 WIFI 网络了，再统一发送出来。所以，这类客户端日志一般都有几个特点：
  1. 预先已经记录成 JSON 了；
  2. 日志主体内容是一个巨大无比的数组，数据元素才是实际的单次日志记录；
  3. 一次 POST 会有几 MB 到几十 MB 大小。


在处理这类数据的时候，第一关是别让数据超长直接给丢弃了（说的就是你啊，Rsyslog）；第二关就是拆分 JSON 数组，把几十 MB 数据扔 ES 字段里，显然是不利于搜索和统计需求的。今天我们就来说说怎么拆分 JSON 数组。

假设收到的是这么一段日志：
{"uid":123456,"upload_datetime":"2015-12-10 11:38:11","logs":[{"type":"crash","timestamp":"2015-12-10 17:55:00","reason":"****"},{"type":"network_error","timestamp":"2015-12-10 17:56:12","tracert":"****"}]}
首先我们知道可以在读取的时候把 JSON 数据解析成 LogStash::Event 对象：
input {

    tcp {

        codec => json

    }

}
但是怎么把解析出来的 logs 字段拆分成多个 event 呢？这里我们可以用一个已有插件：logstash-filter-split。
filter {

    split {

        field => "logs"

    }

    date {

        match => ["timestamp", "yyyy-MM-dd HH:mm:ss"]

        remove_fields => ["logs", "timestamp"]

    }

}
这样，就可以得到两个 event 了：
{"uid":123456,"upload_datetime":"2015-12-10 11:38:11","type":"crash","@timestamp":"2015-12-10T09:55:00Z","reason":"****"}

{"uid":123456,"upload_datetime":"2015-12-10 11:38:11","type":"network_error","@timestamp":"2015-12-10T09:56:12Z","tracert":"****"}
看起来可能跟这个插件的文档描述不太一样。文档上写的是通过 terminator 字符，切割 field 字符串成多个 event。但实际上，field 设置是会自动判断的，如果 field 内容是字符串，就切割字符串成为数组再循环；如果内容已经是数组了，直接循环：
    original_value = event[@field]



    if original_value.is_a?(Array)

        splits = original_value

    elsif original_value.is_a?(String)

        splits = original_value.split(@terminator, -1)

    else

        raise LogStash::ConfigurationError, "Only String and Array types are splittable. field:#{@field} is of type = #{original_value.class}"

    end



    return if splits.length == 1



    splits.each do |value|

        next if value.empty?



        event_split = event.clone

        @logger.debug("Split event", :value => value, :field => @field)

        event_split[(@target || @field)] = value

        filter_matched(event_split)



        yield event_split

    end

    event.cancel
顺带提一句：这里 yield 在 Logstash 1.5.0 之前，实现有问题，生成的新事件，不会继续执行后续 filter，直接进入到 output 阶段。也就是说，如果你用 Logstash 1.4.2 来执行上面那段配置，生成的两个事件会是这样的：
{"@timestamp":"2015-12-10T09:38:13Z","uid":123456,"upload_datetime":"2015-12-10 11:38:11","type":"crash","timestamp":"2015-12-10 17:55:00","reason":"****","logs":[{"type":"crash","timestamp":"2015-12-10 17:55:00","reason":"****"},{"type":"network_error","timestamp":"2015-12-10 17:56:12","tracert":"****"}]}

{"@timestamp":"2015-12-10T09:38:13Z","uid":123456,"upload_datetime":"2015-12-10 11:38:11","type":"network_error","@timestamp":"2015-12-10 17:56:12","tracert":"****","logs":[{"type":"crash","timestamp":"2015-12-10 17:55:00","reason":"****"},{"type":"network_error","timestamp":"2015-12-10 17:56:12","tracert":"****"}]}
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
 advent
三斗室 发表于 : 2015-12-16 22:57 评论 (1)

elasticsearch源码调试环境小结

前端时间折腾了一下源码调试的问题，简单总结以下。
---------------------
调试环境是window（linux理论上通用）
用到的工具类：
1:mvn：https://maven.apache.org/
elasticsearch的源码是用mvn工具管理的，根据pom.xml来下载一些依赖包非常方便。
（当然也可以用gradle，由于不太熟悉，就没研究）
安装mvn，注意配置后环境变量即可。官方文档写的很明白。
最好自己修改一下mvn的setting.xml文件中的本地repo
<!-- localRepository
   | The path to the local repository maven will use to store artifacts.
   |
   | Default: ${user.home}/.m2/repository
  <localRepository>/path/to/local/repo</localRepository>
-->
我设置成了：
<localRepository>E:/m2/repository</localRepository>
mvn -v 测试以下
2:eclipse：编辑器，应用应该还比较广泛的。我用的最新版的mars。
（intellij idea据说这是一个很牛逼的编辑器，也是因为暂时不熟悉，还没研究）
----------------------
步骤：
1: 去github上选择一个tag版本，我用的是2.1.0.
https://github.com/elastic/ela ... 2.1.0 
直接DownloadZip文件即可
（也可以用git clone下来）
解压缩。
假设目录为E:/elasticsearch-2.1.0
2: 编译源代码
cmd 打开命令行
进入源文件目录 E:/elasticsearch-2.1.0
执行 mvn package命令
这个时间段耗时比较长，当然也得根据网速情况。
会出现失败，大多是因为拉取不到依赖包。可以根据提示信息，手动去下载失败的jar，然后拷贝到本地repo对应的文件夹下边即可。
等出现build success信息的时候代表成功了。
可以到core/target目录下看到elasticsearch-2.1.0-SNAPSHOT.jar。
3:转为eclipse工程
可能习惯了eclipse工程，所以这里就直接用mvn转成了eclipse的工程，生成.classpath和.project文件。
进入core目录执行以下指令
mvn eclipse:eclipse
这一步也会消耗一些时间，通常的错误也是jar包下载不成功，根据终端打印的错误信息，把对应jar包直接下载下来，放到本地的repo对应目录下边即可，然后重新运行命令。直到成功。
之后，就会发现出现了.classpath和.project文件了。
然后打开eclipse 直接带入core中的工程即可。
4: 设置运行参数
打开刚刚导入成功的工程：
Run As----Run Configution---Args
设置ProgramArgument 为 start
设置VMArgument为 -Des.path.home=E:\elasticsearch-2.1.0\core\
完毕
-------
现在就就可以运行+调试了。

继续阅读 »
前端时间折腾了一下源码调试的问题，简单总结以下。
---------------------
调试环境是window（linux理论上通用）
用到的工具类：
1:mvn：https://maven.apache.org/
elasticsearch的源码是用mvn工具管理的，根据pom.xml来下载一些依赖包非常方便。
（当然也可以用gradle，由于不太熟悉，就没研究）
安装mvn，注意配置后环境变量即可。官方文档写的很明白。
最好自己修改一下mvn的setting.xml文件中的本地repo
<!-- localRepository
   | The path to the local repository maven will use to store artifacts.
   |
   | Default: ${user.home}/.m2/repository
  <localRepository>/path/to/local/repo</localRepository>
-->
我设置成了：
<localRepository>E:/m2/repository</localRepository>
mvn -v 测试以下
2:eclipse：编辑器，应用应该还比较广泛的。我用的最新版的mars。
（intellij idea据说这是一个很牛逼的编辑器，也是因为暂时不熟悉，还没研究）
----------------------
步骤：
1: 去github上选择一个tag版本，我用的是2.1.0.
https://github.com/elastic/ela ... 2.1.0 
直接DownloadZip文件即可
（也可以用git clone下来）
解压缩。
假设目录为E:/elasticsearch-2.1.0
2: 编译源代码
cmd 打开命令行
进入源文件目录 E:/elasticsearch-2.1.0
执行 mvn package命令
这个时间段耗时比较长，当然也得根据网速情况。
会出现失败，大多是因为拉取不到依赖包。可以根据提示信息，手动去下载失败的jar，然后拷贝到本地repo对应的文件夹下边即可。
等出现build success信息的时候代表成功了。
可以到core/target目录下看到elasticsearch-2.1.0-SNAPSHOT.jar。
3:转为eclipse工程
可能习惯了eclipse工程，所以这里就直接用mvn转成了eclipse的工程，生成.classpath和.project文件。
进入core目录执行以下指令
mvn eclipse:eclipse
这一步也会消耗一些时间，通常的错误也是jar包下载不成功，根据终端打印的错误信息，把对应jar包直接下载下来，放到本地的repo对应目录下边即可，然后重新运行命令。直到成功。
之后，就会发现出现了.classpath和.project文件了。
然后打开eclipse 直接带入core中的工程即可。
4: 设置运行参数
打开刚刚导入成功的工程：
Run As----Run Configution---Args
设置ProgramArgument 为 start
设置VMArgument为 -Des.path.home=E:\elasticsearch-2.1.0\core\
完毕
-------
现在就就可以运行+调试了。

收起阅读 »
 elasticsearch源码调试环境小结
jingkyks 发表于 : 2015-12-16 13:04 评论 (4)

Day9: Elasticsearch template的order

ELK Stack 在入门学习过程中，必然会碰到自己修改定制索引映射(mapping)乃至模板(template)的问题。
这时候，不少比较认真看 Logstash 文档的新用户会通过下面这段配置来制定自己的模板策略：
output {

    elasticsearch {

        host => "127.0.0.1"

        manage_template => true

        template => "/path/to/mytemplate"

        template_name => "myname"

    }

}

然而随后就发现，自己辛辛苦苦修改出来的模板，通过 curl -XGET 'http://127.0.0.1:9200/_template/myname' 看也确实上传成功了，但实际新数据索引创建出来，就是没生效！

这个原因是：Logstash 默认会上传一个名叫 logstash 的模板到 ES 里。如果你在使用上面这个配置之前，曾经运行过 Logstash（一般来说都会），那么 ES 里就已经存在这么一个模板了。你可以curl -XGET 'http://127.0.0.1:9200/_template/logstash' 验证。

这个时候，ES 里就变成有两个模板，logstash 和 myname，都匹配 logstash-* 索引名，要求设置一定的映射规则了。

ES 会按照一定的规则来尝试自动 merge 多个都匹配上了的模板规则，最终运用到索引上:https://www.elastic.co/guide/e ... lates

其中要点就是：template 是可以设置 order 参数的！而不写这个参数，默认的 order 值就是 0。order 值越大，在 merge 规则的时候优先级越高。

所以，解决这个问题的办法很简单：在你自定义的 template 里，加一行，变成这样：
{

    "template" : "logstash-*",

    "order" : 1,

    "settings" : { ... },

    "mappings" : { ... }

}
当然，其实如果只从 Logstash 配置角度出发，其实更简单的办法是：直接修改原来默认的 logstash 模板，然后模板名称也不要改，就好了：
output {

    elasticsearch {

        host => "127.0.0.1"

        manage_template => true

        template_overwrite => true

    }

}
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
继续阅读 »
ELK Stack 在入门学习过程中，必然会碰到自己修改定制索引映射(mapping)乃至模板(template)的问题。
这时候，不少比较认真看 Logstash 文档的新用户会通过下面这段配置来制定自己的模板策略：
output {

    elasticsearch {

        host => "127.0.0.1"

        manage_template => true

        template => "/path/to/mytemplate"

        template_name => "myname"

    }

}

然而随后就发现，自己辛辛苦苦修改出来的模板，通过 curl -XGET 'http://127.0.0.1:9200/_template/myname' 看也确实上传成功了，但实际新数据索引创建出来，就是没生效！

这个原因是：Logstash 默认会上传一个名叫 logstash 的模板到 ES 里。如果你在使用上面这个配置之前，曾经运行过 Logstash（一般来说都会），那么 ES 里就已经存在这么一个模板了。你可以curl -XGET 'http://127.0.0.1:9200/_template/logstash' 验证。

这个时候，ES 里就变成有两个模板，logstash 和 myname，都匹配 logstash-* 索引名，要求设置一定的映射规则了。

ES 会按照一定的规则来尝试自动 merge 多个都匹配上了的模板规则，最终运用到索引上:https://www.elastic.co/guide/e ... lates

其中要点就是：template 是可以设置 order 参数的！而不写这个参数，默认的 order 值就是 0。order 值越大，在 merge 规则的时候优先级越高。

所以，解决这个问题的办法很简单：在你自定义的 template 里，加一行，变成这样：
{

    "template" : "logstash-*",

    "order" : 1,

    "settings" : { ... },

    "mappings" : { ... }

}
当然，其实如果只从 Logstash 配置角度出发，其实更简单的办法是：直接修改原来默认的 logstash 模板，然后模板名称也不要改，就好了：
output {

    elasticsearch {

        host => "127.0.0.1"

        manage_template => true

        template_overwrite => true

    }

}
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
 template  advent
三斗室 发表于 : 2015-12-10 01:13 评论 (3)

大家一起来写Advent吧

三斗已经写了好多篇了，分享了很多小经验和知识，非常不错，不如我们一起把Advent玩起来吧，这样，我们玩一个接力游戏，每个同学写完之后可以@论坛里面的其它同学，被@的同学需要完成一篇小的Advent，然后写完再继续接着传给下一位，如果不在论坛的同学，就邀请他加入下 ：）
 
@的操作就是在贴子里@对方的名字，然后你想办法通知到对方就行了，QQ、论坛消息等等反正告诉对方被@和继续就行咯。
没有找到下一个接班的人就继续写下去。哈哈

写Advent，选择发表类型『文章』，分类选择『advent』，话题添加『advent』+其它的自选

下面是一篇ELK的Advent，顺便分享一下。Day 5 - ELK Operations and Administration
 
 欢迎补充完善规则。
 
继续阅读 »
三斗已经写了好多篇了，分享了很多小经验和知识，非常不错，不如我们一起把Advent玩起来吧，这样，我们玩一个接力游戏，每个同学写完之后可以@论坛里面的其它同学，被@的同学需要完成一篇小的Advent，然后写完再继续接着传给下一位，如果不在论坛的同学，就邀请他加入下 ：）
 
@的操作就是在贴子里@对方的名字，然后你想办法通知到对方就行了，QQ、论坛消息等等反正告诉对方被@和继续就行咯。
没有找到下一个接班的人就继续写下去。哈哈

写Advent，选择发表类型『文章』，分类选择『advent』，话题添加『advent』+其它的自选

下面是一篇ELK的Advent，顺便分享一下。Day 5 - ELK Operations and Administration
 
 欢迎补充完善规则。
  收起阅读 »
 advent
medcl 发表于 : 2015-12-09 17:57 评论 (0)

自建的索引没数据？

ELK的架构：
logstash==>redis==>logstash==>elasticsearch==>kibana开始我自己在ES上建索引，
建索引语句如下：
curl -XPUT "http://localhost:9200/qn-service&quot; -d '{"mappings":{"_default_":{"properties":{"speaker":{"type":"string","index":"not_analyzed"},"play_name":{"type":"string","index":"not_analyzed"},"line_id":{"type":"integer"},"speech_number":{"type":"integer"}}}}}'
然后通过logstash导数据到ES后，却发现查询不到数据，然后用
curl http://localhost:9200/_cat/indices?v  命令发现索引的数据为空；
C4A56AE5-0FC8-4008-92C8-EA3AB20580BC.png

发现es自动建的索引有数据，而我自己的索引数据为空。
找了半天原因没找到，然后就将es中得数据删除，
 curl -XDELETE *[/url]
用上述方法重建索引；
然后按照书上《ELK权威指南》上得方法，直接导入数据到es，
curl -XPUT http://localhost:9200/_bulk --data-binary @shakespeare.json
却发现自己建的索引还是没有数据，es却多了一个叫shakespeare得索引，这个索引中有数据，那么我有两点疑问1：为什么我用书上建索引的方法建立索引(shakespeare名字被我改成qn-service)却没有数据？
2：shakespeare这个索引是哪里来得？
 
logstash shipper.conf
input {
        file {
                path => ["/data/logs/superErpLog/trace/shakespeare.json"]
                start_position => "beginning"
                sincedb_path => "/dev/null"
        }
}
filter{
        json{
                source=>"message"
                remove_field => ["message"]
        }
}
output {
        stdout{}
        redis {
                host => "localhost"
                port => 6379
                data_type => "list"
                key => "performance"
        }
} 
logstash center.conf
input {
        redis {
                host => "localhost"
                port => 6379 
                type => "redis-input"
                data_type => "list"
                key => "performance"
        }   
}

output {
        stdout {}
        elasticsearch {
                cluster => "elasticsearch"
                host => "localhost"
                port => 9200
                codec => "json" 
                protocol => "http"
        }   
}
继续阅读 »
ELK的架构：
logstash==>redis==>logstash==>elasticsearch==>kibana开始我自己在ES上建索引，
建索引语句如下：
curl -XPUT "http://localhost:9200/qn-service&quot; -d '{"mappings":{"_default_":{"properties":{"speaker":{"type":"string","index":"not_analyzed"},"play_name":{"type":"string","index":"not_analyzed"},"line_id":{"type":"integer"},"speech_number":{"type":"integer"}}}}}'
然后通过logstash导数据到ES后，却发现查询不到数据，然后用
curl http://localhost:9200/_cat/indices?v  命令发现索引的数据为空；
C4A56AE5-0FC8-4008-92C8-EA3AB20580BC.png

发现es自动建的索引有数据，而我自己的索引数据为空。
找了半天原因没找到，然后就将es中得数据删除，
 curl -XDELETE *[/url]
用上述方法重建索引；
然后按照书上《ELK权威指南》上得方法，直接导入数据到es，
curl -XPUT http://localhost:9200/_bulk --data-binary @shakespeare.json
却发现自己建的索引还是没有数据，es却多了一个叫shakespeare得索引，这个索引中有数据，那么我有两点疑问1：为什么我用书上建索引的方法建立索引(shakespeare名字被我改成qn-service)却没有数据？
2：shakespeare这个索引是哪里来得？
 
logstash shipper.conf
input {
        file {
                path => ["/data/logs/superErpLog/trace/shakespeare.json"]
                start_position => "beginning"
                sincedb_path => "/dev/null"
        }
}
filter{
        json{
                source=>"message"
                remove_field => ["message"]
        }
}
output {
        stdout{}
        redis {
                host => "localhost"
                port => 6379
                data_type => "list"
                key => "performance"
        }
} 
logstash center.conf
input {
        redis {
                host => "localhost"
                port => 6379 
                type => "redis-input"
                data_type => "list"
                key => "performance"
        }   
}

output {
        stdout {}
        elasticsearch {
                cluster => "elasticsearch"
                host => "localhost"
                port => 9200
                codec => "json" 
                protocol => "http"
        }   
} 收起阅读 »
 custom  index
maxam0128 发表于 : 2015-12-09 16:40 评论 (4)

Day8：隐藏仪表盘的菜单栏

Kibana4 上线后，又有同事找过来。还好这次是小问题：『新版的这个仪表盘顶部菜单栏太宽了啊。头顶上监控屏幕空间有限，能不能省省？』

跟 Kibana3 相比，确实宽了点。这时候好几个方案瞬间进入我脑子里：
  1. 浏览器往下拖动一点，不过要确保定期刷新的时候还能回到拖动位置；
  2. 进 ui/public/chrome/chrome.html 里把 navbar 干掉；
  3. 添加一个 bootstrap 效果，navbar 默认隐藏，鼠标挪上去自动浮现。


不过等打开 chrome.html 看了一下，发现 navbar 本身是有相关的隐藏判断的：
<nav

  ng-style="::{ background: chrome.getNavBackground() }"

  ng-class="{ show: chrome.getVisible() }"

  class="hide navbar navbar-inverse navbar-static-top">
这个设置在 ui/public/chrome/api/angular.js 里的 internals.setVisibleDefault(!$location.search().embed);。我们知道 $locatio.search() 是 AngularJS 的标准用法，这里也就是代表 URL 请求参数里是否有 ?embed 选项。

好了，我们试一下，把 http://localhost:5601/app/kiba ... ydash 改成http://localhost:5601/app/kiba ... embed，回车，果然，整个菜单栏都消失了！同步消失的还有每个 panel 的编辑按钮。

其实呢，embed 在页面上是有说明的，在 dashboard 的 share 连接里，提供了一个 iframe 分享方式，iframe 里使用的，就是 embed 链接！

注意：Kibana4 部分版本的 share 说明中的 embed 位置生成的有问题，请小心。

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
继续阅读 »
Kibana4 上线后，又有同事找过来。还好这次是小问题：『新版的这个仪表盘顶部菜单栏太宽了啊。头顶上监控屏幕空间有限，能不能省省？』

跟 Kibana3 相比，确实宽了点。这时候好几个方案瞬间进入我脑子里：
  1. 浏览器往下拖动一点，不过要确保定期刷新的时候还能回到拖动位置；
  2. 进 ui/public/chrome/chrome.html 里把 navbar 干掉；
  3. 添加一个 bootstrap 效果，navbar 默认隐藏，鼠标挪上去自动浮现。


不过等打开 chrome.html 看了一下，发现 navbar 本身是有相关的隐藏判断的：
<nav

  ng-style="::{ background: chrome.getNavBackground() }"

  ng-class="{ show: chrome.getVisible() }"

  class="hide navbar navbar-inverse navbar-static-top">
这个设置在 ui/public/chrome/api/angular.js 里的 internals.setVisibleDefault(!$location.search().embed);。我们知道 $locatio.search() 是 AngularJS 的标准用法，这里也就是代表 URL 请求参数里是否有 ?embed 选项。

好了，我们试一下，把 http://localhost:5601/app/kiba ... ydash 改成http://localhost:5601/app/kiba ... embed，回车，果然，整个菜单栏都消失了！同步消失的还有每个 panel 的编辑按钮。

其实呢，embed 在页面上是有说明的，在 dashboard 的 share 连接里，提供了一个 iframe 分享方式，iframe 里使用的，就是 embed 链接！

注意：Kibana4 部分版本的 share 说明中的 embed 位置生成的有问题，请小心。

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
 advent
三斗室 发表于 : 2015-12-09 11:07 评论 (3)

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 示例：
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
其 pipeline 设计和 Logstash 不同的是：整个 filter 和 output 流程，都在 Kafka 的 consumer 线程中完成。所以，并发线程数完全是有 Kafka 的 partitions 设置来控制的。

实际运行下来，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 示例：
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
其 pipeline 设计和 Logstash 不同的是：整个 filter 和 output 流程，都在 Kafka 的 consumer 线程中完成。所以，并发线程数完全是有 Kafka 的 partitions 设置来控制的。

实际运行下来，hangout 比 Logstash 确实在处理能力，尤其是 CPU 资源消耗方面，性价比要高出很多。

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
 kafka  advent
三斗室 发表于 : 2015-12-08 00:54 评论 (2)

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 的状态：
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;

        }

    }

}
然后我们需要下面一段 Logstash 配置来定期获取这个数据：

input {

  http_poller {

    urls => {

      0 => {

        method => get

        url => "http://localhost:80/status/format/json&quot;

        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"

  }

}
这样，就可以每 60 秒，获得一次 vts 数据，并重置计数了。

注意，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 的状态：
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;

        }

    }

}
然后我们需要下面一段 Logstash 配置来定期获取这个数据：

input {

  http_poller {

    urls => {

      0 => {

        method => get

        url => "http://localhost:80/status/format/json&quot;

        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"

  }

}
这样，就可以每 60 秒，获得一次 vts 数据，并重置计数了。

注意，urls 是一个 Hash，所以他的执行顺序是根据 Hash.map 来的，为了确保我们是先获取数据再重置，这里干脆用 0, 1 来作为 Hash 的 key，这样顺序就没问题了。

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。 收起阅读 »
 beat  advent
三斗室 发表于 : 2015-12-07 00:18 评论 (0)

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 贴进搜索框里。内容是：
{

  "nested" : {

    "path" : "video_time_duration",

    "query" : {

      "match" : {

        "video_time_duration.type" : "1"

      }

    }

  }

}
意外发生了！Kibana4 竟然在页面上弹出一个错误提示，而且搜索栏的放大镜图标也变成不可以点击的灰色样式，敲回车同样没有反应：

当然我很确定我的数据是没问题的。这时候 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))
地址栏回车之后，页面刷新，看到搜索结果更新(如上图)！虽然搜索栏依然有报错，但实际上 nested query 生效了，我们在下面 search 里看到的都是成功过滤出来的『有过卡顿的视频播放记录』日志。

感谢 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 贴进搜索框里。内容是：
{

  "nested" : {

    "path" : "video_time_duration",

    "query" : {

      "match" : {

        "video_time_duration.type" : "1"

      }

    }

  }

}
意外发生了！Kibana4 竟然在页面上弹出一个错误提示，而且搜索栏的放大镜图标也变成不可以点击的灰色样式，敲回车同样没有反应：

当然我很确定我的数据是没问题的。这时候 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))
地址栏回车之后，页面刷新，看到搜索结果更新(如上图)！虽然搜索栏依然有报错，但实际上 nested query 生效了，我们在下面 search 里看到的都是成功过滤出来的『有过卡顿的视频播放记录』日志。

感谢 Kibana 如此开放的设计原则！

ps: 目前 nested aggregation 还没法像这样简单的绕过，不过已经有相关 pull request 在 review 中，或许 Kibana4.3/4.4 的时候就会合并了。有兴趣的同学，也可以跟我一样先睹为快哟：https://github.com/elastic/kibana/pull/5411

想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
  收起阅读 »
 advent
三斗室 发表于 : 2015-12-05 22:49 评论 (0)

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 哟。 收起阅读 »
 advent
三斗室 发表于 : 2015-12-05 12:13 评论 (0)

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 哟。 收起阅读 »
 advent
三斗室 发表于 : 2015-12-05 12:04 评论 (0)

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 哟。 收起阅读 »
 advent
三斗室 发表于 : 2015-12-05 12:00 评论 (0)

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 哟。 收起阅读 »
 advent
三斗室 发表于 : 2015-12-05 11:56 评论 (1)
Copyright © 2024 · CC BY-NC-SA 3.0

本站服务器及带宽由 提供赞助