從單體式到分布式，系統架構在變，我們對系統的監控需求也在變。隨著(zhù)微服務(wù)概念的提出，容器與云技術(shù)的發(fā)展，如何保障整個(gè)系統鏈路及各分支系統的穩定運行對企業(yè)的網(wǎng)絡(luò )穩定與業(yè)務(wù)發(fā)展尤為重要。不同的監控方式由于其數據源、監控路徑、落地方式等不同，在進(jìn)行全鏈路監控中會(huì )面臨不一樣的挑戰。本文將日志類(lèi)與網(wǎng)絡(luò )數據類(lèi)這兩種市場(chǎng)上主流的性能監控派別從以上三個(gè)方面進(jìn)行討論，看看誰(shuí)能更好地實(shí)現全鏈路監控。

一、數據源對比

• 采樣數據VS全量數據

日志類(lèi)的數據來(lái)源有兩類(lèi)：一種是傳統物理設備上的日志文件，這種日志文件能夠提供的數據格式、數據精細度、數據內容都是各個(gè)設備廠(chǎng)商預先設定的；另外一種是程序開(kāi)發(fā)過(guò)程中或之后，為捕獲程序或者系統本身的運行信息開(kāi)發(fā)出來(lái)的日志系統。日志系統本身不對應用程序發(fā)起主動(dòng)式訪(fǎng)問(wèn)，只是伴隨著(zhù)程序的運行，將相關(guān)的運行數據輸送出來(lái)，大部分日志系統輸送出來(lái)的都是機器本身或者程序運行的狀態(tài)信息。此外，日志屬于采樣數據，信息級別與功能均由人工定義，在存儲以及分析的過(guò)程中時(shí)常因前端需求而更改，按照人為需求進(jìn)行目標輸出，因此邊界十分明顯。

網(wǎng)絡(luò )數據是應用程序之間通過(guò)網(wǎng)絡(luò )進(jìn)行傳輸的獨特過(guò)程數據，能提供業(yè)務(wù)活動(dòng)、應用性能、安全性與IT基礎架構等方面的信息。通過(guò)交換機鏡像的方式將網(wǎng)絡(luò )數據復制出來(lái)，送至分析服務(wù)器從而實(shí)現性能監控。網(wǎng)絡(luò )數據是一種全量數據，通過(guò)旁路捕獲數據包，不消耗任何系統資源，實(shí)時(shí)反映設備、服務(wù)器、系統等運行的狀態(tài)。

• 時(shí)間精度和實(shí)時(shí)性

日志時(shí)間由系統程序自動(dòng)打印，一般精確到毫秒；網(wǎng)絡(luò )數據的時(shí)間戳由捕獲服務(wù)器的高性能網(wǎng)卡抓包時(shí)進(jìn)行標記，最快可以實(shí)現納秒級。盡管同樣采用ntp時(shí)間同步，二者的時(shí)間準確程度也會(huì )因網(wǎng)絡(luò )傳輸等因素產(chǎn)生毫秒級以上的差距。

在網(wǎng)絡(luò )傳輸過(guò)程中，由于Delayed ACK與Nagle算法相互作用會(huì )導致最大500毫秒的延遲。日志往往無(wú)法排查此類(lèi)問(wèn)題，而通過(guò)網(wǎng)絡(luò )數據可以進(jìn)行數據包回溯分析。因此，網(wǎng)絡(luò )數據比日志具備更高的實(shí)時(shí)性。

二、監控路徑對比

作為兩種數據源，日志與網(wǎng)絡(luò )數據所監控的定義與范圍有著(zhù)天然的差別。分布式追蹤領(lǐng)域有三個(gè)重要的概念：Metrics、Trace、Log，全鏈路監控就是利用三者間的關(guān)系分步驟實(shí)現。

• Metrics即指標，反映組件實(shí)時(shí)狀況與健康度；

• Trace即鏈路，反映在單次請求的范圍內如何處理信息；

• Log即日志，反映離散的事件或過(guò)程；

  
  

  

（Metrics、Tracing、Logging三者間的關(guān)系示意圖）

一般進(jìn)行全鏈路監控有兩種做法：

• 第一種做法：首先通過(guò)指標即（Metrics）,查看組件的健康程度、受影響的交易類(lèi)型，再通過(guò)指標關(guān)聯(lián)查看整個(gè)交易路徑的健康度即（Trace），最后定位具體的問(wèn)題節點(diǎn)即（Log），找出根因。

• 第二種做法：當交易出現問(wèn)題，先查看出錯的具體路徑即（Trace），再查看相對應的指標（Metrics），如服務(wù)器或應用性能指標等，最后查看詳細日志數據（Log）。

我們都知道，網(wǎng)絡(luò )數據通常反映的是指標，然而無(wú)論是指標還是日志都必須經(jīng)過(guò)數據加工處理才能進(jìn)入全鏈路追蹤體系。Metrics輔助于應用監控，傾向于節省資源，會(huì )對數據進(jìn)行天然的“壓縮”，而Log傾向于無(wú)限增加，會(huì )頻繁地超出預期容量。無(wú)論是日志類(lèi)還是網(wǎng)絡(luò )數據類(lèi)監控都可以采用以上兩種做法，只不過(guò)介于數據源的因素，網(wǎng)絡(luò )數據類(lèi)監控具有天然可操作性，而日志類(lèi)監控卻經(jīng)過(guò)了一個(gè)漫長(cháng)的發(fā)展期，并衍生出許多新的問(wèn)題。

三、落地方式對比

全鏈路監控的需求不是一開(kāi)始就有的，受制于網(wǎng)絡(luò )科技與業(yè)務(wù)發(fā)展等諸多因素，不同階段對全鏈路監控的標準和需求也有著(zhù)明顯的差異。

網(wǎng)絡(luò )發(fā)展初期，業(yè)務(wù)規模小，企業(yè)通常采用標準作業(yè)程序（SOP）。由于系統多為單體架構，操作簡(jiǎn)單、易部署，為節省資源、縮短時(shí)間成本，除核心系統外，沒(méi)有監控其它系統的需求，因此，系統版本迭代較慢，不易擴展，全鏈路監控也就無(wú)從談起。

到了2010年左右，互聯(lián)網(wǎng)發(fā)展進(jìn)入飛躍期。隨著(zhù)業(yè)務(wù)量逐漸增多，業(yè)務(wù)分支越來(lái)越細，垂直架構逐漸興起。然而，這一時(shí)期，系統與系統之間存在數據冗余，且同一個(gè)子系統中的業(yè)務(wù)無(wú)法實(shí)現關(guān)聯(lián)，盡管全鏈路監控的需求與日俱增，如何實(shí)現卻成為一道現實(shí)難題。

在追求全鏈路監控的過(guò)程中，由于缺乏統一的標準，對現有系統進(jìn)行改造成為當時(shí)較為普遍的解決方案。然而，改造系統同樣面臨兩個(gè)嚴峻問(wèn)題：

• 第一大問(wèn)題：改造周期過(guò)長(cháng)。即便如BMC對系統實(shí)施改造，在半年內也僅能完成兩套系統的改造工作。如果用戶(hù)規模持續增多、業(yè)務(wù)量持續走高，耗時(shí)將會(huì )更久；而通過(guò)網(wǎng)絡(luò )數據對系統進(jìn)行改造，可以實(shí)現3個(gè)月內10套系統的改造升級工作。

• 第二大問(wèn)題：成本過(guò)高。日志改造需要網(wǎng)絡(luò )部門(mén)與開(kāi)發(fā)部門(mén)協(xié)同合作。我們都知道，在企業(yè)內部，開(kāi)發(fā)部門(mén)屬于增效部門(mén)，運維部門(mén)屬于降本部門(mén)，二者之間有天然的隔閡，改造日志勢必會(huì )增加開(kāi)發(fā)成本、增加人天數；而利用網(wǎng)絡(luò )數據進(jìn)行改造，將90%的工作在運維部門(mén)內部完成，極大地降低開(kāi)發(fā)成本，提高運維效率。

2014年，ThoughtWorks首席科學(xué)家Martin Fowler與James Lewis對微服務(wù)提供了完整定義：

• 每個(gè)服務(wù)運行在自己的進(jìn)程中；

• 微服務(wù)之間采用輕量級通信；

• 微服務(wù)應基于業(yè)務(wù)能力進(jìn)行構建；

• 采用自動(dòng)化部署機制實(shí)現微服務(wù)的獨立部署；

• 服務(wù)的管理應采用最小的中心化管理。

隨著(zhù)分布式鏈路架構的日益成熟，云環(huán)境與微服務(wù)的天然契合性，為日志全鏈路監控標準的產(chǎn)生奠定了一定基礎。微服務(wù)即服務(wù)按照不同維度拆分，一次請求往往涉及多個(gè)服務(wù)，這些應用服務(wù)由不同的團隊開(kāi)發(fā)、使用不同的編程語(yǔ)言，橫跨多個(gè)數據中心，因此全鏈路監控勢在必行，進(jìn)一步刺激了基于日志的全鏈路監控標準與工具的產(chǎn)生。

微服務(wù)架構中，業(yè)務(wù)鏈路極其復雜，如何快速發(fā)現問(wèn)題、判斷故障節點(diǎn)、梳理服務(wù)鏈路、分析鏈路性能是影響全鏈路監控的主要問(wèn)題。而基于日志的全鏈路監控就主要圍繞這些問(wèn)題，通過(guò)埋點(diǎn)與生成日志、收集與存儲日志、分析和統計調用鏈路數據來(lái)一一實(shí)現。埋點(diǎn)日志通常要包括traceID、spanID、調用開(kāi)始時(shí)間、協(xié)議類(lèi)型等信息，把統一traceID的Span收集起來(lái)，按時(shí)間排序即timeline，再把ParentID串起來(lái)就組成調用棧，利用traceID查詢(xún)調用鏈情況就可以隨時(shí)定位問(wèn)題。但是在調用的過(guò)程中，如果調用失敗會(huì )直接中斷主流程，而調用過(guò)程又具有高依賴(lài)與頻繁依賴(lài)的特性，因此提升性能、增強穩定性是解決日志全鏈路監控的關(guān)鍵。

（span細節圖）

為了解決性能問(wèn)題，眾多大廠(chǎng)紛紛入局，研發(fā)了許多開(kāi)源的日志類(lèi)監控工具，如谷歌的Dapper、Zipkin、Sky Walking 、Pinpoint等。但是這些開(kāi)源監控產(chǎn)品通常通過(guò)代碼埋點(diǎn)進(jìn)行部署，傳遞的是底層數據，和業(yè)務(wù)的相關(guān)性較低。除此以外，探針的性能、Collector的擴展性、時(shí)間人工成本等因素也影響著(zhù)全鏈路監控的應用。比如，在某大型股份制銀行長(cháng)達兩年的云上分布式鏈路追蹤來(lái)看，其人工成本增加近150%，這對于某些中小型企業(yè)是難以承受的壓力。

（Dapper的分布式跟蹤）

而通過(guò)網(wǎng)絡(luò )數據，無(wú)需對系統進(jìn)行改造，僅需對數據進(jìn)行解碼，梳理各個(gè)節點(diǎn)的訪(fǎng)問(wèn)關(guān)系，刻畫(huà)業(yè)務(wù)的調用路徑，相比日志更易落地。

未來(lái)，隨著(zhù)技術(shù)的發(fā)展，日志類(lèi)全鏈路監控的落地難題也許會(huì )被攻克。但就目前而言，無(wú)論是數據源、監控路徑，亦或落地方式，基于網(wǎng)絡(luò )數據的全鏈路監控明顯優(yōu)于日志。需求決定市場(chǎng)，選擇網(wǎng)絡(luò )數據作為監控數據源，從源頭解決全鏈路監控的一系列難題，即刻落地、節約資源、發(fā)揮高效性能，維護網(wǎng)絡(luò )穩定，推動(dòng)業(yè)務(wù)發(fā)展。