恩崩瓤，重要的事情說三遍袍啡，“ELK真的不是一個產(chǎn)品！”却桶，“ELK真的不是一個產(chǎn)品境输！”，“ELK真的不是一個產(chǎn)品颖系！”
呃嗅剖。。各位看官不用誤會嘁扼，我不是說ELK不好信粮，我也不是ELK黑粉，ELK是一個非常好的日志解決方案趁啸，但是在我看來不是一個產(chǎn)品强缘。好吧好吧。不傅。旅掂。讓我慢慢道來
ELK是一個方案
ELK是我們這些窮苦運維的一個解決方案：我Splunk是一個產(chǎn)品，日志易是一個產(chǎn)品蛤签，LogInsight是一個產(chǎn)品辞友，但是ELK真的是不是啊。震肮。称龙。起碼人家官網(wǎng)沒有大大的打出這個東西就叫做ELK，官網(wǎng)上有ElasticSearch戳晌、LogStash鲫尊、Kibana各個產(chǎn)品的說明（這三個東西真的是產(chǎn)品=。=）沦偎，但是卻沒有一個叫做ELK產(chǎn)品說明文檔疫向。
從發(fā)展歷史來看，LogStash設計之初的目的是為了解決輸入豪嚎、轉換搔驼、輸出的問題，ElasticSearch解決的問題是搜索侈询，Kibana雖然比較正派舌涨，但是再把Beat這種東西套上然后給Kibana放點監(jiān)控的東西居然一點違和感都沒有（好吧，我承認我是有對Kibana先入為主的違和感啦 (≡ω≡．) ）
反正扔字，我認為他就是一個給窮苦運維們使用的解決方案囊嘉，我就這么認為了温技，不服來戰(zhàn) ?（′???）? （別打別打。扭粱。是一個產(chǎn)品了還不行么 ( ＿ ＿)ノ｜扶墻 ）
設計問題
正因為不是一個產(chǎn)品舵鳞，所以其實各個組件設計之間其實考慮是欠缺的（真委屈了我們的Kibana了[](￣▽￣)*），首先琢蛤，LogStash只管輸入蜓堕、格式化、輸出博其，但是卻沒管應該怎么樣放俩滥，放了從哪放到哪，哦贺奠，可能你會說霜旧，人家LogStash可是有區(qū)分時間來建立索引的，╮(╯▽╰)╭ 太弱啦儡率，正因為不是一個產(chǎn)品挂据，所以LogStash根本沒有責任和義務去幫ES管一下元數(shù)據(jù)，讓Kibana跑起來更快一些儿普，搞到最后只能辛苦Kibana自己搞個索引來管元數(shù)據(jù)了崎逃，這種元數(shù)據(jù)的管理方法當然也就沒有那么好啦
LogStash：我是無辜的。 ElasticSearch：別哭眉孩，讓那沒地位的Kibana干
好啦个绍，事情到了這里，那為什么ELK這個解決方案一直都沒有特別好的告警浪汪、告警回調等等功能也就很好理解了巴柿。。這活總不能給Kibana了吧死遭。广恢。它還只是個孩子
總的來說
總的來說，ELK只是一個問題的解決方案呀潭，剛好他們三個發(fā)現(xiàn)钉迷，咦，我們原來組合在一起還能干這種事情丫钠署！但是糠聪，他們真的只是一個解決方案，不能算是一個完整的產(chǎn)品（怎么辦谐鼎，說道這里我好怕你們開始拿百科產(chǎn)品的概念來噴我）
