elastic作数据源，对比kibana与grafana

         今天说说，我们为什么会选择从kibana4迁移到grafana，并选用grafana作为elasticsearch的图表展现工具。 文章中关于kinaba和grafana的对比会有些片面，勿喷.

 

最一开始使用kibana ElasticSearch的组合是为了集中式收集应用及系统日志.  后来由于业务方面的原因，现在各个业务的多数模块也选择依赖elasticsearch。除此之外，现在监控的数据也从opentsdb hbase迁移到elasticsearch里面。 目的 ？ 只为更好的实时聚合计算，并快速的展现

 

先说下kibana方面的事，kibana往往在展现一条数据的时候效果是完美的，尤其是kibana4那种清淡的绿色让人心旷神怡。 但很多时候我们要做多维度数据图表展现, 这地方kibna貌似没有做图表样式的优化。当很多条数据拥挤在一起时，很难区分出每个点的数值，换句话说很不直观。  另外kibana更加适合日志类型的展现， 虽然他也可以kv结构，但配置起来有些麻烦. 

 

另外kibana没有管理的api,  只能点来点去.  在kibana4.x的版本里集成了一个node服务端，但就最新的版本来说，他只是被当成一个静态服务器使用，没有更多的动态功能，比如权限管理。 

去年写过一个文章专门描述kibana批量操作的问题. 当时的需求是有很多的图表及dashboard面板.  如果靠着手动点击不怎么现实.  后来发现Kibana的数据都存在elasticsearch里，

所以写了个较完整的python模块去直接操作elasticsearch，其实就是个.kibana的配置文件.  因为api跟公司的业务耦合一起了，所以暂不方便开源出来。 kibana es批量操作，http://xiaorui.cc/?p=1570 有兴趣看看.

 

kibana没有权限管理，用户管理。  大多数人都是使用nginx做为kibana的基本密码认证（HTTP Auth Basic），这样做也能保证一定的安全，但毕竟不和规矩. 

 

刚才说的kibana的槽点, 在grafana里是可以解决的。对比kibana4来说，grafana支持更多数据源.  grafana以前的1.x版本就支持不少的时序数据库，比如最风光的influxdb，适合大集群大存储的opentsdb， 单机存储的graphite . 后有老外把zabbix扩展到grafana里。现在新版的grafana也支持elasticsearch了。   感叹，elasticsearch是越来越火了，功能也越来越丰富. 

grafana官方有不少语言的控制api, 只是没有python的。 在github中找到一个老外开源的grafana python api , grafana_api_client。  grafana docs有详细的api使用文档，有兴趣的朋友看看. 

 

 

 

 

 

 

Python

 

1 2 3 4 5 6 7 8 9 10

fromgrafana_api_client importGrafanaClient client=GrafanaClient(("admin","admin"),host="127.0.0.1",port=3000)# or, alternatively: client=GrafanaClient("yourapikey",host="127.0.0.1",port=3000) client.org() #{"id":1,"name":"Main Org."} client.org.replace(name="Your Org Ltd.") #{"id":1,"name":"Your Org Ltd."} client.dashboards.db.create(dashboard={...},overwrite=False) #{"dashboard": {...}, "overwrite": False}

kibana vs grafana功能对比:

单纯的日志，我还是推荐大家把日志报表放在elk （ kibana ）里面的，因为kibana的模板有针对日志的search语法，有的query_string ,match 全文匹配。 如果kibana本身的搜索需求不能满足你，你可以使用JSON Input来实现自定义的搜索语法。 grafana用的则都是类似term这样的精确匹配. 

监控方面的数据，尤其是那种metrics监控类型数据，非常适合用Elasticsearch Grafana组合.  题外说下，对于监控数据的落地我们走了不少的坑，从rrdtool, mysql, Influxdb, OpenTsdb到最后的Elasticsearch，其中的db选型失败也有我们自身能力的原因.  Opentsdb没有想象中的那么好. 

修正上面的说法，grafana的新增图表里面，会有elasticsearch和ES LOG两项. 对于metric names字段也是有正则匹配的模式，对于具体的value是可以模糊匹配，正则匹配，lucene全文索引匹配规则. 

 

       

       我用过kibana的好多版本,  我曾经在Kibana Issue问过他们为什么不把kibana的node.js后端做的丰富一点，作者给我的答复是, 他们本来就不想做太复杂，只是想单纯的做前端图表显示.

 

       转自： http://xiaorui.cc/2016/01/07/%E4%BB%8Ekibana%E8%BF%81%E7%A7%BB%E5%88%B0grafana%E4%BD%9C%E4%B8%BAelasticsearch%E7%9A%84%E5%89%8D%E7%AB%AF%E5%B1%95%E7%8E%B0/

评论

1 楼 tobato 2016-12-30  

Elasticsearch 和 Influxdb 为何选了Elasticsearch? 最近在考虑选型，希望楼主能给点信息。