企業(yè)規(guī)模不同，日志運(yùn)維的方式就有所不同。在WOT2016移動(dòng)互聯(lián)網(wǎng)技術(shù)峰會(huì)上，來(lái)自新浪微博的資深系統(tǒng)開(kāi)發(fā)工程師于炳哲，同與會(huì)者深入分析了小企業(yè)與大企業(yè)的日志運(yùn)維問(wèn)題，手機(jī)微博日志系統(tǒng)架構(gòu)相關(guān)的調(diào)優(yōu)，以及自己對(duì)日志運(yùn)維的反思。
小企業(yè)日志運(yùn)維
小企業(yè)日志運(yùn)維關(guān)注點(diǎn)在于：成本、數(shù)據(jù)規(guī)模以及維護(hù)的難度。首先，我們來(lái)看看小企業(yè)在不同規(guī)模下的日志架構(gòu)。小企業(yè)日志架構(gòu)的特點(diǎn)：擴(kuò)展相對(duì)簡(jiǎn)單、業(yè)務(wù)復(fù)雜度低、業(yè)務(wù)依賴度低、歷史遺留問(wèn)題相對(duì)較少，所以重構(gòu)成本相對(duì)較低、可投入的資源相對(duì)較少。
其實(shí)對(duì)于小企業(yè)來(lái)講可能都會(huì)經(jīng)歷幾個(gè)階段，首先是開(kāi)荒的階段，即是服務(wù)剛剛上線，還處于測(cè)試和開(kāi)發(fā)的階段。這時(shí)候，企業(yè)的應(yīng)用可能就是布置一臺(tái)或者兩臺(tái)服務(wù)器，此時(shí)沒(méi)有必要做一套完整的日志架構(gòu)。用純文本 + grep + awk + sed即可完成日志的提取。如果使用傳統(tǒng)的數(shù)據(jù)庫(kù)，可以在開(kāi)發(fā)中將重要數(shù)據(jù)直接寫(xiě)入數(shù)據(jù)庫(kù)。或者使用第三方監(jiān)控，采用業(yè)務(wù)接口監(jiān)控(lua -> nginx shard dict -> DB(graphite))。
然后，進(jìn)入數(shù)據(jù)增長(zhǎng)階段。此時(shí)的架構(gòu)變成了分布式，也就是日志可能在不同的服務(wù)器上，業(yè)務(wù)也已經(jīng)上線，這時(shí)候需要及時(shí)的反饋信息，需要專業(yè)的運(yùn)維人員做日志架構(gòu)設(shè)計(jì)。如下圖的基于ALK簡(jiǎn)單的設(shè)計(jì)：
隨著日志的逐漸增多，業(yè)務(wù)的逐漸擴(kuò)展，進(jìn)入了日志服務(wù)器中轉(zhuǎn)階段，此時(shí)需要收集的日志總量還未達(dá)到Elasticsearch(單數(shù)據(jù)節(jié)點(diǎn))的寫(xiě)入量，企業(yè)對(duì)日志數(shù)據(jù)的安全性要求并不是特別高，同時(shí)對(duì)單點(diǎn)問(wèn)題也不是很重視。在盡量少的運(yùn)維投入下，希望快速構(gòu)建。不要有太高的技術(shù)門(mén)檻。
這時(shí)候架構(gòu)可能就會(huì)變成這樣，這是一個(gè)大家中小企業(yè)，或者在50人以下，KPI在幾萬(wàn)左右的廠商，基本就可以采用這種架構(gòu)。就是說(shuō)你的前面是日志agent，把日志直接寫(xiě)到日志服務(wù)器上，直接落磁盤(pán)。在這個(gè)上面用logstash或者其他的一些日志處理的組件，直接進(jìn)行收集，把日志寫(xiě)到ES里。在這個(gè)階段還沒(méi)有到達(dá)一個(gè)ES的性能瓶頸，我一直強(qiáng)調(diào)的是在整個(gè)日志的架構(gòu)當(dāng)中不需要一下把這個(gè)架構(gòu)架的特別完美，而是要強(qiáng)調(diào)這種漸進(jìn)的方式，因?yàn)槌杀臼呛苤匾?，?duì)于小企業(yè)來(lái)講。
這時(shí)提出了一個(gè)新的要求，就是前端服務(wù)器已無(wú)法承載增幅的日志量，日志需要統(tǒng)一歸檔，就此進(jìn)入隊(duì)列階段。這時(shí)需要考慮數(shù)據(jù)安全問(wèn)題，保障日志安全不丟失。同時(shí)需要一寫(xiě)多讀。所謂一寫(xiě)多讀就是你的日志架構(gòu)是往一個(gè)地方寫(xiě)，同時(shí)有多個(gè)地方進(jìn)行消費(fèi)，比如說(shuō)業(yè)務(wù)部門(mén)，或者是你的運(yùn)維部門(mén)。
現(xiàn)在比較流行的一個(gè)日志處理的架構(gòu)，前端也是agent寫(xiě)入，同時(shí)中間使用kafka或者redis這種緩沖的隊(duì)列做相應(yīng)的隊(duì)列存儲(chǔ)。然后通過(guò)logstash indexer，把這個(gè)數(shù)據(jù)寫(xiě)到ES里面，或者寫(xiě)到DB里面。同時(shí)我這里面用了kibana做一些數(shù)據(jù)展示。在這個(gè)里面你要考慮隊(duì)列的選型問(wèn)題，首先隊(duì)列選型問(wèn)題，如果使用redis可能涉及到一個(gè)成本的問(wèn)題，它的內(nèi)存，如果數(shù)據(jù)比較多的話，你的內(nèi)存是比較昂貴的，在成本上面可能要考慮。另外還有一個(gè)是分布式的問(wèn)題，如果你用redis進(jìn)行分布式方面的話，它本身是不支持這種的，你可能需要一些其他的組件來(lái)做這個(gè)redis的分布式。其實(shí)我比較建議的是使用開(kāi)包即用的kafka，它可以說(shuō)是天生的分布式的隊(duì)列，它是用磁盤(pán)做這種數(shù)據(jù)存儲(chǔ)的，所以在成本方面也是相對(duì)比較低廉的。
在此，我想強(qiáng)調(diào)的是存儲(chǔ)的擴(kuò)展，比如說(shuō)ES存儲(chǔ)的擴(kuò)展，這個(gè)可能是一個(gè)常用的、常規(guī)的一個(gè)擴(kuò)展架構(gòu)，就是一個(gè)分角色的架構(gòu)。最前端用client，前面掛一個(gè)LB的方式做負(fù)載均衡，然后把數(shù)據(jù)寫(xiě)到client上。隨后在client和ES的Node進(jìn)行交互，同時(shí)使用master進(jìn)行整個(gè)集群數(shù)據(jù)狀況的一些保存。對(duì)于一些中小規(guī)模的企業(yè)，能做到這一步基本就夠用。
最后，對(duì)于小企業(yè)日志運(yùn)維，我有以下幾點(diǎn)補(bǔ)充：一是，一切架構(gòu)設(shè)計(jì)都要以測(cè)試為先，同時(shí)做好監(jiān)控。二是，涉及到logstash和Rsyslog的問(wèn)題，logstash本身可能涉及到的它的整個(gè)日志傳輸，涉及到一些不可控的問(wèn)題，它雖然是開(kāi)源的，但是它很多的一些過(guò)程并沒(méi)有很好的自帶的監(jiān)控，丟不丟日志，傳輸過(guò)程中有沒(méi)有問(wèn)題，實(shí)際上你是不知道的，你只能是通過(guò)業(yè)務(wù)兩邊進(jìn)行對(duì)數(shù)。三是，Rsyslog提供impstats監(jiān)控模塊。impstats模塊專門(mén)做事件級(jí)別的監(jiān)控，已經(jīng)精確到某一個(gè)事件是成功還是失敗的這種監(jiān)控，而且性能非常好。通過(guò)Rsyslog的rmpc的模塊，我們可以做整個(gè)日志傳輸?shù)谋O(jiān)控。最后，Elasticsearch的監(jiān)控可以使用自帶的插件。Elasticsearch的監(jiān)控我推薦，如果是在人力投入并不是特別強(qiáng)的公司，可以直接完全使用它自帶的一些插件，同時(shí)可以使用比如說(shuō)Elasticsearchmabo這種插件。