引言

隨著互聯(lián)網(wǎng)業(yè)務快速擴展,軟件架構設計也變得愈發(fā)復雜,為滿足大量客戶高并發(fā)的請求,系統(tǒng)逐步走向分布式,如單體架構的服務拆分為微服務,這些微服務構成了復雜的分布式網(wǎng)絡。同時,復雜的分布式調(diào)用網(wǎng)絡可能會有成千上萬的服務,如果一個服務出現(xiàn)問題,可能會導致數(shù)十個服務出現(xiàn)異常,對異常問題的排查將十分困難。

分布式鏈路跟蹤是將分布式請求還原成請求的調(diào)用鏈路,如一次點擊請求的處理過程,經(jīng)過多個服務及實例。當出現(xiàn)異常節(jié)點時,需采集異常節(jié)點的全鏈路信息,文獻探討了基于采樣方式采集異常鏈路,該策略能提升異常鏈路采集速率,但實際生產(chǎn)中99.99%的非異常日志對問題排查作用不大,而0.01%的異常日志則起到關鍵作用。在保證異常日志鏈路查全率的前提下,提高異常日志采集速率能在業(yè)務高峰期起到重要作用。

本文提出了一種分布式鏈路異常日志采集方法,能在保證異常日志鏈路查全率的前提下,提高異常日志采集速率,以提升服務異常時的運維排查效率。

1分布式技術

1.1分布式系統(tǒng)

分布式系統(tǒng)是指由多臺在網(wǎng)絡上分散的計算機通過網(wǎng)絡連接而成的系統(tǒng),系統(tǒng)的計算處理邏輯和控制功能分布在這個系統(tǒng)網(wǎng)絡的計算機上。而計算機的分布式部署就是將微服務應用有規(guī)則地分散在多臺獨立運行的計算機設備上,同一功能的微服務應用可能同時部署到多臺計算機上,利用多臺計算機服務器進行應用的負載均衡。

1.2鏈路跟蹤

鏈路跟蹤在請求調(diào)用鏈路還原、調(diào)用網(wǎng)絡重構方面對分布式服務起到關鍵作用,可以協(xié)助運維人員快速定位分布式服務框架下的請求調(diào)用鏈路,提高微服務的運維定位效率。

一個請求接口內(nèi)可能調(diào)用了多個應用服務,排查接口內(nèi)的異常節(jié)點,需要清楚請求服務調(diào)用多個服務的順序,就是調(diào)用鏈。為了實現(xiàn)調(diào)用鏈,對請求調(diào)用的每個服務按先后排序標記唯一標志,該標志定義為spanId:為了標志每次請求的調(diào)用情況,需要對每一次請求也標記唯一標志,該標志定義為traceId,如圖1所示。

1.3翻滾時間窗口

翻滾時間窗口指的是讀取數(shù)據(jù)的窗口所含時間長度固定,若時間窗口設定為ns,則該時間窗口只讀取當前ns內(nèi)的數(shù)據(jù),而不會讀取前ns或后ns的數(shù)據(jù),且時間連續(xù),窗口不會出現(xiàn)重疊。

2框架構建

2.1基于翻滾移動窗口實時提取分布式流數(shù)據(jù)方案

隨著業(yè)務的辦理,業(yè)務執(zhí)行日志將不斷產(chǎn)生,并實時寫入日志服務器。由于日志數(shù)據(jù)是實時產(chǎn)生并寫入日志服務器的,讀取日志數(shù)據(jù)就是一個面向流處理的場景,并非批處理的場景。每個日志服務器上的數(shù)據(jù)都是從上到下逐條寫入,且時間上是順序的。

因此,基于翻滾時間移動窗口讀取日志流數(shù)據(jù),該方案是每次在日志服務器從上到下按照固定時間長度非重復性地讀取該時間段內(nèi)日志數(shù)據(jù)。時間窗口是基于歷史統(tǒng)計請求的最長時間x1.1獲得,應用歷史統(tǒng)計最長時長記為Regmax,時間窗口寬度記為W,即W=Regmax×1.1。

2.2日志數(shù)據(jù)暫存

每個時間窗口寬度提取出的日志數(shù)據(jù)將作為一個集合,并對每個集合按從小到大的順序分配編號setId(eg:l,2,3,…)。同時,對當前集合的每條數(shù)據(jù)進行遍歷,每條日志數(shù)據(jù)所含的標志字段有:traceId(請求標志)、status(請求狀態(tài))。由于請求是并發(fā)的,可能在短時間內(nèi)大量請求進入系統(tǒng),不同請求的traceId不同,每經(jīng)過不同的應用服務后,都會產(chǎn)生相應的日志并存入日志文件,這樣就造成同一個traceId下日志中間會存在各個不一樣的traceId的請求調(diào)用到不同應用產(chǎn)生的日志,同一個traceId不同應用服務的日志將不會連續(xù)。

所以,為了把相同traceId的請求日志區(qū)分出來,引入了日志數(shù)據(jù)存入數(shù)據(jù)結構:Map<stringLLinkedList<string>>。其中,Map里的key=traceId,Map里的va1ue=LinkedList<string>,LinkedList為有序列表,LinkedList的每條數(shù)據(jù)為該日志信息。

2.3提取異常日志traceld

一個穩(wěn)定的系統(tǒng),業(yè)務辦理的成功率都在99.99%以上,這些業(yè)務成功辦理的日志信息對于極少數(shù)業(yè)務辦理失敗的原因排查無關緊要,最重要的是業(yè)務辦理時出現(xiàn)的問題信息,需要通過暴露出來的異常信息進行排查,才能解決存在的問題。

然而,為了區(qū)分正常和異常的日志,需要把重要的異常日志從大量的日志信息中提取出來。通過判斷讀取出來的日志信息,判斷該日志信息的狀態(tài)是否為200,如果為非200,那么該日志為異常日志,需要把該日志所在讀取的批次setId和該日志的traceId記錄到錯慢日志集合,并用Map<stringLList<string>>存儲,其中,Map里的key=setId,Map里的value=traceId。

2.4計算

通過上述三個步驟,完成對日志流數(shù)據(jù)的實時按批次讀取和按批次存儲,把識別到的異常日志對應的traceId提取出來,并使用集合方式存儲起來。

以異常集合的traceId為出發(fā)點,從暫存的數(shù)據(jù)中提取出涉及該鏈路的所有節(jié)點日志數(shù)據(jù)。由于日志數(shù)據(jù)是按批次讀取的,所以異常日志traceId也是按集合批次進行存儲區(qū)分。但落在當前setId集合里的鏈路日志,可能存在該鏈路數(shù)據(jù)落在相鄰的setId集合里,為了確保囊括該請求鏈路所有節(jié)點的日志數(shù)據(jù),需要把setId集合的前后兩個setId集合對應traceId提取出來。

所以,計算setId=n的日志數(shù)據(jù)時,需2.3點提到的集合(n-l,n,n+l)esetId,并從2.2的traceId集合里獲取key值一致的traceId所對應的List<string>數(shù)據(jù)。

3實驗

采用日志大小為4GB的日志服務器作為日志流輸出口,異常日志采集服務器分類4G內(nèi)存。通過上述方法對日志流數(shù)據(jù)進行異常日志鏈路采集。通過對日志流輸出進行調(diào)整,測試采用上述方法在不同日志流輸出速率下的異常鏈路采集時長。

設定日志流速率在700~1650MB/s范圍內(nèi),日志流速率間隔為50MB/s,調(diào)整日志流速率,日志采集時長/日志流時長、異常日志查全率統(tǒng)計如圖2所示。當日志流速率在1200~1300MB/s時,采集時長和日志流時長的比值大于1,表明采集時間比日志流時間長,并且隨著日志流速率提高,采集時間與日志流時長比值增大,那么異常日志采集最高速率在1200~1300MB/s為宜。

為了更精確地獲取異常日志采集速率,設定日志流速率在ll50~1340MB/s范圍內(nèi),日志流速率間隔為10MB/s,調(diào)整日志流速率,日志采集時長/日志流時長、異常日志查全率統(tǒng)計如圖3所示。當日志流速率大于1260MB/s時,采集時長和日志流時長的比值大于1,如表1所示,表明采集速率達到最大值。

4結果與討論

當日志流速率在1260MB/s以下時,采集時間與日志流時間一致:當日志流速率在1260MB/s以上時,采集時間比日志流時間長,并且隨著日志流速率提高,采集時長與日志流時長比值增大。數(shù)據(jù)表明,采集速率達到1260MB/s,日志流速率在1260MB/s以內(nèi)時能實時處理日志信息。

5結語

本文旨在分析分布式系統(tǒng)鏈路日志的現(xiàn)況,提出了一種分布式鏈路異常日志采集的方法:只要請求的鏈路跟蹤數(shù)據(jù)存在異常節(jié)點,那么該異常節(jié)點涉及的全鏈路數(shù)據(jù)將被采集。通過該方法,分布式鏈路異常日志采集速率達到了1260MB/s,查全率達到100%。該方法大幅提升了業(yè)務高峰期系統(tǒng)故障問題定位的效率,提高了系統(tǒng)故障處理能力和業(yè)務辦理質(zhì)量,提升了客戶滿意度。