Day3: 《创建一个你自己的 Beat》

Elastic Advent 第三篇, 手头上事情实在太多,这两天正在进行权威指南翻译的冲刺阶段,临时填下坑,翻译官网的一篇文章吧(原文:https://www.elastic.co/blog/build-your-own-beat),Advent 规则很自由的,没说不能翻译文章啊,嘿嘿嘿,另外号召大家踊跃报名,大家一起玩才有意思。
 
活动地址:http://elasticsearch.cn/article/107
 
言归正传!
 Beat 是一个开源的用来构建轻量级数据汇集的平台,可用于将各种类型的数据发送至Elasticsearch 与 Logstash。我们有 Packetbeat 用于监控局域网内服务器之间的网络流量信息,有 Filebeat 收集服务器上的日志信息,还有新推出的 Metricbeat 可以定期获取外部系统的监控指标信息,除此以外,你还可以非常方便的基于 libbeat 框架来构建你属于自己的专属 Beat,目前 beas 社区已经有超过25个 Community Beats 了。

Elastic 还提供一个 Beat generator(Beat 生成器)来帮你快速构建属于你自己的 Beat。通过这篇博客你将会看到如何通过 Beat 生成器来快速创建一个你自己的 Beat。今天我们创建的是一个叫做 lsbeat 的 Beat,lsbeat 非常类似 Unix 系统下的命令行 ls,我们用 lsbeat 来索引目录和文件信息。本篇文章环境基于 Unix 系统,如果你是 Windows 或是其它系统,相关操作可能需要根据实际情况进行调整。

第一步 – 配置 Golang 环境

Beats 是用 Golang写的,显然,要创建和开发一个 beat,Golang 环境必不可少,关于这方面的文章很多,建议查看这篇 Golang 的安装向导: install Golang。当前 Beats 需要的最低版本是 Golang 1.6。另外请确保正确设置了你的 $GOPATH 环境变量。

另外 Golang Glide 被用来进行包的依赖管理,所以也需要确保正确安装,最低版本是 Glide 0.10.0,安装说明点这里。

让我们先来看看 lsbeat 将会用到的一段代码吧,这是一个简单的 golang 程序,通过命令行接收一个目录参数,然后列出该目录下的文件和子目录信息。
package main

import (
"fmt"
"io/ioutil"
"os"
)

func main() {
//apply run path "." without argument.
if len(os.Args) == 1 {
listDir(".")
} else {
listDir(os.Args[1])
}
}

func listDir(dirFile string) {
files, _ := ioutil.ReadDir(dirFile)
for _, f := range files {
t := f.ModTime()
fmt.Println(f.Name(), dirFile+"/"+f.Name(), f.IsDir(), t, f.Size())

if f.IsDir() {
listDir(dirFile + "/" + f.Name())
}
}
}

后面我们将使用到这段代码和 listDir 函数。

第二步 – 生成项目

要生成一个你自己的 Beat,就要用到 beat-generator 了,首先你必须安装 cookiecutter。安装的详细说明看这里。安装好 cookiecutter 之后,我们要给自己的 Beat 起一个好听的名字,最好是小写的英文字母,我们今天这个例子就叫 lsbeat 吧。

生成项目模板之前,我们需要下载 Beats generator 包文件,就在 beats 仓库。安装好 GoLang 之后,你就可以很方便的使用 go get 命令来下载 Beats generator 包文件了。 当你执行下面的这个命令后,所有的源码文件都会下载到 $GOPATH/src 目录。
$ go get github.com/elastic/beats

在 GOPATH 下创建一个以你自己github账号名称命名的目录,并切换过去,然后执行 cookiecutter 命令并指向 Beat Generator 源码路径。
$ cd $GOPATH/src/github.com/{user}
$ cookiecutter $GOPATH/src/github.com/elastic/beats/generate/beat

Cookiecutter 接下来会问你几个问题,比如项目名称,我们输入:lsbeat;你的 github 用户名,输入你自己的 github 账户;还有两个关于beat和beat_path应该会自动识别,默认回车就好;最后的问题,你可以输入你的姓和名。
project_name [Examplebeat]: lsbeat
github_name [your-github-name]: {username}
beat [lsbeat]:
beat_path [github.com/{github id}]:
full_name [Firstname Lastname]: {Full Name}


现在应该已经创建好了一个名为 lsbeat 的目录,并且里面应该会生成一些文件,让我们一起来看一下吧,结构如下:
$ cd lsbeat
$ tree
.
├── CONTRIBUTING.md
├── LICENSE
├── Makefile
├── README.md
├── beater
│ └── lsbeat.go
├── config
│ ├── config.go
│ └── config_test.go
├── dev-tools
│ └── packer
│ ├── Makefile
│ ├── beats
│ │ └── lsbeat.yml
│ └── version.yml
├── docs
│ └── index.asciidoc
├── etc
│ ├── beat.yml
│ └── fields.yml
├── glide.yaml
├── lsbeat.template.json
├── main.go
├── main_test.go
└── tests
└── system
├── config
│ └── lsbeat.yml.j2
├── lsbeat.py
├── requirements.txt
└── test_base.py


我们刚刚已经生成好了一个原始的 Beat 模板了,但是你还需要获取相关的依赖和设置好 git 仓库。

首先,你需要拉取依赖的相关包信息,我们的这个例子是 lsbeat,我们先做一些的基本的配置,回头再看看详细看看其它的模板和配置文件,只需要执行 make setup 就可以自动获取依赖。
$ make setup


当你创建好了自己的 Beat 之后,记得上传到 github 仓库,并和社区进行分享哦,如下:


beats.png



要 push lsbeat 到你的 git 仓库,只需要执行如下命令:
$ git remote add origin git@github.com:{username}/lsbeat.git
$ git push -u origin master


恭喜你,现在你已经完成了一个 Beat ,并且发布了第一个版本到了 Github,不过里面还没有什么具体内容,现在让我们进一步看看里面的代码吧。

第四步 – 配置

执行过上面一系列命令之后,项目里将会自动创建名为 lsbeat.yml 和 lsbeat.template.json 的配置文件。所有的基本配置项都已经生成在了里面。
lsbeat.yml
lsbeat:
# Defines how often an event is sent to the output
period: 1s


Period 参数包含在每一个生成的 Beats 里面,它表示 lsbeat 将会每隔 1 秒钟轮询一次,这里我们修改 period 时间间隔为 10 秒。还可以在修改 etc/ 目录下面的 beat.yml 文件,这里新增一个 path 参数表示我们具体要监听哪个目录。
lsbeat:
# Defines how often an event is sent to the output
period: 10s
path: "."


参数添加好了之后,我们只需要运行 make update 命令就能让这些修改应用到配置文件lsbeat.yml。
$ make update
$ cat lsbeat.yml

################### Lsbeat Configuration Example #########################

############################# Lsbeat ######################################

lsbeat:
# Defines how often an event is sent to the output
period: 10s
path: "."
###############################################################################


修改完 yml 文件,记得修改 config/config.go文件,添加一个path 参数。
package config

import "time"

type Config struct {
Period time.Duration `config:"period"`
Path string `config:"path"`
}

var DefaultConfig = Config{
Period: 10 * time.Second,
Path: ".",
}


同时我们修改 period 默认时间间隔为 10 秒,默认监听的是当前目录 (.) 。.

第五步 – 添加代码

每一个 Beat 需要实现 Beater 接口,里面定义了 Run() 和 Stop() 函数。. 

我们可以定义一个名为 Lsbeat 的结构体,然后用这个对象实现 Beater 接口。然后添加字段 lastIndexTime 来保存最后运行的时间戳信息。
type Lsbeat struct {
done chan struct{}
config config.Config
client publisher.Client

lastIndexTime time.Time
...
}


另外,每个 Beat 还需要实现 New() 方法来接收 Beat 配置信息和返回 Lsbeat 的具体实例。
func New(b *beat.Beat, cfg *common.Config) (beat.Beater, error) {
config := config.DefaultConfig
if err := cfg.Unpack(&config); err != nil {
return nil, fmt.Errorf("Error reading config file: %v", err)
}

ls := &Lsbeat{
done: make(chan struct{}),
config: config,
}
return ls, nil
}


在我们的 lsbeat 例子中,我们要做的就是扩展默认的 Run() 函数来导出指定目录的文件和子目录信息。

在修改 Run() 函数之前,我们先在 lsbeat.go 增加 listDir() 函数,就是我们前面最开始测试的那段代码,用于收集目录和文件信息的简单例子稍微修改一下。另外我们还要生成以下字段信息:
"@timestamp": common.Time(time.Now()),
"type": beatname,
"modtime": common.Time(t),
"filename": f.Name(),
"path": dirFile + "/" + f.Name(),
"directory": f.IsDir(),
"filesize": f.Size(),


第一次运行的时候我们将索引所有的文件和目录信息,然后我们再定期检查是否有新文件被创建或者修改,再索引这些新创建的文件和目录。每次定期检查的时间戳都会保存在 lasIndexTime 变量,完整代码如下:
func (bt *Lsbeat) listDir(dirFile string, beatname string, init bool) {
files, _ := ioutil.ReadDir(dirFile)
for _, f := range files {
t := f.ModTime()

event := common.MapStr{
"@timestamp": common.Time(time.Now()),
"type": beatname,
"modtime": common.Time(t),
"filename": f.Name(),
"path": dirFile + "/" + f.Name(),
"directory": f.IsDir(),
"filesize": f.Size(),
}
if init {
// index all files and directories on init
bt.client.PublishEvent(event)
} else {
// Index only changed files since last run.
if t.After(bt.lastIndexTime) {
bt.client.PublishEvent(event)
}
}

if f.IsDir() {
bt.listDir(dirFile+"/"+f.Name(), beatname, init)
}
}
}


记住在最开始需要导入 “io/ioutil” 包。
import (
"fmt"
"io/ioutil"
"time"
)


现在,让我们看看如何在 Run() 函数里面调用 listDir() 函数,并且保存时间戳到 lasIndexTime 变量。
func (bt *Lsbeat) Run(b *beat.Beat) error {
logp.Info("lsbeat is running! Hit CTRL-C to stop it.")

bt.client = b.Publisher.Connect()
ticker := time.NewTicker(bt.config.Period)
counter := 1
for {

select {
case <-bt.done:
return nil
case <-ticker.C:
}

bt.listDir(bt.config.Path, b.Name, true) // call lsDir
bt.lastIndexTime = time.Now() // mark Timestamp

logp.Info("Event sent")
counter++
}

}


函数 Stop() 用来中断 run 的循环执行,保持默认生成的就行。
func (bt *Lsbeat) Stop() {
bt.client.Close()
close(bt.done)
}


到这里,编码部分基本就完成了。我们接下来添加新字段到 mapping 中,修改文件 etc/fields.yml。.
- key: lsbeat
title: LS Beat
description:
fields:
- name: counter
type: integer
required: true
description: >
PLEASE UPDATE DOCUMENTATION
#new fiels added lsbeat
- name: modtime
type: date
- name: filename
type: text
- name: path
- name: directory
type: boolean
- name: filesize
type: long


重新应用新的配置。

$ make update

字段 file_name 将使用 nGram 分词,我们还需要在文件 lsbeat.template.json 的 “settings” 节点添加一个自定义的 analyzer。
{
"mappings": {
...
},
"order": 0,
"settings": {
"index.refresh_interval": "5s",
"analysis": {
"analyzer": {
"ls_ngram_analyzer": {
"tokenizer": "ls_ngram_tokenizer"
}
},
"tokenizer": {
"ls_ngram_tokenizer": {
"type": "ngram",
"min_gram": "2",
"token_chars": [
"letter",
"digit"
]
}
}
}
},
"template": "lsbeat-*"
}


第六步 – 编译和运行

现在我们可以编译和运行了,只需要执行 make 命令就可以编译出可执行文件 lsbeat (lsbeat.exe on windows) 。

$ make

修改 lsbeat.yml 文件,设置需要监听的目录,如: “/Users/ec2-user/go”,记住是全路径。
lsbeat:
# Defines how often an event is sent to the output
period: 10s
path: "/Users/ec2-user/go"

同时确保你的 elasticsearch 和 kibana 正常运行。现在运行一下 lsbeat 命令看看会发生什么事情吧。

$ ./lsbeat

打开Kibana,通过调用 _cat 接口我们看看的索引是不是创建了。

beats-1.png


可以看到创建了一个名为 lsbeat-2016.06.03 的索引,并且看到已经有了一些文档了。现在对 filename 字段查询一下,由于使用的是 nGram 分词,支持模糊匹配,我们使用 lsbe 关键字搜一下。

beats-2.png


大功告成! 恭喜你,你已经完成了第一个属于你自己的 beat。
继续阅读 »
Elastic Advent 第三篇, 手头上事情实在太多,这两天正在进行权威指南翻译的冲刺阶段,临时填下坑,翻译官网的一篇文章吧(原文:https://www.elastic.co/blog/build-your-own-beat),Advent 规则很自由的,没说不能翻译文章啊,嘿嘿嘿,另外号召大家踊跃报名,大家一起玩才有意思。
 
活动地址:http://elasticsearch.cn/article/107
 
言归正传!
 Beat 是一个开源的用来构建轻量级数据汇集的平台,可用于将各种类型的数据发送至Elasticsearch 与 Logstash。我们有 Packetbeat 用于监控局域网内服务器之间的网络流量信息,有 Filebeat 收集服务器上的日志信息,还有新推出的 Metricbeat 可以定期获取外部系统的监控指标信息,除此以外,你还可以非常方便的基于 libbeat 框架来构建你属于自己的专属 Beat,目前 beas 社区已经有超过25个 Community Beats 了。

Elastic 还提供一个 Beat generator(Beat 生成器)来帮你快速构建属于你自己的 Beat。通过这篇博客你将会看到如何通过 Beat 生成器来快速创建一个你自己的 Beat。今天我们创建的是一个叫做 lsbeat 的 Beat,lsbeat 非常类似 Unix 系统下的命令行 ls,我们用 lsbeat 来索引目录和文件信息。本篇文章环境基于 Unix 系统,如果你是 Windows 或是其它系统,相关操作可能需要根据实际情况进行调整。

第一步 – 配置 Golang 环境

Beats 是用 Golang写的,显然,要创建和开发一个 beat,Golang 环境必不可少,关于这方面的文章很多,建议查看这篇 Golang 的安装向导: install Golang。当前 Beats 需要的最低版本是 Golang 1.6。另外请确保正确设置了你的 $GOPATH 环境变量。

另外 Golang Glide 被用来进行包的依赖管理,所以也需要确保正确安装,最低版本是 Glide 0.10.0,安装说明点这里。

让我们先来看看 lsbeat 将会用到的一段代码吧,这是一个简单的 golang 程序,通过命令行接收一个目录参数,然后列出该目录下的文件和子目录信息。
package main

import (
"fmt"
"io/ioutil"
"os"
)

func main() {
//apply run path "." without argument.
if len(os.Args) == 1 {
listDir(".")
} else {
listDir(os.Args[1])
}
}

func listDir(dirFile string) {
files, _ := ioutil.ReadDir(dirFile)
for _, f := range files {
t := f.ModTime()
fmt.Println(f.Name(), dirFile+"/"+f.Name(), f.IsDir(), t, f.Size())

if f.IsDir() {
listDir(dirFile + "/" + f.Name())
}
}
}

后面我们将使用到这段代码和 listDir 函数。

第二步 – 生成项目

要生成一个你自己的 Beat,就要用到 beat-generator 了,首先你必须安装 cookiecutter。安装的详细说明看这里。安装好 cookiecutter 之后,我们要给自己的 Beat 起一个好听的名字,最好是小写的英文字母,我们今天这个例子就叫 lsbeat 吧。

生成项目模板之前,我们需要下载 Beats generator 包文件,就在 beats 仓库。安装好 GoLang 之后,你就可以很方便的使用 go get 命令来下载 Beats generator 包文件了。 当你执行下面的这个命令后,所有的源码文件都会下载到 $GOPATH/src 目录。
$ go get github.com/elastic/beats

在 GOPATH 下创建一个以你自己github账号名称命名的目录,并切换过去,然后执行 cookiecutter 命令并指向 Beat Generator 源码路径。
$ cd $GOPATH/src/github.com/{user}
$ cookiecutter $GOPATH/src/github.com/elastic/beats/generate/beat

Cookiecutter 接下来会问你几个问题,比如项目名称,我们输入:lsbeat;你的 github 用户名,输入你自己的 github 账户;还有两个关于beat和beat_path应该会自动识别,默认回车就好;最后的问题,你可以输入你的姓和名。
project_name [Examplebeat]: lsbeat
github_name [your-github-name]: {username}
beat [lsbeat]:
beat_path [github.com/{github id}]:
full_name [Firstname Lastname]: {Full Name}


现在应该已经创建好了一个名为 lsbeat 的目录,并且里面应该会生成一些文件,让我们一起来看一下吧,结构如下:
$ cd lsbeat
$ tree
.
├── CONTRIBUTING.md
├── LICENSE
├── Makefile
├── README.md
├── beater
│ └── lsbeat.go
├── config
│ ├── config.go
│ └── config_test.go
├── dev-tools
│ └── packer
│ ├── Makefile
│ ├── beats
│ │ └── lsbeat.yml
│ └── version.yml
├── docs
│ └── index.asciidoc
├── etc
│ ├── beat.yml
│ └── fields.yml
├── glide.yaml
├── lsbeat.template.json
├── main.go
├── main_test.go
└── tests
└── system
├── config
│ └── lsbeat.yml.j2
├── lsbeat.py
├── requirements.txt
└── test_base.py


我们刚刚已经生成好了一个原始的 Beat 模板了,但是你还需要获取相关的依赖和设置好 git 仓库。

首先,你需要拉取依赖的相关包信息,我们的这个例子是 lsbeat,我们先做一些的基本的配置,回头再看看详细看看其它的模板和配置文件,只需要执行 make setup 就可以自动获取依赖。
$ make setup


当你创建好了自己的 Beat 之后,记得上传到 github 仓库,并和社区进行分享哦,如下:


beats.png



要 push lsbeat 到你的 git 仓库,只需要执行如下命令:
$ git remote add origin git@github.com:{username}/lsbeat.git
$ git push -u origin master


恭喜你,现在你已经完成了一个 Beat ,并且发布了第一个版本到了 Github,不过里面还没有什么具体内容,现在让我们进一步看看里面的代码吧。

第四步 – 配置

执行过上面一系列命令之后,项目里将会自动创建名为 lsbeat.yml 和 lsbeat.template.json 的配置文件。所有的基本配置项都已经生成在了里面。
lsbeat.yml
lsbeat:
# Defines how often an event is sent to the output
period: 1s


Period 参数包含在每一个生成的 Beats 里面,它表示 lsbeat 将会每隔 1 秒钟轮询一次,这里我们修改 period 时间间隔为 10 秒。还可以在修改 etc/ 目录下面的 beat.yml 文件,这里新增一个 path 参数表示我们具体要监听哪个目录。
lsbeat:
# Defines how often an event is sent to the output
period: 10s
path: "."


参数添加好了之后,我们只需要运行 make update 命令就能让这些修改应用到配置文件lsbeat.yml。
$ make update
$ cat lsbeat.yml

################### Lsbeat Configuration Example #########################

############################# Lsbeat ######################################

lsbeat:
# Defines how often an event is sent to the output
period: 10s
path: "."
###############################################################################


修改完 yml 文件,记得修改 config/config.go文件,添加一个path 参数。
package config

import "time"

type Config struct {
Period time.Duration `config:"period"`
Path string `config:"path"`
}

var DefaultConfig = Config{
Period: 10 * time.Second,
Path: ".",
}


同时我们修改 period 默认时间间隔为 10 秒,默认监听的是当前目录 (.) 。.

第五步 – 添加代码

每一个 Beat 需要实现 Beater 接口,里面定义了 Run() 和 Stop() 函数。. 

我们可以定义一个名为 Lsbeat 的结构体,然后用这个对象实现 Beater 接口。然后添加字段 lastIndexTime 来保存最后运行的时间戳信息。
type Lsbeat struct {
done chan struct{}
config config.Config
client publisher.Client

lastIndexTime time.Time
...
}


另外,每个 Beat 还需要实现 New() 方法来接收 Beat 配置信息和返回 Lsbeat 的具体实例。
func New(b *beat.Beat, cfg *common.Config) (beat.Beater, error) {
config := config.DefaultConfig
if err := cfg.Unpack(&config); err != nil {
return nil, fmt.Errorf("Error reading config file: %v", err)
}

ls := &Lsbeat{
done: make(chan struct{}),
config: config,
}
return ls, nil
}


在我们的 lsbeat 例子中,我们要做的就是扩展默认的 Run() 函数来导出指定目录的文件和子目录信息。

在修改 Run() 函数之前,我们先在 lsbeat.go 增加 listDir() 函数,就是我们前面最开始测试的那段代码,用于收集目录和文件信息的简单例子稍微修改一下。另外我们还要生成以下字段信息:
"@timestamp": common.Time(time.Now()),
"type": beatname,
"modtime": common.Time(t),
"filename": f.Name(),
"path": dirFile + "/" + f.Name(),
"directory": f.IsDir(),
"filesize": f.Size(),


第一次运行的时候我们将索引所有的文件和目录信息,然后我们再定期检查是否有新文件被创建或者修改,再索引这些新创建的文件和目录。每次定期检查的时间戳都会保存在 lasIndexTime 变量,完整代码如下:
func (bt *Lsbeat) listDir(dirFile string, beatname string, init bool) {
files, _ := ioutil.ReadDir(dirFile)
for _, f := range files {
t := f.ModTime()

event := common.MapStr{
"@timestamp": common.Time(time.Now()),
"type": beatname,
"modtime": common.Time(t),
"filename": f.Name(),
"path": dirFile + "/" + f.Name(),
"directory": f.IsDir(),
"filesize": f.Size(),
}
if init {
// index all files and directories on init
bt.client.PublishEvent(event)
} else {
// Index only changed files since last run.
if t.After(bt.lastIndexTime) {
bt.client.PublishEvent(event)
}
}

if f.IsDir() {
bt.listDir(dirFile+"/"+f.Name(), beatname, init)
}
}
}


记住在最开始需要导入 “io/ioutil” 包。
import (
"fmt"
"io/ioutil"
"time"
)


现在,让我们看看如何在 Run() 函数里面调用 listDir() 函数,并且保存时间戳到 lasIndexTime 变量。
func (bt *Lsbeat) Run(b *beat.Beat) error {
logp.Info("lsbeat is running! Hit CTRL-C to stop it.")

bt.client = b.Publisher.Connect()
ticker := time.NewTicker(bt.config.Period)
counter := 1
for {

select {
case <-bt.done:
return nil
case <-ticker.C:
}

bt.listDir(bt.config.Path, b.Name, true) // call lsDir
bt.lastIndexTime = time.Now() // mark Timestamp

logp.Info("Event sent")
counter++
}

}


函数 Stop() 用来中断 run 的循环执行,保持默认生成的就行。
func (bt *Lsbeat) Stop() {
bt.client.Close()
close(bt.done)
}


到这里,编码部分基本就完成了。我们接下来添加新字段到 mapping 中,修改文件 etc/fields.yml。.
- key: lsbeat
title: LS Beat
description:
fields:
- name: counter
type: integer
required: true
description: >
PLEASE UPDATE DOCUMENTATION
#new fiels added lsbeat
- name: modtime
type: date
- name: filename
type: text
- name: path
- name: directory
type: boolean
- name: filesize
type: long


重新应用新的配置。

$ make update

字段 file_name 将使用 nGram 分词,我们还需要在文件 lsbeat.template.json 的 “settings” 节点添加一个自定义的 analyzer。
{
"mappings": {
...
},
"order": 0,
"settings": {
"index.refresh_interval": "5s",
"analysis": {
"analyzer": {
"ls_ngram_analyzer": {
"tokenizer": "ls_ngram_tokenizer"
}
},
"tokenizer": {
"ls_ngram_tokenizer": {
"type": "ngram",
"min_gram": "2",
"token_chars": [
"letter",
"digit"
]
}
}
}
},
"template": "lsbeat-*"
}


第六步 – 编译和运行

现在我们可以编译和运行了,只需要执行 make 命令就可以编译出可执行文件 lsbeat (lsbeat.exe on windows) 。

$ make

修改 lsbeat.yml 文件,设置需要监听的目录,如: “/Users/ec2-user/go”,记住是全路径。
lsbeat:
# Defines how often an event is sent to the output
period: 10s
path: "/Users/ec2-user/go"

同时确保你的 elasticsearch 和 kibana 正常运行。现在运行一下 lsbeat 命令看看会发生什么事情吧。

$ ./lsbeat

打开Kibana,通过调用 _cat 接口我们看看的索引是不是创建了。

beats-1.png


可以看到创建了一个名为 lsbeat-2016.06.03 的索引,并且看到已经有了一些文档了。现在对 filename 字段查询一下,由于使用的是 nGram 分词,支持模糊匹配,我们使用 lsbe 关键字搜一下。

beats-2.png


大功告成! 恭喜你,你已经完成了第一个属于你自己的 beat。 收起阅读 »

开源一组ES工具包,请大家帮忙宣传下,谢谢

wES
https://github.com/DataSays/wES/ 

wES 是一组开源的Java ElasticSearch客户端和工具; 简洁但是很勥 :)
wES = Java Retrofit2/OkHttp版本的客户端(不依赖Json类库,高度可定制) + 工具包 + spring-boot demo + 常用的ElasticSearch环境Dockerfile

wES 模块
wES 分割成许多模块, 可以按需选择.
wUtil: 一些有用的帮助类和工具类.
wES-client: 一个基于Retrofit2/OkHttp的Java客户端, 她是基于官方的ElasticSearch Rest API规范生成的. 她包含两种访问ElasticSearch的实现: OkHttp3版本的和Retrofit2版本. 而且她只依赖okhttp3/retrofit2,并且可以通过实现org.datasays.wes.core.IConvert接口支持任意一种Java Json类库. 你可以按照你的想法使用她.
wES-toolkit: 一些使用wES-client和ElasticSearch的工具包. 她包含了一套基于Gson的标准IConvert实现及封装代码库.
wES-demo: 一个Spring-boot + Vue.js的web应用, 用于展示一些通用的ElasticSearch使用场景.
wES-docker: 一些构建ElasticSearch开发/生产环境的常用Dockerfiles和shell脚本.

 
继续阅读 »
https://github.com/DataSays/wES/ 

wES 是一组开源的Java ElasticSearch客户端和工具; 简洁但是很勥 :)
wES = Java Retrofit2/OkHttp版本的客户端(不依赖Json类库,高度可定制) + 工具包 + spring-boot demo + 常用的ElasticSearch环境Dockerfile

wES 模块
wES 分割成许多模块, 可以按需选择.
wUtil: 一些有用的帮助类和工具类.
wES-client: 一个基于Retrofit2/OkHttp的Java客户端, 她是基于官方的ElasticSearch Rest API规范生成的. 她包含两种访问ElasticSearch的实现: OkHttp3版本的和Retrofit2版本. 而且她只依赖okhttp3/retrofit2,并且可以通过实现org.datasays.wes.core.IConvert接口支持任意一种Java Json类库. 你可以按照你的想法使用她.
wES-toolkit: 一些使用wES-client和ElasticSearch的工具包. 她包含了一套基于Gson的标准IConvert实现及封装代码库.
wES-demo: 一个Spring-boot + Vue.js的web应用, 用于展示一些通用的ElasticSearch使用场景.
wES-docker: 一些构建ElasticSearch开发/生产环境的常用Dockerfiles和shell脚本.

  收起阅读 »

Day2:《Kibana 系漫游指南》

大家好,欢迎你们来到 ELK 三体星系的第二天。昨天,wood 送给大家一本脚踏实地的生存指南,今天让我们仰望星空,由我给大家介绍一下围绕在 Kibana 身边的诸多行星们~

Kibana Plugin 类型简介

我们最熟悉的 Kibana Plugin,其实就是 Kibana 本身~ Kibana 提供了一整套框架,我们可以在此基础上,开发诸多不同类型的插件,包括:
  • app
  • visTypes
  • spyModes
  • fieldFormatter


列这么几个源码里的名词出来可能大家觉得比较晦涩。其实呢,app 就是同时具有前后端实现的应用,在 Kibana 5 里,默认分发的 app 有四个:实现日志查询和可视化的 kibana app、实现时序指标统计和可视化的 timelion app、实现和 ES 接口交互命令的 console app、在有异常的时候才看得到的状态页面 status_page app。

而 visTypes 则是在 kibana 中具体可用的可视化效果。默认分发的有:kbn_vislib_vis_types、metric、table、markdown。我们常用的那些由 D3.js 完成的饼图线图地图,都是在 kbn_vislib_vis_types 中完成的。

fieldFormatter 则用来定义在 ES 中相同类型的数据,根据其实际含义,可以有不同的展示方式。比如说:URL 肯定是一个字符串,但是可以用 fieldFormatter 把它在页面展示的时候,加上 `<a href></a>` 的样式,让人一键点击;同理,还可以过滤判断一下图片类 URL,加上 `<img src></img>` 的样式,直接在 Kibana 界面上就看图片内容~~

官方的我们会看手册啦~

好啦好啦,我也不会真的去抄一把官方手册假冒《Kibana 系漫游指南》来骗你们流量的。下面给大家介绍一些社区开源的,让你绝对眼前一亮的各种新奇扩展:

1. logtrail
    这是一个 app 插件,创意来自 papertrail 公司的产品。完全的满足了 Geeker 们喜欢黑底白字终端的癖好~不过其实实现非常简单:每隔 10 秒请求一次最近 500 条日志就是啦!

2. vectormap
    这是一个 visType 插件,也就是我们在 Kibana3 里曾经用过的 map panel 效果。这个插件不被官方直接采用的一个原因是版权许可问题。不做商用的情况下,这个插件还是可以极大方便我们做行政区域的访问情况统计和展示的。
    
3. kbn_network
    这也是一个 visType 插件,酷毙了的网状图效果!通过不同的 aggs 数据展示 node 和 relational。
    注意这个跟 Elastic 的 graph 并不是完全一致的东西。该插件要求你本身的数据已经有直接的关联可用。
    
4. sentinl
    这是一个同时带有 spyMode 和 app 双插件的项目。其基础思路是参照 Elastic 的 Watcher 接口,但是将监控告警的进程从 ES 挪到 Kibana 里。同时还可以通过 phantomjs 做到截图报表。
    
    这个项目最大的特点,是通过 spyMode 插件,大大降低了配置告警规则的复杂度。这个扩展让你可以在 Kibana 上配置任意聚合效果之后,就地点击定义当前聚合语句为告警规则!
    
5. kibana-keynote
    这是另一个剑走偏锋的 app 插件,出自 Kibana 作者本人之手。它的作用是:播放 keynote 演讲稿!事实上项目里放的演讲稿就是作者本人在 ELastic{ON} 2016 上用的。让我们猜一猜下周的大会上,他会不会就用这个插件给我们分享呢?

今天就先讲这几颗最闪亮的星了~有兴趣了解更多 Kibana 行星的游客,欢迎阅读全本《Kibana系漫游指南》

也欢迎观看 Kibana 行星的《探索·发现》节目哟~
继续阅读 »
大家好,欢迎你们来到 ELK 三体星系的第二天。昨天,wood 送给大家一本脚踏实地的生存指南,今天让我们仰望星空,由我给大家介绍一下围绕在 Kibana 身边的诸多行星们~

Kibana Plugin 类型简介

我们最熟悉的 Kibana Plugin,其实就是 Kibana 本身~ Kibana 提供了一整套框架,我们可以在此基础上,开发诸多不同类型的插件,包括:
  • app
  • visTypes
  • spyModes
  • fieldFormatter


列这么几个源码里的名词出来可能大家觉得比较晦涩。其实呢,app 就是同时具有前后端实现的应用,在 Kibana 5 里,默认分发的 app 有四个:实现日志查询和可视化的 kibana app、实现时序指标统计和可视化的 timelion app、实现和 ES 接口交互命令的 console app、在有异常的时候才看得到的状态页面 status_page app。

而 visTypes 则是在 kibana 中具体可用的可视化效果。默认分发的有:kbn_vislib_vis_types、metric、table、markdown。我们常用的那些由 D3.js 完成的饼图线图地图,都是在 kbn_vislib_vis_types 中完成的。

fieldFormatter 则用来定义在 ES 中相同类型的数据,根据其实际含义,可以有不同的展示方式。比如说:URL 肯定是一个字符串,但是可以用 fieldFormatter 把它在页面展示的时候,加上 `<a href></a>` 的样式,让人一键点击;同理,还可以过滤判断一下图片类 URL,加上 `<img src></img>` 的样式,直接在 Kibana 界面上就看图片内容~~

官方的我们会看手册啦~

好啦好啦,我也不会真的去抄一把官方手册假冒《Kibana 系漫游指南》来骗你们流量的。下面给大家介绍一些社区开源的,让你绝对眼前一亮的各种新奇扩展:

1. logtrail
    这是一个 app 插件,创意来自 papertrail 公司的产品。完全的满足了 Geeker 们喜欢黑底白字终端的癖好~不过其实实现非常简单:每隔 10 秒请求一次最近 500 条日志就是啦!

2. vectormap
    这是一个 visType 插件,也就是我们在 Kibana3 里曾经用过的 map panel 效果。这个插件不被官方直接采用的一个原因是版权许可问题。不做商用的情况下,这个插件还是可以极大方便我们做行政区域的访问情况统计和展示的。
    
3. kbn_network
    这也是一个 visType 插件,酷毙了的网状图效果!通过不同的 aggs 数据展示 node 和 relational。
    注意这个跟 Elastic 的 graph 并不是完全一致的东西。该插件要求你本身的数据已经有直接的关联可用。
    
4. sentinl
    这是一个同时带有 spyMode 和 app 双插件的项目。其基础思路是参照 Elastic 的 Watcher 接口,但是将监控告警的进程从 ES 挪到 Kibana 里。同时还可以通过 phantomjs 做到截图报表。
    
    这个项目最大的特点,是通过 spyMode 插件,大大降低了配置告警规则的复杂度。这个扩展让你可以在 Kibana 上配置任意聚合效果之后,就地点击定义当前聚合语句为告警规则!
    
5. kibana-keynote
    这是另一个剑走偏锋的 app 插件,出自 Kibana 作者本人之手。它的作用是:播放 keynote 演讲稿!事实上项目里放的演讲稿就是作者本人在 ELastic{ON} 2016 上用的。让我们猜一猜下周的大会上,他会不会就用这个插件给我们分享呢?

今天就先讲这几颗最闪亮的星了~有兴趣了解更多 Kibana 行星的游客,欢迎阅读全本《Kibana系漫游指南》

也欢迎观看 Kibana 行星的《探索·发现》节目哟~ 收起阅读 »

Day1: 大规模Elasticsearch集群管理心得

ElasticSearch目前在互联网公司主要用于两种应用场景,其一是用于构建业务的搜索功能模块且多是垂直领域的搜索,数据量级一般在千万至数十亿这个级别;其二用于大规模数据的实时OLAP,经典的如ELKStack,数据规模可能达到千亿或更多。 这两种场景的数据索引和应用访问模式上差异较大,在硬件选型和集群优化方面侧重点也会有所不同。一般来说后一种场景属于大数据范畴,数据量级和集群规模更大,在管理方面也更有挑战。

应Medcl大大的邀请,为ES中文社区做今年的Advent开篇,分享一下我在管理自家公司用于日志分析的ES集群方面的一点心得,蜻蜓点水,泛泛而谈,希望大方向上能对大家提供一些帮助。

这里的自家,即是携程旅行网。从2013年开始接触ES,我们团队先后实践过0.9.x -> 5.0.0中间各个版本,从最初只用于运维内部IIS日志的分析,到如今支持IT、呼叫中心、安全、测试、业务研发等多个部门超过200种日志型数据的实时检索与分析。 一路走来,愉悦了大家,也死磕了自己。

目前我们最大的日志单集群有120个data node,运行于70台物理服务器上。数据规模如下:
  • 单日索引数据条数600亿,新增索引文件25TB (含一个复制片则为50TB)
  • 业务高峰期峰值索引速率维持在百万条/秒
  • 历史数据保留时长根据业务需求制定,从10天 - 90天不等
  • 集群共3441个索引、17000个分片、数据总量约9300亿, 磁盘总消耗1PB
  • Kibana用户600多人, 每日来自Kibana和第三方的API调用共63万次
  • 查询响应时间百分位 75%:0.160s  90%:1.640s 95%:6.691s 99%:14.0039s


运维这样大规模的ES集群,有哪些值得注意的地方?

一. 必不可少的工具
工欲善其事必先利其器,从一开始,哪怕就只有几个node,就应该使用分布式配置管理工具来做集群的部署。随着应用的成熟,集群规模的逐步扩大,效率的提升会凸显。 官方提供了ES Puppet Module和Chef Cookbook,熟悉这两个工具的同学可以直接拿过来用。 我们自己则是采用的Ansible,编写了一套Playbook来达到类似的效果。 用熟这类工具,对于集群的初始部署,配置批量更改,集群版本升级,重启故障结点都会快捷和安全许多。
第二个必备利器就是sense插件。通过这个插件直接调用集群的restful API,在做集群和索引的状态查看,索引配置更改的时候非常方便。语法提示和自动补全功能更是实用,减少了翻看文档的频率。在Kibana5里面,sense已经成为一个内置的控制台,无需额外安装。

二. 硬件配置
我们采用的是32vcoreCPU + 128GB RAM的服务器,磁盘配置大部分服务器是12块4TB SATA机械磁盘做的Raid0,少部分机器是刚上了不久的6块800GB SSD raid0,主要目的是想做冷热数据分离,后面谈到集群架构的时候,再进一步解释一下如何利用硬件资源。

三. 集群的管理
  1. 首先很有必要对ES的结点做角色划分和隔离。大家知道ES的data node除了放数据以外,也可以兼任master和client的角色,多数同学会将这些角色混入到data node。然而对于一个规模较大,用户较多的集群,master和client在一些极端使用情况下可能会有性能瓶颈甚至内存溢出,从而使得共存的data node故障。data node的故障恢复涉及到数据的迁移,对集群资源有一定消耗,容易造成数据写入延迟或者查询减慢。如果将master和client独立出来,一旦出现问题,重启后几乎是瞬间就恢复的,对用户几乎没有任何影响。另外将这些角色独立出来的以后,也将对应的计算资源消耗从data node剥离出来,更容易掌握data node资源消耗与写入量和查询量之间的联系,便于做容量管理和规划。
  2. 避免过高的并发,包括控制shard数量和threadpool的数量。在写入量和查询性能能够满足的前提下,为索引分配尽量少的分片。分片过多会带来诸多负面影响,例如:每次查询后需要汇总排序的数据更多;过多的并发带来的线程切换造成过多的CPU损耗;索引的删除和配置更新更慢Issue#18776; 过多的shard也带来更多小的segment,而过多的小segment会带来非常显著的heap内存消耗,特别是如果查询线程配置得很多的情况下。 配置过大的threadpool更是会产生很多诡异的性能问题Issue#18161里所描述的问题就是我们所经历过的。 默认的Theadpool大小一般来说工作得很不错了。
  3. 冷热数据最好做分离。对于日志型应用来说,一般是每天建立一个新索引,当天的热索引在写入的同时也会有较多的查询。如果上面还存有比较长时间之前的冷数据,那么当用户做大跨度的历史数据查询的时候,过多的磁盘IO和CPU消耗很容易拖慢写入,造成数据的延迟。所以我们用了一部分机器来做冷数据的存储,利用ES可以给结点配置自定义属性的功能,为冷结点加上"boxtype":"weak"的标识,每晚通过维护脚本更新冷数据的索引路由设置index.routing.allocation.{require|include|exclude},让数据自动向冷结点迁移。 冷数据的特性是不再写入,用户查的频率较低,但量级可能很大。比如我们有个索引每天2TB,并且用户要求保持过去90天数据随时可查。保持这么大量的索引为open状态,并非只消耗磁盘空间。ES为了快速访问磁盘上的索引文件,需要在内存里驻留一些数据(索引文件的索引),也就是所谓的segment memory。稍微熟悉ES的同学知道,JVM heap分配不能超过32GB,对于我们128GB RAM, 48TB磁盘空间的机器而言,如果只跑一个ES实例,只能利用到32GB不到的heap,当heap快用饱和的时候,磁盘上保存的索引文件还不到10TB,这样显然是不经济的。 因此我们决定在冷结点上跑3个ES实例,每个分配31GB heap空间,从而可以在一台物理服务器上存储30多TB的索引数据并保持open状态,供用户随时搜索。 实际使用下来,由于冷数据搜索频率不高,也没有写入,即时只剩余35GB内存给os做文件系统缓存,查询性能还是可以满足需求的。
  4. 不同数据量级的shard最好隔离到不同组别的结点。 大家知道ES会自己平衡shard在集群的分布,这个自动平衡的逻辑主要考量三个因素。其一同一索引下的shard尽量分散到不同的结点;其二每个结点上的shard数量尽量接近;其三结点的磁盘有足够的剩余空间。这个策略只能保证shard数量分布均匀,而并不能保证数据大小分布均匀。 实际应用中,我们有200多种索引,数据量级差别很大,大的一天几个TB,小的一个月才几个GB,并且每种类型的数据保留时长又千差万别。抛出的问题,就是如何能比较平衡并充分的利用所有节点的资源。 针对这个问题,我们还是通过对结点添加属性标签来做分组,结合index routing控制的方式来做一些精细化的控制。尽量让不同量级的数据使用不同组别的结点,使得每个组内结点上的数据量比较容易自动平衡。
  5. 定期做索引的force merge,并且最好是每个shard merge成一个segment。前面提到过,heap消耗与segment数量也有关系,force merge可以显著降低这种消耗。 如果merge成一个segment还有一个好处,就是对于terms aggregation,搜索时无需构造Global Ordinals,可以提升聚合速度。


四. 版本选择
我们在2.4版本上稳定跑了很长时间,比较保守的同学可以上2.4,激进有精力折腾的可以考虑最新的5.0。 我们集群两周前从v2.4.0升级到了v5.0.0这个版本,除了升级第一周遇到一个不稳定的问题以外,感觉新版本带来的以下特性还是非常值得去升级的:
  • 结点启动的Bootstrap过程加入了很多关键系统参数设置的核验,比如Max File Descriptors, Memory Lock, Virtual Memory设置等等,如果设置不正确会拒绝启动并抛出异常。 与其带着错误的系统参数启动,并在日后造成性能问题,不如启动失败告知用户问题,是个很好的设计!
  • 索引性能提升。升级后在同样索引速率下,我们看到cpu消耗下降非常明显,除了对索引速率提升有帮助,也会一定程度提升搜索速率。
  • 新的数值型数据结构,存储空间更小,Range和地理位置计算更快速
  • Instant Aggregation对于类似now-7d to now这样的范围查询聚合能够做cache了,实际使用下来,效果明显,用户在Kibana上跑个过去一周数据的聚合,头2次刷新慢点,之后有cache了几乎就瞬间刷出!
  • 更多的保护措施保证集群的稳定,比如对一次搜索hit的shard数量做了限制,增强了circuit breaker的特性,更好的防护集群资源被坏查询耗尽。


升级第一周,我们的冷数据结点出现间歇性不响应问题,从而刨出3个issue提交给官方:
Issue#21595 Issue#21612 Issue#21611
第一个问题确认为Bug,将在5.0.2修复,其他两个目前还不清楚根源,看起来也只在我们的应用场景里遇到了。所幸问题都找到了了规避措施,实施这些措施以后,最近一周我们的集群重新回到以前2.4版本时期的稳定状态。


五. 监控
不差钱没空折腾的建议还是买官方的xpack省心,有精力折腾的,利用ES各种丰富的stats api,用自己熟悉的监控工具采集数据,可视化出来就好了。 那么多监控指标,最最关键的还是以下几类:
  1. 各类Thread pool的使用情况,active/queue/reject可视化出来。 判断集群是否有性能瓶颈了,看看业务高峰期各类queue是不是很高,reject是不是经常发生,基本可以做到心里有数。
  2. JVM的heap used%以及old GC的频率,如果old GC频率很高,并且多次GC过后heap used%几乎下不来,说明heap压力太大,要考虑扩容了。(也有可能是有问题的查询或者聚合造成的,需要结合用户访问记录来判断)。
  3. Segment memory大小和Segment的数量。节点上存放的索引较多的时候,这两个指标就值得关注,要知道segment memory是常驻heap不会被GC回收的,因此当heap压力太大的时候,可以结合这个指标判断是否是因为节点上存放的数据过多,需要扩容。Segement的数量也是比较关键的,如果小的segment非常多,比如有几千,即使segment memory本身不多,但是在搜索线程很多的情况下,依然会吃掉相当多的heap,原因是lucene为每个segment会在thread local里记录状态信息,这块的heap内存开销和(segment数量* thread数量)相关。
  4. 很有必要记录用户的访问记录。我们只开放了http api给用户,前置了一个nginx做http代理,将用户第三方api的访问记录通过access log全部记录下来。通过分析访问记录,可以在集群出现性能问题时,快速找到问题根源,对于问题排查和性能优化都很有帮助。


最后就是多上手实践,遇到问题多查官方资料,多Google看是否有其他人遇到同类问题,精力充足有编程背景的同学也可以多刨刨源码。
继续阅读 »
ElasticSearch目前在互联网公司主要用于两种应用场景,其一是用于构建业务的搜索功能模块且多是垂直领域的搜索,数据量级一般在千万至数十亿这个级别;其二用于大规模数据的实时OLAP,经典的如ELKStack,数据规模可能达到千亿或更多。 这两种场景的数据索引和应用访问模式上差异较大,在硬件选型和集群优化方面侧重点也会有所不同。一般来说后一种场景属于大数据范畴,数据量级和集群规模更大,在管理方面也更有挑战。

应Medcl大大的邀请,为ES中文社区做今年的Advent开篇,分享一下我在管理自家公司用于日志分析的ES集群方面的一点心得,蜻蜓点水,泛泛而谈,希望大方向上能对大家提供一些帮助。

这里的自家,即是携程旅行网。从2013年开始接触ES,我们团队先后实践过0.9.x -> 5.0.0中间各个版本,从最初只用于运维内部IIS日志的分析,到如今支持IT、呼叫中心、安全、测试、业务研发等多个部门超过200种日志型数据的实时检索与分析。 一路走来,愉悦了大家,也死磕了自己。

目前我们最大的日志单集群有120个data node,运行于70台物理服务器上。数据规模如下:
  • 单日索引数据条数600亿,新增索引文件25TB (含一个复制片则为50TB)
  • 业务高峰期峰值索引速率维持在百万条/秒
  • 历史数据保留时长根据业务需求制定,从10天 - 90天不等
  • 集群共3441个索引、17000个分片、数据总量约9300亿, 磁盘总消耗1PB
  • Kibana用户600多人, 每日来自Kibana和第三方的API调用共63万次
  • 查询响应时间百分位 75%:0.160s  90%:1.640s 95%:6.691s 99%:14.0039s


运维这样大规模的ES集群,有哪些值得注意的地方?

一. 必不可少的工具
工欲善其事必先利其器,从一开始,哪怕就只有几个node,就应该使用分布式配置管理工具来做集群的部署。随着应用的成熟,集群规模的逐步扩大,效率的提升会凸显。 官方提供了ES Puppet Module和Chef Cookbook,熟悉这两个工具的同学可以直接拿过来用。 我们自己则是采用的Ansible,编写了一套Playbook来达到类似的效果。 用熟这类工具,对于集群的初始部署,配置批量更改,集群版本升级,重启故障结点都会快捷和安全许多。
第二个必备利器就是sense插件。通过这个插件直接调用集群的restful API,在做集群和索引的状态查看,索引配置更改的时候非常方便。语法提示和自动补全功能更是实用,减少了翻看文档的频率。在Kibana5里面,sense已经成为一个内置的控制台,无需额外安装。

二. 硬件配置
我们采用的是32vcoreCPU + 128GB RAM的服务器,磁盘配置大部分服务器是12块4TB SATA机械磁盘做的Raid0,少部分机器是刚上了不久的6块800GB SSD raid0,主要目的是想做冷热数据分离,后面谈到集群架构的时候,再进一步解释一下如何利用硬件资源。

三. 集群的管理
  1. 首先很有必要对ES的结点做角色划分和隔离。大家知道ES的data node除了放数据以外,也可以兼任master和client的角色,多数同学会将这些角色混入到data node。然而对于一个规模较大,用户较多的集群,master和client在一些极端使用情况下可能会有性能瓶颈甚至内存溢出,从而使得共存的data node故障。data node的故障恢复涉及到数据的迁移,对集群资源有一定消耗,容易造成数据写入延迟或者查询减慢。如果将master和client独立出来,一旦出现问题,重启后几乎是瞬间就恢复的,对用户几乎没有任何影响。另外将这些角色独立出来的以后,也将对应的计算资源消耗从data node剥离出来,更容易掌握data node资源消耗与写入量和查询量之间的联系,便于做容量管理和规划。
  2. 避免过高的并发,包括控制shard数量和threadpool的数量。在写入量和查询性能能够满足的前提下,为索引分配尽量少的分片。分片过多会带来诸多负面影响,例如:每次查询后需要汇总排序的数据更多;过多的并发带来的线程切换造成过多的CPU损耗;索引的删除和配置更新更慢Issue#18776; 过多的shard也带来更多小的segment,而过多的小segment会带来非常显著的heap内存消耗,特别是如果查询线程配置得很多的情况下。 配置过大的threadpool更是会产生很多诡异的性能问题Issue#18161里所描述的问题就是我们所经历过的。 默认的Theadpool大小一般来说工作得很不错了。
  3. 冷热数据最好做分离。对于日志型应用来说,一般是每天建立一个新索引,当天的热索引在写入的同时也会有较多的查询。如果上面还存有比较长时间之前的冷数据,那么当用户做大跨度的历史数据查询的时候,过多的磁盘IO和CPU消耗很容易拖慢写入,造成数据的延迟。所以我们用了一部分机器来做冷数据的存储,利用ES可以给结点配置自定义属性的功能,为冷结点加上"boxtype":"weak"的标识,每晚通过维护脚本更新冷数据的索引路由设置index.routing.allocation.{require|include|exclude},让数据自动向冷结点迁移。 冷数据的特性是不再写入,用户查的频率较低,但量级可能很大。比如我们有个索引每天2TB,并且用户要求保持过去90天数据随时可查。保持这么大量的索引为open状态,并非只消耗磁盘空间。ES为了快速访问磁盘上的索引文件,需要在内存里驻留一些数据(索引文件的索引),也就是所谓的segment memory。稍微熟悉ES的同学知道,JVM heap分配不能超过32GB,对于我们128GB RAM, 48TB磁盘空间的机器而言,如果只跑一个ES实例,只能利用到32GB不到的heap,当heap快用饱和的时候,磁盘上保存的索引文件还不到10TB,这样显然是不经济的。 因此我们决定在冷结点上跑3个ES实例,每个分配31GB heap空间,从而可以在一台物理服务器上存储30多TB的索引数据并保持open状态,供用户随时搜索。 实际使用下来,由于冷数据搜索频率不高,也没有写入,即时只剩余35GB内存给os做文件系统缓存,查询性能还是可以满足需求的。
  4. 不同数据量级的shard最好隔离到不同组别的结点。 大家知道ES会自己平衡shard在集群的分布,这个自动平衡的逻辑主要考量三个因素。其一同一索引下的shard尽量分散到不同的结点;其二每个结点上的shard数量尽量接近;其三结点的磁盘有足够的剩余空间。这个策略只能保证shard数量分布均匀,而并不能保证数据大小分布均匀。 实际应用中,我们有200多种索引,数据量级差别很大,大的一天几个TB,小的一个月才几个GB,并且每种类型的数据保留时长又千差万别。抛出的问题,就是如何能比较平衡并充分的利用所有节点的资源。 针对这个问题,我们还是通过对结点添加属性标签来做分组,结合index routing控制的方式来做一些精细化的控制。尽量让不同量级的数据使用不同组别的结点,使得每个组内结点上的数据量比较容易自动平衡。
  5. 定期做索引的force merge,并且最好是每个shard merge成一个segment。前面提到过,heap消耗与segment数量也有关系,force merge可以显著降低这种消耗。 如果merge成一个segment还有一个好处,就是对于terms aggregation,搜索时无需构造Global Ordinals,可以提升聚合速度。


四. 版本选择
我们在2.4版本上稳定跑了很长时间,比较保守的同学可以上2.4,激进有精力折腾的可以考虑最新的5.0。 我们集群两周前从v2.4.0升级到了v5.0.0这个版本,除了升级第一周遇到一个不稳定的问题以外,感觉新版本带来的以下特性还是非常值得去升级的:
  • 结点启动的Bootstrap过程加入了很多关键系统参数设置的核验,比如Max File Descriptors, Memory Lock, Virtual Memory设置等等,如果设置不正确会拒绝启动并抛出异常。 与其带着错误的系统参数启动,并在日后造成性能问题,不如启动失败告知用户问题,是个很好的设计!
  • 索引性能提升。升级后在同样索引速率下,我们看到cpu消耗下降非常明显,除了对索引速率提升有帮助,也会一定程度提升搜索速率。
  • 新的数值型数据结构,存储空间更小,Range和地理位置计算更快速
  • Instant Aggregation对于类似now-7d to now这样的范围查询聚合能够做cache了,实际使用下来,效果明显,用户在Kibana上跑个过去一周数据的聚合,头2次刷新慢点,之后有cache了几乎就瞬间刷出!
  • 更多的保护措施保证集群的稳定,比如对一次搜索hit的shard数量做了限制,增强了circuit breaker的特性,更好的防护集群资源被坏查询耗尽。


升级第一周,我们的冷数据结点出现间歇性不响应问题,从而刨出3个issue提交给官方:
Issue#21595 Issue#21612 Issue#21611
第一个问题确认为Bug,将在5.0.2修复,其他两个目前还不清楚根源,看起来也只在我们的应用场景里遇到了。所幸问题都找到了了规避措施,实施这些措施以后,最近一周我们的集群重新回到以前2.4版本时期的稳定状态。


五. 监控
不差钱没空折腾的建议还是买官方的xpack省心,有精力折腾的,利用ES各种丰富的stats api,用自己熟悉的监控工具采集数据,可视化出来就好了。 那么多监控指标,最最关键的还是以下几类:
  1. 各类Thread pool的使用情况,active/queue/reject可视化出来。 判断集群是否有性能瓶颈了,看看业务高峰期各类queue是不是很高,reject是不是经常发生,基本可以做到心里有数。
  2. JVM的heap used%以及old GC的频率,如果old GC频率很高,并且多次GC过后heap used%几乎下不来,说明heap压力太大,要考虑扩容了。(也有可能是有问题的查询或者聚合造成的,需要结合用户访问记录来判断)。
  3. Segment memory大小和Segment的数量。节点上存放的索引较多的时候,这两个指标就值得关注,要知道segment memory是常驻heap不会被GC回收的,因此当heap压力太大的时候,可以结合这个指标判断是否是因为节点上存放的数据过多,需要扩容。Segement的数量也是比较关键的,如果小的segment非常多,比如有几千,即使segment memory本身不多,但是在搜索线程很多的情况下,依然会吃掉相当多的heap,原因是lucene为每个segment会在thread local里记录状态信息,这块的heap内存开销和(segment数量* thread数量)相关。
  4. 很有必要记录用户的访问记录。我们只开放了http api给用户,前置了一个nginx做http代理,将用户第三方api的访问记录通过access log全部记录下来。通过分析访问记录,可以在集群出现性能问题时,快速找到问题根源,对于问题排查和性能优化都很有帮助。


最后就是多上手实践,遇到问题多查官方资料,多Google看是否有其他人遇到同类问题,精力充足有编程背景的同学也可以多刨刨源码。 收起阅读 »

java客户端连接es5.0(基于xpack安全管理)

 
Settings settings = Settings.builder().put("cluster.name", "xxx")
.put("xpack.security.transport.ssl.enabled", false)
.put("xpack.security.user", "xxx:xxx")
.put("client.transport.sniff", true).build();
try {
client = new PreBuiltXPackTransportClient(settings)
.addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName("xxx.xxx.xxx.xxx"), 9300))
.addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName("xxx.xxx.xxx.xxx"), 9300));
} catch (UnknownHostException e) {
e.printStackTrace();
}
继续阅读 »
 
Settings settings = Settings.builder().put("cluster.name", "xxx")
.put("xpack.security.transport.ssl.enabled", false)
.put("xpack.security.user", "xxx:xxx")
.put("client.transport.sniff", true).build();
try {
client = new PreBuiltXPackTransportClient(settings)
.addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName("xxx.xxx.xxx.xxx"), 9300))
.addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName("xxx.xxx.xxx.xxx"), 9300));
} catch (UnknownHostException e) {
e.printStackTrace();
}
收起阅读 »

Pandasticsearch: An Elasticsearch client exposing DataFrame API

https://github.com/onesuper/pandasticsearch
 
# Create a DataFrame object
from pandasticsearch import DataFrame
df = DataFrame.from_es('http://localhost:9200', index='people')

# Print the schema(mapping) of the index
df.print_schema()
# company
# |-- employee
# |-- name: {'index': 'not_analyzed', 'type': 'string'}
# |-- age: {'type': 'integer'}
# |-- gender: {'index': 'not_analyzed', 'type': 'string'}

# Inspect the columns
df.columns
#['name', 'age', 'gender']

# Get the column
df.name
# Column('name')

# Filter
df.filter(df.age < 13).collect()
# [Row(age=12,gender='female',name='Alice'), Row(age=11,gender='male',name='Bob')]

# Project
df.filter(df.age < 25).select('name', 'age').collect()
# [Row(age=12,name='Alice'), Row(age=11,name='Bob'), Row(age=13,name='Leo')]

# Print the rows into console
df.filter(df.age < 25).select('name').show(3)
# +------+
# | name |
# +------+
# | Alice|
# | Bob |
# | Leo |
# +------+

# Sort
df.sort(df.age.asc).select('name', 'age').collect()
#[Row(age=11,name='Bob'), Row(age=12,name='Alice'), Row(age=13,name='Leo')]

# Aggregate
df[df.gender == 'male'].agg(df.age.avg).collect()
# [Row(avg(age)=12)]

# Groupby
df.groupby('gender').collect()
# [Row(doc_count=1), Row(doc_count=2)]

# Groupby and then aggregate
df.groupby('gender').agg(df.age.max).collect()
# [Row(doc_count=1, max(age)=12), Row(doc_count=2, max(age)=13)]

# Convert to Pandas object for subsequent analysis
df[df.gender == 'male'].agg(df.age.avg).to_pandas()
# avg(age)
# 0 12
继续阅读 »
https://github.com/onesuper/pandasticsearch
 
# Create a DataFrame object
from pandasticsearch import DataFrame
df = DataFrame.from_es('http://localhost:9200', index='people')

# Print the schema(mapping) of the index
df.print_schema()
# company
# |-- employee
# |-- name: {'index': 'not_analyzed', 'type': 'string'}
# |-- age: {'type': 'integer'}
# |-- gender: {'index': 'not_analyzed', 'type': 'string'}

# Inspect the columns
df.columns
#['name', 'age', 'gender']

# Get the column
df.name
# Column('name')

# Filter
df.filter(df.age < 13).collect()
# [Row(age=12,gender='female',name='Alice'), Row(age=11,gender='male',name='Bob')]

# Project
df.filter(df.age < 25).select('name', 'age').collect()
# [Row(age=12,name='Alice'), Row(age=11,name='Bob'), Row(age=13,name='Leo')]

# Print the rows into console
df.filter(df.age < 25).select('name').show(3)
# +------+
# | name |
# +------+
# | Alice|
# | Bob |
# | Leo |
# +------+

# Sort
df.sort(df.age.asc).select('name', 'age').collect()
#[Row(age=11,name='Bob'), Row(age=12,name='Alice'), Row(age=13,name='Leo')]

# Aggregate
df[df.gender == 'male'].agg(df.age.avg).collect()
# [Row(avg(age)=12)]

# Groupby
df.groupby('gender').collect()
# [Row(doc_count=1), Row(doc_count=2)]

# Groupby and then aggregate
df.groupby('gender').agg(df.age.max).collect()
# [Row(doc_count=1, max(age)=12), Row(doc_count=2, max(age)=13)]

# Convert to Pandas object for subsequent analysis
df[df.gender == 'male'].agg(df.age.avg).to_pandas()
# avg(age)
# 0 12
收起阅读 »

Elastic Advent Calendar 活动启动咯!

时间一转又到了年末,去年的 Advent 在三斗的发起下,进行的很不错,今年的 Advent 活动继续办下去吧,借鉴日本(http://qiita.com/advent-calendar/2016/elastic)的做法,我们今年可以先报名占坑,预定一个日子和你打算写的文章的标题,尽量错开时间。

今年的Advent文章也会同步发布到社区公众号。

去年 Advent 活动回顾 http://elasticsearch.cn/topic/advent
 
由于本站没有日历的功能,大家留言评论报名预定就好了。
 
格式(仅12月):日期,标题
如:12月x日 , xxx 小技巧一则
 
已发布:
《大规模Elasticsearch集群管理心得》
《Kibana 系漫游指南》 
《创建一个你自己的 Beat》
《将sql转换为es的DSL》
《Elasticsearch 2.x mapping tips》
《无外网环境10分钟快速集成 elasticsearch-head》
《Elasticsearch 5 入坑指南》
《可定制的 elasticsearch 数据导入工具 ——mysql_2_elasticsearch》
《记一次es性能调优》
《PacketBeat奇妙的OOM小记》
《ES5.0.0 安装记录》
继续阅读 »
时间一转又到了年末,去年的 Advent 在三斗的发起下,进行的很不错,今年的 Advent 活动继续办下去吧,借鉴日本(http://qiita.com/advent-calendar/2016/elastic)的做法,我们今年可以先报名占坑,预定一个日子和你打算写的文章的标题,尽量错开时间。

今年的Advent文章也会同步发布到社区公众号。

去年 Advent 活动回顾 http://elasticsearch.cn/topic/advent
 
由于本站没有日历的功能,大家留言评论报名预定就好了。
 
格式(仅12月):日期,标题
如:12月x日 , xxx 小技巧一则
 
已发布:
《大规模Elasticsearch集群管理心得》
《Kibana 系漫游指南》 
《创建一个你自己的 Beat》
《将sql转换为es的DSL》
《Elasticsearch 2.x mapping tips》
《无外网环境10分钟快速集成 elasticsearch-head》
《Elasticsearch 5 入坑指南》
《可定制的 elasticsearch 数据导入工具 ——mysql_2_elasticsearch》
《记一次es性能调优》
《PacketBeat奇妙的OOM小记》
《ES5.0.0 安装记录》 收起阅读 »

Elastic Stack 5.0 正式发布

Snip20161027_6.png

作者:Shay Banon,原文:https://www.elastic.co/blog/elastic-stack-5-0-0-released 

记得在 2016 年 2 月份,就在 Elastic{ON} 16 大会之后,我写了一篇标题为 [Heya, Elastic Stack and X-Pack] (https://www.elastic.co/blog/heya-elastic-stack-and-x-pack ) 的博客。经过了几乎整整一年的努力,中间发布了 5  个 Alpha,1 个 Beta 和一个 RC 版本,今天我们非常高兴的正式宣布发布 Elastic Stack 的 GA 正式版本。

并且,重要的是,于此同时,在我们的 [Elastic Cloud](https://www.elastic.co/cloud/as-a-service/signup ) 上面也同步进行了更新。所以如果你需要托管的 Elasticsearch 和 Kibana ,那么没有其它地方比这里更及时了。我们致力于让 Elastic Cloud 成为一个托管 Elasticsearch 的最佳场所。事实上,在正式版发布之前,我们也提供了 RC 版本方便你用于测试。

我们的团队今天正在庆祝这一时刻,我希望你能加入我们。

GA 版本今天已经可以下载了,如果要加入 Elastic 团队 11 月 3 号的线上活动,了解更多有关于本次发布和向工程师提问,请点击这里 [注册!](https://www.elastic.co/live/v5 )
 

在开始探索发布详情之前,我想借此机会来回顾一下有哪些背后的事情让我们走到今天。

## 我们的社区

最近的 Elastic{ON} Tour,在每场活动的开场我会讨论我们公司过去几年的简短历史。最近一次活动的高潮是当我宣布我们的累计下载总数达到了七千五百万。当我第一次开始这个项目的时候,我希望她能够被能够被广泛使用,但是我们的社区的热情和激情总是不断的给我快乐和惊喜。

## 先驱者计划

考虑到这一点,我想分享一下 [先驱者计划](https://www.elastic.co/blog/elastic-pioneer-program ) 的一些结果。该计划开始于一个简单的前提,你如何使用 Elastic Stack 对我们来说非常重要,不管是产品研发还是确保发布高质量的可用版本。我非常高兴的告诉大家自四月份发布的第一个Alpha版本,我们的社区一共提交了146个issue。

我们的社区是Elastic其中一个最宝贵的财产。事实上,在这次发布中讨论的最多的就是为什么命名为 "Elastic Stack"。

## Elastic Stack

过去一年,我们收购了Packetbeat 团队,然后Beats 就诞生了。这是一个开源的用于构建轻量级数据收集的平台,可用于日志、基础设施监控指标、网络流量等数据的收集,并且以前所未有的简单方式来将数据发送至Logstash或Elasticsearch。同时我们热爱那些已经习惯于将 ELK 作为代表我们软件栈的你们,只不过加上Beats,我们不知道如何将“B”和E-L-K组合在一起。(NOTE:过去用过ELKB)

但Elastic Stack 远不只是一个名字。当我们开始发布一个周期,我们开发提交、构建、测试和发布的是一整个软件栈。这个很重要,从内部来保证兼容性。并且,对你来说,它可以帮助你提升部署速度,减少版本冲突,让开发者轻松的处理整个 Elastic Stack的兼容性问题。

## 一场特性之旅

在我开始这篇博客之前,我打算列举每个产品的一些主要特性,但是发现好像很难确定从哪里开始和结束。我们每个产品和技术的leader 已经创建了单独的博客来讨论各自产品的特性,没人比他们更适合介绍其中的故事。 我个人,更是对其中的一些特性感到非常兴奋,相较于简单的罗列,我会提供一些简短概要并且鼓励你去阅读每个产品详细的博客。


Ingest Node

Ingest Node 是Elasticsearch 的一个节点类型,允许你对数据做一些加工,比如:grok、geoip、date和其它索引(或重建)过程中的基本数据操作。 通过访问REST API的时候指定一个参数“?pipeline=x”来使用由一系列处理器(processors)构造的管道,它可用帮你对文档进行预处理,原生的在Elasticsearch内部,在索引之前做灵活的 ingest部署。这不代表要替换掉Logstash,也不会移除对Beats的需要,只为你设计数据采集架构时提供一种更加灵活的可能性。

Elasticsearch 性能

性能报告倾向于提供一个大纲,尤其是比较性的性能测试报告,基于此,我们花了很大力气来比较5.0.0 与之前发布的版本。数据现在已经可用了,这个数据也是我们用来检查和确保我们正在做正确的事情来保证性能,我们是如此的公开来避免由性能测试数字引起的所谓秘密和怀疑。事实上,不止测试结果,我们还公布了我们的硬件和配置,我们还开源了我们的工具链(叫做 [Rally](https://github.com/elastic/rally )) 和测试记录本身([Rally-Tracks](https://github.com/elastic/rally-tracks ))。

Metricbeat

Metricbeat 替换 Topbeat 成为Elastic Stack里主要的收集度量指标的工具。和Topbeat一样,Metricbeat 收集和“top” 类似的诸如机器及进程的资源(CPU, memory, disk, network)统计信息。和Topbeat不同的是,Metricbeat 同时也收集其它系统的指标信息,如:Apache、HAProxy、MongoDB、MySQL、Nginx、PostgreSQL、 Redis和 Zookeeper,并且在不久的将来还会支持更多应用和系统。

Logstash 监控 API** - 这是一个新的监控特性提供Logstash 管道及其插件在运行时的可视状态。这个组件收集Logstash处理你数据的各种操作性统计指标信息,所有的这些信息都可通过简单的API来进行查询。

Timelion

以前以re{Search} 项目介绍过,现在Timelion 作为Kibana原生的核心组件可直接可用。Timelion 提供一个查询表达式和可视化类型让你探索基于时间的数据。

再列举几个,诸如BKD 树、scaled_float 和 half_float ,我们投入了大量的精力到 [Elasticsearch 可靠性](https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html ) 中,另外Kibana惊艳的重新设计(我从来不知道我们以前有这么讨厌这些边框直到移除), Beats 支持的Kafaka输出,等等,还有很多很多。

这是一个非常大的版本发布,非常有必要阅读相关独立的博客来了解更多范围内的改进。






## X-Pack

在Elastic 我们热爱扩展。太多我们构建的东西我们给他们起了非常有趣的名字,如:Shield、Marvel和Watcher,作为提供给我们客户的额外的插件,独立闭源但没限制开源部分的能力的特性,随着后面又增加了Graph 和Reporting,安装流程也变得困难和困惑。

来和X-Pack 打个招呼吧!

一个包含了security、alerting、monitoring & management、reporting和graph 能力的Elastic Stack的插件。我们对5.0的工程不仅限于Elastic Stack,同时也包括给X-Pack 添加如下:
  1. Kibana里的管理和监控的UI界面
  2. Kibana里创建用户和角色的UI界面
  3. 非常简化的安装流程


X-Pack 可以试用,同时提供商业和免费(基本)授权证书选项。我们尤其兴奋的将X-Pack的某些特性开放出来免费使用,详细请见 [Subscriptions](https://www.elastic.co/subscriptions ) 页。

## 放在最后

我敬畏发布此次版本所做的所有努力,来自我们社区和客户的共同参与,以及为了将来发布所做的一系列背地里的工作。一如既往,理解一个版本的最好方式就是去体验它。







   
 
继续阅读 »
Snip20161027_6.png

作者:Shay Banon,原文:https://www.elastic.co/blog/elastic-stack-5-0-0-released 

记得在 2016 年 2 月份,就在 Elastic{ON} 16 大会之后,我写了一篇标题为 [Heya, Elastic Stack and X-Pack] (https://www.elastic.co/blog/heya-elastic-stack-and-x-pack ) 的博客。经过了几乎整整一年的努力,中间发布了 5  个 Alpha,1 个 Beta 和一个 RC 版本,今天我们非常高兴的正式宣布发布 Elastic Stack 的 GA 正式版本。

并且,重要的是,于此同时,在我们的 [Elastic Cloud](https://www.elastic.co/cloud/as-a-service/signup ) 上面也同步进行了更新。所以如果你需要托管的 Elasticsearch 和 Kibana ,那么没有其它地方比这里更及时了。我们致力于让 Elastic Cloud 成为一个托管 Elasticsearch 的最佳场所。事实上,在正式版发布之前,我们也提供了 RC 版本方便你用于测试。

我们的团队今天正在庆祝这一时刻,我希望你能加入我们。

GA 版本今天已经可以下载了,如果要加入 Elastic 团队 11 月 3 号的线上活动,了解更多有关于本次发布和向工程师提问,请点击这里 [注册!](https://www.elastic.co/live/v5 )
 

在开始探索发布详情之前,我想借此机会来回顾一下有哪些背后的事情让我们走到今天。

## 我们的社区

最近的 Elastic{ON} Tour,在每场活动的开场我会讨论我们公司过去几年的简短历史。最近一次活动的高潮是当我宣布我们的累计下载总数达到了七千五百万。当我第一次开始这个项目的时候,我希望她能够被能够被广泛使用,但是我们的社区的热情和激情总是不断的给我快乐和惊喜。

## 先驱者计划

考虑到这一点,我想分享一下 [先驱者计划](https://www.elastic.co/blog/elastic-pioneer-program ) 的一些结果。该计划开始于一个简单的前提,你如何使用 Elastic Stack 对我们来说非常重要,不管是产品研发还是确保发布高质量的可用版本。我非常高兴的告诉大家自四月份发布的第一个Alpha版本,我们的社区一共提交了146个issue。

我们的社区是Elastic其中一个最宝贵的财产。事实上,在这次发布中讨论的最多的就是为什么命名为 "Elastic Stack"。

## Elastic Stack

过去一年,我们收购了Packetbeat 团队,然后Beats 就诞生了。这是一个开源的用于构建轻量级数据收集的平台,可用于日志、基础设施监控指标、网络流量等数据的收集,并且以前所未有的简单方式来将数据发送至Logstash或Elasticsearch。同时我们热爱那些已经习惯于将 ELK 作为代表我们软件栈的你们,只不过加上Beats,我们不知道如何将“B”和E-L-K组合在一起。(NOTE:过去用过ELKB)

但Elastic Stack 远不只是一个名字。当我们开始发布一个周期,我们开发提交、构建、测试和发布的是一整个软件栈。这个很重要,从内部来保证兼容性。并且,对你来说,它可以帮助你提升部署速度,减少版本冲突,让开发者轻松的处理整个 Elastic Stack的兼容性问题。

## 一场特性之旅

在我开始这篇博客之前,我打算列举每个产品的一些主要特性,但是发现好像很难确定从哪里开始和结束。我们每个产品和技术的leader 已经创建了单独的博客来讨论各自产品的特性,没人比他们更适合介绍其中的故事。 我个人,更是对其中的一些特性感到非常兴奋,相较于简单的罗列,我会提供一些简短概要并且鼓励你去阅读每个产品详细的博客。


Ingest Node

Ingest Node 是Elasticsearch 的一个节点类型,允许你对数据做一些加工,比如:grok、geoip、date和其它索引(或重建)过程中的基本数据操作。 通过访问REST API的时候指定一个参数“?pipeline=x”来使用由一系列处理器(processors)构造的管道,它可用帮你对文档进行预处理,原生的在Elasticsearch内部,在索引之前做灵活的 ingest部署。这不代表要替换掉Logstash,也不会移除对Beats的需要,只为你设计数据采集架构时提供一种更加灵活的可能性。

Elasticsearch 性能

性能报告倾向于提供一个大纲,尤其是比较性的性能测试报告,基于此,我们花了很大力气来比较5.0.0 与之前发布的版本。数据现在已经可用了,这个数据也是我们用来检查和确保我们正在做正确的事情来保证性能,我们是如此的公开来避免由性能测试数字引起的所谓秘密和怀疑。事实上,不止测试结果,我们还公布了我们的硬件和配置,我们还开源了我们的工具链(叫做 [Rally](https://github.com/elastic/rally )) 和测试记录本身([Rally-Tracks](https://github.com/elastic/rally-tracks ))。

Metricbeat

Metricbeat 替换 Topbeat 成为Elastic Stack里主要的收集度量指标的工具。和Topbeat一样,Metricbeat 收集和“top” 类似的诸如机器及进程的资源(CPU, memory, disk, network)统计信息。和Topbeat不同的是,Metricbeat 同时也收集其它系统的指标信息,如:Apache、HAProxy、MongoDB、MySQL、Nginx、PostgreSQL、 Redis和 Zookeeper,并且在不久的将来还会支持更多应用和系统。

Logstash 监控 API** - 这是一个新的监控特性提供Logstash 管道及其插件在运行时的可视状态。这个组件收集Logstash处理你数据的各种操作性统计指标信息,所有的这些信息都可通过简单的API来进行查询。

Timelion

以前以re{Search} 项目介绍过,现在Timelion 作为Kibana原生的核心组件可直接可用。Timelion 提供一个查询表达式和可视化类型让你探索基于时间的数据。

再列举几个,诸如BKD 树、scaled_float 和 half_float ,我们投入了大量的精力到 [Elasticsearch 可靠性](https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html ) 中,另外Kibana惊艳的重新设计(我从来不知道我们以前有这么讨厌这些边框直到移除), Beats 支持的Kafaka输出,等等,还有很多很多。

这是一个非常大的版本发布,非常有必要阅读相关独立的博客来了解更多范围内的改进。






## X-Pack

在Elastic 我们热爱扩展。太多我们构建的东西我们给他们起了非常有趣的名字,如:Shield、Marvel和Watcher,作为提供给我们客户的额外的插件,独立闭源但没限制开源部分的能力的特性,随着后面又增加了Graph 和Reporting,安装流程也变得困难和困惑。

来和X-Pack 打个招呼吧!

一个包含了security、alerting、monitoring & management、reporting和graph 能力的Elastic Stack的插件。我们对5.0的工程不仅限于Elastic Stack,同时也包括给X-Pack 添加如下:
  1. Kibana里的管理和监控的UI界面
  2. Kibana里创建用户和角色的UI界面
  3. 非常简化的安装流程


X-Pack 可以试用,同时提供商业和免费(基本)授权证书选项。我们尤其兴奋的将X-Pack的某些特性开放出来免费使用,详细请见 [Subscriptions](https://www.elastic.co/subscriptions ) 页。

## 放在最后

我敬畏发布此次版本所做的所有努力,来自我们社区和客户的共同参与,以及为了将来发布所做的一系列背地里的工作。一如既往,理解一个版本的最好方式就是去体验它。







   
  收起阅读 »

elasticsearch-analysis-pinyin更新至es2.4.1和5.0.0-rc1

版本分别支持到最新的 es v2.4.1和 es v5.0.0-rc1
新增若干特性,支持多种选项配置,支持 pinyin 的切分,比之前需要结合 ngram 的方式更加准确,
如:liudehuaalibaba13zhuanghan->liu,de,hua,a,li,ba,ba,13,zhuang,han,
具体配置参加文档:
https://github.com/medcl/elasticsearch-analysis-pinyin
 
下载:
https://github.com/medcl/elasticsearch-analysis-pinyin/releases
 
欢迎测试:
curl -XPUT http://localhost:9200/medcl/ -d'
{
"index" : {
"analysis" : {
"analyzer" : {
"pinyin_analyzer" : {
"tokenizer" : "my_pinyin"
}
},
"tokenizer" : {
"my_pinyin" : {
"type" : "pinyin",
"keep_separate_first_letter" : false,
"keep_full_pinyin" : true,
"keep_original" : false,
"limit_first_letter_length" : 16,
"lowercase" : true
}
}
}
}
}'

curl http://localhost:9200/medcl/_a ... lyzer
{
"tokens" : [ {
"token" : "liu",
"start_offset" : 0,
"end_offset" : 1,
"type" : "word",
"position" : 0
}, {
"token" : "de",
"start_offset" : 1,
"end_offset" : 2,
"type" : "word",
"position" : 1
}, {
"token" : "hua",
"start_offset" : 2,
"end_offset" : 3,
"type" : "word",
"position" : 2
}, {
"token" : "a",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 3
}, {
"token" : "b",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 4
}, {
"token" : "c",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 5
}, {
"token" : "d",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 6
}, {
"token" : "liu",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 7
}, {
"token" : "de",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 8
}, {
"token" : "hua",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 9
}, {
"token" : "wo",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 10
}, {
"token" : "bu",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 11
}, {
"token" : "zhi",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 12
}, {
"token" : "dao",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 13
}, {
"token" : "shi",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 14
}, {
"token" : "shui",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 15
}, {
"token" : "ldhabcdliudehuaw",
"start_offset" : 0,
"end_offset" : 16,
"type" : "word",
"position" : 16
} ]
}

 
继续阅读 »
版本分别支持到最新的 es v2.4.1和 es v5.0.0-rc1
新增若干特性,支持多种选项配置,支持 pinyin 的切分,比之前需要结合 ngram 的方式更加准确,
如:liudehuaalibaba13zhuanghan->liu,de,hua,a,li,ba,ba,13,zhuang,han,
具体配置参加文档:
https://github.com/medcl/elasticsearch-analysis-pinyin
 
下载:
https://github.com/medcl/elasticsearch-analysis-pinyin/releases
 
欢迎测试:
curl -XPUT http://localhost:9200/medcl/ -d'
{
"index" : {
"analysis" : {
"analyzer" : {
"pinyin_analyzer" : {
"tokenizer" : "my_pinyin"
}
},
"tokenizer" : {
"my_pinyin" : {
"type" : "pinyin",
"keep_separate_first_letter" : false,
"keep_full_pinyin" : true,
"keep_original" : false,
"limit_first_letter_length" : 16,
"lowercase" : true
}
}
}
}
}'

curl http://localhost:9200/medcl/_a ... lyzer
{
"tokens" : [ {
"token" : "liu",
"start_offset" : 0,
"end_offset" : 1,
"type" : "word",
"position" : 0
}, {
"token" : "de",
"start_offset" : 1,
"end_offset" : 2,
"type" : "word",
"position" : 1
}, {
"token" : "hua",
"start_offset" : 2,
"end_offset" : 3,
"type" : "word",
"position" : 2
}, {
"token" : "a",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 3
}, {
"token" : "b",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 4
}, {
"token" : "c",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 5
}, {
"token" : "d",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 6
}, {
"token" : "liu",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 7
}, {
"token" : "de",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 8
}, {
"token" : "hua",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 9
}, {
"token" : "wo",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 10
}, {
"token" : "bu",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 11
}, {
"token" : "zhi",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 12
}, {
"token" : "dao",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 13
}, {
"token" : "shi",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 14
}, {
"token" : "shui",
"start_offset" : 2,
"end_offset" : 31,
"type" : "word",
"position" : 15
}, {
"token" : "ldhabcdliudehuaw",
"start_offset" : 0,
"end_offset" : 16,
"type" : "word",
"position" : 16
} ]
}

  收起阅读 »

Elastic{ON} Dev China 2016 开始报名了!

大会网站:https://info.elastic.co/elasticon-dev-china.html 
大会网站:​http://conf.elasticsearch.cn​
大会介绍:
Elastic 中国开发者大会 2016(Elastic{ON} Dev China 2016)是由 Elastic 官方在中国举办的第一次开发者大会,前身 ESCC (Elasticsearch China Conference) 是由 Elastic 中文社区每年定期举办的线下交流活动,主要围绕 Elastic 的开源产品: Elasticsearch、Logstash、Kibana 和 Beats,探讨在搜索、数据实时分析、日志分析、安全等领域的实践与应用。 

大会时间:
2016-12-10 08:00 至 2016-12-10 18:00 周六
 
如何参与:
提供赞助:http://elasticsearch.mikecrm.com/nECSP4
提交演讲:http://elasticsearch.mikecrm.com/x0y56G
当志愿者:http://elasticsearch.mikecrm.com/n5BVwP
购买门票:http://event.3188.la/460820612/
 
大会具体场地和日程不断更新中,敬请关注!
继续阅读 »
大会网站:https://info.elastic.co/elasticon-dev-china.html 
大会网站:​http://conf.elasticsearch.cn​
大会介绍:
Elastic 中国开发者大会 2016(Elastic{ON} Dev China 2016)是由 Elastic 官方在中国举办的第一次开发者大会,前身 ESCC (Elasticsearch China Conference) 是由 Elastic 中文社区每年定期举办的线下交流活动,主要围绕 Elastic 的开源产品: Elasticsearch、Logstash、Kibana 和 Beats,探讨在搜索、数据实时分析、日志分析、安全等领域的实践与应用。 

大会时间:
2016-12-10 08:00 至 2016-12-10 18:00 周六
 
如何参与:
提供赞助:http://elasticsearch.mikecrm.com/nECSP4
提交演讲:http://elasticsearch.mikecrm.com/x0y56G
当志愿者:http://elasticsearch.mikecrm.com/n5BVwP
购买门票:http://event.3188.la/460820612/
 
大会具体场地和日程不断更新中,敬请关注! 收起阅读 »