Elastic Stack

Elastic Stack

Elastic Stack 6.0 发布 beta 版本啦!

资讯动态medcl 发表了文章 • 11 个评论 • 2653 次浏览 • 2017-08-09 10:29 • 来自相关话题

头条新闻:Elastic Stack 6.0 发布 beta 版本了。https://www.elastic.co/blog/el ... %3Dcn      注意啦,现在 6.0 还没 GA,不建议直接上生产环境,但是鼓励大家本地测试,和 5.0 一样,我们这次也有一个 Elastic Pioneer 活动,踊跃测试并发现 bug 的同学,可以获得 6.0 特殊纪念礼品一份,欢迎大家一起来捉虫,捉到的 Bug 直接在对应的 GitHub 上提交 issue,打上对应的版本 tag,如6.0.0-beta1 即可参与活动。
DGu1frNXoAEVYlM.jpg
  6.0 beta1 作为一个具备里程碑意义的版本,相比之前的 alpha 版本,又包含了哪些激动人心的新特性呢,下面我们分别来看一下吧。   Elasticsearch [下载] [6.0 Breaking Chages] https://www.elastic.co/blog/el ... eased
  • Sequence numbers and fast recovery
新的序列号机制会为每一个增删改操作分配一个顺序号,可以实现操作层面的细粒度复制,避免低效的基于索引文件的拷贝与 translog 的重做;Translog 使用新的过期机制,默认是 12 小时或者 512MB 大小,方便副本的快速恢复;该特性也为后面的跨数据中心的数据同步铺平了道路。
  • Search scalability
移除 _field_stats 接口,现在每个搜索请求多了一个轻量级的 shard prefiltering phase,提前过滤掉不需要参与实践查询的 shards,并在 shard 级别判断查询是否有效,并重写查询,只在真正有相应数据的 shard 上执行查询;新增参数 max_concurrent_shard_requests 来限制单次请求的并发分片请求数。
  • Preventing full disks
新增参数来控制当磁盘占用达到某个警戒线之后不允许继续写入;限制 Elasticsearch 的日志占用,默认按 128MB 滚动覆盖,限制 ES 总日志文件大小不超过 2GB。
  • Removal of default passwords
为了更加安全,XPack 的默认密码 changeme 去掉了,提供了相应的工具来进行配置。
  • 优化 Profiling 的开销占用,进一步较少针对超时及查询取消的检查开销
  • 提升 Percolator 的性能
 更多改进:[Beta1 Release Notes]     Kibana [下载] [Breaking Changes] https://www.elastic.co/blog/ki ... eased
  • Upgrade Assistant and Rolling Upgrade Support
  新增的集群升级助手,属于 X-Pack 的免费功能,自动帮你诊断集群升级要处理的各种问题,支持跨大版本间滚动升级的检测。
issue_1619_2.png
  • Watcher UI for Threshold Based Alerts
新增提供基于阈值的快速设置 Watcher 预警规则的 UI 界面。
Snip20170809_9.png
  • Experimental Kibana Query Language
引入新的 Kibana 查询语言:Kuery,支持智能提示和错误失败等丰富的特性。
  • Refactoring of the Visualizations Code
通过此次重构,开发者不再受限于只能使用 Angular 来做渲染了,以及扩展更多的灵活性,方便对 Kibana 的二次开发。
issue_11786_0.JPG
  • X-Pack Monitoring Email Notifications for Cluster Alerts
支持设置监控的告警邮件发送。
Snip20170809_7.png
  • Cluster Alert for X-Pack License Expiration
证书过期现在有自动的提示了。
image_(3).png
  • New Colors to Improve Accessibility
改进Kibana的可用性,如导航的快捷键支持,对色盲色弱用户的友好支持等。
Screen_Shot_2017-07-28_at_1.26_.42_PM_.png
Snip20170809_10.png
  • Full Screen Mode for Dashboard
新增的全屏模式对 Dashboard 的大屏展现更加友好。
Snip20170809_8.png
更多详情:[6.0 Beta1 Release Notes]     Logstash [下载]  https://www.elastic.co/blog/lo ... eased
  • Pipeline Viewer
X-Pack Basic 新增的免费功能,用户可以非常直观的了解管道配置,以图形化的方式来展现,从而了解数据流向与处理逻辑,包括管道执行的各项重要指标,从而优化 Logstash 性能。
pipeline_viz2.png
  • Centrally manage configurations
用户可以方便的通过图形化 UI 集中式批量管理所有 Logstash 实例的配置文件,并动态修改生效,不需要重启和单独维护每个 Logstash 的实例。
Snip20170809_11.png
  • Ingest to Logstash convertor
提供一个方便将 Elasticsearch Ingest 脚本转换为 Logstash 配置文件的工具。
$LS_HOME/bin/ingest-convert.sh --input file:///tmp/ingest/apache.json --output file:///tmp/ingest/apache.conf 

   Beats [下载] [Breaking Changes] https://www.elastic.co/blog/be ... eased
  • Auditbeat
一个新的 Beat,通过将 Linux Kernel 内的各种事件统统接入到 Elastic Stack 来进行安全审计。
auditbeat-file-integrity-dashboard.png
  • New commands and configuration layout
一些常见的操作,你现在可以直接通过命令的方式来快速操作了。
$ metricbeat modules list
$ metricbeat modules enable redis
$ metricbeat modules disable redis
  • Add Docker metadata to the Docker logs
将 Docker 相关的元数据附加到日志里面,从而丰富上层的分析与应用,详情可见这篇博客:https://www.elastic.co/blog/en ... ebeat
  • Internal pipeline refactoring
Beats 在管道这一块做了大量的重构,现在不支持 1 个管道 2 个输出了。   更多详情:[Beta1 Release Notes]    ES-Hadoop [下载] https://www.elastic.co/blog/es ... eased
  • Spark 2.2.0 and Stable Support for Spark Structured Streaming
  • Support for new Join Fields
  • Multiple Mappings and Multiple Index Reads
  更多详情:[Release Notes]   上面介绍的众多特性,相信总有一个能让你动心,赶紧下载试试吧,记得反馈哦!  

使用 Elastic Stack 来监控和调优 Golang 应用程序

Beatsmedcl 发表了文章 • 0 个评论 • 5838 次浏览 • 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 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 模块收集的数据进行的可视化分析吧:
df9c563e-f831-11e6-835c-183f3f9e5b94.png
  上面的图简单解读一下: 最上面一栏是 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.yml
metricbeat.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")
效果如下:
Snip20170304_9.png
从上图可以看到,发往 Elasticsearch 的消息很稳定,没有出现丢消息的情况,同时关于 Metricbeat 的内存情况,我们打开导入的 Dashboard 查看:
Snip20170304_10.png
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了,上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标,在结合 Elastic Stack 可以快速的进行分析,希望对大家有用。 最后,这个 Golang 模块目前还没 release,估计在 beats 6.0 发布,有兴趣尝鲜的可以自己下载源码打包。

Elastic Stack 5.2.2 发布

资讯动态medcl 发表了文章 • 5 个评论 • 1420 次浏览 • 2017-03-01 10:37 • 来自相关话题

Elasticsearch 5.2.2
  • 修复request熔断器没有正确处理当前运行请求数的bug,当请求返回前却被客户端关闭时没有对计数减一,会造成节点慢慢的不能处理任何请求,除非重启节点,所有的用户都应该升级 #23317
  • 修复cgroup正则解析的bug,造成节点的不能正常启动 #23219
  • 被shard锁暂缓执行的请求可能会别其他线程启动,并且该请求丢失了上下文,会造成该请求被当做非法请求而拒绝
  • 恢复terms agg的include/exclude参数的支持
  下载:https://www.elastic.co/downloads/elasticsearch 完整的Release notes:https://www.elastic.co/guide/e ... .html XPack release notes:https://www.elastic.co/guide/e ... 5.2.2   Logstash 5.2.2
  • 修复持久化队列在windows启用造成的崩溃
  • 修复多实例公用相同的数据目录造成的数据损坏
  • 修复JVM性能指标收集造成的吞吐影响
  下载:https://www.elastic.co/downloads/logstash Release notes:https://www.elastic.co/guide/e ... .html   Kibana 5.2.2
  •  之前的版本kibana的visualization依赖一个旧的Elasticsearch的include/exclude特性,但是该功能在Elasticsearch5.2.1被突然移除了,引起了kibana的visualization的错误,现在Kibana对新创建的visualization使用正确的结构,并且能在查询时自动转换遗留的旧结构到新的结构
  • 从5.2.0开始,包含sub-bucket的垂直条形图(vertical bar)配置为分组没有合适的缩减y轴,造成相当小甚至某些情况下不可用,这次回归将再次对y轴进行必要的扩展而不管其条形图的模式
  下载:https://www.elastic.co/downloads/kibana 完整Release notes https://www.elastic.co/guide/e ... .html   Beats 5.2.2
  • Metricbeat修复当docker容器被kill掉造成的docker 模块挂起的bug
  • Metricbeat修复超时时间设置而不是默认值
  Release notes:https://www.elastic.co/guide/e ... .html 下载:https://www.elastic.co/downloads/beats/

Elastic Stack 5.2.1 发布

资讯动态medcl 发表了文章 • 4 个评论 • 2668 次浏览 • 2017-02-15 14:07 • 来自相关话题

Elasticsearch 5.2.1 发布内容   基于 Lucene 6.4.1,所有5.2.0 用户都应该升级到该版本,修正了很多 bug,尤其了 Lucene6.4.1修复了两个重要的内存泄漏:
  • 当存储字段配置为“best_compression",我们依赖于 JVM 回收机制来释放解压缩实例(Deflater/Inflater instances)。然而这些类也行只使用了很少的 JVM 堆栈内存,却使用了大量了本地内存,所以可能 会出现在 JVM 回收解压缩实例之前而操作系统先用完了本地内存。 LUCENE-7647
  • 特定的查询可能会持有 IndexReader 的一个引用,当这些查询被缓存之后,本来应该已经被删除的段会因为这个引用而继续被 Lucene 持有。LUCENE-7657
  功能废弃:
  • Geo distance range 废弃,请使用`geo_distance` bucket aggregation 或 geo_distance sort来替代。#22835
 改进增强:
  • 分配解释 API(allocation explaining)在未分配主分片信息中包含陈旧的副本信息(不管是陈旧还是损坏的)#22826
  Bug 修复:
  • 如果查询超时,将缓存结果置为无效。#22807
  • Reindex 接口支持来源 es 版本<2.0,当不能清除旧的 scroll 不记录日志。
  • 将参数:search.highlight.term_vector_multi_value 保留为节点级别。
  其他细节详见 Release notes。  Download Elasticsearch 5.2.1 X-Pack 5.2.1 release notes   Kibana 5.2.1 发布内容:   在该版本中主要包括了一些重要的 bug 修复,包含一个安全风险的 fix 以及可能造成 kibana 崩溃的问题。 在5.0早期的版本中,如果配置了 SSL,特定的请求会造成 Kibana 无法释放文件打开句柄,这会造成进程随着时间推移的崩溃。请求在发生数据之前被取消也会造成进程的崩溃。还有一个安全的风险:ESA-2017-02(Http 头信息可能泄露敏感信息的问题,注:Kibana4不受影响)。   其他详见:Release notes Download Kibana 5.2.1   Beats,Logstash 发布内容见: https://www.elastic.co/guide/e ... .html https://www.elastic.co/guide/e ... .html    

Elastic Stack 5.2.0 发布

资讯动态medcl 发表了文章 • 1 个评论 • 4087 次浏览 • 2017-02-03 13:26 • 来自相关话题

本周三,Elastic 发布了 ElasticStack 的全新版本5.2.0,包含了很多激动人心的特性,让我们 一起来看看吧, (Elastic Stack 包括 Elasticsearch、Logstash、Kibana、Beats):  Elasticsearch 5.2.0 主要亮点:
  1. 新增数字和日期范围字段类型,非常方便对范围类型进行交并集的查询,比如你的数据是日历类型的数据,每天都有一些会议信息,会议的开始和结束时间都不同,你想看本周那天有空,可以使用 range fields 很方便的进行查询。了解更多
  2. 新增分片分配解释 API,会告知分片失败的具体原因,如分片损坏、磁盘写满还是配置错误,进行快速运维,以前只能根据经验到处寻找可能是什么问题,费事费力,了解更多
  3. 对 Keyword 类型标准化,在5.0将 string 类型拆成了 text 和 keyword两种类型,text 支持分词,keyword 则不分词默认支持 doc values,不过有时候你还需要对 keyword 类型进行一些标准化处理,如都转成小写,现在可以使用 normalizers 参数来指定标准化的 filter。
  4. Terms 聚合的分区,terms 聚合默认返回10个 term,以前如果你需要返回全部的 term 列表是不可能的任务(基于内存压力),现在你可以通过将请求分区,以多次请求的方式来取回这些数据,了解更多
  5. 字段折叠,在搜索时可以按某个字段的值进行折叠,在每个折叠的值内进行排序选取 topN,了解更多
  相关链接: Download Elasticsearch 5.2.0 Elasticsearch 5.2.0 release notes Elasticsearch 5.2.0 breaking changes X-Pack 5.2.0 release notes   Logstash 5.2.0 主要亮点:
  1. 新的监控 UI,现在 X-Pack 也能监控 logstash 了,X-Pack 基础免费版就包括,如下图:
    MonitoringUI-rel-blog.png
    Screen_Shot_2017-01-09_at_16.51_.49_.png
  2. 更多的监控 API,新增3个类型的统计信息:cgroup、持久化队列和 output新增持续时间字段。
  3. 离线插件管理,在很多没有公网的部署环境,都需要离线安装,以前的离线安装不够完善,尽管大部分插件没问题,但是还是存在个别插件的依赖链下载不完整的问题,为了解决这个问题,我们基本上重新设计了整个工作流程使用了新的方式来打包插件和他所有的依赖,了解更多
  相关连接: Download Logstash 5.2.0 Logstash 5.2.0 release notes   Kibana 5.2.0 主要亮点:
  1. 支持 Elasticsearch Tribe 节点,在“admin”集群的基础上,引入了新的“data”集群,“data”集群可以理解成 Kibana 后面的数据来源,可以是 tribe 节点,而“admin”集群是存放 kibana 可视化信息“。kibana”索引的地方,默认 data 和 admin 集群都是在同一个集群,且不能是 tribe 节点,目前还有一些细节正在处理,如 console 还不能很好的工作。
  2. 增加新的可视化类型:热点图(heatmap),可以很方便的按区间和按时间来显示数据的范围分布,如下图:
    Heatmap_Linechart.png
  3. 开始进行国际化的支持,感谢 IBM 团队的努力,目前已经提供了基础的框架支持,虽然是万里长征的第一大步,但也是非常激动人心的。
  4. 地图服务的改进,Elastic 自己的 Tile 地图服务已经上线几个月了,我们现在能提供10个级别的缩放了,X-Pack 基础用户可以达到12个级别的缩放,并且我们正在尝试18个级别的缩放,并且从5.2开始,我们能让这些级别动态调整,不用发布新的 Kibana。
  5. 监控容器中的 Elasticsearch,现在我们可以监控容器里面的 Elasticsearch 实例的运行情况了,CPU 利用率、GC、堆栈使用情况等,如下图:
    monitoring-elasticsearch-in-containers.png
  相关连接: Download Kibana 5.2.0 Kibana 5.2.0 release notes   Beats 5.2.0 主要亮点:
  1. 新增 Beat:Heartbeat,一个新的正式的官方beat 成员,用于可用性监控,和所有的 beat 一样,轻量级,Heartbeat 可以用于很多场景,比如安全,你不希望暴露某个端口时,使用 Heartbeat,当你发现该端口对外开启了,就可以触发通知,或者服务/网站可用性检测,服务down 了可以及时感知,目前支持:ICMP、TCP 和 HTTP 类型的监控,目前 Heartbeat还处于 beat 阶段,暂不推荐用于生产环境。
  2. Metricbeat 可跟踪网络连接,从5.2开始,Metricbeat 导出了 linux 系统的应用程序的网络连接信息,每个进程打开的 tcp 套接字,本地及远程的 ip 都包含在内,基于它,你可以进行如下的图分析:
    connections-2.png
  3. 收集Prometheus导出的指标,从5.2开始,监控系统普罗米修斯的收集模块导出的数据可以提供给 Metricbeat 然后索引进 Elasticsearch。
  相关连接: Download Beats 5.2.0 Beats 5.2.0 release notes   Elastic Stack 下载链接:https://www.elastic.co/downloads Bug 反馈:http://github.com/elastic 以后有版本的更新消息都会在这里发布一份中文版,欢迎大家关注。

对话 Kibana 之父:如果需要,你应该自己动手编写工具

资讯动态medcl 发表了文章 • 2 个评论 • 2902 次浏览 • 2017-01-11 11:45 • 来自相关话题

转载:http://www.infoq.com/cn/news/2 ... nToolElastic 中国开发者大会 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 
IMG_4857.gif
早在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的人联系我问要不要合并在成为同一家公司,我们才发现彼此的看法竟然不谋而合。
elastic-logo-H-full-color.jpg
我现在依然是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
Snip20170111_11.png
研发情况 研发出新功能的第一版本通常很快,但是需要不断的测试确保所有运转正常。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起来。不要等其他人的开源代码,有可能你会等到,但是有可能你永远等不到。在你写出来之后,你没准会收获惊喜。

 
1.png
 

Elastic Stack 5.0 正式发布

资讯动态medcl 发表了文章 • 0 个评论 • 3801 次浏览 • 2016-10-27 16:28 • 来自相关话题

Snip20161027_6.png
作者:Shay Banon,原文:https://www.elastic.co/blog/el ... eased  记得在 2016 年 2 月份,就在 Elastic{ON} 16 大会之后,我写了一篇标题为 [Heya, Elastic Stack and X-Pack] (https://www.elastic.co/blog/he ... -pack ) 的博客。经过了几乎整整一年的努力,中间发布了 5  个 Alpha,1 个 Beta 和一个 RC 版本,今天我们非常高兴的正式宣布发布 Elastic Stack 的 GA 正式版本。 并且,重要的是,于此同时,在我们的 [Elastic Cloud](https://www.elastic.co/cloud/as-a-service/signup ) 上面也同步进行了更新。所以如果你需要托管的 Elasticsearch 和 Kibana ,那么没有其它地方比这里更及时了。我们致力于让 Elastic Cloud 成为一个托管 Elasticsearch 的最佳场所。事实上,在正式版发布之前,我们也提供了 RC 版本方便你用于测试。 我们的团队今天正在庆祝这一时刻,我希望你能加入我们。 GA 版本今天已经可以下载了,如果要加入 Elastic 团队 11 月 3 号的线上活动,了解更多有关于本次发布和向工程师提问,请点击这里 [注册!](https://www.elastic.co/live/v5 )   在开始探索发布详情之前,我想借此机会来回顾一下有哪些背后的事情让我们走到今天。 ## 我们的社区 最近的 Elastic{ON} Tour,在每场活动的开场我会讨论我们公司过去几年的简短历史。最近一次活动的高潮是当我宣布我们的累计下载总数达到了七千五百万。当我第一次开始这个项目的时候,我希望她能够被能够被广泛使用,但是我们的社区的热情和激情总是不断的给我快乐和惊喜。 ## 先驱者计划 考虑到这一点,我想分享一下 [先驱者计划](https://www.elastic.co/blog/el ... ogram ) 的一些结果。该计划开始于一个简单的前提,你如何使用 Elastic Stack 对我们来说非常重要,不管是产品研发还是确保发布高质量的可用版本。我非常高兴的告诉大家自四月份发布的第一个Alpha版本,我们的社区一共提交了146个issue。 我们的社区是Elastic其中一个最宝贵的财产。事实上,在这次发布中讨论的最多的就是为什么命名为 "Elastic Stack"。 ## Elastic Stack 过去一年,我们收购了Packetbeat 团队,然后Beats 就诞生了。这是一个开源的用于构建轻量级数据收集的平台,可用于日志、基础设施监控指标、网络流量等数据的收集,并且以前所未有的简单方式来将数据发送至Logstash或Elasticsearch。同时我们热爱那些已经习惯于将 ELK 作为代表我们软件栈的你们,只不过加上Beats,我们不知道如何将“B”和E-L-K组合在一起。(NOTE:过去用过ELKB) 但Elastic Stack 远不只是一个名字。当我们开始发布一个周期,我们开发提交、构建、测试和发布的是一整个软件栈。这个很重要,从内部来保证兼容性。并且,对你来说,它可以帮助你提升部署速度,减少版本冲突,让开发者轻松的处理整个 Elastic Stack的兼容性问题。 ## 一场特性之旅 在我开始这篇博客之前,我打算列举每个产品的一些主要特性,但是发现好像很难确定从哪里开始和结束。我们每个产品和技术的leader 已经创建了单独的博客来讨论各自产品的特性,没人比他们更适合介绍其中的故事。 我个人,更是对其中的一些特性感到非常兴奋,相较于简单的罗列,我会提供一些简短概要并且鼓励你去阅读每个产品详细的博客。 Ingest Node Ingest Node 是Elasticsearch 的一个节点类型,允许你对数据做一些加工,比如:grok、geoip、date和其它索引(或重建)过程中的基本数据操作。 通过访问REST API的时候指定一个参数“?pipeline=x”来使用由一系列处理器(processors)构造的管道,它可用帮你对文档进行预处理,原生的在Elasticsearch内部,在索引之前做灵活的 ingest部署。这不代表要替换掉Logstash,也不会移除对Beats的需要,只为你设计数据采集架构时提供一种更加灵活的可能性。 Elasticsearch 性能 性能报告倾向于提供一个大纲,尤其是比较性的性能测试报告,基于此,我们花了很大力气来比较5.0.0 与之前发布的版本。数据现在已经可用了,这个数据也是我们用来检查和确保我们正在做正确的事情来保证性能,我们是如此的公开来避免由性能测试数字引起的所谓秘密和怀疑。事实上,不止测试结果,我们还公布了我们的硬件和配置,我们还开源了我们的工具链(叫做 [Rally](https://github.com/elastic/rally )) 和测试记录本身([Rally-Tracks](https://github.com/elastic/rally-tracks ))。 Metricbeat Metricbeat 替换 Topbeat 成为Elastic Stack里主要的收集度量指标的工具。和Topbeat一样,Metricbeat 收集和“top” 类似的诸如机器及进程的资源(CPU, memory, disk, network)统计信息。和Topbeat不同的是,Metricbeat 同时也收集其它系统的指标信息,如:Apache、HAProxy、MongoDB、MySQL、Nginx、PostgreSQL、 Redis和 Zookeeper,并且在不久的将来还会支持更多应用和系统。 Logstash 监控 API** - 这是一个新的监控特性提供Logstash 管道及其插件在运行时的可视状态。这个组件收集Logstash处理你数据的各种操作性统计指标信息,所有的这些信息都可通过简单的API来进行查询。 Timelion 以前以re{Search} 项目介绍过,现在Timelion 作为Kibana原生的核心组件可直接可用。Timelion 提供一个查询表达式和可视化类型让你探索基于时间的数据。 再列举几个,诸如BKD 树、scaled_float 和 half_float ,我们投入了大量的精力到 [Elasticsearch 可靠性](https://www.elastic.co/guide/e ... .html ) 中,另外Kibana惊艳的重新设计(我从来不知道我们以前有这么讨厌这些边框直到移除), Beats 支持的Kafaka输出,等等,还有很多很多。 这是一个非常大的版本发布,非常有必要阅读相关独立的博客来了解更多范围内的改进。 ## X-Pack 在Elastic 我们热爱扩展。太多我们构建的东西我们给他们起了非常有趣的名字,如:Shield、Marvel和Watcher,作为提供给我们客户的额外的插件,独立闭源但没限制开源部分的能力的特性,随着后面又增加了Graph 和Reporting,安装流程也变得困难和困惑。 来和X-Pack 打个招呼吧! 一个包含了security、alerting、monitoring & management、reporting和graph 能力的Elastic Stack的插件。我们对5.0的工程不仅限于Elastic Stack,同时也包括给X-Pack 添加如下:
  1. Kibana里的管理和监控的UI界面
  2. Kibana里创建用户和角色的UI界面
  3. 非常简化的安装流程
X-Pack 可以试用,同时提供商业和免费(基本)授权证书选项。我们尤其兴奋的将X-Pack的某些特性开放出来免费使用,详细请见 [Subscriptions](https://www.elastic.co/subscriptions ) 页。 ## 放在最后 我敬畏发布此次版本所做的所有努力,来自我们社区和客户的共同参与,以及为了将来发布所做的一系列背地里的工作。一如既往,理解一个版本的最好方式就是去体验它。      

Elastic 为 Elastic Stack 带来新的 Graph 实时图分析功能

资讯动态medcl 发表了文章 • 1 个评论 • 6966 次浏览 • 2016-03-31 09:36 • 来自相关话题

Mountain View, Calif. and Amsterdam, The Netherlands – March 30, 2016,英文原文
BestBuy2-768x414.jpg
Elastic 今天宣布发布一个新的用于 Elasticsearch 和 Kibana 的插件,通过它们您可以很方便的发现、理解和探索您现有数据之间的关系。通过结合速度与相关度的搜索与图分析,Graph 已开启一页新的篇章同时为 Elastic Stack 带来更多的使用场景。   “我们构建 Graph 来帮助您以更多的方式来分析您存储在 Elasticsearch 中的数据” -- Steve Kearns,Elastic 高级产品总监提到, “通过把相关度作为切入点来查看数据间的关系,以前需要涉及到多个系统、批量作业甚至机器学习才能做到的事情,现在变成容易解决的问题。” Graph 为 Elastic Stack 开启新的使用场景 当您往 Elasticsearch 存储数据时 -- 产品信息、用户资料、文档、日志 -- 这些数据通常会包含对象(实体、人员、角色或者机器等)之间的引用关系。最好的探索这些关系的方法就是以可视化的方式去查看,Graph 通过以 Kibana 插件的方式提供了这样的能力。和 Elastic 的所有产品一样,它的 UI 界面设计简单易用,API 接口丰富强大,借助于 Elastic 在相关性评分的丰富经验,挖掘出您数据中最有价值的关系信息。这种独特的图形探索方式,并且无需引入新的索引格式,允许用户直接查询现有的数据,为 Elastic Stack 打开了一个新的更广泛的使用场景。 Graph 让一些复杂问题和场景(如行为分析、反欺诈、网络安全、药物发现、个性化医疗,或者基于持续的实时数据构建个性化推荐)的处理变得简单。Graph 通过相关性评分计算分离噪音和有用信息,自动识别最重要的这些关系。由于构建于 Elasticsearch 之上,Graph 天然具备高可用和近实时的能力。 Graph 为关系性探索带来相关度 当数据添加到 Elasticsearch 后,索引进程会跟踪和记录该文档每个字段每个值,更新全局词频信息,并准备相关数据用于大的范围查询。这些统计信息还被用来计算搜索的相关度以及有效的用于 Aggregation 中。通过 Graph,Elastic Stack 将以一种新的方式来使用这些统计信息 -- 首先是识别文档间的关系,然后再为指定查询按最相关的关系进行优先级排序处理。 相比之下,传统的图分析技术仅基于给定关系的简单的频次统计。这种方法的缺点是关系连接最多的元素 -- 如《肖申克的救赎》的电影推荐指数或在星巴克的信用卡购买数据 -- 被认为是最重要的而返回但不一定最有价值。Elasticsearch 中的 Graph,相关度会根据与每个关系的重要程度来进行计算而不是简单的平均处理,返回的是重要的结果,避免出现频繁或平常的连接关系 “Graph 是一个极好的例子,让大家看到我们的产品所带来的无限可能性以及我们如何努力让我们的用户尽可能容易的得益于 Elastic Stack。” -- Shay Banon,Elastic CTO 与联合创始人说 -- “我很自豪地看到我们的公司在持续创新,然后也迫不及待的想要看到我们的客户采用 Graph 这种新方法来解决真正具有挑战性的问题和案例.” 了解更多: Graph 产品首页 观看 Graph 在线研讨会   关于 Elastic Elastic 是世界领先的软件提供商,致力于结构化和非结构化数据的实时可用性,用户场景包括搜索、日志和数据分析等领域。公司由 Elasticsearch、Kibana、Logstash 和 Beats 这些开源项目背后的开发人员于2012年创立,Elastic Stack、X-Pack 和 Elastic Cloud 这些产品迄今累计已超过5千万次下载。 Elastic 由 Benchmark Capital、Index Ventures 及 NEA 投资,总部位于阿姆斯特丹和加州山景城,公司员工及办事处遍布全球各地。欲了解更多,请访问 http://elastic.co

使用 Elastic Stack 来监控和调优 Golang 应用程序

Beatsmedcl 发表了文章 • 0 个评论 • 5838 次浏览 • 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 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 模块收集的数据进行的可视化分析吧:
df9c563e-f831-11e6-835c-183f3f9e5b94.png
  上面的图简单解读一下: 最上面一栏是 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.yml
metricbeat.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")
效果如下:
Snip20170304_9.png
从上图可以看到,发往 Elasticsearch 的消息很稳定,没有出现丢消息的情况,同时关于 Metricbeat 的内存情况,我们打开导入的 Dashboard 查看:
Snip20170304_10.png
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了,上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标,在结合 Elastic Stack 可以快速的进行分析,希望对大家有用。 最后,这个 Golang 模块目前还没 release,估计在 beats 6.0 发布,有兴趣尝鲜的可以自己下载源码打包。

对话 Kibana 之父:如果需要,你应该自己动手编写工具

资讯动态medcl 发表了文章 • 2 个评论 • 2902 次浏览 • 2017-01-11 11:45 • 来自相关话题

转载:http://www.infoq.com/cn/news/2 ... nToolElastic 中国开发者大会 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 
IMG_4857.gif
早在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的人联系我问要不要合并在成为同一家公司,我们才发现彼此的看法竟然不谋而合。
elastic-logo-H-full-color.jpg
我现在依然是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
Snip20170111_11.png
研发情况 研发出新功能的第一版本通常很快,但是需要不断的测试确保所有运转正常。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起来。不要等其他人的开源代码,有可能你会等到,但是有可能你永远等不到。在你写出来之后,你没准会收获惊喜。

 
1.png
 

Elastic Stack 6.0 发布 beta 版本啦!

资讯动态medcl 发表了文章 • 11 个评论 • 2653 次浏览 • 2017-08-09 10:29 • 来自相关话题

头条新闻:Elastic Stack 6.0 发布 beta 版本了。https://www.elastic.co/blog/el ... %3Dcn      注意啦,现在 6.0 还没 GA,不建议直接上生产环境,但是鼓励大家本地测试,和 5.0 一样,我们这次也有一个 Elastic Pioneer 活动,踊跃测试并发现 bug 的同学,可以获得 6.0 特殊纪念礼品一份,欢迎大家一起来捉虫,捉到的 Bug 直接在对应的 GitHub 上提交 issue,打上对应的版本 tag,如6.0.0-beta1 即可参与活动。
DGu1frNXoAEVYlM.jpg
  6.0 beta1 作为一个具备里程碑意义的版本,相比之前的 alpha 版本,又包含了哪些激动人心的新特性呢,下面我们分别来看一下吧。   Elasticsearch [下载] [6.0 Breaking Chages] https://www.elastic.co/blog/el ... eased
  • Sequence numbers and fast recovery
新的序列号机制会为每一个增删改操作分配一个顺序号,可以实现操作层面的细粒度复制,避免低效的基于索引文件的拷贝与 translog 的重做;Translog 使用新的过期机制,默认是 12 小时或者 512MB 大小,方便副本的快速恢复;该特性也为后面的跨数据中心的数据同步铺平了道路。
  • Search scalability
移除 _field_stats 接口,现在每个搜索请求多了一个轻量级的 shard prefiltering phase,提前过滤掉不需要参与实践查询的 shards,并在 shard 级别判断查询是否有效,并重写查询,只在真正有相应数据的 shard 上执行查询;新增参数 max_concurrent_shard_requests 来限制单次请求的并发分片请求数。
  • Preventing full disks
新增参数来控制当磁盘占用达到某个警戒线之后不允许继续写入;限制 Elasticsearch 的日志占用,默认按 128MB 滚动覆盖,限制 ES 总日志文件大小不超过 2GB。
  • Removal of default passwords
为了更加安全,XPack 的默认密码 changeme 去掉了,提供了相应的工具来进行配置。
  • 优化 Profiling 的开销占用,进一步较少针对超时及查询取消的检查开销
  • 提升 Percolator 的性能
 更多改进:[Beta1 Release Notes]     Kibana [下载] [Breaking Changes] https://www.elastic.co/blog/ki ... eased
  • Upgrade Assistant and Rolling Upgrade Support
  新增的集群升级助手,属于 X-Pack 的免费功能,自动帮你诊断集群升级要处理的各种问题,支持跨大版本间滚动升级的检测。
issue_1619_2.png
  • Watcher UI for Threshold Based Alerts
新增提供基于阈值的快速设置 Watcher 预警规则的 UI 界面。
Snip20170809_9.png
  • Experimental Kibana Query Language
引入新的 Kibana 查询语言:Kuery,支持智能提示和错误失败等丰富的特性。
  • Refactoring of the Visualizations Code
通过此次重构,开发者不再受限于只能使用 Angular 来做渲染了,以及扩展更多的灵活性,方便对 Kibana 的二次开发。
issue_11786_0.JPG
  • X-Pack Monitoring Email Notifications for Cluster Alerts
支持设置监控的告警邮件发送。
Snip20170809_7.png
  • Cluster Alert for X-Pack License Expiration
证书过期现在有自动的提示了。
image_(3).png
  • New Colors to Improve Accessibility
改进Kibana的可用性,如导航的快捷键支持,对色盲色弱用户的友好支持等。
Screen_Shot_2017-07-28_at_1.26_.42_PM_.png
Snip20170809_10.png
  • Full Screen Mode for Dashboard
新增的全屏模式对 Dashboard 的大屏展现更加友好。
Snip20170809_8.png
更多详情:[6.0 Beta1 Release Notes]     Logstash [下载]  https://www.elastic.co/blog/lo ... eased
  • Pipeline Viewer
X-Pack Basic 新增的免费功能,用户可以非常直观的了解管道配置,以图形化的方式来展现,从而了解数据流向与处理逻辑,包括管道执行的各项重要指标,从而优化 Logstash 性能。
pipeline_viz2.png
  • Centrally manage configurations
用户可以方便的通过图形化 UI 集中式批量管理所有 Logstash 实例的配置文件,并动态修改生效,不需要重启和单独维护每个 Logstash 的实例。
Snip20170809_11.png
  • Ingest to Logstash convertor
提供一个方便将 Elasticsearch Ingest 脚本转换为 Logstash 配置文件的工具。
$LS_HOME/bin/ingest-convert.sh --input file:///tmp/ingest/apache.json --output file:///tmp/ingest/apache.conf 

   Beats [下载] [Breaking Changes] https://www.elastic.co/blog/be ... eased
  • Auditbeat
一个新的 Beat,通过将 Linux Kernel 内的各种事件统统接入到 Elastic Stack 来进行安全审计。
auditbeat-file-integrity-dashboard.png
  • New commands and configuration layout
一些常见的操作,你现在可以直接通过命令的方式来快速操作了。
$ metricbeat modules list
$ metricbeat modules enable redis
$ metricbeat modules disable redis
  • Add Docker metadata to the Docker logs
将 Docker 相关的元数据附加到日志里面,从而丰富上层的分析与应用,详情可见这篇博客:https://www.elastic.co/blog/en ... ebeat
  • Internal pipeline refactoring
Beats 在管道这一块做了大量的重构,现在不支持 1 个管道 2 个输出了。   更多详情:[Beta1 Release Notes]    ES-Hadoop [下载] https://www.elastic.co/blog/es ... eased
  • Spark 2.2.0 and Stable Support for Spark Structured Streaming
  • Support for new Join Fields
  • Multiple Mappings and Multiple Index Reads
  更多详情:[Release Notes]   上面介绍的众多特性,相信总有一个能让你动心,赶紧下载试试吧,记得反馈哦!  

使用 Elastic Stack 来监控和调优 Golang 应用程序

Beatsmedcl 发表了文章 • 0 个评论 • 5838 次浏览 • 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 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 模块收集的数据进行的可视化分析吧:
df9c563e-f831-11e6-835c-183f3f9e5b94.png
  上面的图简单解读一下: 最上面一栏是 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.yml
metricbeat.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")
效果如下:
Snip20170304_9.png
从上图可以看到,发往 Elasticsearch 的消息很稳定,没有出现丢消息的情况,同时关于 Metricbeat 的内存情况,我们打开导入的 Dashboard 查看:
Snip20170304_10.png
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了,上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标,在结合 Elastic Stack 可以快速的进行分析,希望对大家有用。 最后,这个 Golang 模块目前还没 release,估计在 beats 6.0 发布,有兴趣尝鲜的可以自己下载源码打包。

Elastic Stack 5.2.2 发布

资讯动态medcl 发表了文章 • 5 个评论 • 1420 次浏览 • 2017-03-01 10:37 • 来自相关话题

Elasticsearch 5.2.2
  • 修复request熔断器没有正确处理当前运行请求数的bug,当请求返回前却被客户端关闭时没有对计数减一,会造成节点慢慢的不能处理任何请求,除非重启节点,所有的用户都应该升级 #23317
  • 修复cgroup正则解析的bug,造成节点的不能正常启动 #23219
  • 被shard锁暂缓执行的请求可能会别其他线程启动,并且该请求丢失了上下文,会造成该请求被当做非法请求而拒绝
  • 恢复terms agg的include/exclude参数的支持
  下载:https://www.elastic.co/downloads/elasticsearch 完整的Release notes:https://www.elastic.co/guide/e ... .html XPack release notes:https://www.elastic.co/guide/e ... 5.2.2   Logstash 5.2.2
  • 修复持久化队列在windows启用造成的崩溃
  • 修复多实例公用相同的数据目录造成的数据损坏
  • 修复JVM性能指标收集造成的吞吐影响
  下载:https://www.elastic.co/downloads/logstash Release notes:https://www.elastic.co/guide/e ... .html   Kibana 5.2.2
  •  之前的版本kibana的visualization依赖一个旧的Elasticsearch的include/exclude特性,但是该功能在Elasticsearch5.2.1被突然移除了,引起了kibana的visualization的错误,现在Kibana对新创建的visualization使用正确的结构,并且能在查询时自动转换遗留的旧结构到新的结构
  • 从5.2.0开始,包含sub-bucket的垂直条形图(vertical bar)配置为分组没有合适的缩减y轴,造成相当小甚至某些情况下不可用,这次回归将再次对y轴进行必要的扩展而不管其条形图的模式
  下载:https://www.elastic.co/downloads/kibana 完整Release notes https://www.elastic.co/guide/e ... .html   Beats 5.2.2
  • Metricbeat修复当docker容器被kill掉造成的docker 模块挂起的bug
  • Metricbeat修复超时时间设置而不是默认值
  Release notes:https://www.elastic.co/guide/e ... .html 下载:https://www.elastic.co/downloads/beats/

Elastic Stack 5.2.1 发布

资讯动态medcl 发表了文章 • 4 个评论 • 2668 次浏览 • 2017-02-15 14:07 • 来自相关话题

Elasticsearch 5.2.1 发布内容   基于 Lucene 6.4.1,所有5.2.0 用户都应该升级到该版本,修正了很多 bug,尤其了 Lucene6.4.1修复了两个重要的内存泄漏:
  • 当存储字段配置为“best_compression",我们依赖于 JVM 回收机制来释放解压缩实例(Deflater/Inflater instances)。然而这些类也行只使用了很少的 JVM 堆栈内存,却使用了大量了本地内存,所以可能 会出现在 JVM 回收解压缩实例之前而操作系统先用完了本地内存。 LUCENE-7647
  • 特定的查询可能会持有 IndexReader 的一个引用,当这些查询被缓存之后,本来应该已经被删除的段会因为这个引用而继续被 Lucene 持有。LUCENE-7657
  功能废弃:
  • Geo distance range 废弃,请使用`geo_distance` bucket aggregation 或 geo_distance sort来替代。#22835
 改进增强:
  • 分配解释 API(allocation explaining)在未分配主分片信息中包含陈旧的副本信息(不管是陈旧还是损坏的)#22826
  Bug 修复:
  • 如果查询超时,将缓存结果置为无效。#22807
  • Reindex 接口支持来源 es 版本<2.0,当不能清除旧的 scroll 不记录日志。
  • 将参数:search.highlight.term_vector_multi_value 保留为节点级别。
  其他细节详见 Release notes。  Download Elasticsearch 5.2.1 X-Pack 5.2.1 release notes   Kibana 5.2.1 发布内容:   在该版本中主要包括了一些重要的 bug 修复,包含一个安全风险的 fix 以及可能造成 kibana 崩溃的问题。 在5.0早期的版本中,如果配置了 SSL,特定的请求会造成 Kibana 无法释放文件打开句柄,这会造成进程随着时间推移的崩溃。请求在发生数据之前被取消也会造成进程的崩溃。还有一个安全的风险:ESA-2017-02(Http 头信息可能泄露敏感信息的问题,注:Kibana4不受影响)。   其他详见:Release notes Download Kibana 5.2.1   Beats,Logstash 发布内容见: https://www.elastic.co/guide/e ... .html https://www.elastic.co/guide/e ... .html    

Elastic Stack 5.2.0 发布

资讯动态medcl 发表了文章 • 1 个评论 • 4087 次浏览 • 2017-02-03 13:26 • 来自相关话题

本周三,Elastic 发布了 ElasticStack 的全新版本5.2.0,包含了很多激动人心的特性,让我们 一起来看看吧, (Elastic Stack 包括 Elasticsearch、Logstash、Kibana、Beats):  Elasticsearch 5.2.0 主要亮点:
  1. 新增数字和日期范围字段类型,非常方便对范围类型进行交并集的查询,比如你的数据是日历类型的数据,每天都有一些会议信息,会议的开始和结束时间都不同,你想看本周那天有空,可以使用 range fields 很方便的进行查询。了解更多
  2. 新增分片分配解释 API,会告知分片失败的具体原因,如分片损坏、磁盘写满还是配置错误,进行快速运维,以前只能根据经验到处寻找可能是什么问题,费事费力,了解更多
  3. 对 Keyword 类型标准化,在5.0将 string 类型拆成了 text 和 keyword两种类型,text 支持分词,keyword 则不分词默认支持 doc values,不过有时候你还需要对 keyword 类型进行一些标准化处理,如都转成小写,现在可以使用 normalizers 参数来指定标准化的 filter。
  4. Terms 聚合的分区,terms 聚合默认返回10个 term,以前如果你需要返回全部的 term 列表是不可能的任务(基于内存压力),现在你可以通过将请求分区,以多次请求的方式来取回这些数据,了解更多
  5. 字段折叠,在搜索时可以按某个字段的值进行折叠,在每个折叠的值内进行排序选取 topN,了解更多
  相关链接: Download Elasticsearch 5.2.0 Elasticsearch 5.2.0 release notes Elasticsearch 5.2.0 breaking changes X-Pack 5.2.0 release notes   Logstash 5.2.0 主要亮点:
  1. 新的监控 UI,现在 X-Pack 也能监控 logstash 了,X-Pack 基础免费版就包括,如下图:
    MonitoringUI-rel-blog.png
    Screen_Shot_2017-01-09_at_16.51_.49_.png
  2. 更多的监控 API,新增3个类型的统计信息:cgroup、持久化队列和 output新增持续时间字段。
  3. 离线插件管理,在很多没有公网的部署环境,都需要离线安装,以前的离线安装不够完善,尽管大部分插件没问题,但是还是存在个别插件的依赖链下载不完整的问题,为了解决这个问题,我们基本上重新设计了整个工作流程使用了新的方式来打包插件和他所有的依赖,了解更多
  相关连接: Download Logstash 5.2.0 Logstash 5.2.0 release notes   Kibana 5.2.0 主要亮点:
  1. 支持 Elasticsearch Tribe 节点,在“admin”集群的基础上,引入了新的“data”集群,“data”集群可以理解成 Kibana 后面的数据来源,可以是 tribe 节点,而“admin”集群是存放 kibana 可视化信息“。kibana”索引的地方,默认 data 和 admin 集群都是在同一个集群,且不能是 tribe 节点,目前还有一些细节正在处理,如 console 还不能很好的工作。
  2. 增加新的可视化类型:热点图(heatmap),可以很方便的按区间和按时间来显示数据的范围分布,如下图:
    Heatmap_Linechart.png
  3. 开始进行国际化的支持,感谢 IBM 团队的努力,目前已经提供了基础的框架支持,虽然是万里长征的第一大步,但也是非常激动人心的。
  4. 地图服务的改进,Elastic 自己的 Tile 地图服务已经上线几个月了,我们现在能提供10个级别的缩放了,X-Pack 基础用户可以达到12个级别的缩放,并且我们正在尝试18个级别的缩放,并且从5.2开始,我们能让这些级别动态调整,不用发布新的 Kibana。
  5. 监控容器中的 Elasticsearch,现在我们可以监控容器里面的 Elasticsearch 实例的运行情况了,CPU 利用率、GC、堆栈使用情况等,如下图:
    monitoring-elasticsearch-in-containers.png
  相关连接: Download Kibana 5.2.0 Kibana 5.2.0 release notes   Beats 5.2.0 主要亮点:
  1. 新增 Beat:Heartbeat,一个新的正式的官方beat 成员,用于可用性监控,和所有的 beat 一样,轻量级,Heartbeat 可以用于很多场景,比如安全,你不希望暴露某个端口时,使用 Heartbeat,当你发现该端口对外开启了,就可以触发通知,或者服务/网站可用性检测,服务down 了可以及时感知,目前支持:ICMP、TCP 和 HTTP 类型的监控,目前 Heartbeat还处于 beat 阶段,暂不推荐用于生产环境。
  2. Metricbeat 可跟踪网络连接,从5.2开始,Metricbeat 导出了 linux 系统的应用程序的网络连接信息,每个进程打开的 tcp 套接字,本地及远程的 ip 都包含在内,基于它,你可以进行如下的图分析:
    connections-2.png
  3. 收集Prometheus导出的指标,从5.2开始,监控系统普罗米修斯的收集模块导出的数据可以提供给 Metricbeat 然后索引进 Elasticsearch。
  相关连接: Download Beats 5.2.0 Beats 5.2.0 release notes   Elastic Stack 下载链接:https://www.elastic.co/downloads Bug 反馈:http://github.com/elastic 以后有版本的更新消息都会在这里发布一份中文版,欢迎大家关注。

对话 Kibana 之父:如果需要,你应该自己动手编写工具

资讯动态medcl 发表了文章 • 2 个评论 • 2902 次浏览 • 2017-01-11 11:45 • 来自相关话题

转载:http://www.infoq.com/cn/news/2 ... nToolElastic 中国开发者大会 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 
IMG_4857.gif
早在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的人联系我问要不要合并在成为同一家公司,我们才发现彼此的看法竟然不谋而合。
elastic-logo-H-full-color.jpg
我现在依然是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
Snip20170111_11.png
研发情况 研发出新功能的第一版本通常很快,但是需要不断的测试确保所有运转正常。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起来。不要等其他人的开源代码,有可能你会等到,但是有可能你永远等不到。在你写出来之后,你没准会收获惊喜。

 
1.png
 

Elastic Stack 5.0 正式发布

资讯动态medcl 发表了文章 • 0 个评论 • 3801 次浏览 • 2016-10-27 16:28 • 来自相关话题

Snip20161027_6.png
作者:Shay Banon,原文:https://www.elastic.co/blog/el ... eased  记得在 2016 年 2 月份,就在 Elastic{ON} 16 大会之后,我写了一篇标题为 [Heya, Elastic Stack and X-Pack] (https://www.elastic.co/blog/he ... -pack ) 的博客。经过了几乎整整一年的努力,中间发布了 5  个 Alpha,1 个 Beta 和一个 RC 版本,今天我们非常高兴的正式宣布发布 Elastic Stack 的 GA 正式版本。 并且,重要的是,于此同时,在我们的 [Elastic Cloud](https://www.elastic.co/cloud/as-a-service/signup ) 上面也同步进行了更新。所以如果你需要托管的 Elasticsearch 和 Kibana ,那么没有其它地方比这里更及时了。我们致力于让 Elastic Cloud 成为一个托管 Elasticsearch 的最佳场所。事实上,在正式版发布之前,我们也提供了 RC 版本方便你用于测试。 我们的团队今天正在庆祝这一时刻,我希望你能加入我们。 GA 版本今天已经可以下载了,如果要加入 Elastic 团队 11 月 3 号的线上活动,了解更多有关于本次发布和向工程师提问,请点击这里 [注册!](https://www.elastic.co/live/v5 )   在开始探索发布详情之前,我想借此机会来回顾一下有哪些背后的事情让我们走到今天。 ## 我们的社区 最近的 Elastic{ON} Tour,在每场活动的开场我会讨论我们公司过去几年的简短历史。最近一次活动的高潮是当我宣布我们的累计下载总数达到了七千五百万。当我第一次开始这个项目的时候,我希望她能够被能够被广泛使用,但是我们的社区的热情和激情总是不断的给我快乐和惊喜。 ## 先驱者计划 考虑到这一点,我想分享一下 [先驱者计划](https://www.elastic.co/blog/el ... ogram ) 的一些结果。该计划开始于一个简单的前提,你如何使用 Elastic Stack 对我们来说非常重要,不管是产品研发还是确保发布高质量的可用版本。我非常高兴的告诉大家自四月份发布的第一个Alpha版本,我们的社区一共提交了146个issue。 我们的社区是Elastic其中一个最宝贵的财产。事实上,在这次发布中讨论的最多的就是为什么命名为 "Elastic Stack"。 ## Elastic Stack 过去一年,我们收购了Packetbeat 团队,然后Beats 就诞生了。这是一个开源的用于构建轻量级数据收集的平台,可用于日志、基础设施监控指标、网络流量等数据的收集,并且以前所未有的简单方式来将数据发送至Logstash或Elasticsearch。同时我们热爱那些已经习惯于将 ELK 作为代表我们软件栈的你们,只不过加上Beats,我们不知道如何将“B”和E-L-K组合在一起。(NOTE:过去用过ELKB) 但Elastic Stack 远不只是一个名字。当我们开始发布一个周期,我们开发提交、构建、测试和发布的是一整个软件栈。这个很重要,从内部来保证兼容性。并且,对你来说,它可以帮助你提升部署速度,减少版本冲突,让开发者轻松的处理整个 Elastic Stack的兼容性问题。 ## 一场特性之旅 在我开始这篇博客之前,我打算列举每个产品的一些主要特性,但是发现好像很难确定从哪里开始和结束。我们每个产品和技术的leader 已经创建了单独的博客来讨论各自产品的特性,没人比他们更适合介绍其中的故事。 我个人,更是对其中的一些特性感到非常兴奋,相较于简单的罗列,我会提供一些简短概要并且鼓励你去阅读每个产品详细的博客。 Ingest Node Ingest Node 是Elasticsearch 的一个节点类型,允许你对数据做一些加工,比如:grok、geoip、date和其它索引(或重建)过程中的基本数据操作。 通过访问REST API的时候指定一个参数“?pipeline=x”来使用由一系列处理器(processors)构造的管道,它可用帮你对文档进行预处理,原生的在Elasticsearch内部,在索引之前做灵活的 ingest部署。这不代表要替换掉Logstash,也不会移除对Beats的需要,只为你设计数据采集架构时提供一种更加灵活的可能性。 Elasticsearch 性能 性能报告倾向于提供一个大纲,尤其是比较性的性能测试报告,基于此,我们花了很大力气来比较5.0.0 与之前发布的版本。数据现在已经可用了,这个数据也是我们用来检查和确保我们正在做正确的事情来保证性能,我们是如此的公开来避免由性能测试数字引起的所谓秘密和怀疑。事实上,不止测试结果,我们还公布了我们的硬件和配置,我们还开源了我们的工具链(叫做 [Rally](https://github.com/elastic/rally )) 和测试记录本身([Rally-Tracks](https://github.com/elastic/rally-tracks ))。 Metricbeat Metricbeat 替换 Topbeat 成为Elastic Stack里主要的收集度量指标的工具。和Topbeat一样,Metricbeat 收集和“top” 类似的诸如机器及进程的资源(CPU, memory, disk, network)统计信息。和Topbeat不同的是,Metricbeat 同时也收集其它系统的指标信息,如:Apache、HAProxy、MongoDB、MySQL、Nginx、PostgreSQL、 Redis和 Zookeeper,并且在不久的将来还会支持更多应用和系统。 Logstash 监控 API** - 这是一个新的监控特性提供Logstash 管道及其插件在运行时的可视状态。这个组件收集Logstash处理你数据的各种操作性统计指标信息,所有的这些信息都可通过简单的API来进行查询。 Timelion 以前以re{Search} 项目介绍过,现在Timelion 作为Kibana原生的核心组件可直接可用。Timelion 提供一个查询表达式和可视化类型让你探索基于时间的数据。 再列举几个,诸如BKD 树、scaled_float 和 half_float ,我们投入了大量的精力到 [Elasticsearch 可靠性](https://www.elastic.co/guide/e ... .html ) 中,另外Kibana惊艳的重新设计(我从来不知道我们以前有这么讨厌这些边框直到移除), Beats 支持的Kafaka输出,等等,还有很多很多。 这是一个非常大的版本发布,非常有必要阅读相关独立的博客来了解更多范围内的改进。 ## X-Pack 在Elastic 我们热爱扩展。太多我们构建的东西我们给他们起了非常有趣的名字,如:Shield、Marvel和Watcher,作为提供给我们客户的额外的插件,独立闭源但没限制开源部分的能力的特性,随着后面又增加了Graph 和Reporting,安装流程也变得困难和困惑。 来和X-Pack 打个招呼吧! 一个包含了security、alerting、monitoring & management、reporting和graph 能力的Elastic Stack的插件。我们对5.0的工程不仅限于Elastic Stack,同时也包括给X-Pack 添加如下:
  1. Kibana里的管理和监控的UI界面
  2. Kibana里创建用户和角色的UI界面
  3. 非常简化的安装流程
X-Pack 可以试用,同时提供商业和免费(基本)授权证书选项。我们尤其兴奋的将X-Pack的某些特性开放出来免费使用,详细请见 [Subscriptions](https://www.elastic.co/subscriptions ) 页。 ## 放在最后 我敬畏发布此次版本所做的所有努力,来自我们社区和客户的共同参与,以及为了将来发布所做的一系列背地里的工作。一如既往,理解一个版本的最好方式就是去体验它。      

Elastic 为 Elastic Stack 带来新的 Graph 实时图分析功能

资讯动态medcl 发表了文章 • 1 个评论 • 6966 次浏览 • 2016-03-31 09:36 • 来自相关话题

Mountain View, Calif. and Amsterdam, The Netherlands – March 30, 2016,英文原文
BestBuy2-768x414.jpg
Elastic 今天宣布发布一个新的用于 Elasticsearch 和 Kibana 的插件,通过它们您可以很方便的发现、理解和探索您现有数据之间的关系。通过结合速度与相关度的搜索与图分析,Graph 已开启一页新的篇章同时为 Elastic Stack 带来更多的使用场景。   “我们构建 Graph 来帮助您以更多的方式来分析您存储在 Elasticsearch 中的数据” -- Steve Kearns,Elastic 高级产品总监提到, “通过把相关度作为切入点来查看数据间的关系,以前需要涉及到多个系统、批量作业甚至机器学习才能做到的事情,现在变成容易解决的问题。” Graph 为 Elastic Stack 开启新的使用场景 当您往 Elasticsearch 存储数据时 -- 产品信息、用户资料、文档、日志 -- 这些数据通常会包含对象(实体、人员、角色或者机器等)之间的引用关系。最好的探索这些关系的方法就是以可视化的方式去查看,Graph 通过以 Kibana 插件的方式提供了这样的能力。和 Elastic 的所有产品一样,它的 UI 界面设计简单易用,API 接口丰富强大,借助于 Elastic 在相关性评分的丰富经验,挖掘出您数据中最有价值的关系信息。这种独特的图形探索方式,并且无需引入新的索引格式,允许用户直接查询现有的数据,为 Elastic Stack 打开了一个新的更广泛的使用场景。 Graph 让一些复杂问题和场景(如行为分析、反欺诈、网络安全、药物发现、个性化医疗,或者基于持续的实时数据构建个性化推荐)的处理变得简单。Graph 通过相关性评分计算分离噪音和有用信息,自动识别最重要的这些关系。由于构建于 Elasticsearch 之上,Graph 天然具备高可用和近实时的能力。 Graph 为关系性探索带来相关度 当数据添加到 Elasticsearch 后,索引进程会跟踪和记录该文档每个字段每个值,更新全局词频信息,并准备相关数据用于大的范围查询。这些统计信息还被用来计算搜索的相关度以及有效的用于 Aggregation 中。通过 Graph,Elastic Stack 将以一种新的方式来使用这些统计信息 -- 首先是识别文档间的关系,然后再为指定查询按最相关的关系进行优先级排序处理。 相比之下,传统的图分析技术仅基于给定关系的简单的频次统计。这种方法的缺点是关系连接最多的元素 -- 如《肖申克的救赎》的电影推荐指数或在星巴克的信用卡购买数据 -- 被认为是最重要的而返回但不一定最有价值。Elasticsearch 中的 Graph,相关度会根据与每个关系的重要程度来进行计算而不是简单的平均处理,返回的是重要的结果,避免出现频繁或平常的连接关系 “Graph 是一个极好的例子,让大家看到我们的产品所带来的无限可能性以及我们如何努力让我们的用户尽可能容易的得益于 Elastic Stack。” -- Shay Banon,Elastic CTO 与联合创始人说 -- “我很自豪地看到我们的公司在持续创新,然后也迫不及待的想要看到我们的客户采用 Graph 这种新方法来解决真正具有挑战性的问题和案例.” 了解更多: Graph 产品首页 观看 Graph 在线研讨会   关于 Elastic Elastic 是世界领先的软件提供商,致力于结构化和非结构化数据的实时可用性,用户场景包括搜索、日志和数据分析等领域。公司由 Elasticsearch、Kibana、Logstash 和 Beats 这些开源项目背后的开发人员于2012年创立,Elastic Stack、X-Pack 和 Elastic Cloud 这些产品迄今累计已超过5千万次下载。 Elastic 由 Benchmark Capital、Index Ventures 及 NEA 投资,总部位于阿姆斯特丹和加州山景城,公司员工及办事处遍布全球各地。欲了解更多,请访问 http://elastic.co