ELK真的不是一个产品

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/weixin_29477879/article/details/52193278

恩,重要的事情说三遍,“ELK真的不是一个产品!”,“ELK真的不是一个产品!”,“ELK真的不是一个产品!”

呃。。各位看官不用误会,我不是说ELK不好,我也不是ELK黑粉,ELK是一个非常好的日志解决方案,但是在我看来不是一个产品。好吧好吧。。。让我慢慢道来

这里写图片描述

ELK是一个方案

ELK是我们这些穷苦运维的一个解决方案:我Splunk是一个产品,日志易是一个产品,LogInsight是一个产品,但是ELK真的是不是啊。。。起码人家官网没有大大的打出这个东西就叫做ELK,官网上有ElasticSearch、LogStash、Kibana各个产品的说明(这三个东西真的是产品=。=),但是却没有一个叫做ELK产品说明文档。

从发展历史来看,LogStash设计之初的目的是为了解决输入、转换、输出的问题,ElasticSearch解决的问题是搜索,Kibana虽然比较正派,但是再把Beat这种东西套上然后给Kibana放点监控的东西居然一点违和感都没有(好吧,我承认我是有对Kibana先入为主的违和感啦 (≡ω≡.) )

反正,我认为他就是一个给穷苦运维们使用的解决方案,我就这么认为了,不服来战 ʅ(´◔౪◔)ʃ (别打别打。。是一个产品了还不行么 ( _ _)ノ|扶墙 )

这里写图片描述

设计问题

正因为不是一个产品,所以其实各个组件设计之间其实考虑是欠缺的(真委屈了我们的Kibana了[]~( ̄▽ ̄)~*),首先,LogStash只管输入、格式化、输出,但是却没管应该怎么样放,放了从哪放到哪,哦,可能你会说,人家LogStash可是有区分时间来建立索引的,╮(╯▽╰)╭ 太弱啦,正因为不是一个产品,所以LogStash根本没有责任和义务去帮ES管一下元数据,让Kibana跑起来更快一些,搞到最后只能辛苦Kibana自己搞个索引来管元数据了,这种元数据的管理方法当然也就没有那么好啦

这里写图片描述

LogStash:我是无辜的。 ElasticSearch:别哭,让那没地位的Kibana干

好啦,事情到了这里,那为什么ELK这个解决方案一直都没有特别好的告警、告警回调等等功能也就很好理解了。。这活总不能给Kibana了吧。。它还只是个孩子

这里写图片描述

总的来说

总的来说,ELK只是一个问题的解决方案,刚好他们三个发现,咦,我们原来组合在一起还能干这种事情丫!但是,他们真的只是一个解决方案,不能算是一个完整的产品(怎么办,说道这里我好怕你们开始拿百科产品的概念来喷我)

这里写图片描述

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页