項(xiàng)目中之前都是采用數(shù)據(jù)庫(kù)來(lái)記錄日志，雖然記錄還算挺方便，但是每次都要到數(shù)據(jù)庫(kù)來(lái)查詢(xún)，如果日志在單獨(dú)的數(shù)據(jù)庫(kù)還好，只是有點(diǎn)麻煩。如果記錄的日志數(shù)據(jù)庫(kù)和生產(chǎn)正式庫(kù)在一起，不僅會(huì)影響生產(chǎn)庫(kù)的正常使用，也會(huì)帶來(lái)安全隱患。
項(xiàng)目早期沒(méi)有統(tǒng)一規(guī)劃，也是時(shí)間倉(cāng)促，沒(méi)有做好日志的規(guī)劃，所有日志都記錄到數(shù)據(jù)庫(kù)中。的確也遇到了性能問(wèn)題，因此在了解ELK的基礎(chǔ)上，使用其作為日志采集、處理和檢索的幾本框架。
大體框架
日志數(shù)據(jù)流如下，應(yīng)用將日志落地在本地文件，部署在每臺(tái)服務(wù)器上的FileBeat負(fù)責(zé)收集日志，然后將日志發(fā)送給LogStash；LogStash將日志進(jìn)行處理之后，比如parse等；然后將處理后的Json對(duì)象傳遞給ElasticSearch，進(jìn)行落地并進(jìn)行索引處理；最后通過(guò)Kibana來(lái)提供web界面，來(lái)查看日志等。因?yàn)镋S是基于Lucene的，所以Kibana支持Lucene查詢(xún)語(yǔ)法。
對(duì)于日志數(shù)據(jù)流特別大的情況，LogStash會(huì)造成擁堵，這個(gè)時(shí)候可以使用消息隊(duì)列來(lái)進(jìn)行緩沖。同時(shí)，日志一旦進(jìn)過(guò)LogStash之后，會(huì)不方面一些流處理程序來(lái)讀取。這個(gè)時(shí)候使用kafka就比較好了，因?yàn)閗afka是將消息持久化在本地，流處理應(yīng)用可以從消息的offset初始的地方來(lái)讀取。加入kafka的后的流程如下：