恩，重要的事情说三遍，“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只是一个问题的解决方案，刚好他们三个发现，咦，我们原来组合在一起还能干这种事情丫！但是，他们真的只是一个解决方案，不能算是一个完整的产品（怎么办，说道这里我好怕你们开始拿百科产品的概念来喷我）