知乎為什麼要自己開發日誌聚合系統「kids」而不用更簡潔方便的「ELK」？

12-29

ELK部署方便，而elasticsearch是基於Lucene的分散式搜索引擎，本身就是一個分散式了，而且ELK是個很成熟的方案。為何知乎還要自己開發一套系統呢？

- 參考

zhihu/kids · GitHub

kids：知乎日誌系統 - Hacker"s log - 知乎專欄

知乎發布的分散式日誌系統 Kids 意義在於哪裡？ - 軟體開發

2010年scribe停止開發，之後才有一大把開源日誌系統出現。有心人去github上看看就知道，目前流行的幾個，logstash、graylog2、fluentd、flume，都是從11、12年開始起步的。我第一次看到logstash是在devopsweekly上，說實話，那時候的logstash並沒有牛逼到讓人一眼覺得這就是未來一統江山的項目的了……說ES，graylog2也是用的ES做存儲，說頁面，那時候kibana還是php寫的一個小頁面，我自己看了兩天es官網文檔，一下午寫了個頁面生成的統計報表已經比kibana好用了。唯一讓我拋棄graylog2選擇logstash的原因是：graylog2的官網不幸在那個時候被牆了！！！

那個12年，我提供場地，北京的 ES 愛好者們聚會，三十來個人，聽 medcl 一個人講基礎知識講了一個下午——可見那時候真的是沒啥人懂。

但是隨著深入，真的是越來越認定elk了。這是一個開源社區的話題。logstash的作者，jordansissel，是devops界的著名人物，從零幾年就維護著每年一度的sysadvent活動；對比一下各項目在devopsweekly上出現的頻率，elk也是遙遙領先。強者愈強。曝光率可以帶來貢獻者活躍度，也就有了未來。差不多一年時間，其他項目都加上了以logstash的schema輸出數據，kibana的angularjs版本推出，ES融資並收購l和k……

不過，這都是13年的事情了……12年的SACC，當時七牛還是又拍的CTO演講說他們的數據都是走logstash收集，一天有一個億的event，我當時還驚訝著呢。而現在，我自己手頭走logstash的event一天有二十多億。

所以12年，大家(知乎)選擇自己搞或者選擇其他的系統，都是再正常不過的事情。

相關：鄙人 logstash 群群主，gitbook上有寫關於logstash和kibana的中文電子書。

只想分析一下為什麼不用elasticsearch+logstash+kibana這樣的方案。
我們先分析一下時間。
提問裡面的第二個參考鏈接，也就是知乎專欄里第一次介紹這個kids系統是兩年前。
elasticsearch在github上的第一個release是2010年2月8日，0.4.0版本。
logstash在github上的第一個release是2011年5月7日，1.0.0版本。
kibana在github上的第一個release是2013年4月4日，3.0.0-m1版本。
貌似在2012年還沒有Kibana唉，logstash也剛發布沒多久。說有多成熟，呵呵。

再來看一下Google的搜索趨勢

在2012年的這樣一個時間點上，你說讓我選擇elasticsearch+logstash+kibana這樣的一個方案，你忽悠誰呢？

自己寫東西的前提是沒得選……
即便放在2014年，ELK裡面，Elasticsearch 是機器消耗大戶，Logstash 還有各種深坑，連 File 分卷都沒完成，Kibanna 出現得時間那麼晚，加上 JRuby 這樣的資源消耗大戶，換我有人力物力我也會自己寫……

可控，是系統架構師追求的目標之一……

寫了一個東西，替代了市面上的其他開源方案，別人不好接手，這樣更有底氣跟老闆說加薪。還有就是練手，練好了萬一以後跳槽呢，也正好作為忽悠資本，一箭雙鵰。

我們公司是flume+kafka+storm，快的一塌糊塗，後兩者穩定的一塌糊塗，代碼寫起來簡單的一塌糊塗，一天消息50多億，普通情況下100-200MB/s的數據吞吐，簡單的一塌糊塗。開源牛的一塌糊塗，自己寫那是傻的一塌糊塗。

很少有系統是完美的，不是說做不到，而是不可能花那麼多錢（時間，人都是錢）。自己做系統的好處就是：有坑我知道，我知道怎麼改。其實日誌處理沒有想的那麼簡單或複雜，難點是如何從這些日誌中真正的幫助找問題。

一般自己搞一套東西的原因，對外的解釋都很高大上，和理想情懷有關，其實單獨搞一套東西，無外乎兩個目的，自己為了練手和為了升職加薪。

利用開源的組件可以快速搭建系統，但是如果要追求高性能和大數據量並發，還是要自己進行演算法優化。ELK經過優化可以實現千億級別的數據量處理，如果達到萬億級別的就需要Hadoop架構了。

(大前提是知乎的日誌量級,想必並沒有那麼大,而這個需求又相當通用型的.)
==============毒舌的分割線==============
說好聽點這些是練手,放到以後的人看,就是自造飛機那種民科嘛.(或者民工,民間工程師的民工).
把飛機開好做一個好飛行員, 輪船引擎會修也是輪機長, 才是更常見的道路.

==============理客中的分割線==============
然而哪個蓬勃發展的技術領域,也都是必然經歷這種活躍的階段的,萊特兄弟就顯然是民工哈.

想想在學校接受的教育(答主通信工程不是CS),是一點不會讓本科學子產生自己單槍匹馬可以做一個通用系統的想法的,當然也不會抑制學生們自己攢個收音機再有錢了湊個軟基站的想法的,但是教學內容是會給你正確的暗示告訴學生嚴謹的工程和智力娛樂的區別的.

主要原因還是市場吧, 工程的成功就是在市場競爭中成功的存活,給使用者創造價值, 土木通信機械等等都是面對一個成文標準下的統一市場, 基本都是公開的, 因為最終交付的核心還是產品.

而軟體行業被劃分為服務業, 除了一些OS,語言編譯器,資料庫等基礎設施軟體, 大多數軟體的主要交付形式是服務, 工程師的價值也在於為客戶提供持續的服務, 知乎的這套日誌系統帶上支撐它的人所提供的服務, 才是一個整體, 這個整體能夠服務好他的目的他的客戶就是成功的.

自己寫的東西有專人維護，出了問題有支持，開源的組件出了問題只有加班了。

先不討論這兩者誰優誰劣，最起碼自己做出來的東西以後拿出去能吹牛逼，就像是自己培養的孩子一樣，能夠親眼見證他的成長與煩惱，也不失為人生的一種樂趣，我覺得這就是知乎工程師的情懷吧，而且拿了投資人的錢，有資本做這些事情，做出來這套系統以後也就是軟體著作和專利方面的事情，對公司的財務及未來的融資都很有幫助的，可以標榜高新技術企業，北京市政府是有政策扶持的，海淀區政府也會有很多政策及資金上的補貼，做這事肯定不虧，萬一成功了呢!!!