恩，重要的事情說三遍，“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只是一個問題的解決方案，剛好他們三個發現，咦，我們原來組合在一起還能幹這種事情丫！但是，他們真的只是一個解決方案，不能算是一個完整的產品（怎麼辦，說道這裏我好怕你們開始拿百科產品的概念來噴我）
