kibana
kibaba 5.2.2版本中，如果没有查询结果，dashboard报表显示No results found，有没有什么办法不让页面显示no relusts found，显示默认的数据0即可
Kibana • loopmocker 回复了问题 • 2 人关注 • 1 个回复 • 619 次浏览 • 3 天前
Kibana error with X-Pack monitoring
Kibana • medcl 回复了问题 • 2 人关注 • 1 个回复 • 264 次浏览 • 2017-06-19 12:47
kibana已运行但无法再浏览器打开
Kibana • helloAmy 回复了问题 • 1 人关注 • 1 个回复 • 830 次浏览 • 2017-06-15 17:24
ELK - Kibana doesn't recognize geo_point field
Kibana • kennywu76 回复了问题 • 2 人关注 • 1 个回复 • 287 次浏览 • 2017-06-06 18:17
geoip和timestamp的两个问题
Kibana • medcl 回复了问题 • 2 人关注 • 1 个回复 • 438 次浏览 • 2017-05-17 09:15
关于使用Kibana的公司。
Kibana • medcl 回复了问题 • 2 人关注 • 1 个回复 • 646 次浏览 • 2017-05-11 23:46
使用 Elastic Stack 来监控和调优 Golang 应用程序
Beats • medcl 发表了文章 • 0 个评论 • 2628 次浏览 • 2017-03-03 11:16
Golang 因为其语法简单，上手快且方便部署正被越来越多的开发者所青睐，一个 Golang 程序开发好了之后，势必要关心其运行情况，今天在这里就给大家介绍一下如果使用 Elastic Stack 来分析 Golang 程序的内存使用情况，方便对 Golang 程序做长期监控进而调优和诊断，甚至发现一些潜在的内存泄露等问题。
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
Apache ModuleCouchbase ModuleDocker ModuleHAProxy Modulekafka ModuleMongoDB ModuleMySQL ModuleNginx ModulePostgreSQL ModulePrometheus ModuleRedis ModuleSystem ModuleZooKeeper Module
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：$(document).ready(function() {$('pre code').each(function(i, block) { hljs.highlightBlock( block); }); });import _ "expvar"如果 Golang 没有启动 http 服务，使用下面的方式启动一个即可，这里端口是 6060，如下：func metricsHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
first := true
report := func(key string, value interface{}) {
if !first {
fmt.Fprintf(w, ",\n")
}
first = false
if str, ok := value.(string); ok {
fmt.Fprintf(w, "%q: %q", key, str)
} else {
fmt.Fprintf(w, "%q: %v", key, value)
}
}
fmt.Fprintf(w, "{\n")
expvar.Do(func(kv expvar.KeyValue) {
report(kv.Key, kv.Value)
})
fmt.Fprintf(w, "\n}\n")
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/debug/vars", metricsHandler)
endpoint := http.ListenAndServe("localhost:6060", mux)
}默认注册的访问路径是/debug/vars， 编译启动之后，就可以通过 http://localhost:6060/debug/vars 来访问 expvar 以 JSON 格式暴露出来的这些内部变量，默认提供了 Golang 的 runtime.Memstats 信息，也就是上面分析的数据源，当然你还可以注册自己的变量，这里暂时不提。
OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.ymlmetricbeat.modules:
- module: golang
metricsets: ["heap"]
enabled: true
period: 10s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"上面的参数启用了 Golang 监控模块，并且会10秒获取一次配置路径的返回内存数据，我们同样配置该配置文件，设置数据输出到本机的 Elasticsearch：output.elasticsearch:
hosts: ["localhost:9200"]
现在启动 Metricbeat：./metricbeat -e -v现在在 Elasticsearch 应该就有数据了，当然记得确保 Elasticsearch 和 Kibana 是可用状态，你可以在 Kibana 根据数据灵活自定义可视化，推荐使用 Timelion 来进行分析，当然为了方便也可以直接导入提供的样例仪表板，就是上面第一个图的效果。
关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：var inerInt int64 = 1024
pubInt := expvar.NewInt("your_metric_key")
pubInt.Set(inerInt)
pubInt.Add(2)在 Metricbeat 内部也同样暴露了很多内部运行的信息，所以 Metricbeat 可以自己监控自己了。。。
首先，启动的时候带上参数设置pprof监控的地址，如下：./metricbeat -httpprof="127.0.0.1:6060" -e -v这样我们就能够通过 [url=http://127.0.0.1:6060/debug/vars]http://127.0.0.1:6060/debug/vars[/url] 访问到内部运行情况了，如下：{
"output.events.acked": 1088,
"output.write.bytes": 1027455,
"output.write.errors": 0,
"output.messages.dropped": 0,
"output.elasticsearch.publishEvents.call.count": 24,
"output.elasticsearch.read.bytes": 12215,
"output.elasticsearch.read.errors": 0,
"output.elasticsearch.write.bytes": 1027455,
"output.elasticsearch.write.errors": 0,
"output.elasticsearch.events.acked": 1088,
"output.elasticsearch.events.not_acked": 0,
"output.kafka.events.acked": 0,
"output.kafka.events.not_acked": 0,
"output.kafka.publishEvents.call.count": 0,
"output.logstash.write.errors": 0,
"output.logstash.write.bytes": 0,
"output.logstash.events.acked": 0,
"output.logstash.events.not_acked": 0,
"output.logstash.publishEvents.call.count": 0,
"output.logstash.read.bytes": 0,
"output.logstash.read.errors": 0,
"output.redis.events.acked": 0,
"output.redis.events.not_acked": 0,
"output.redis.read.bytes": 0,
"output.redis.read.errors": 0,
"output.redis.write.bytes": 0,
"output.redis.write.errors": 0,
"beat.memstats.memory_total": 155721720,
"beat.memstats.memory_alloc": 3632728,
"beat.memstats.gc_next": 6052800,
"cmdline": ["./metricbeat","-httpprof=127.0.0.1:6060","-e","-v"],
"fetches": {"system-cpu": {"events": 4, "failures": 0, "success": 4}, "system-filesystem": {"events": 20, "failures": 0, "success": 4}, "system-fsstat": {"events": 4, "failures": 0, "success": 4}, "system-load": {"events": 4, "failures": 0, "success": 4}, "system-memory": {"events": 4, "failures": 0, "success": 4}, "system-network": {"events": 44, "failures": 0, "success": 4}, "system-process": {"events": 1008, "failures": 0, "success": 4}},
"libbeat.config.module.running": 0,
"libbeat.config.module.starts": 0,
"libbeat.config.module.stops": 0,
"libbeat.config.reloads": 0,
"memstats": {"Alloc":3637704,"TotalAlloc":155
... ...比如，上面就能看到output模块Elasticsearch的处理情况，如 output.elasticsearch.events.acked 参数表示发送到 Elasticsearch Ack返回之后的消息。
现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：- module: golang
metricsets: ["heap","expvar"]
enabled: true
period: 1s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"
expvar:
namespace: "metricbeat"
path: "/debug/vars"上面的一个参数 namespace 表示自定义指标的一个命令空间，主要是为了方便管理，这里是 Metricbeat 自身的信息，所以 namespace 就是 metricbeat。
重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.acked").derivative().label("Elasticsearch Success"),.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.not_acked").derivative().label("Elasticsearch Failed")效果如下：
从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。 查看全部
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
Apache ModuleCouchbase ModuleDocker ModuleHAProxy Modulekafka ModuleMongoDB ModuleMySQL ModuleNginx ModulePostgreSQL ModulePrometheus ModuleRedis ModuleSystem ModuleZooKeeper Module
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：$(document).ready(function() {$('pre code').each(function(i, block) { hljs.highlightBlock( block); }); });import _ "expvar"如果 Golang 没有启动 http 服务，使用下面的方式启动一个即可，这里端口是 6060，如下：func metricsHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
first := true
report := func(key string, value interface{}) {
if !first {
fmt.Fprintf(w, ",\n")
}
first = false
if str, ok := value.(string); ok {
fmt.Fprintf(w, "%q: %q", key, str)
} else {
fmt.Fprintf(w, "%q: %v", key, value)
}
}
fmt.Fprintf(w, "{\n")
expvar.Do(func(kv expvar.KeyValue) {
report(kv.Key, kv.Value)
})
fmt.Fprintf(w, "\n}\n")
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/debug/vars", metricsHandler)
endpoint := http.ListenAndServe("localhost:6060", mux)
}默认注册的访问路径是/debug/vars， 编译启动之后，就可以通过 http://localhost:6060/debug/vars 来访问 expvar 以 JSON 格式暴露出来的这些内部变量，默认提供了 Golang 的 runtime.Memstats 信息，也就是上面分析的数据源，当然你还可以注册自己的变量，这里暂时不提。
OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.ymlmetricbeat.modules:
- module: golang
metricsets: ["heap"]
enabled: true
period: 10s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"上面的参数启用了 Golang 监控模块，并且会10秒获取一次配置路径的返回内存数据，我们同样配置该配置文件，设置数据输出到本机的 Elasticsearch：output.elasticsearch:
hosts: ["localhost:9200"]
现在启动 Metricbeat：./metricbeat -e -v现在在 Elasticsearch 应该就有数据了，当然记得确保 Elasticsearch 和 Kibana 是可用状态，你可以在 Kibana 根据数据灵活自定义可视化，推荐使用 Timelion 来进行分析，当然为了方便也可以直接导入提供的样例仪表板，就是上面第一个图的效果。
关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：var inerInt int64 = 1024
pubInt := expvar.NewInt("your_metric_key")
pubInt.Set(inerInt)
pubInt.Add(2)在 Metricbeat 内部也同样暴露了很多内部运行的信息，所以 Metricbeat 可以自己监控自己了。。。
首先，启动的时候带上参数设置pprof监控的地址，如下：./metricbeat -httpprof="127.0.0.1:6060" -e -v这样我们就能够通过 [url=http://127.0.0.1:6060/debug/vars]http://127.0.0.1:6060/debug/vars[/url] 访问到内部运行情况了，如下：{
"output.events.acked": 1088,
"output.write.bytes": 1027455,
"output.write.errors": 0,
"output.messages.dropped": 0,
"output.elasticsearch.publishEvents.call.count": 24,
"output.elasticsearch.read.bytes": 12215,
"output.elasticsearch.read.errors": 0,
"output.elasticsearch.write.bytes": 1027455,
"output.elasticsearch.write.errors": 0,
"output.elasticsearch.events.acked": 1088,
"output.elasticsearch.events.not_acked": 0,
"output.kafka.events.acked": 0,
"output.kafka.events.not_acked": 0,
"output.kafka.publishEvents.call.count": 0,
"output.logstash.write.errors": 0,
"output.logstash.write.bytes": 0,
"output.logstash.events.acked": 0,
"output.logstash.events.not_acked": 0,
"output.logstash.publishEvents.call.count": 0,
"output.logstash.read.bytes": 0,
"output.logstash.read.errors": 0,
"output.redis.events.acked": 0,
"output.redis.events.not_acked": 0,
"output.redis.read.bytes": 0,
"output.redis.read.errors": 0,
"output.redis.write.bytes": 0,
"output.redis.write.errors": 0,
"beat.memstats.memory_total": 155721720,
"beat.memstats.memory_alloc": 3632728,
"beat.memstats.gc_next": 6052800,
"cmdline": ["./metricbeat","-httpprof=127.0.0.1:6060","-e","-v"],
"fetches": {"system-cpu": {"events": 4, "failures": 0, "success": 4}, "system-filesystem": {"events": 20, "failures": 0, "success": 4}, "system-fsstat": {"events": 4, "failures": 0, "success": 4}, "system-load": {"events": 4, "failures": 0, "success": 4}, "system-memory": {"events": 4, "failures": 0, "success": 4}, "system-network": {"events": 44, "failures": 0, "success": 4}, "system-process": {"events": 1008, "failures": 0, "success": 4}},
"libbeat.config.module.running": 0,
"libbeat.config.module.starts": 0,
"libbeat.config.module.stops": 0,
"libbeat.config.reloads": 0,
"memstats": {"Alloc":3637704,"TotalAlloc":155
... ...比如，上面就能看到output模块Elasticsearch的处理情况，如 output.elasticsearch.events.acked 参数表示发送到 Elasticsearch Ack返回之后的消息。
现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：- module: golang
metricsets: ["heap","expvar"]
enabled: true
period: 1s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"
expvar:
namespace: "metricbeat"
path: "/debug/vars"上面的一个参数 namespace 表示自定义指标的一个命令空间，主要是为了方便管理，这里是 Metricbeat 自身的信息，所以 namespace 就是 metricbeat。
重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.acked").derivative().label("Elasticsearch Success"),.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.not_acked").derivative().label("Elasticsearch Failed")效果如下：
从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。 查看全部
Golang 因为其语法简单，上手快且方便部署正被越来越多的开发者所青睐，一个 Golang 程序开发好了之后，势必要关心其运行情况，今天在这里就给大家介绍一下如果使用 Elastic Stack 来分析 Golang 程序的内存使用情况，方便对 Golang 程序做长期监控进而调优和诊断，甚至发现一些潜在的内存泄露等问题。
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：
OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.yml
现在启动 Metricbeat：
关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：
首先，启动的时候带上参数设置pprof监控的地址，如下：
现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：
重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：
从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
- Apache Module
- Couchbase Module
- Docker Module
- HAProxy Module
- kafka Module
- MongoDB Module
- MySQL Module
- Nginx Module
- PostgreSQL Module
- Prometheus Module
- Redis Module
- System Module
- ZooKeeper Module
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：
import _ "expvar"func metricsHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
first := true
report := func(key string, value interface{}) {
if !first {
fmt.Fprintf(w, ",\n")
}
first = false
if str, ok := value.(string); ok {
fmt.Fprintf(w, "%q: %q", key, str)
} else {
fmt.Fprintf(w, "%q: %v", key, value)
}
}
fmt.Fprintf(w, "{\n")
expvar.Do(func(kv expvar.KeyValue) {
report(kv.Key, kv.Value)
})
fmt.Fprintf(w, "\n}\n")
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/debug/vars", metricsHandler)
endpoint := http.ListenAndServe("localhost:6060", mux)
}OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.yml
metricbeat.modules:
- module: golang
metricsets: ["heap"]
enabled: true
period: 10s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"output.elasticsearch:
hosts: ["localhost:9200"]现在启动 Metricbeat：
./metricbeat -e -v关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：
var inerInt int64 = 1024
pubInt := expvar.NewInt("your_metric_key")
pubInt.Set(inerInt)
pubInt.Add(2)首先，启动的时候带上参数设置pprof监控的地址，如下：
./metricbeat -httpprof="127.0.0.1:6060" -e -v{
"output.events.acked": 1088,
"output.write.bytes": 1027455,
"output.write.errors": 0,
"output.messages.dropped": 0,
"output.elasticsearch.publishEvents.call.count": 24,
"output.elasticsearch.read.bytes": 12215,
"output.elasticsearch.read.errors": 0,
"output.elasticsearch.write.bytes": 1027455,
"output.elasticsearch.write.errors": 0,
"output.elasticsearch.events.acked": 1088,
"output.elasticsearch.events.not_acked": 0,
"output.kafka.events.acked": 0,
"output.kafka.events.not_acked": 0,
"output.kafka.publishEvents.call.count": 0,
"output.logstash.write.errors": 0,
"output.logstash.write.bytes": 0,
"output.logstash.events.acked": 0,
"output.logstash.events.not_acked": 0,
"output.logstash.publishEvents.call.count": 0,
"output.logstash.read.bytes": 0,
"output.logstash.read.errors": 0,
"output.redis.events.acked": 0,
"output.redis.events.not_acked": 0,
"output.redis.read.bytes": 0,
"output.redis.read.errors": 0,
"output.redis.write.bytes": 0,
"output.redis.write.errors": 0,
"beat.memstats.memory_total": 155721720,
"beat.memstats.memory_alloc": 3632728,
"beat.memstats.gc_next": 6052800,
"cmdline": ["./metricbeat","-httpprof=127.0.0.1:6060","-e","-v"],
"fetches": {"system-cpu": {"events": 4, "failures": 0, "success": 4}, "system-filesystem": {"events": 20, "failures": 0, "success": 4}, "system-fsstat": {"events": 4, "failures": 0, "success": 4}, "system-load": {"events": 4, "failures": 0, "success": 4}, "system-memory": {"events": 4, "failures": 0, "success": 4}, "system-network": {"events": 44, "failures": 0, "success": 4}, "system-process": {"events": 1008, "failures": 0, "success": 4}},
"libbeat.config.module.running": 0,
"libbeat.config.module.starts": 0,
"libbeat.config.module.stops": 0,
"libbeat.config.reloads": 0,
"memstats": {"Alloc":3637704,"TotalAlloc":155
... ...现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：
- module: golang
metricsets: ["heap","expvar"]
enabled: true
period: 1s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"
expvar:
namespace: "metricbeat"
path: "/debug/vars"重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：
.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.acked").derivative().label("Elasticsearch Success"),.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.not_acked").derivative().label("Elasticsearch Failed")从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。
对话 Kibana 之父：如果需要，你应该自己动手编写工具
资讯动态 • medcl 发表了文章 • 1 个评论 • 1128 次浏览 • 2017-01-11 11:45
转载：http://www.infoq.com/cn/news/2 ... nTool
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
如果你有一个想法，把它code出来，build起来。不要等其他人的开源代码，有可能你会等到，但是有可能你永远等不到。在你写出来之后，你没准会收获惊喜。
查看全部
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
如果你有一个想法，把它code出来，build起来。不要等其他人的开源代码，有可能你会等到，但是有可能你永远等不到。在你写出来之后，你没准会收获惊喜。
查看全部
转载：http://www.infoq.com/cn/news/2 ... nTool
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
如果你有一个想法，把它code出来，build起来。不要等其他人的开源代码，有可能你会等到，但是有可能你永远等不到。在你写出来之后，你没准会收获惊喜。
kibaba 5.2.2版本中，如果没有查询结果，dashboard报表显示No results found，有没有什么办法不让页面显示no relusts found，显示默认的数据0即可
回复Kibana • loopmocker 回复了问题 • 2 人关注 • 1 个回复 • 619 次浏览 • 3 天前
Kibana error with X-Pack monitoring
回复Kibana • medcl 回复了问题 • 2 人关注 • 1 个回复 • 264 次浏览 • 2017-06-19 12:47
ELK - Kibana doesn't recognize geo_point field
回复Kibana • kennywu76 回复了问题 • 2 人关注 • 1 个回复 • 287 次浏览 • 2017-06-06 18:17
使用 Elastic Stack 来监控和调优 Golang 应用程序
Beats • medcl 发表了文章 • 0 个评论 • 2628 次浏览 • 2017-03-03 11:16
Golang 因为其语法简单，上手快且方便部署正被越来越多的开发者所青睐，一个 Golang 程序开发好了之后，势必要关心其运行情况，今天在这里就给大家介绍一下如果使用 Elastic Stack 来分析 Golang 程序的内存使用情况，方便对 Golang 程序做长期监控进而调优和诊断，甚至发现一些潜在的内存泄露等问题。
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
Apache ModuleCouchbase ModuleDocker ModuleHAProxy Modulekafka ModuleMongoDB ModuleMySQL ModuleNginx ModulePostgreSQL ModulePrometheus ModuleRedis ModuleSystem ModuleZooKeeper Module
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：import _ "expvar"如果 Golang 没有启动 http 服务，使用下面的方式启动一个即可，这里端口是 6060，如下：func metricsHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
first := true
report := func(key string, value interface{}) {
if !first {
fmt.Fprintf(w, ",\n")
}
first = false
if str, ok := value.(string); ok {
fmt.Fprintf(w, "%q: %q", key, str)
} else {
fmt.Fprintf(w, "%q: %v", key, value)
}
}
fmt.Fprintf(w, "{\n")
expvar.Do(func(kv expvar.KeyValue) {
report(kv.Key, kv.Value)
})
fmt.Fprintf(w, "\n}\n")
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/debug/vars", metricsHandler)
endpoint := http.ListenAndServe("localhost:6060", mux)
}默认注册的访问路径是/debug/vars， 编译启动之后，就可以通过 http://localhost:6060/debug/vars 来访问 expvar 以 JSON 格式暴露出来的这些内部变量，默认提供了 Golang 的 runtime.Memstats 信息，也就是上面分析的数据源，当然你还可以注册自己的变量，这里暂时不提。
OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.ymlmetricbeat.modules:
- module: golang
metricsets: ["heap"]
enabled: true
period: 10s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"上面的参数启用了 Golang 监控模块，并且会10秒获取一次配置路径的返回内存数据，我们同样配置该配置文件，设置数据输出到本机的 Elasticsearch：output.elasticsearch:
hosts: ["localhost:9200"]
现在启动 Metricbeat：./metricbeat -e -v现在在 Elasticsearch 应该就有数据了，当然记得确保 Elasticsearch 和 Kibana 是可用状态，你可以在 Kibana 根据数据灵活自定义可视化，推荐使用 Timelion 来进行分析，当然为了方便也可以直接导入提供的样例仪表板，就是上面第一个图的效果。
关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：var inerInt int64 = 1024
pubInt := expvar.NewInt("your_metric_key")
pubInt.Set(inerInt)
pubInt.Add(2)在 Metricbeat 内部也同样暴露了很多内部运行的信息，所以 Metricbeat 可以自己监控自己了。。。
首先，启动的时候带上参数设置pprof监控的地址，如下：./metricbeat -httpprof="127.0.0.1:6060" -e -v这样我们就能够通过 [url=http://127.0.0.1:6060/debug/vars]http://127.0.0.1:6060/debug/vars[/url] 访问到内部运行情况了，如下：{
"output.events.acked": 1088,
"output.write.bytes": 1027455,
"output.write.errors": 0,
"output.messages.dropped": 0,
"output.elasticsearch.publishEvents.call.count": 24,
"output.elasticsearch.read.bytes": 12215,
"output.elasticsearch.read.errors": 0,
"output.elasticsearch.write.bytes": 1027455,
"output.elasticsearch.write.errors": 0,
"output.elasticsearch.events.acked": 1088,
"output.elasticsearch.events.not_acked": 0,
"output.kafka.events.acked": 0,
"output.kafka.events.not_acked": 0,
"output.kafka.publishEvents.call.count": 0,
"output.logstash.write.errors": 0,
"output.logstash.write.bytes": 0,
"output.logstash.events.acked": 0,
"output.logstash.events.not_acked": 0,
"output.logstash.publishEvents.call.count": 0,
"output.logstash.read.bytes": 0,
"output.logstash.read.errors": 0,
"output.redis.events.acked": 0,
"output.redis.events.not_acked": 0,
"output.redis.read.bytes": 0,
"output.redis.read.errors": 0,
"output.redis.write.bytes": 0,
"output.redis.write.errors": 0,
"beat.memstats.memory_total": 155721720,
"beat.memstats.memory_alloc": 3632728,
"beat.memstats.gc_next": 6052800,
"cmdline": ["./metricbeat","-httpprof=127.0.0.1:6060","-e","-v"],
"fetches": {"system-cpu": {"events": 4, "failures": 0, "success": 4}, "system-filesystem": {"events": 20, "failures": 0, "success": 4}, "system-fsstat": {"events": 4, "failures": 0, "success": 4}, "system-load": {"events": 4, "failures": 0, "success": 4}, "system-memory": {"events": 4, "failures": 0, "success": 4}, "system-network": {"events": 44, "failures": 0, "success": 4}, "system-process": {"events": 1008, "failures": 0, "success": 4}},
"libbeat.config.module.running": 0,
"libbeat.config.module.starts": 0,
"libbeat.config.module.stops": 0,
"libbeat.config.reloads": 0,
"memstats": {"Alloc":3637704,"TotalAlloc":155
... ...比如，上面就能看到output模块Elasticsearch的处理情况，如 output.elasticsearch.events.acked 参数表示发送到 Elasticsearch Ack返回之后的消息。
现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：- module: golang
metricsets: ["heap","expvar"]
enabled: true
period: 1s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"
expvar:
namespace: "metricbeat"
path: "/debug/vars"上面的一个参数 namespace 表示自定义指标的一个命令空间，主要是为了方便管理，这里是 Metricbeat 自身的信息，所以 namespace 就是 metricbeat。
重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.acked").derivative().label("Elasticsearch Success"),.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.not_acked").derivative().label("Elasticsearch Failed")效果如下：
从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。 查看全部
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
Apache ModuleCouchbase ModuleDocker ModuleHAProxy Modulekafka ModuleMongoDB ModuleMySQL ModuleNginx ModulePostgreSQL ModulePrometheus ModuleRedis ModuleSystem ModuleZooKeeper Module
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：import _ "expvar"如果 Golang 没有启动 http 服务，使用下面的方式启动一个即可，这里端口是 6060，如下：func metricsHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
first := true
report := func(key string, value interface{}) {
if !first {
fmt.Fprintf(w, ",\n")
}
first = false
if str, ok := value.(string); ok {
fmt.Fprintf(w, "%q: %q", key, str)
} else {
fmt.Fprintf(w, "%q: %v", key, value)
}
}
fmt.Fprintf(w, "{\n")
expvar.Do(func(kv expvar.KeyValue) {
report(kv.Key, kv.Value)
})
fmt.Fprintf(w, "\n}\n")
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/debug/vars", metricsHandler)
endpoint := http.ListenAndServe("localhost:6060", mux)
}默认注册的访问路径是/debug/vars， 编译启动之后，就可以通过 http://localhost:6060/debug/vars 来访问 expvar 以 JSON 格式暴露出来的这些内部变量，默认提供了 Golang 的 runtime.Memstats 信息，也就是上面分析的数据源，当然你还可以注册自己的变量，这里暂时不提。
OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.ymlmetricbeat.modules:
- module: golang
metricsets: ["heap"]
enabled: true
period: 10s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"上面的参数启用了 Golang 监控模块，并且会10秒获取一次配置路径的返回内存数据，我们同样配置该配置文件，设置数据输出到本机的 Elasticsearch：output.elasticsearch:
hosts: ["localhost:9200"]
现在启动 Metricbeat：./metricbeat -e -v现在在 Elasticsearch 应该就有数据了，当然记得确保 Elasticsearch 和 Kibana 是可用状态，你可以在 Kibana 根据数据灵活自定义可视化，推荐使用 Timelion 来进行分析，当然为了方便也可以直接导入提供的样例仪表板，就是上面第一个图的效果。
关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：var inerInt int64 = 1024
pubInt := expvar.NewInt("your_metric_key")
pubInt.Set(inerInt)
pubInt.Add(2)在 Metricbeat 内部也同样暴露了很多内部运行的信息，所以 Metricbeat 可以自己监控自己了。。。
首先，启动的时候带上参数设置pprof监控的地址，如下：./metricbeat -httpprof="127.0.0.1:6060" -e -v这样我们就能够通过 [url=http://127.0.0.1:6060/debug/vars]http://127.0.0.1:6060/debug/vars[/url] 访问到内部运行情况了，如下：{
"output.events.acked": 1088,
"output.write.bytes": 1027455,
"output.write.errors": 0,
"output.messages.dropped": 0,
"output.elasticsearch.publishEvents.call.count": 24,
"output.elasticsearch.read.bytes": 12215,
"output.elasticsearch.read.errors": 0,
"output.elasticsearch.write.bytes": 1027455,
"output.elasticsearch.write.errors": 0,
"output.elasticsearch.events.acked": 1088,
"output.elasticsearch.events.not_acked": 0,
"output.kafka.events.acked": 0,
"output.kafka.events.not_acked": 0,
"output.kafka.publishEvents.call.count": 0,
"output.logstash.write.errors": 0,
"output.logstash.write.bytes": 0,
"output.logstash.events.acked": 0,
"output.logstash.events.not_acked": 0,
"output.logstash.publishEvents.call.count": 0,
"output.logstash.read.bytes": 0,
"output.logstash.read.errors": 0,
"output.redis.events.acked": 0,
"output.redis.events.not_acked": 0,
"output.redis.read.bytes": 0,
"output.redis.read.errors": 0,
"output.redis.write.bytes": 0,
"output.redis.write.errors": 0,
"beat.memstats.memory_total": 155721720,
"beat.memstats.memory_alloc": 3632728,
"beat.memstats.gc_next": 6052800,
"cmdline": ["./metricbeat","-httpprof=127.0.0.1:6060","-e","-v"],
"fetches": {"system-cpu": {"events": 4, "failures": 0, "success": 4}, "system-filesystem": {"events": 20, "failures": 0, "success": 4}, "system-fsstat": {"events": 4, "failures": 0, "success": 4}, "system-load": {"events": 4, "failures": 0, "success": 4}, "system-memory": {"events": 4, "failures": 0, "success": 4}, "system-network": {"events": 44, "failures": 0, "success": 4}, "system-process": {"events": 1008, "failures": 0, "success": 4}},
"libbeat.config.module.running": 0,
"libbeat.config.module.starts": 0,
"libbeat.config.module.stops": 0,
"libbeat.config.reloads": 0,
"memstats": {"Alloc":3637704,"TotalAlloc":155
... ...比如，上面就能看到output模块Elasticsearch的处理情况，如 output.elasticsearch.events.acked 参数表示发送到 Elasticsearch Ack返回之后的消息。
现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：- module: golang
metricsets: ["heap","expvar"]
enabled: true
period: 1s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"
expvar:
namespace: "metricbeat"
path: "/debug/vars"上面的一个参数 namespace 表示自定义指标的一个命令空间，主要是为了方便管理，这里是 Metricbeat 自身的信息，所以 namespace 就是 metricbeat。
重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.acked").derivative().label("Elasticsearch Success"),.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.not_acked").derivative().label("Elasticsearch Failed")效果如下：
从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。 查看全部
Golang 因为其语法简单，上手快且方便部署正被越来越多的开发者所青睐，一个 Golang 程序开发好了之后，势必要关心其运行情况，今天在这里就给大家介绍一下如果使用 Elastic Stack 来分析 Golang 程序的内存使用情况，方便对 Golang 程序做长期监控进而调优和诊断，甚至发现一些潜在的内存泄露等问题。
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：
OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.yml
现在启动 Metricbeat：
关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：
首先，启动的时候带上参数设置pprof监控的地址，如下：
现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：
重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：
从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
- Apache Module
- Couchbase Module
- Docker Module
- HAProxy Module
- kafka Module
- MongoDB Module
- MySQL Module
- Nginx Module
- PostgreSQL Module
- Prometheus Module
- Redis Module
- System Module
- ZooKeeper Module
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：
import _ "expvar"func metricsHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
first := true
report := func(key string, value interface{}) {
if !first {
fmt.Fprintf(w, ",\n")
}
first = false
if str, ok := value.(string); ok {
fmt.Fprintf(w, "%q: %q", key, str)
} else {
fmt.Fprintf(w, "%q: %v", key, value)
}
}
fmt.Fprintf(w, "{\n")
expvar.Do(func(kv expvar.KeyValue) {
report(kv.Key, kv.Value)
})
fmt.Fprintf(w, "\n}\n")
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/debug/vars", metricsHandler)
endpoint := http.ListenAndServe("localhost:6060", mux)
}OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.yml
metricbeat.modules:
- module: golang
metricsets: ["heap"]
enabled: true
period: 10s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"output.elasticsearch:
hosts: ["localhost:9200"]现在启动 Metricbeat：
./metricbeat -e -v关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：
var inerInt int64 = 1024
pubInt := expvar.NewInt("your_metric_key")
pubInt.Set(inerInt)
pubInt.Add(2)首先，启动的时候带上参数设置pprof监控的地址，如下：
./metricbeat -httpprof="127.0.0.1:6060" -e -v{
"output.events.acked": 1088,
"output.write.bytes": 1027455,
"output.write.errors": 0,
"output.messages.dropped": 0,
"output.elasticsearch.publishEvents.call.count": 24,
"output.elasticsearch.read.bytes": 12215,
"output.elasticsearch.read.errors": 0,
"output.elasticsearch.write.bytes": 1027455,
"output.elasticsearch.write.errors": 0,
"output.elasticsearch.events.acked": 1088,
"output.elasticsearch.events.not_acked": 0,
"output.kafka.events.acked": 0,
"output.kafka.events.not_acked": 0,
"output.kafka.publishEvents.call.count": 0,
"output.logstash.write.errors": 0,
"output.logstash.write.bytes": 0,
"output.logstash.events.acked": 0,
"output.logstash.events.not_acked": 0,
"output.logstash.publishEvents.call.count": 0,
"output.logstash.read.bytes": 0,
"output.logstash.read.errors": 0,
"output.redis.events.acked": 0,
"output.redis.events.not_acked": 0,
"output.redis.read.bytes": 0,
"output.redis.read.errors": 0,
"output.redis.write.bytes": 0,
"output.redis.write.errors": 0,
"beat.memstats.memory_total": 155721720,
"beat.memstats.memory_alloc": 3632728,
"beat.memstats.gc_next": 6052800,
"cmdline": ["./metricbeat","-httpprof=127.0.0.1:6060","-e","-v"],
"fetches": {"system-cpu": {"events": 4, "failures": 0, "success": 4}, "system-filesystem": {"events": 20, "failures": 0, "success": 4}, "system-fsstat": {"events": 4, "failures": 0, "success": 4}, "system-load": {"events": 4, "failures": 0, "success": 4}, "system-memory": {"events": 4, "failures": 0, "success": 4}, "system-network": {"events": 44, "failures": 0, "success": 4}, "system-process": {"events": 1008, "failures": 0, "success": 4}},
"libbeat.config.module.running": 0,
"libbeat.config.module.starts": 0,
"libbeat.config.module.stops": 0,
"libbeat.config.reloads": 0,
"memstats": {"Alloc":3637704,"TotalAlloc":155
... ...现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：
- module: golang
metricsets: ["heap","expvar"]
enabled: true
period: 1s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"
expvar:
namespace: "metricbeat"
path: "/debug/vars"重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：
.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.acked").derivative().label("Elasticsearch Success"),.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.not_acked").derivative().label("Elasticsearch Failed")从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。
对话 Kibana 之父：如果需要，你应该自己动手编写工具
资讯动态 • medcl 发表了文章 • 1 个评论 • 1128 次浏览 • 2017-01-11 11:45
转载：http://www.infoq.com/cn/news/2 ... nTool
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
如果你有一个想法，把它code出来，build起来。不要等其他人的开源代码，有可能你会等到，但是有可能你永远等不到。在你写出来之后，你没准会收获惊喜。
查看全部
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
如果你有一个想法，把它code出来，build起来。不要等其他人的开源代码，有可能你会等到，但是有可能你永远等不到。在你写出来之后，你没准会收获惊喜。
查看全部
转载：http://www.infoq.com/cn/news/2 ... nTool
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
如果你有一个想法，把它code出来，build起来。不要等其他人的开源代码，有可能你会等到，但是有可能你永远等不到。在你写出来之后，你没准会收获惊喜。
Day21: 如何快速把Kibana4 Discover页的Document Table导出成CSV
Advent • 三斗室 发表了文章 • 6 个评论 • 2066 次浏览 • 2015-12-24 16:33
我们都知道Kibana4里，所有的aggregation生成的visualize都可以在请求细节查看里选择`Export`成raw或者formatted。其中formatted就是CSV文件。
但是Discover页上，除了顶部的date_histogram这个visualize，更重要的是下边的search document table的内容。当我们通过搜索发现异常信息，想要长期保存证据，或者分享给其他没有权限的外部人员的时候，单纯保存search到es，或者分享单条日志的link都不顶用，还是需要能导出成一个文件。
可惜Kibana4没有针对search document table的导出！
国外一家叫MineWhat的公司，最近公开了一个非常细小的创新方案，意图解决这个问题。他们的方式是：避免修改Kibana源码，而通过chrome浏览器插件完成……
点击这个地址安装chrome插件：https://chrome.google.com/webs ... lated
然后再访问Kibana的时候，你会发现自己的搜索框最右侧多了一个CSV按钮：
然后点击这个『CSV』按钮，会弹出一片提示：
可以点击选择，把search document table内容保存到本机的复制粘贴板，还是Google Drive网盘。
我们当然选择本机……
然后打开本地的文本文件，Ctrl+V，就看到编辑器里出现了整个CSV内容。
实测下来，发现有个小问题，粘贴出来的数据里丢掉了空格~不过聊胜于无吧，还是介绍给大家一试。
注意：这个功能只会导出目前页面上已经展示出来的table内容。并不代表其使用了scroll API去ES拉取全部结果集！ 查看全部
但是Discover页上，除了顶部的date_histogram这个visualize，更重要的是下边的search document table的内容。当我们通过搜索发现异常信息，想要长期保存证据，或者分享给其他没有权限的外部人员的时候，单纯保存search到es，或者分享单条日志的link都不顶用，还是需要能导出成一个文件。
可惜Kibana4没有针对search document table的导出！
国外一家叫MineWhat的公司，最近公开了一个非常细小的创新方案，意图解决这个问题。他们的方式是：避免修改Kibana源码，而通过chrome浏览器插件完成……
点击这个地址安装chrome插件：https://chrome.google.com/webs ... lated
然后再访问Kibana的时候，你会发现自己的搜索框最右侧多了一个CSV按钮：
然后点击这个『CSV』按钮，会弹出一片提示：
可以点击选择，把search document table内容保存到本机的复制粘贴板，还是Google Drive网盘。
我们当然选择本机……
然后打开本地的文本文件，Ctrl+V，就看到编辑器里出现了整个CSV内容。
实测下来，发现有个小问题，粘贴出来的数据里丢掉了空格~不过聊胜于无吧，还是介绍给大家一试。
注意：这个功能只会导出目前页面上已经展示出来的table内容。并不代表其使用了scroll API去ES拉取全部结果集！ 查看全部
我们都知道Kibana4里，所有的aggregation生成的visualize都可以在请求细节查看里选择`Export`成raw或者formatted。其中formatted就是CSV文件。
但是Discover页上，除了顶部的date_histogram这个visualize，更重要的是下边的search document table的内容。当我们通过搜索发现异常信息，想要长期保存证据，或者分享给其他没有权限的外部人员的时候，单纯保存search到es，或者分享单条日志的link都不顶用，还是需要能导出成一个文件。
可惜Kibana4没有针对search document table的导出！
国外一家叫MineWhat的公司，最近公开了一个非常细小的创新方案，意图解决这个问题。他们的方式是：避免修改Kibana源码，而通过chrome浏览器插件完成……
点击这个地址安装chrome插件：https://chrome.google.com/webs ... lated
然后再访问Kibana的时候，你会发现自己的搜索框最右侧多了一个CSV按钮：
然后点击这个『CSV』按钮，会弹出一片提示：
可以点击选择，把search document table内容保存到本机的复制粘贴板，还是Google Drive网盘。
我们当然选择本机……
然后打开本地的文本文件，Ctrl+V，就看到编辑器里出现了整个CSV内容。
实测下来，发现有个小问题，粘贴出来的数据里丢掉了空格~不过聊胜于无吧，还是介绍给大家一试。
注意：这个功能只会导出目前页面上已经展示出来的table内容。并不代表其使用了scroll API去ES拉取全部结果集！
但是Discover页上，除了顶部的date_histogram这个visualize，更重要的是下边的search document table的内容。当我们通过搜索发现异常信息，想要长期保存证据，或者分享给其他没有权限的外部人员的时候，单纯保存search到es，或者分享单条日志的link都不顶用，还是需要能导出成一个文件。
可惜Kibana4没有针对search document table的导出！
国外一家叫MineWhat的公司，最近公开了一个非常细小的创新方案，意图解决这个问题。他们的方式是：避免修改Kibana源码，而通过chrome浏览器插件完成……
点击这个地址安装chrome插件：https://chrome.google.com/webs ... lated
然后再访问Kibana的时候，你会发现自己的搜索框最右侧多了一个CSV按钮：
然后点击这个『CSV』按钮，会弹出一片提示：
可以点击选择，把search document table内容保存到本机的复制粘贴板，还是Google Drive网盘。
我们当然选择本机……
然后打开本地的文本文件，Ctrl+V，就看到编辑器里出现了整个CSV内容。
实测下来，发现有个小问题，粘贴出来的数据里丢掉了空格~不过聊胜于无吧，还是介绍给大家一试。
注意：这个功能只会导出目前页面上已经展示出来的table内容。并不代表其使用了scroll API去ES拉取全部结果集！
Day11: timelion请求语法
Advent • 三斗室 发表了文章 • 0 个评论 • 2198 次浏览 • 2015-12-16 23:01
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 哟。 查看全部
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 的请求语法所支持的函数分为几类，罗列如下：
可视化效果类：
数据运算类：
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
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() 的简写想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
Day8：隐藏仪表盘的菜单栏
Advent • 三斗室 发表了文章 • 3 个评论 • 953 次浏览 • 2015-12-09 11:07
Kibana4 上线后，又有同事找过来。还好这次是小问题：『新版的这个仪表盘顶部菜单栏太宽了啊。头顶上监控屏幕空间有限，能不能省省？』
跟 Kibana3 相比，确实宽了点。这时候好几个方案瞬间进入我脑子里：
浏览器往下拖动一点，不过要确保定期刷新的时候还能回到拖动位置；进 ui/public/chrome/chrome.html 里把 navbar 干掉；添加一个 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 哟。 查看全部
跟 Kibana3 相比，确实宽了点。这时候好几个方案瞬间进入我脑子里：
浏览器往下拖动一点，不过要确保定期刷新的时候还能回到拖动位置；进 ui/public/chrome/chrome.html 里把 navbar 干掉；添加一个 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 相比，确实宽了点。这时候好几个方案瞬间进入我脑子里：
不过等打开 chrome.html 看了一下，发现 navbar 本身是有相关的隐藏判断的：
好了，我们试一下，把 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 哟。
跟 Kibana3 相比，确实宽了点。这时候好几个方案瞬间进入我脑子里：
- 浏览器往下拖动一点，不过要确保定期刷新的时候还能回到拖动位置；
- 进 ui/public/chrome/chrome.html 里把 navbar 干掉；
- 添加一个 bootstrap 效果，navbar 默认隐藏，鼠标挪上去自动浮现。
不过等打开 chrome.html 看了一下，发现 navbar 本身是有相关的隐藏判断的：
<nav
ng-style="::{ background: chrome.getNavBackground() }"
ng-class="{ show: chrome.getVisible() }"
class="hide navbar navbar-inverse navbar-static-top">好了，我们试一下，把 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 哟。
Day5: Kibana4的rison序列化妙用
Advent • 三斗室 发表了文章 • 0 个评论 • 1165 次浏览 • 2015-12-05 22:49
前几天，我们已经一步步搞定了一个业务日志从 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 哟。
查看全部
因为 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 贴进搜索框里。内容是：
当然我很确定我的数据是没问题的。这时候 Kibana4 的另一个特性救了我：它默认会把所有可修改的状态都 rison 序列化了放在 URL 里！于是我尝试直接在浏览器地址栏里输入下面这段 URL：
感谢 Kibana 如此开放的设计原则！
ps: 目前 nested aggregation 还没法像这样简单的绕过，不过已经有相关 pull request 在 review 中，或许 Kibana4.3/4.4 的时候就会合并了。有兴趣的同学，也可以跟我一样先睹为快哟：https://github.com/elastic/kibana/pull/5411
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
因为 Kibana 上的输入框，默认使用 querystring 语法。这个里面压根没有对 nested object 的相关语法设计。
不过经过仔细查阅，发现原来 Kibana4 的搜索输入框，其实除了 querystring 以外，还支持 JSON 字符串的方式直接定义 query！其具体处理方式就是：把你输入的字符串判断一下是否是 JSON，如果是 JSON，直接替换进{"query": 这里}；如果不是，才生成一个 querystring query 放进 {"query":{"query_string":""}}
那我们来尝试一下把第三天写的那个 nested query 贴进搜索框里。内容是：
{
"nested" : {
"path" : "video_time_duration",
"query" : {
"match" : {
"video_time_duration.type" : "1"
}
}
}
}当然我很确定我的数据是没问题的。这时候 Kibana4 的另一个特性救了我：它默认会把所有可修改的状态都 rison 序列化了放在 URL 里！于是我尝试直接在浏览器地址栏里输入下面这段 URL：
http://kibana:5601/#/discover?_g=()&_a=(columns:!(_source),index:%5Blogstash-mweibo-%5DYYYY.MM.DD,interval:auto,query:(nested:(path:video_time_duration,query:(term:(video_time_duration.type:1)))),sort:!('@timestamp',desc))感谢 Kibana 如此开放的设计原则！
ps: 目前 nested aggregation 还没法像这样简单的绕过，不过已经有相关 pull request 在 review 中，或许 Kibana4.3/4.4 的时候就会合并了。有兴趣的同学，也可以跟我一样先睹为快哟：https://github.com/elastic/kibana/pull/5411
想了解更全面的 ELK Stack 知识和细节，欢迎购买我的《ELK Stack权威指南》，也欢迎加 QQ 群：315428175 哟。
elasticsearch logstash kibana beats 资料分享
资料分享 • abcdef 发表了文章 • 1 个评论 • 1984 次浏览 • 2015-12-02 14:40
ELK系列文章推荐 http://www.ttlsa.com/log-system/elk/ 写的还不错。
ELK系列文章推荐 http://www.ttlsa.com/log-system/elk/ 写的还不错。
开源可视化和快速分析组件.
