■ 中移互聯(lián)（杭州）科技有限公司 闞宗挺 劉順宇

編者按：網(wǎng)絡(luò)信息迅速發(fā)展的今天，企業(yè)在面對用戶劇增的實際場景時，單節(jié)點的接口服務(wù)已無法滿足劇增的訪問量，這時就需要用到分布式架構(gòu)：企業(yè)將相同的服務(wù)發(fā)布到不同的服務(wù)器上。但在分布式架構(gòu)中日志的管理就成了一個必須要解決的問題，分散式的日志結(jié)構(gòu)難以迅速定位查詢目標(biāo)，因此要用到分布式日志服務(wù)來對我們的日志進(jìn)行統(tǒng)一管理。

在項目中通常會遇到并發(fā)量突增時導(dǎo)致系統(tǒng)不可用而采用分布式架構(gòu)的情況，日志此時也要進(jìn)行統(tǒng)一管理，方便查詢定位。在進(jìn)行統(tǒng)一管理時，如果集群服務(wù)器有許多臺，那么這么多臺服務(wù)器同時向統(tǒng)一日志系統(tǒng)發(fā)送數(shù)據(jù)，將導(dǎo)致系統(tǒng)的IO效率特別底下，存在數(shù)據(jù)丟失的情況。為解決該問題，加入一個二級日志儲存策略，將部分服務(wù)器日志先通過緩存?zhèn)魅攵墐Υ?，再通過二級儲存通過緩存?zhèn)魅虢y(tǒng)一日志系統(tǒng)，這樣統(tǒng)一日志系統(tǒng)的總連接數(shù)大大減少，

IO效率大大提高。另外，為了保證總系統(tǒng)的穩(wěn)定性，業(yè)務(wù)和日志服務(wù)之間必須是解耦的，因此通過監(jiān)聽日志文件而非采用遠(yuǎn)程寫入日志的形式。日志服務(wù)器宕機對業(yè)務(wù)無干擾，某個業(yè)務(wù)服務(wù)器宕機對日志服務(wù)也沒有影響，日志服務(wù)可以繼續(xù)收集其他服務(wù)器的日志。

需求分析

本系統(tǒng)包括三個需求模塊，分別是組件通信模塊、分級采集日志模塊、日志管理模塊、日志查詢分析模塊。

1.組件通信模塊

應(yīng)用服務(wù)器和二級儲存，二級儲存和統(tǒng)一日志服務(wù)之間都是通過遠(yuǎn)程過程調(diào)用來實現(xiàn)的。在數(shù)據(jù)傳輸時，會把待傳數(shù)據(jù)放到緩沖中，再進(jìn)行發(fā)送。

2.分級采集日志模塊

此模塊主要是為了解決集群中的應(yīng)用服務(wù)器過多同時進(jìn)行數(shù)據(jù)傳輸時造成統(tǒng)一日志服務(wù)端負(fù)載過大導(dǎo)致系統(tǒng)崩潰，在應(yīng)用服務(wù)器和日志服務(wù)儲存端添加一個二級儲存作為一個中間傳輸間，二級服務(wù)器與應(yīng)用服務(wù)器之間是一對多關(guān)系，這樣通過增加二級緩存數(shù)可避免上述系統(tǒng)崩潰的情況，而且當(dāng)某個應(yīng)用服務(wù)器長時間未發(fā)送日志時，會在其對應(yīng)的二級存儲上發(fā)出日志警報，幫助查找原因。

3.日志管理模塊

對生產(chǎn)日志進(jìn)行日常監(jiān)控，并提供實時預(yù)警，此外為了實現(xiàn)系統(tǒng)分權(quán)限、分角色管理，還應(yīng)用了PaaS下的多租戶框架，以此來實現(xiàn)不同用戶組對不同日志的操作和監(jiān)控。

4.日志查詢分析模塊

日志查詢分析是對統(tǒng)一日志服務(wù)中的日志進(jìn)行錯誤回溯，數(shù)據(jù)挖掘并提取有用的信息，可以用來監(jiān)測接口的性能以及給用戶畫像。

總體設(shè)計

在本文介紹的統(tǒng)一日志管理總體上采用分層的思想建立二級儲存系統(tǒng)，同時為了提高IO效率，會通過緩存來減少單位時間傳輸次數(shù)。通過Elasticsearch技術(shù)來實現(xiàn)日志的持久化儲存和全文檢索。可以用來處理PB級的數(shù)據(jù)，查詢效率高。為了避免日志儲存并發(fā)大的問題可以配置Elasticsearch集 群來實現(xiàn)。當(dāng)我們的服務(wù)相當(dāng)多時，單節(jié)點儲存的效率是相當(dāng)?shù)偷模虼宋覀兲砑恿艘粋€二級儲存策略，將不同的服務(wù)日志分開持久化到二級日志服務(wù)中，再將二級服務(wù)中的日志投遞到服務(wù)日志中隨后交給Elasticsearch處理，圖1是整體設(shè)計架構(gòu)圖。

系統(tǒng)模塊設(shè)計

1.日志通用模型

圖1 總體設(shè)計

圖2 日志通用模型

圖3 日志采集架構(gòu)

在進(jìn)行分布式日志系統(tǒng)中，沿用之前的通用的日志模型是不準(zhǔn)確的，因為普通的日志模型一般包括：日志級別、日志生成時間、日志所在類名、日志內(nèi)容。在分布式系統(tǒng)中，我們應(yīng)該在普通日志模型的基礎(chǔ)上加上服務(wù)器的IP以及日志的文件路徑。這樣在進(jìn)行查找錯誤時，可以快速定位到哪個項目的哪個類下發(fā)生錯誤，便能快速的對項目進(jìn)行維護(hù)，日志通用模型如圖2所示。

2.日志采集模塊

日志采集采用無侵入式的方式來采集日志，用戶按照原來的方式通過配置將日志輸出到該服務(wù)器特定的文件中，采集時通過在服務(wù)器上安裝日志監(jiān)聽插件進(jìn)行監(jiān)聽特定文件夾下的文件信息是否發(fā)生變化，把增加的部分?jǐn)?shù)據(jù)采集到該插件中，通過該插件的投遞功能將緩存的日志投遞到遠(yuǎn)程的日志服務(wù)中，這樣通過在每個服務(wù)器中加入日志監(jiān)聽插件來實現(xiàn)日志的采集和統(tǒng)一儲存，架構(gòu)如圖3所示。

3.日志查詢模塊

不同的日志儲存方案可以提高日志查詢的效率，因此我們可以采用Elasticsearch對日志進(jìn)行儲存，儲存之前將接受到的文件通過日志的模型字段進(jìn)行內(nèi)容映射，并通過Elasticsearch的分布式實時文件存儲技術(shù)將每一個字段都編入索引，使其可以被搜索。查詢分析時可以通過Elasticsearch進(jìn)行全文檢索查詢。因其每個字段都已加入索引，查詢效率比較高。然后對查詢到的數(shù)據(jù)進(jìn)行數(shù)據(jù)清洗、篩選、展示。架構(gòu)如圖4所示。

4.日志管理模塊

（1） 監(jiān)控模塊

監(jiān)控模塊用于顯示日志系統(tǒng)一段時間內(nèi)的性能狀態(tài)，如：吞吐量,并發(fā)量，日志采集效率等，通過sql語句每隔一段時間進(jìn)行查詢一次這些狀態(tài)信息，將計算結(jié)果用柱狀圖或儀表盤的形式顯示在Web上，用于管理人員分析，起到監(jiān)控預(yù)防作用。

（2）告警模塊

當(dāng)使用sql進(jìn)行查詢監(jiān)測日志的性能超出了管理人員規(guī)定的所能接受的最大范圍時，會通知管理人員進(jìn)行排查問題，如圖5所示。

（3）多租戶模塊

對于查詢系統(tǒng)為了維護(hù)日志系統(tǒng)的安全，可以對不同的地區(qū)分配不同的組，將相關(guān)查詢?nèi)藛T分配到該人員對應(yīng)地區(qū)對應(yīng)的組上，通過給不同的組增加相應(yīng)的權(quán)限來約束管理人員。比如某些地區(qū)可以不用了解系統(tǒng)的性能，可以在相應(yīng)的組上將相應(yīng)的權(quán)限按鈕關(guān)閉。亦需要設(shè)立一個超級管理員組對系統(tǒng)的整體進(jìn)行調(diào)控，圖6為架構(gòu)分析圖。

圖4 日志查詢架構(gòu)

圖5 日志監(jiān)控告警模塊架構(gòu)

圖6 日志多租戶模塊架構(gòu)

圖7 日志分析架構(gòu)

5.日志分析模塊

日志分析是為了更好的能夠幫助企業(yè)掌控系統(tǒng)運行狀況，以及分析用戶行為特征，以便更好地優(yōu)化系統(tǒng)，提升用戶體驗。

系統(tǒng)同時支持離線和實時分析。兩種方式都提供SQL的思想來提供查詢分析服務(wù)。在日志分析模塊應(yīng)用層通過報表和儀表盤的方式來實現(xiàn)安全診斷與分析。圖7為數(shù)據(jù)處理架構(gòu)圖。

測試實驗

進(jìn)行測試的應(yīng)用服務(wù)器均在linux服務(wù)器進(jìn)行壓力測試，目的是為了測試單節(jié)點儲存與增加二級儲存之間的性能差異，以及通過統(tǒng)一儲存后查詢的效率。

經(jīng)測試，可以得出以下結(jié)論二級儲存日志收集的采集效率明顯比單節(jié)點的收集效率高，而且在并發(fā)量達(dá)到2000時單節(jié)點儲存出現(xiàn)了數(shù)據(jù)丟失的問題。

用戶在通過日志查詢查找問題時，直接通過查詢頁面進(jìn)行統(tǒng)一查詢即可，追蹤問題效率更高。由此可見該種日志采集方案具有更高的性能和可用性。