【51CTO.com原創(chuàng)稿件】企業(yè)規(guī)模不同，日志運維的方式就有所不同。在WOT2016移動互聯(lián)網(wǎng)技術(shù)峰會上，來自新浪微博的資深系統(tǒng)開發(fā)工程師于炳哲，同與會者深入分析了小企業(yè)與大企業(yè)的日志運維問題，手機微博日志系統(tǒng)架構(gòu)相關(guān)的調(diào)優(yōu)，以及自己對日志運維的反思。

小企業(yè)日志運維

小企業(yè)日志運維關(guān)注點在于：成本、數(shù)據(jù)規(guī)模以及維護的難度。首先，我們來看看小企業(yè)在不同規(guī)模下的日志架構(gòu)。小企業(yè)日志架構(gòu)的特點：擴展相對簡單、業(yè)務(wù)復(fù)雜度低、業(yè)務(wù)依賴度低、歷史遺留問題相對較少，所以重構(gòu)成本相對較低、可投入的資源相對較少。

其實對于小企業(yè)來講可能都會經(jīng)歷幾個階段，首先是開荒的階段，即是服務(wù)剛剛上線，還處于測試和開發(fā)的階段。這時候，企業(yè)的應(yīng)用可能就是布置一臺或者兩臺服務(wù)器，此時沒有必要做一套完整的日志架構(gòu)。用純文本 + grep + awk + sed即可完成日志的提取。如果使用傳統(tǒng)的數(shù)據(jù)庫，可以在開發(fā)中將重要數(shù)據(jù)直接寫入數(shù)據(jù)庫?；蛘呤褂玫谌奖O(jiān)控，采用業(yè)務(wù)接口監(jiān)控(lua -> nginx shard dict -> DB(graphite))。

然后，進入數(shù)據(jù)增長階段。此時的架構(gòu)變成了分布式，也就是日志可能在不同的服務(wù)器上，業(yè)務(wù)也已經(jīng)上線，這時候需要及時的反饋信息，需要專業(yè)的運維人員做日志架構(gòu)設(shè)計。如下圖的基于ALK簡單的設(shè)計：

隨著日志的逐漸增多，業(yè)務(wù)的逐漸擴展，進入了日志服務(wù)器中轉(zhuǎn)階段，此時需要收集的日志總量還未達到Elasticsearch(單數(shù)據(jù)節(jié)點)的寫入量，企業(yè)對日志數(shù)據(jù)的安全性要求并不是特別高，同時對單點問題也不是很重視。在盡量少的運維投入下，希望快速構(gòu)建。不要有太高的技術(shù)門檻。

這時候架構(gòu)可能就會變成這樣，這是一個大家中小企業(yè)，或者在50人以下，KPI在幾萬左右的廠商，基本就可以采用這種架構(gòu)。就是說你的前面是日志agent，把日志直接寫到日志服務(wù)器上，直接落磁盤。在這個上面用logstash或者其他的一些日志處理的組件，直接進行收集，把日志寫到ES里。在這個階段還沒有到達一個ES的性能瓶頸，我一直強調(diào)的是在整個日志的架構(gòu)當(dāng)中不需要一下把這個架構(gòu)架的特別***，而是要強調(diào)這種漸進的方式，因為成本是很重要的，對于小企業(yè)來講。

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

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

在此，我想強調(diào)的是存儲的擴展，比如說ES存儲的擴展，這個可能是一個常用的、常規(guī)的一個擴展架構(gòu)，就是一個分角色的架構(gòu)。最前端用client，前面掛一個LB的方式做負載均衡，然后把數(shù)據(jù)寫到client上。隨后在client和ES的Node進行交互，同時使用master進行整個集群數(shù)據(jù)狀況的一些保存。對于一些中小規(guī)模的企業(yè)，能做到這一步基本就夠用。

***，對于小企業(yè)日志運維，我有以下幾點補充：一是，一切架構(gòu)設(shè)計都要以測試為先，同時做好監(jiān)控。二是，涉及到logstash和Rsyslog的問題，logstash本身可能涉及到的它的整個日志傳輸，涉及到一些不可控的問題，它雖然是開源的，但是它很多的一些過程并沒有很好的自帶的監(jiān)控，丟不丟日志，傳輸過程中有沒有問題，實際上你是不知道的，你只能是通過業(yè)務(wù)兩邊進行對數(shù)。三是，Rsyslog提供impstats監(jiān)控模塊。impstats模塊專門做事件級別的監(jiān)控，已經(jīng)精確到某一個事件是成功還是失敗的這種監(jiān)控，而且性能非常好。通過Rsyslog的rmpc的模塊，我們可以做整個日志傳輸?shù)谋O(jiān)控。***，Elasticsearch的監(jiān)控可以使用自帶的插件。Elasticsearch的監(jiān)控我推薦，如果是在人力投入并不是特別強的公司，可以直接完全使用它自帶的一些插件，同時可以使用比如說Elasticsearchmabo這種插件。

大企業(yè)日志運維

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

【講師簡介】

[[174905]]

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

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

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