欢迎参加Elastic的Meetup线下活动问卷调查

资讯动态medcl 发表了文章 • 0 个评论 • 228 次浏览 • 3 天前 • 来自相关话题

问卷调查直达链接:https://www.surveymonkey.com/r/elastic-china17 
 
同学们,乡亲们:
    想要今年的Elastic线下活动来到您身边么,快参加我们的问卷调查吧,如果您的城市不在下拉列表,记得添加进去,问卷调查比较简单啦,大概只需要花费您几分钟时间,快来吧:https://www.surveymonkey.com/r/elastic-china17 。
 
   另外Elastic也在寻找各个城市的演讲者、场地赞助、协办方、志愿者。如果您有项目用到了任何Elasticsearch、Kibana、Logstash或Beats,并且有兴趣分享您的经验故事(不管是5分钟还是50分钟)请让我们知道,我们非常愿意与我们的社区一起分享您的故事。不管是哪种参与方式都欢迎,请在问卷内留下联系方式或联系我:medcl123(添加注明来意)。
我们感谢您参与本次问卷调查!问题集中在您想参加的线下活动类型,调查结果将被用来使组织者更好地安排活动计划。本调查预计需要花费2 - 5分钟才能完成。我们将与所有参与调查的人分享任何有趣的发现。所有收集的信息将保持匿名。为了鼓励大家花费这一天中的几分钟时间,将随机抽取五个人赢得 $50 美元的亚马逊礼品卡和十五个人将赢得 Elastic Stack 特别版T恤。为了进行抽奖活动,我们会在调查结束时要求您提供电子邮件,但只会用它来让您知道如果您中奖了。
 
除了这个问卷调查,我们在也同时更新了 Elastic 用户组的行为准则(Code of Conduct)。参加我们的活动意味着您同意我们的准则。完整的准则可以访问:https://www.elastic.co/community/codeofconduct。所有的细节可以这个链接页找到。如果您还要其他问题,也欢迎告知我们:) — 我们会一直在这里提供帮助!  :)
  查看全部
问卷调查直达链接:https://www.surveymonkey.com/r/elastic-china17 
 
同学们,乡亲们:
    想要今年的Elastic线下活动来到您身边么,快参加我们的问卷调查吧,如果您的城市不在下拉列表,记得添加进去,问卷调查比较简单啦,大概只需要花费您几分钟时间,快来吧:https://www.surveymonkey.com/r/elastic-china17
 
   另外Elastic也在寻找各个城市的演讲者、场地赞助、协办方、志愿者。如果您有项目用到了任何Elasticsearch、Kibana、Logstash或Beats,并且有兴趣分享您的经验故事(不管是5分钟还是50分钟)请让我们知道,我们非常愿意与我们的社区一起分享您的故事。不管是哪种参与方式都欢迎,请在问卷内留下联系方式或联系我:medcl123(添加注明来意)。

我们感谢您参与本次问卷调查!问题集中在您想参加的线下活动类型,调查结果将被用来使组织者更好地安排活动计划。本调查预计需要花费2 - 5分钟才能完成。我们将与所有参与调查的人分享任何有趣的发现。所有收集的信息将保持匿名。为了鼓励大家花费这一天中的几分钟时间,将随机抽取五个人赢得 $50 美元的亚马逊礼品卡和十五个人将赢得 Elastic Stack 特别版T恤。为了进行抽奖活动,我们会在调查结束时要求您提供电子邮件,但只会用它来让您知道如果您中奖了。


 
除了这个问卷调查,我们在也同时更新了 Elastic 用户组的行为准则(Code of Conduct)。参加我们的活动意味着您同意我们的准则。完整的准则可以访问:https://www.elastic.co/community/codeofconduct。所有的细节可以这个链接页找到。如果您还要其他问题,也欢迎告知我们:) — 我们会一直在这里提供帮助!  :)
 
timg.jpeg

Elasticsearch 安全加固 101

Elasticsearchmedcl 发表了文章 • 0 个评论 • 1504 次浏览 • 2017-01-13 13:03 • 来自相关话题

 最近 MongoDB 的安全事件闹得沸沸扬扬,应该不少人都听说了吧,事情大概是,因为 MongoDB 默认的安全设置造成了数据外泄并且被黑客勒索才能找回数据,想了解的,这里有几个链接:
http://mt.sohu.com/20170107/n478047698.shtml​ 
http://www.jianshu.com/p/48d17a69e190​ 
http://bbs.tianya.cn/post-itinfo-503786-1.shtml​ 
 
安全从来不是等到出事才要注意的事情,可以说安全是第一重要的事情,不管你是公司的CTO、技术总监、运维总监、架构师还是一线工程师,都应该有安全意识,好了,废话不多说了,Elasticsearch 的用户现在越来越多了,有些已经成为公司的基础服务,所以数据的安全非常重要,今天主要给大家介绍 Elasticsearch 围绕安全方面的的几点使用事项:
 
下载安装
 
     请使用正规渠道下载 Elasticsearch,首选官方网站,下载完成,记得要验证下载文件的 sha1值和官网下载的提供的sha1值进行对比,避免下载过程中被人拦截破坏文件,甚至注入恶意代码。
不要随便安装第三方的插件,插件有可能引入安全漏洞甚至本身自带后门,需谨慎使用。
    链接君:https://www.elastic.co/downloads 
 
 
使用最新的 Elasticsearch
 
    请关注 Elastic 网站,及时更新升级 Elasticsearch 的最新版本,Elasticsearch 每次版本发布都会优化和改进一部分功能,尤其是安全漏洞的补丁,仔细阅读 Elasticsearch 的更新记录,Elasticsearch 的版本遵照 语义化版本 ,所以小版本间应该是能够无缝升级的,建议及时本地测试和线上更新,升级前,记得 snapshot 做好备份。
    链接君:https://www.elastic.co/downloads
 
 
修改默认的 Elasticsearch 集群名称
 
     Elasticsearch 默认的集群名称是 elasticsearch,请在生成环境上一定要修改成其他的名称,并且不同的环境和不同的集群要保证不相同,监控集群节点情况,如果有未知节点加入,一定要及时预警。
    文档君:https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html#cluster.name
 
 不要暴露 Elasticsearch 在公网上
 
      Elasticsearch 默认端口是9200,绑定的是本机127.0.0.1的这个 ip,这个默认参数其实很安全,但是有很多人想要绑定其他的 lan 口或者公网的 ip,可以修改相应参数,记住,修改有风险,如果确实需要将 Elasticsearch 暴露在公网环境,请修改特定的端口绑定IP,不要直接修改参数: network.host,而是要分别修改:http.port 来绑定 HTTP 协议9200 端口的 IP(RESTful 接口调用),修改:transport.tcp.port 对应的 TCP 9300 端口的 IP(集群内通信),如果你不需要 http 端口,你干脆禁用掉,另外还需要在 Elasticsearch 之上加上成熟的安全防护措施(注意是成熟的!),在这里提供几种方案:
9200的 HTTP 接口之上加上 Nginx 来提供 Http Basic-Auth 的基本的身份认证,辅助 SSL 证书进行传输层的加密,Nginx 进一步限制可接受 Verb 请求类型及可被操作的索引前缀。使用 Elastic 的 X-Pack 插件,同样提供了 Http Basic-Auth 和 SSL 传输层的加密,X-Pack 还能提供内外 Elasticsearch 集群节点间的流量加密,避免旁路攻击。
 
     文档君:https://www.elastic.co/guide/e ... tings 
 
禁用批量删除索引
 
Elasticsearch 支持通过_all(全部)和通配符(*)来批量删除索引,在生产环境,这个有点危险,你可以通过设置: action.destructive_requires_name: true 来禁用它。

安全使用动态脚本

     Elasticsearch 的脚本很方便的可以对数据进行操作,不过如果你暂时没有用上,还请禁用它(Elasticsearch 在1.2.x 以后已经默认禁用了),如果你已经在使用动态脚本,比如 Groovy,它不是沙盒机制的脚本引擎,启用 inline 或 store 类型的groovy 有安全风险,请限制脚本的接触方,比如通过模板的方式来限制脚本的调用,只需要执行特定预先定义好的脚本,对调用参数进行过滤和参数值的检测,做好验证,同时各种日志都必须要保留好,方便进行日志分析,异常的调用和请求一定要有发现和预警机制。
      Elasticsearch 默认启用了  Java Security Manager ,但还请正确配置其白名单。
      使用 Groovy 或者JavaScript 等脚本的用户,尽快迁移到 Painless 脚本,Painless 更快更安全。
      文档君:https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-security.html
 
给 Elasticsearch 服务器加固
 
     服务器加固是一个必备流程,不管上面运行的是什么服务;
     首先,请开启防火墙,请设置防火墙规则,只开启必备的端口,完成之后,使用扫描工具扫描服务器,检查端口开发情况;
     如果可能,不要用密码的方法来远程登录服务器,使用公私钥的方式来 ssh 登录服务器,如果只能使用密码,请妥善保管好你的用户名和密码,禁用 root 用户,不用使用弱密码。
     关注 Java 最新的漏洞,使用安全的 JVM 运行时。
     服务器及时更新最新的软件,使用安全的 repo 软件源,绑定软件源的 host和 ip,避免 dns 污染造成的攻击,关注服务器软件漏洞,及时打上补丁。
     收集系统日志和安装相应的入侵检测软件,及时发现服务器是否有异常行为。
 
不要以 root 身份运行 Elasticsearch

    如果你的运维人员打算以 root 身份来运行某个服务,这个运维人员一定是一个不合格的运维人员,记住一定不要以 root 身份来运行 Elasticsearch,另外,要不和其他的服务公用相同的用户,然后还要保证该用户的权限要最小化。
     范例君:sudo -u es-user ES_JAVA_OPTS="-Xms1024m -Xmx1024m" /opt/elasticsearch/bin/elasticsearc
 
正确设置 Elasticsearch 的数据目录
 
     请确保 Elasticsearch 的目录分配了合理的读写权限,避免使用共享文件系统,确保只有 elasticsearch 的启动用户才能访问,同理,日志目录也一样需要正确配置,避免泄露敏感信息。
     文档君:https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html#path-settings
 
定期对 Elasticsearch 进行备份
 
     使用 Elasticsearch 提供的备份还原机制,定期对 Elasticsearch 的数据进行快照备份,以备不时之需。
     文档君:https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html
 
加上监控和预警
 
     Elasticsearch 提供了很好的默认参数,对参数方面还做了正确性检测,bootstrap 启动检查,不准确的参数,直接不允许 Elasticsearch 启动,以至于有很多人抱怨,怎么现在部署到线上默认就需要做这么多设置才能使用呢,是的,以前启动就默认绑定了所有的网卡,集群见自动发现和相连,现在需要手动绑定局域网网卡,默认只是绑定的本机127.0.0.1的 ip,对上线来说麻烦了一点,做了这些检查也就是为了保证数据安全,以前很多的公网都能直接访问的 Elasticsearch 实例,都是因为默认设置就绑定了公网 ip,但是这些还不够,作为用户,你还需要收集各种日志和系统监控信息,及时主动掌握服务健康和资源使用情况,发现异常情况要及时处理,这里提供一些方案:
使用开源的 Elastic Stack 收集这些日志,可以使用 Filebeat 收集日志,Metricbeat收集系统监控信息,存进 Elasticsearch,一旦发现异常的波动,使用 Watcher 来进行预警,通过邮件或者 webhook 调用短信、微信或者电话。使用其他的监控产品,如 OneAPM、AppDynamic、NewRelic 等等。使用托管的 Elasticsearch 云的产品,如 Elastic Cloud等等。

是的,把安全这个事情考虑进去之后,很多事情都要比没考虑要变得更加复杂和麻烦,千里之堤毁于蚁穴,一个不起眼的忽视就有可能造成全部数据的丢失和泄露,出来混迟早是要还的,安全问题千万不能忽视。
 
以上几点建议举例针对 linux 平台,其他平台思路基本上一样,仅供参考,安全是一个包含很多方方面面的学科,抛砖引玉,希望大家有用。 

最后,Elastic 非常关心我们的产品安全,如果您发现有任何安全方面的问题,还请在这里上报:
https://www.elastic.co/community/security
企业用户需要 X-Pack 及 Elastic 官方技术支持,请访问下面的链接:
https://www.elastic.co/cn/contact
  查看全部
images.jpeg

 最近 MongoDB 的安全事件闹得沸沸扬扬,应该不少人都听说了吧,事情大概是,因为 MongoDB 默认的安全设置造成了数据外泄并且被黑客勒索才能找回数据,想了解的,这里有几个链接:
http://mt.sohu.com/20170107/n478047698.shtml​ 
http://www.jianshu.com/p/48d17a69e190​ 
http://bbs.tianya.cn/post-itinfo-503786-1.shtml​ 
 
安全从来不是等到出事才要注意的事情,可以说安全是第一重要的事情,不管你是公司的CTO、技术总监、运维总监、架构师还是一线工程师,都应该有安全意识,好了,废话不多说了,Elasticsearch 的用户现在越来越多了,有些已经成为公司的基础服务,所以数据的安全非常重要,今天主要给大家介绍 Elasticsearch 围绕安全方面的的几点使用事项:
 
下载安装
 
     请使用正规渠道下载 Elasticsearch,首选官方网站,下载完成,记得要验证下载文件的 sha1值和官网下载的提供的sha1值进行对比,避免下载过程中被人拦截破坏文件,甚至注入恶意代码。
不要随便安装第三方的插件,插件有可能引入安全漏洞甚至本身自带后门,需谨慎使用。
    链接君:https://www.elastic.co/downloads 
 
 
使用最新的 Elasticsearch
 
    请关注 Elastic 网站,及时更新升级 Elasticsearch 的最新版本,Elasticsearch 每次版本发布都会优化和改进一部分功能,尤其是安全漏洞的补丁,仔细阅读 Elasticsearch 的更新记录,Elasticsearch 的版本遵照 语义化版本 ,所以小版本间应该是能够无缝升级的,建议及时本地测试和线上更新,升级前,记得 snapshot 做好备份。
    链接君:https://www.elastic.co/downloads
 
 
修改默认的 Elasticsearch 集群名称
 
     Elasticsearch 默认的集群名称是 elasticsearch,请在生成环境上一定要修改成其他的名称,并且不同的环境和不同的集群要保证不相同,监控集群节点情况,如果有未知节点加入,一定要及时预警。
    文档君:https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html#cluster.name
 
 不要暴露 Elasticsearch 在公网上
 
      Elasticsearch 默认端口是9200,绑定的是本机127.0.0.1的这个 ip,这个默认参数其实很安全,但是有很多人想要绑定其他的 lan 口或者公网的 ip,可以修改相应参数,记住,修改有风险,如果确实需要将 Elasticsearch 暴露在公网环境,请修改特定的端口绑定IP,不要直接修改参数: network.host,而是要分别修改:http.port 来绑定 HTTP 协议9200 端口的 IP(RESTful 接口调用),修改:transport.tcp.port 对应的 TCP 9300 端口的 IP(集群内通信),如果你不需要 http 端口,你干脆禁用掉,另外还需要在 Elasticsearch 之上加上成熟的安全防护措施(注意是成熟的!),在这里提供几种方案:
  1. 9200的 HTTP 接口之上加上 Nginx 来提供 Http Basic-Auth 的基本的身份认证,辅助 SSL 证书进行传输层的加密,Nginx 进一步限制可接受 Verb 请求类型及可被操作的索引前缀。
  2. 使用 Elastic 的 X-Pack 插件,同样提供了 Http Basic-Auth 和 SSL 传输层的加密,X-Pack 还能提供内外 Elasticsearch 集群节点间的流量加密,避免旁路攻击。

 
     文档君:https://www.elastic.co/guide/e ... tings 
 
禁用批量删除索引
 
Elasticsearch 支持通过_all(全部)和通配符(*)来批量删除索引,在生产环境,这个有点危险,你可以通过设置: action.destructive_requires_name: true 来禁用它。

安全使用动态脚本

     Elasticsearch 的脚本很方便的可以对数据进行操作,不过如果你暂时没有用上,还请禁用它(Elasticsearch 在1.2.x 以后已经默认禁用了),如果你已经在使用动态脚本,比如 Groovy,它不是沙盒机制的脚本引擎,启用 inline 或 store 类型的groovy 有安全风险,请限制脚本的接触方,比如通过模板的方式来限制脚本的调用,只需要执行特定预先定义好的脚本,对调用参数进行过滤和参数值的检测,做好验证,同时各种日志都必须要保留好,方便进行日志分析,异常的调用和请求一定要有发现和预警机制。
      Elasticsearch 默认启用了  Java Security Manager ,但还请正确配置其白名单。
      使用 Groovy 或者JavaScript 等脚本的用户,尽快迁移到 Painless 脚本,Painless 更快更安全。
      文档君:https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-security.html
 
给 Elasticsearch 服务器加固
 
     服务器加固是一个必备流程,不管上面运行的是什么服务;
     首先,请开启防火墙,请设置防火墙规则,只开启必备的端口,完成之后,使用扫描工具扫描服务器,检查端口开发情况;
     如果可能,不要用密码的方法来远程登录服务器,使用公私钥的方式来 ssh 登录服务器,如果只能使用密码,请妥善保管好你的用户名和密码,禁用 root 用户,不用使用弱密码。
     关注 Java 最新的漏洞,使用安全的 JVM 运行时。
     服务器及时更新最新的软件,使用安全的 repo 软件源,绑定软件源的 host和 ip,避免 dns 污染造成的攻击,关注服务器软件漏洞,及时打上补丁。
     收集系统日志和安装相应的入侵检测软件,及时发现服务器是否有异常行为。
 
不要以 root 身份运行 Elasticsearch

    如果你的运维人员打算以 root 身份来运行某个服务,这个运维人员一定是一个不合格的运维人员,记住一定不要以 root 身份来运行 Elasticsearch,另外,要不和其他的服务公用相同的用户,然后还要保证该用户的权限要最小化。
     范例君:
sudo -u es-user ES_JAVA_OPTS="-Xms1024m -Xmx1024m"  /opt/elasticsearch/bin/elasticsearc

 
正确设置 Elasticsearch 的数据目录
 
     请确保 Elasticsearch 的目录分配了合理的读写权限,避免使用共享文件系统,确保只有 elasticsearch 的启动用户才能访问,同理,日志目录也一样需要正确配置,避免泄露敏感信息。
     文档君:https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html#path-settings
 
定期对 Elasticsearch 进行备份
 
     使用 Elasticsearch 提供的备份还原机制,定期对 Elasticsearch 的数据进行快照备份,以备不时之需。
     文档君:https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html
 
加上监控和预警
 
     Elasticsearch 提供了很好的默认参数,对参数方面还做了正确性检测,bootstrap 启动检查,不准确的参数,直接不允许 Elasticsearch 启动,以至于有很多人抱怨,怎么现在部署到线上默认就需要做这么多设置才能使用呢,是的,以前启动就默认绑定了所有的网卡,集群见自动发现和相连,现在需要手动绑定局域网网卡,默认只是绑定的本机127.0.0.1的 ip,对上线来说麻烦了一点,做了这些检查也就是为了保证数据安全,以前很多的公网都能直接访问的 Elasticsearch 实例,都是因为默认设置就绑定了公网 ip,但是这些还不够,作为用户,你还需要收集各种日志和系统监控信息,及时主动掌握服务健康和资源使用情况,发现异常情况要及时处理,这里提供一些方案:
  1. 使用开源的 Elastic Stack 收集这些日志,可以使用 Filebeat 收集日志,Metricbeat收集系统监控信息,存进 Elasticsearch,一旦发现异常的波动,使用 Watcher 来进行预警,通过邮件或者 webhook 调用短信、微信或者电话。
  2. 使用其他的监控产品,如 OneAPM、AppDynamic、NewRelic 等等。
  3. 使用托管的 Elasticsearch 云的产品,如 Elastic Cloud等等。


是的,把安全这个事情考虑进去之后,很多事情都要比没考虑要变得更加复杂和麻烦,千里之堤毁于蚁穴,一个不起眼的忽视就有可能造成全部数据的丢失和泄露,出来混迟早是要还的,安全问题千万不能忽视。
 
以上几点建议举例针对 linux 平台,其他平台思路基本上一样,仅供参考,安全是一个包含很多方方面面的学科,抛砖引玉,希望大家有用。 

最后,Elastic 非常关心我们的产品安全,如果您发现有任何安全方面的问题,还请在这里上报:
https://www.elastic.co/community/security
企业用户需要 X-Pack 及 Elastic 官方技术支持,请访问下面的链接:
https://www.elastic.co/cn/contact
 

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

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

转载:http://www.infoq.com/cn/news/2017/01/Rashid-buildYourOwnTool
在 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/2017/01/Rashid-buildYourOwnTool
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 

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

 

Day2:《Kibana 系漫游指南》

Advent三斗室 发表了文章 • 3 个评论 • 1581 次浏览 • 2016-12-02 22:48 • 来自相关话题

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

Kibana Plugin 类型简介

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

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

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

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

官方的我们会看手册啦~

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

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

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

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

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

Kibana Plugin 类型简介

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


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

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

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

官方的我们会看手册啦~

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

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

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

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

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

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

Adventkennywu76 发表了文章 • 14 个评论 • 3660 次浏览 • 2016-12-02 10:07 • 来自相关话题

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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


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


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


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


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

Elastic Advent Calendar 活动启动咯!

Adventmedcl 发表了文章 • 11 个评论 • 981 次浏览 • 2016-11-04 13:46 • 来自相关话题

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

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

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

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

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

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

资讯动态medcl 发表了文章 • 8 个评论 • 627 次浏览 • 2016-09-20 22:23 • 来自相关话题

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

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

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

成都地区Elastic中文社区线下活动通知公告!!!

Elasticsearchxuchengxi2013 发表了文章 • 1 个评论 • 2382 次浏览 • 2016-09-18 17:16 • 来自相关话题

Elastic中文社区技术沙龙【成都站】即将开始咯!
    Elastic 中文社区联手成都卡莱博尔信息技术股份有限公司共同举办线下技术分享会,欢迎对elastic、搜索引擎、大数据等相关技术感兴趣的朋友来参加。
   卡莱博尔是一家以“大数据、移动智能和认知计算”技术为核心的高新技术企业,公司坐落于成都市高新区天府五街,致力于成为中国高端装备产业大数据应用产品和服务提供商,主要为“国防军工、民用航空、先进船舶、轨道交通、电力能源”等装备行业,提供基于装备运行全生命周期故障预测与健康管理相关的大数据技术支撑和运营服务。
    ElasticSearch(下文简称ES)是当前流行的企业级搜索引擎,它提供了一个分布式多用户能力的全文搜索引擎。大数据时代ES能够提供简单易用的方式帮助企业从大型数据库中快速提取有效信息进行分析。
主办方:elastic中文社区        http://elasticsearch.cn/article/101
协办方:成都卡莱博尔信息技术股份有限公司  http://www.cdcalabar.com
 





活动信息:
活动时间:2016年10月29日 下午13:00-17:30(本周六)
活动地点:成都市高新区天府软件园E区1栋10楼  成都卡莱博尔信息技术股份有限公司 多功能会议厅
           (活动地点如有变化,会提前通知)
场地容量:60人
活动费用:免费 
交通信息:地铁1号线  天府五街站下车  E区1栋10楼

分享主题:
(1)ES 在多维分析中的使用​  —— 李峰@ logicmonitor    logicmonitor数据平台高级工程师 
                                                     专注于hadoop生态系统相关实数数据的存储计算
(2)ElasticStack V5 新特性与变化   —— Medcl@elastic  Elastic中文社区创始人和布道师
ElasticStack包括Elasticsearch、Logstash、Kibana和Beats,ElasticStack将在过段时间发布一个V5.0全新版本,这次的分享将给大家介绍一下5.0版里面各个产品的一些新的特性和改进。曾勇是Elasticsearch国内首批用户,自2010年起就开始接触Elasticsearch并投入到生产环境中使用,并编写过一系列的中文处理相关的插件,是Elasticsearch中文社区发起人,筹办了一系列线上线下的Elasticsearch技术分享与交流活动,出于对Elasticsearch的喜爱,目前已全职加入Elasticsearch项目背后的Elastic公司。
(3)探究ES的内部存储结构  —— 林添@ logicmonitor    logicmonitor后端高级工程师  
                                   
PPT资料链接:https://github.com/rudyLi/es-chengdu-meetup-share​ 

报名方式:
 (1)报名连接:http://www.jsform.com/web/form ... fc6a6
 (2)扫描下面微信二维码加入成都Elastic微信群,无法扫描的同学加我微信(xcx_2013),我来拉你进群。电话:15008467351

真诚邀请对elastic技术、搜索引擎技术、大数据存储索引可视化、大数据分析、日志分析等技术感兴趣的朋友前来交流和分享。
  查看全部
Elastic中文社区技术沙龙【成都站】即将开始咯!
    Elastic 中文社区联手成都卡莱博尔信息技术股份有限公司共同举办线下技术分享会,欢迎对elastic、搜索引擎、大数据等相关技术感兴趣的朋友来参加。
   卡莱博尔是一家以“大数据、移动智能和认知计算”技术为核心的高新技术企业,公司坐落于成都市高新区天府五街,致力于成为中国高端装备产业大数据应用产品和服务提供商,主要为“国防军工、民用航空、先进船舶、轨道交通、电力能源”等装备行业,提供基于装备运行全生命周期故障预测与健康管理相关的大数据技术支撑和运营服务。
    ElasticSearch(下文简称ES)是当前流行的企业级搜索引擎,它提供了一个分布式多用户能力的全文搜索引擎。大数据时代ES能够提供简单易用的方式帮助企业从大型数据库中快速提取有效信息进行分析。
主办方:elastic中文社区        http://elasticsearch.cn/article/101
协办方:成都卡莱博尔信息技术股份有限公司  http://www.cdcalabar.com
 
海报图标.png


活动信息:
活动时间:2016年10月29日 下午13:00-17:30(本周六)
活动地点:成都市高新区天府软件园E区1栋10楼  成都卡莱博尔信息技术股份有限公司 多功能会议厅
           (活动地点如有变化,会提前通知)
场地容量:60人
活动费用:免费 
交通信息:地铁1号线  天府五街站下车  E区1栋10楼

分享主题:
(1)ES 在多维分析中的使用​  —— 李峰@ logicmonitor    logicmonitor数据平台高级工程师 
                                                     专注于hadoop生态系统相关实数数据的存储计算
(2)ElasticStack V5 新特性与变化   —— Medcl@elastic  Elastic中文社区创始人和布道师
ElasticStack包括Elasticsearch、Logstash、Kibana和Beats,ElasticStack将在过段时间发布一个V5.0全新版本,这次的分享将给大家介绍一下5.0版里面各个产品的一些新的特性和改进。曾勇是Elasticsearch国内首批用户,自2010年起就开始接触Elasticsearch并投入到生产环境中使用,并编写过一系列的中文处理相关的插件,是Elasticsearch中文社区发起人,筹办了一系列线上线下的Elasticsearch技术分享与交流活动,出于对Elasticsearch的喜爱,目前已全职加入Elasticsearch项目背后的Elastic公司。
(3)探究ES的内部存储结构  —— 林添@ logicmonitor    logicmonitor后端高级工程师  
                                   
PPT资料链接:https://github.com/rudyLi/es-chengdu-meetup-share​ 

报名方式:
 (1)报名连接:http://www.jsform.com/web/form ... fc6a6
 (2)扫描下面微信二维码加入成都Elastic微信群,无法扫描的同学加我微信(xcx_2013),我来拉你进群。电话:15008467351

真诚邀请对elastic技术、搜索引擎技术、大数据存储索引可视化、大数据分析、日志分析等技术感兴趣的朋友前来交流和分享。
 

Elastic中文社区【深圳】第一次线下活动 开始报名啦!

Elasticsearchnodexy 发表了文章 • 1 个评论 • 1975 次浏览 • 2016-08-09 15:34 • 来自相关话题

Elastic中文社区技术沙龙【深圳站】 
主办方:elastic中文社区        http://elasticsearch.cn/article/99 协办方:vivo移动互联网中心 http://www.vivo.com.cn






PPT 下载: https://github.com/node/esmeetup-shenzhen2016 

活动现场:






活动信息:
活动时间:2016年9月10日 下午13:00活动地点:深圳市福田区上梅林地铁站 安得街89号步步高大楼1楼场地容量:100人活动费用:免费 ( 现场有福利派发 : )交通信息:地铁4号龙华线 上梅林站 ,公交 万科大厦站参考地标:梅林天虹西侧,卓越城对面

报名方式:
报名链接:http://biaodan100.com/web/formview/57a98d000cf2e5aae034e1e4或者扫码二维码:





真诚邀请对elastic技术栈,搜索引擎技术,大数据存储索引可视化,日志分析等技术感兴趣的朋友前来交流和分享。

分享主题:
ElasticStack V5 新特性与变化              By 曾勇@elastic  Elastic开发工程师与技术布道师ElasticStack包括Elasticsearch、Logstash、Kibana和Beats,ElasticStack将在过段时间发布一个V5.0全新版本,这次的分享将给大家介绍一下5.0版里面各个产品的一些新的特性和改进。曾勇是Elasticsearch国内首批用户,自2010年起就开始接触Elasticsearch并投入到生产环境中使用,并编写过一系列的中文处理相关的插件,是Elasticsearch中文社区发起人,筹办了一系列线上线下的Elasticsearch技术分享与交流活动,出于对Elasticsearch的喜爱,目前已全职加入Elasticsearch项目背后的Elastic公司。ELK应用 --- 一卡易实时日志分析平台   By 夏小成@一卡易   一线码农目前一卡易实时日志分析平台汇集了包括windows事务日志、linux日志、haproxy访问日志、业务数据库审计日志和大数据平台日志,为一卡易数十个产品线提供了便捷的日志检索和分析服务。未来我们会把elasticsearch逐渐引入到我们的业务系统,更深层次挖掘她的魅力。构建数据驱动的动画工作室 - es及ELK实践          By 赵昆@东方梦工厂   IT与数据系统工程师京东日志系统es运维经验分享及es源码改造实践   By 成睿 @京东曾负责京东日志系统的搜索平台,目前负责京东到家商品搜索平台。介绍京东日志系统es的一些运维经验和我2次改es源代码的实践。



----------------------------------------------------------------------------------
联络邮件: nodexy@qq.com 或者直接站内私信。----------------------------------------------------------------------------------

  查看全部
Elastic中文社区技术沙龙【深圳站】 

es-vmic-weixin.png



PPT 下载: https://github.com/node/esmeetup-shenzhen2016 

活动现场:
Elastic技术沙龙_深圳站_大合影_final.jpg



活动信息:
  • 活动时间:2016年9月10日 下午13:00
  • 活动地点:深圳市福田区上梅林地铁站 安得街89号步步高大楼1楼
  • 场地容量:100人
  • 活动费用:免费 ( 现场有福利派发 : )
  • 交通信息:地铁4号龙华线 上梅林站 ,公交 万科大厦站
  • 参考地标:梅林天虹西侧,卓越城对面


报名方式:

qrcode.jpg


真诚邀请对elastic技术栈,搜索引擎技术,大数据存储索引可视化,日志分析等技术感兴趣的朋友前来交流和分享。

分享主题:
  • ElasticStack V5 新特性与变化              By 曾勇@elastic  Elastic开发工程师与技术布道师ElasticStack包括Elasticsearch、Logstash、Kibana和Beats,ElasticStack将在过段时间发布一个V5.0全新版本,这次的分享将给大家介绍一下5.0版里面各个产品的一些新的特性和改进。曾勇是Elasticsearch国内首批用户,自2010年起就开始接触Elasticsearch并投入到生产环境中使用,并编写过一系列的中文处理相关的插件,是Elasticsearch中文社区发起人,筹办了一系列线上线下的Elasticsearch技术分享与交流活动,出于对Elasticsearch的喜爱,目前已全职加入Elasticsearch项目背后的Elastic公司。
  • ELK应用 --- 一卡易实时日志分析平台   By 夏小成@一卡易   一线码农目前一卡易实时日志分析平台汇集了包括windows事务日志、linux日志、haproxy访问日志、业务数据库审计日志和大数据平台日志,为一卡易数十个产品线提供了便捷的日志检索和分析服务。未来我们会把elasticsearch逐渐引入到我们的业务系统,更深层次挖掘她的魅力。
  • 构建数据驱动的动画工作室 - es及ELK实践          By 赵昆@东方梦工厂   IT与数据系统工程师
  • 京东日志系统es运维经验分享及es源码改造实践   By 成睿 @京东曾负责京东日志系统的搜索平台,目前负责京东到家商品搜索平台。介绍京东日志系统es的一些运维经验和我2次改es源代码的实践。




----------------------------------------------------------------------------------
联络邮件: nodexy@qq.com 或者直接站内私信。----------------------------------------------------------------------------------

 

南京Elastic社区第一次线下活动

默认分类kenny_ye 发表了文章 • 0 个评论 • 3481 次浏览 • 2016-05-26 20:45 • 来自相关话题

1. 主办方
Elastic中文社区  趋势科技





2. 时间地点
 活动时间:2016年6月25日 14:00 - 17:30 
 活动地点:雨花区软件大道48号苏豪国际广场B座(靠花神庙地铁站)





3. 主题 
分享一:ES和Kibana在实时流量分析中的应用
演讲者简介:
杨润达​ 南京云利来软件科技有限公司研发部
 
主题简介:
流量的抓取和存储,流量的可视化,有关流量异常的案例分析,在线的kibana功能展示。
 
分享二:ELK平台SaaS化的问题和解决方案
演讲者简介:



 
王晓亮(Tomo Wang) 瀚思安信高级研发工程师
毕业于南京大学,曾就职于趋势科技、Opera,现任瀚思安信高级研发工程师,负责瀚思在线安全分析平台“安全易”的研发工作。
 
主题简介:
ELK(ElasticSearch,Logstash,Kibana)是一套有效的开源日志分析平台,它们作为工具使用非常便利,但是如果要围绕它们搭建在线服务,却有诸多问题。这次的分享主要介绍“安全易”在SaaS化ELK平台的过程中遇到的问题以及对应的技术方案。
 
分享三:ES在苏宁海量日志平台的实践
演讲者简介:




彭燕卿 苏宁云商IT总部监控研发中心技术副总监
9年软件研发经验,09年加入苏宁,先后从事了SOA系统开发、苏宁易购等大型网站的性能分析调优、监控平台等系统研发和架构工作,目前主要从事苏宁监控系统架构及技术管理工作,专注于APM以及Elasticsearch等实时计算领域。
 
主题简介:
实时日志平台ES架构演变,ES使用过程中遇到的坑及调优,Kibana二次开发等。
 
分享四:甲方安全看日志消息在ELK中的流转​
演讲者简介:
李天爽 闻心科技上海研发中心总监
毕业于南京大学,曾担任趋势科技高级工程师,携程信息安全部资深安全研发工程师。
 
主题简介:
分享携程的日志平台架构、安全事件在ELK中的生命周期、ES的权限方案等。
 
分享五:ES在移动病毒分析和检测中的应用
演讲者简介:




李啸(White Li) 趋势科技中国研发中心资深工程师
毕业于南京邮电大学,曾就职于小米、百度,专注于大规模分布式系统的架构和运维,现负责趋势科技移动安全专家系统的开发工作。
 
主题简介:
介绍ES在样本分析、检测系统中的应用和逐步演变,重点探讨碰到的问题和解决方案。
 
4. 主题slides

ES南京meetup资料


  查看全部
1. 主办方
Elastic中文社区  趋势科技
eslogo.jpg


2. 时间地点
 活动时间:2016年6月25日 14:00 - 17:30 
 活动地点:雨花区软件大道48号苏豪国际广场B座(靠花神庙地铁站)
suhao.PNG


3. 主题 
分享一:ES和Kibana在实时流量分析中的应用
演讲者简介:
杨润达​ 南京云利来软件科技有限公司研发部
 
主题简介:
流量的抓取和存储,流量的可视化,有关流量异常的案例分析,在线的kibana功能展示。
 
分享二:ELK平台SaaS化的问题和解决方案
演讲者简介:
翰思-王晓亮.jpg
 
王晓亮(Tomo Wang) 瀚思安信高级研发工程师
毕业于南京大学,曾就职于趋势科技、Opera,现任瀚思安信高级研发工程师,负责瀚思在线安全分析平台“安全易”的研发工作。
 
主题简介:
ELK(ElasticSearch,Logstash,Kibana)是一套有效的开源日志分析平台,它们作为工具使用非常便利,但是如果要围绕它们搭建在线服务,却有诸多问题。这次的分享主要介绍“安全易”在SaaS化ELK平台的过程中遇到的问题以及对应的技术方案。
 
分享三:ES在苏宁海量日志平台的实践
演讲者简介:
苏宁-彭燕卿.jpg

彭燕卿 苏宁云商IT总部监控研发中心技术副总监
9年软件研发经验,09年加入苏宁,先后从事了SOA系统开发、苏宁易购等大型网站的性能分析调优、监控平台等系统研发和架构工作,目前主要从事苏宁监控系统架构及技术管理工作,专注于APM以及Elasticsearch等实时计算领域。
 
主题简介:
实时日志平台ES架构演变,ES使用过程中遇到的坑及调优,Kibana二次开发等。
 
分享四:甲方安全看日志消息在ELK中的流转​
演讲者简介:
李天爽 闻心科技上海研发中心总监
毕业于南京大学,曾担任趋势科技高级工程师,携程信息安全部资深安全研发工程师。
 
主题简介:
分享携程的日志平台架构、安全事件在ELK中的生命周期、ES的权限方案等。
 
分享五:ES在移动病毒分析和检测中的应用
演讲者简介:
趋势-李啸.jpg

李啸(White Li) 趋势科技中国研发中心资深工程师
毕业于南京邮电大学,曾就职于小米、百度,专注于大规模分布式系统的架构和运维,现负责趋势科技移动安全专家系统的开发工作。
 
主题简介:
介绍ES在样本分析、检测系统中的应用和逐步演变,重点探讨碰到的问题和解决方案。
 
4. 主题slides

ES南京meetup资料