【51CTO.com原創(chuàng)稿件】企業(yè)規(guī)模不同，日志運(yùn)維的方式就有所不同。在WOT2016移動(dòng)互聯(lián)網(wǎng)技術(shù)峰會(huì)上，來自新浪微博的資深系統(tǒng)開發(fā)工程師于炳哲，同與會(huì)者深入分析了小企業(yè)與大企業(yè)的日志運(yù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ù)的難度。首先，我們來看看小企業(yè)在不同規(guī)模下的日志架構(gòu)。小企業(yè)日志架構(gòu)的特點(diǎn)：擴(kuò)展相對(duì)簡(jiǎn)單、業(yè)務(wù)復(fù)雜度低、業(yè)務(wù)依賴度低、歷史遺留問題相對(duì)較少，所以重構(gòu)成本相對(duì)較低、可投入的資源相對(duì)較少。

其實(shí)對(duì)于小企業(yè)來講可能都會(huì)經(jīng)歷幾個(gè)階段，首先是開荒的階段，即是服務(wù)剛剛上線，還處于測(cè)試和開發(fā)的階段。這時(shí)候，企業(yè)的應(yīng)用可能就是布置一臺(tái)或者兩臺(tái)服務(wù)器，此時(shí)沒有必要做一套完整的日志架構(gòu)。用純文本 + grep + awk + sed即可完成日志的提取。如果使用傳統(tǒng)的數(shù)據(jù)庫(kù)，可以在開發(fā)中將重要數(shù)據(jù)直接寫入數(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))的寫入量，企業(yè)對(duì)日志數(shù)據(jù)的安全性要求并不是特別高，同時(shí)對(duì)單點(diǎn)問題也不是很重視。在盡量少的運(yùn)維投入下，希望快速構(gòu)建。不要有太高的技術(shù)門檻。

這時(shí)候架構(gòu)可能就會(huì)變成這樣，這是一個(gè)大家中小企業(yè)，或者在50人以下，KPI在幾萬左右的廠商，基本就可以采用這種架構(gòu)。就是說你的前面是日志agent，把日志直接寫到日志服務(wù)器上，直接落磁盤。在這個(gè)上面用logstash或者其他的一些日志處理的組件，直接進(jìn)行收集，把日志寫到ES里。在這個(gè)階段還沒有到達(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è)來講。

這時(shí)提出了一個(gè)新的要求，就是前端服務(wù)器已無法承載增幅的日志量，日志需要統(tǒng)一歸檔，就此進(jìn)入隊(duì)列階段。這時(shí)需要考慮數(shù)據(jù)安全問題，保障日志安全不丟失。同時(shí)需要一寫多讀。所謂一寫多讀就是你的日志架構(gòu)是往一個(gè)地方寫，同時(shí)有多個(gè)地方進(jìn)行消費(fèi)，比如說業(yè)務(wù)部門，或者是你的運(yùn)維部門。

現(xiàn)在比較流行的一個(gè)日志處理的架構(gòu)，前端也是agent寫入，同時(shí)中間使用kafka或者redis這種緩沖的隊(duì)列做相應(yīng)的隊(duì)列存儲(chǔ)。然后通過logstash indexer，把這個(gè)數(shù)據(jù)寫到ES里面，或者寫到DB里面。同時(shí)我這里面用了kibana做一些數(shù)據(jù)展示。在這個(gè)里面你要考慮隊(duì)列的選型問題，首先隊(duì)列選型問題，如果使用redis可能涉及到一個(gè)成本的問題，它的內(nèi)存，如果數(shù)據(jù)比較多的話，你的內(nèi)存是比較昂貴的，在成本上面可能要考慮。另外還有一個(gè)是分布式的問題，如果你用redis進(jìn)行分布式方面的話，它本身是不支持這種的，你可能需要一些其他的組件來做這個(gè)redis的分布式。其實(shí)我比較建議的是使用開包即用的kafka，它可以說是天生的分布式的隊(duì)列，它是用磁盤做這種數(shù)據(jù)存儲(chǔ)的，所以在成本方面也是相對(duì)比較低廉的。

在此，我想強(qiáng)調(diào)的是存儲(chǔ)的擴(kuò)展，比如說ES存儲(chǔ)的擴(kuò)展，這個(gè)可能是一個(gè)常用的、常規(guī)的一個(gè)擴(kuò)展架構(gòu)，就是一個(gè)分角色的架構(gòu)。最前端用client，前面掛一個(gè)LB的方式做負(fù)載均衡，然后把數(shù)據(jù)寫到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的問題，logstash本身可能涉及到的它的整個(gè)日志傳輸，涉及到一些不可控的問題，它雖然是開源的，但是它很多的一些過程并沒有很好的自帶的監(jiān)控，丟不丟日志，傳輸過程中有沒有問題，實(shí)際上你是不知道的，你只能是通過業(yè)務(wù)兩邊進(jìn)行對(duì)數(shù)。三是，Rsyslog提供impstats監(jiān)控模塊。impstats模塊專門做事件級(jí)別的監(jiān)控，已經(jīng)精確到某一個(gè)事件是成功還是失敗的這種監(jiān)控，而且性能非常好。通過Rsyslog的rmpc的模塊，我們可以做整個(gè)日志傳輸?shù)谋O(jiān)控。***，Elasticsearch的監(jiān)控可以使用自帶的插件。Elasticsearch的監(jiān)控我推薦，如果是在人力投入并不是特別強(qiáng)的公司，可以直接完全使用它自帶的一些插件，同時(shí)可以使用比如說Elasticsearchmabo這種插件。

大企業(yè)日志運(yùn)維

大企業(yè)日志系統(tǒng)的特點(diǎn)和關(guān)注點(diǎn)在于：成本、運(yùn)營(yíng)與運(yùn)維數(shù)據(jù)復(fù)雜性、歷史遺留問題較多、各部門相互依賴、應(yīng)對(duì)業(yè)務(wù)突增情況的能力以及丟失率監(jiān)控&SLA(針對(duì)日志傳輸丟失情況的長(zhǎng)久數(shù)據(jù)，都要保存到SLA里面，在SLA里面做一些你系統(tǒng)的一些評(píng)價(jià)，就是你這個(gè)系統(tǒng)到底靠不靠譜，其實(shí)是要用SLA來衡量的。)。

談到大規(guī)模的日志傳輸，我們首先要考慮這個(gè)架構(gòu)到底要怎么設(shè)計(jì)，到底是使用同步架構(gòu)還是使用異步架構(gòu)。什么叫同步架構(gòu)?就是ETL、格式整理和轉(zhuǎn)發(fā)放在一起。這會(huì)存在一個(gè)什么問題?如果整個(gè)業(yè)務(wù)比較平穩(wěn)的話還好。但是如果業(yè)務(wù)突然間出現(xiàn)爆增等突發(fā)情況的時(shí)候，上面的架構(gòu)就會(huì)出現(xiàn)問題。你需要解析的，可能就放在那個(gè)地方，后面的數(shù)據(jù)又轉(zhuǎn)發(fā)不出去，前的服務(wù)發(fā)生了什么你可能根本不知道。此時(shí)，就需要把傳輸和解析進(jìn)行分隔。

因此，我建議在設(shè)計(jì)日志傳輸架構(gòu)的時(shí)候盡量設(shè)計(jì)成異步架構(gòu)。

如何控制成本和優(yōu)化業(yè)務(wù)呢?日志量越大成本就會(huì)越大，日志量大不是可以用來自豪的事情。可以用來自豪的是，你的成本做了多少意義的事情。在大企業(yè)的日志傳輸中其實(shí)存在很多垃圾數(shù)據(jù)，沒有收集的意義。所以我們首先要做的就是對(duì)日志進(jìn)行分類。然后就是對(duì)格式進(jìn)行協(xié)定，對(duì)日志進(jìn)行合并以及分級(jí)傳輸，實(shí)現(xiàn)運(yùn)維侵入開發(fā)。

以Rsyslog為例，首先所有日志要有志tag，以其進(jìn)行區(qū)分。然后需要高保的tag調(diào)用高保RuleSet，其他的日志tag以syslogfacility-text進(jìn)行區(qū)分，通過syslogfacility-text來寫入普通的通道。***使用rsyslog的action中的屬性：action.execOnlyEveryNthTime實(shí)現(xiàn)按比例丟棄。

接下來，我重點(diǎn)介紹一下日志降級(jí)。日志降級(jí)是用來干什么的?在企業(yè)的業(yè)務(wù)量遇到突發(fā)情況的時(shí)候，需要對(duì)服務(wù)進(jìn)行降級(jí)。為什么要降級(jí)?因?yàn)檎Ｇ闆r下，日志量處于一個(gè)比較平穩(wěn)的狀態(tài)，一點(diǎn)點(diǎn)的傳。類似于某某明星離婚的時(shí)候，這個(gè)日志量就會(huì)爆增。為什么會(huì)爆增呢?首先日志是有一個(gè)特點(diǎn)的，在正常情況下可能就記錄一下infor或者這些日志，但是如果出現(xiàn)錯(cuò)誤的時(shí)候，這個(gè)錯(cuò)誤量就會(huì)跟著這個(gè)業(yè)務(wù)量一樣樣的往上漲。這時(shí)就要考慮日志降級(jí)的問題，如果不降級(jí)的話，很有可能把下行帶寬全部打滿，遭遇計(jì)算量、帶寬以及磁盤三個(gè)瓶頸。

以手機(jī)微博為例，我們來看看日志降級(jí)的邏輯。首先，就是要?jiǎng)討B(tài)調(diào)整各個(gè)日志tag的級(jí)別。然后，它定義了兩種級(jí)別：是否轉(zhuǎn)發(fā)與是否落磁盤。

這是一個(gè)邏輯的圖，這里面我們用了一個(gè)PHP的動(dòng)態(tài)加載庫(kù)，它可以把你相應(yīng)的降級(jí)規(guī)則，就是對(duì)某一個(gè)日志，在需要降級(jí)的時(shí)候把它降到哪個(gè)通道里，把它降到哪個(gè)級(jí)別里的定義。然后我們會(huì)和監(jiān)控進(jìn)行連接，當(dāng)監(jiān)控發(fā)現(xiàn)某些業(yè)務(wù)突然出現(xiàn)突增的時(shí)候。這里面當(dāng)然是基于規(guī)則，如果說這個(gè)規(guī)則滿足的時(shí)候，就開始進(jìn)行降級(jí)。

在大企業(yè)日志運(yùn)維的情況下，我們需要注意，企業(yè)的日志傳輸是需要監(jiān)控的，對(duì)于架構(gòu)的每個(gè)環(huán)節(jié)都需要進(jìn)行測(cè)試，主要是壓測(cè)。此外，***通過隊(duì)列解藕各個(gè)部門的依賴，并實(shí)現(xiàn)運(yùn)維侵入開發(fā)，及時(shí)發(fā)現(xiàn)問題反饋給開發(fā)，發(fā)現(xiàn)開發(fā)中的不合乎規(guī)范的問題，并提供解決方案。

微博日志系統(tǒng)架構(gòu)及相關(guān)調(diào)優(yōu)

調(diào)優(yōu)從來就沒有一個(gè)標(biāo)準(zhǔn)的答案，所有調(diào)優(yōu)一定要從內(nèi)部了解系統(tǒng)開始，調(diào)優(yōu)一定要基于測(cè)試與監(jiān)控。下面，我們以Elasticsearch和Rsyslog的調(diào)優(yōu)為例來具體了解一下：

◆Elasticsearch的調(diào)優(yōu)

我們經(jīng)常強(qiáng)調(diào)Elasticsearch的調(diào)優(yōu)到底在調(diào)什么，我們首先要看一下一條數(shù)據(jù)寫進(jìn)來的時(shí)候是經(jīng)過怎樣的過程。首先是把數(shù)據(jù)寫到index-buffer當(dāng)中，在這個(gè)階段你的數(shù)據(jù)還是搜索不到的。然后會(huì)有異步的程序把這個(gè)數(shù)據(jù)從index-buffer當(dāng)中refresh出來，這個(gè)就是refresh階段。一講到Elasticsearch調(diào)優(yōu)的時(shí)候，肯定大家就要講到有一個(gè)調(diào)優(yōu)項(xiàng)叫做index-buffer refresh，這個(gè)refresh的間隔時(shí)間。然后就到了這個(gè)flosystem cache這一層，到了這一層的時(shí)候你的數(shù)據(jù)是可以被搜到了，因?yàn)樗赡芫瓦M(jìn)行切分。***一步是磁盤操作flush，把數(shù)據(jù)從flosystem-cache刷到磁盤當(dāng)中。進(jìn)入disk層有個(gè)merge階段，也就是說其實(shí)在ES當(dāng)中是有一個(gè)異步的進(jìn)程，Merge這個(gè)數(shù)據(jù)，就是把system進(jìn)行合并，這個(gè)操作因?yàn)樗荌O操作，它對(duì)性能的損耗是比較大的。再就是translog，它實(shí)際是一個(gè)數(shù)據(jù)庫(kù)記錄操作日志，把所有的對(duì)ES的操作首先先記到translog當(dāng)中，如果在系統(tǒng)寫入發(fā)生異常的時(shí)候，從translog把操作進(jìn)行恢復(fù)。在flush寫入之后，刪除translog。

至此，我們可以看到，在寫入的過程中，ES的性能主要merge、flush、reflush，還有translog的flush的階段被消耗。了解到這個(gè)過程，我們就可以參照ES的官方文檔，去對(duì)相應(yīng)的各個(gè)階段進(jìn)行調(diào)優(yōu)。當(dāng)然首先要知道企業(yè)的性能狀態(tài)，如果IO有問題就調(diào)merge，如果CPU的問題可以考慮在reflush方面做調(diào)整。

然后就是調(diào)優(yōu)的方向，merge官方默認(rèn)參數(shù)是按照SSD的磁盤來做的調(diào)優(yōu)，實(shí)際它是不太適合機(jī)械磁盤這種服務(wù)的。因此，我建議如果涉及到IO問題，可以考慮把merge的進(jìn)程數(shù)調(diào)低。在數(shù)據(jù)寫入特別大時(shí)，采取網(wǎng)絡(luò)限流。在內(nèi)核層面，ES配置文件里含有了一些系統(tǒng)提供的很好的參數(shù)。

◆Rsyslog的調(diào)優(yōu)

如圖所示，這是Rsyslog一個(gè)內(nèi)部隊(duì)列，Rsyslog的內(nèi)部也是比較復(fù)雜的。首先是input的這個(gè)進(jìn)程，接著是預(yù)處理的階段，比如它會(huì)進(jìn)行一些分類，把你的某一個(gè)日志tag按照一個(gè)什么分類寫到一個(gè)什么地方。再往后就是filter Engine，在這之前會(huì)有一個(gè)Queue，就是說這個(gè)數(shù)據(jù)在內(nèi)部會(huì)維護(hù)一個(gè)隊(duì)列，然后Filter到這個(gè)隊(duì)列里主動(dòng)拉取數(shù)據(jù)。后面是Action processor，它在前面也有每一個(gè)事件的隊(duì)列，Action的進(jìn)程會(huì)從相應(yīng)的隊(duì)列當(dāng)中寫數(shù)據(jù)。這就是的內(nèi)部的結(jié)構(gòu)。

Rsyslog主要有Main queue和Action queue兩種類型的隊(duì)列，四種隊(duì)列設(shè)置，分別是：Direct queue、Disk queue、In-memory queue（LinkedList、FixdArray）、Disk-assisted memory queue。

總結(jié)

日志量就是成本，所以不要以花了多少錢而自豪，而是要以做了多少事作為目標(biāo)。要傳輸有價(jià)值的數(shù)據(jù)!要多注意業(yè)務(wù)優(yōu)化。此外，一定要記住：選擇哪一種架構(gòu)由具體的場(chǎng)景決定，不要過度設(shè)計(jì)，但要盡量快速迭代。

【講師簡(jiǎn)介】

[[174905]]

于炳哲，現(xiàn)就職于新浪微博-手機(jī)微博移動(dòng)服務(wù)保障部，任系統(tǒng)開發(fā)工程師，負(fù)責(zé)手機(jī)微博服務(wù)端和客戶端的日志收集、傳輸?shù)裙ぷ鳎约澳壳靶吕司W(wǎng)&新浪微博***的Elasticsearch集群的維護(hù)與相關(guān)中間件的開發(fā)維護(hù)工作。主要專注于日志相關(guān)技術(shù)，關(guān)注日志處理，傳輸，存儲(chǔ);等相關(guān)領(lǐng)域，對(duì)大規(guī)模數(shù)據(jù)量下的日志治理有一定的經(jīng)驗(yàn)。曾就職于北京問日科技(365日歷)從事Java服務(wù)端開發(fā)和日志處理，運(yùn)維監(jiān)控報(bào)警等相關(guān)工作。

本文由于炳哲于2016年8月，在WOT2016移動(dòng)互聯(lián)網(wǎng)技術(shù)峰會(huì)運(yùn)維與安全專場(chǎng)《日志漫談-不同規(guī)模下的日志運(yùn)維與優(yōu)化》主題演講整理而成。WOT2016大數(shù)據(jù)峰會(huì)將 于2016年11月25-26日在北京粵財(cái)JW萬豪酒店召開，屆時(shí)，數(shù)十位大數(shù)據(jù)領(lǐng)域一線專家、數(shù)據(jù)技術(shù)先行者將齊聚現(xiàn)場(chǎng)，在圍繞機(jī)器學(xué)習(xí)、實(shí)時(shí)計(jì)算、系統(tǒng)架構(gòu)、NoSQL技術(shù)實(shí)踐等前沿技術(shù)話題展開深度交流和溝通探討的同時(shí)，分享大數(shù)據(jù)領(lǐng)域***實(shí)踐和最熱門的行業(yè)應(yīng)用。了解WOT2016大數(shù)據(jù)技術(shù)峰會(huì)更多信息，請(qǐng)登陸大會(huì)官網(wǎng)：http://wot.51cto.com/2016bigdata/

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】