雖然作為一個后端開發(fā)，可能對日志系統(tǒng)lek的直接應(yīng)用多過于學(xué)習(xí)維護(hù)，但是我們運維維護(hù)的elasticsearch總是崩，每次都說我用得不對，出于這個原因，決定對lek進(jìn)行一次粗略的學(xué)習(xí)，對基本概念和使用方法記錄和總結(jié)。

我們的lek

lek是三個工具，負(fù)責(zé)數(shù)據(jù)采集的logstash，負(fù)責(zé)存放和搜索的elasticsearch，負(fù)責(zé)數(shù)據(jù)展示的kibana，在我們公司還有用到一個負(fù)責(zé)數(shù)據(jù)上報的kafka，kafka也是logstash的數(shù)據(jù)來源。

按照我們現(xiàn)在的使用場景主要是：記錄用戶行為事件，我也是主要以存儲用戶事件為例來學(xué)習(xí)這三個工具，畢竟學(xué)了沒有應(yīng)用場景很難徹底掌握。

主要操作按照數(shù)據(jù)流向來講。

用戶操作調(diào)用外部接口，外部接口調(diào)用微服務(wù)，其中有些微服務(wù)是底層上報服務(wù)，而上報服務(wù)將kafka封裝，約定一個kafka topic對應(yīng)一個用戶行為，比如登錄，注冊，產(chǎn)生消費。用戶每個行為都會調(diào)用到這個上報服務(wù)，所以負(fù)載非常高，但是得益于kafka優(yōu)秀的性能，我們的一些監(jiān)聽事件的需求得以實現(xiàn)，并且最重要的是可以解耦，比如當(dāng)用戶登錄超過3天送代金券或者說用戶登錄時等級超過某個級別時送什么東西。每個服務(wù)之間相互獨立，互不干擾，只需要監(jiān)聽相應(yīng)的topic就完事了。

然后logstash也是監(jiān)聽了kafka的所有的用戶事件廣播，將kafka的廣播內(nèi)容轉(zhuǎn)化成對應(yīng)es中預(yù)先設(shè)定好的的數(shù)據(jù)類型，將數(shù)據(jù)過濾，拼接，批量之后，對es發(fā)起存儲請求，將用戶在什么時間段干了什么存進(jìn)es中。

logstash存進(jìn)elasticsearch的大量數(shù)據(jù)，通過elasticsearch的優(yōu)秀搜索性能，在全文檢索，日志分析這個場景上，es比mysql搜索起來快很多（為了提高數(shù)據(jù)可用性，我們還將同樣的數(shù)據(jù)存儲進(jìn)一個分月分表的mysql中，但是很少用，搜索起來也比es慢很多），然后這些數(shù)據(jù)可以讓我們數(shù)據(jù)中心分析，或者是做一些年度榜單，或者是用戶個人年度總結(jié)的一些數(shù)據(jù)來源，又或者是用戶統(tǒng)計。

kibana作為es數(shù)據(jù)可視話工具，在日常中用得比較多。比如經(jīng)常有運營讓我?guī)兔茨硞€用戶是不是真的連續(xù)登陸能領(lǐng)取優(yōu)惠還是在欺騙我們的運營，或者是測試說我們莫名其妙改了他的密碼，我們會用他曾經(jīng)干了什么來打他的臉，或者是被盜號了ip多次變化，或者是怎樣的一些用戶行為需要查詢的。打開kibana，點一點就能把相關(guān)的數(shù)據(jù)輕松找到，而不用寫腳本，或者復(fù)雜的es查詢語句。

之后會每天學(xué)習(xí)一個工具，在此記錄發(fā)表。

ps：在網(wǎng)上看到很多公司通過lek來記錄服務(wù)日志，但是我們公司并沒有那么多資源可以搭建滿足所有服務(wù)日志采集的lek，所以只記錄最重要的用戶事件。。。要是有條件，可以通過logstash把所有日志都存進(jìn)es，特別是針對微服務(wù)來說，這樣，像是調(diào)用鏈的數(shù)據(jù)來源，可視化日志，日志分析都有可能實現(xiàn)。