日志VS網(wǎng)絡(luò)數(shù)據(jù)，誰能做好全鏈路監(jiān)控？
[導(dǎo)讀]對系統(tǒng)的運(yùn)行狀態(tài)進(jìn)行監(jiān)控，是IT工程師的一項(xiàng)重要工作。如果不能確保整個系統(tǒng)及其鏈路處于穩(wěn)定運(yùn)行的狀態(tài)，那么，企業(yè)的業(yè)務(wù)穩(wěn)定發(fā)展就無從談起。21世紀(jì)以來，隨著云計(jì)算的興起，系統(tǒng)架構(gòu)發(fā)生了顯著的變化。分布式崛起，開始取代單體式，成為行業(yè)的主流選擇。微服務(wù)概念的提出，容器等云原生技術(shù)的...
對系統(tǒng)的運(yùn)行狀態(tài)進(jìn)行監(jiān)控，是IT工程師的一項(xiàng)重要工作。
如果不能確保整個系統(tǒng)及其鏈路處于穩(wěn)定運(yùn)行的狀態(tài)，那么，企業(yè)的業(yè)務(wù)穩(wěn)定發(fā)展就無從談起。
21世紀(jì)以來，隨著云計(jì)算的興起，系統(tǒng)架構(gòu)發(fā)生了顯著的變化。分布式崛起，開始取代單體式，成為行業(yè)的主流選擇。微服務(wù)概念的提出，容器等云原生技術(shù)的發(fā)展，加劇了這一變化。
系統(tǒng)架構(gòu)變化之后，對系統(tǒng)進(jìn)行監(jiān)控的需求也隨之變化，監(jiān)控難度大幅增加。
目前，對系統(tǒng)進(jìn)行全鏈路監(jiān)控，根據(jù)數(shù)據(jù)源、監(jiān)控路徑、落地方式等不同，存在多種監(jiān)控方式。市場上最主流的監(jiān)控派別，是日志類和網(wǎng)絡(luò)數(shù)據(jù)類。
接下來，我們通過對比的方式，看看這兩種技術(shù)派別的主要差異。
▉ 數(shù)據(jù)源對比
日志類的數(shù)據(jù)來源有兩類：
一種是傳統(tǒng)物理設(shè)備上的日志文件，這種日志文件能夠提供的數(shù)據(jù)格式、數(shù)據(jù)精細(xì)度、數(shù)據(jù)內(nèi)容，都是各個設(shè)備廠商預(yù)先設(shè)定的。
另外一種，是程序開發(fā)過程中或開發(fā)完成后，為捕獲程序或者系統(tǒng)本身的運(yùn)行信息，開發(fā)出來的日志系統(tǒng)。
日志系統(tǒng)本身不對應(yīng)用程序發(fā)起主動式訪問，只是伴隨著程序的運(yùn)行，將相關(guān)的運(yùn)行數(shù)據(jù)（機(jī)器本身或者程序運(yùn)行的狀態(tài)信息）輸送出來。
此外，日志屬于采樣數(shù)據(jù)，信息級別與功能均由人工定義，在存儲以及分析的過程中，時常因前端需求而更改，按照人為需求進(jìn)行目標(biāo)輸出，因此邊界十分明顯。
再來看看網(wǎng)絡(luò)數(shù)據(jù)。
網(wǎng)絡(luò)數(shù)據(jù)是應(yīng)用程序之間通過網(wǎng)絡(luò)進(jìn)行傳輸?shù)莫?dú)特過程數(shù)據(jù)。它能夠提供業(yè)務(wù)活動、應(yīng)用性能、安全性與IT基礎(chǔ)架構(gòu)等方面的信息。
獲取網(wǎng)絡(luò)數(shù)據(jù)的方式比較簡單，通過交換機(jī)鏡像的方式，就可以將網(wǎng)絡(luò)數(shù)據(jù)復(fù)制出來。
網(wǎng)絡(luò)數(shù)據(jù)獲取之后，送至分析服務(wù)器，即可實(shí)現(xiàn)性能監(jiān)控。
網(wǎng)絡(luò)數(shù)據(jù)是一種全量數(shù)據(jù)，通過旁路捕獲數(shù)據(jù)包，不消耗任何系統(tǒng)資源，可以實(shí)時反映設(shè)備、服務(wù)器、系統(tǒng)等運(yùn)行的狀態(tài)。
日志時間由系統(tǒng)程序自動打印，一般精確到毫秒。
網(wǎng)絡(luò)數(shù)據(jù)的時間戳，由捕獲服務(wù)器的高性能網(wǎng)卡抓包時進(jìn)行標(biāo)記，最快可以實(shí)現(xiàn)納秒級。
盡管兩者同樣采用ntp時間同步，但兩者之間的時間準(zhǔn)確程度也會因網(wǎng)絡(luò)傳輸?shù)纫蛩禺a(chǎn)生毫秒級以上的差距。
在網(wǎng)絡(luò)傳輸過程中，由于Delayed ACK與Nagle算法的相互作用，會導(dǎo)致最大500毫秒的延遲。日志往往無法排查此類問題，而通過網(wǎng)絡(luò)數(shù)據(jù)可以進(jìn)行數(shù)據(jù)包回溯分析。因此，網(wǎng)絡(luò)數(shù)據(jù)比日志具備更高的實(shí)時性。
▉ 監(jiān)控路徑對比
作為兩種數(shù)據(jù)源，日志與網(wǎng)絡(luò)數(shù)據(jù)所監(jiān)控的定義與范圍有著天然的差別。
分布式追蹤領(lǐng)域有三個重要的概念：Metrics、Trace、Log：
（Metrics、Tracing、Logging三者間的關(guān)系示意圖）
全鏈路監(jiān)控，就是利用上述三者之間的關(guān)系，分步驟實(shí)現(xiàn)的。
一般來說，進(jìn)行全鏈路監(jiān)控有兩種做法：
網(wǎng)絡(luò)數(shù)據(jù)，通常反映的是指標(biāo)。然而，無論是指標(biāo)還是日志，都必須經(jīng)過數(shù)據(jù)加工處理，才能進(jìn)入全鏈路追蹤體系。
Metrics輔助于應(yīng)用監(jiān)控，傾向于節(jié)省資源，會對數(shù)據(jù)進(jìn)行天然的“壓縮”。而Log傾向于無限增加，會頻繁地超出預(yù)期容量。
無論是日志類還是網(wǎng)絡(luò)數(shù)據(jù)類監(jiān)控，都可以采用以上兩種做法。只不過介于數(shù)據(jù)源的因素，網(wǎng)絡(luò)數(shù)據(jù)類監(jiān)控具有天然可操作性，而日志類監(jiān)控卻經(jīng)過了一個漫長的發(fā)展期，并衍生出許多新的問題。
▉ 落地方式對比
全鏈路監(jiān)控的需求，并不是一開始就有的。受制于網(wǎng)絡(luò)技術(shù)與業(yè)務(wù)發(fā)展等諸多因素，不同階段對全鏈路監(jiān)控的標(biāo)準(zhǔn)和需求也有著明顯的差異。
網(wǎng)絡(luò)發(fā)展初期，業(yè)務(wù)規(guī)模小，企業(yè)通常采用標(biāo)準(zhǔn)作業(yè)程序（SOP）。
此時，由于系統(tǒng)多為單體架構(gòu)，操作簡單、易部署，為節(jié)省資源、縮短時間成本，除核心系統(tǒng)外，沒有監(jiān)控其它系統(tǒng)的需求。因此，系統(tǒng)版本迭代較慢，不易擴(kuò)展，全鏈路監(jiān)控也就無從談起。
到了2010年左右，互聯(lián)網(wǎng)發(fā)展進(jìn)入飛躍期。隨著業(yè)務(wù)量逐漸增多，業(yè)務(wù)分支越來越細(xì)，垂直架構(gòu)逐漸興起。
然而，這一時期，系統(tǒng)與系統(tǒng)之間存在數(shù)據(jù)冗余，且同一個子系統(tǒng)中的業(yè)務(wù)無法實(shí)現(xiàn)關(guān)聯(lián)。盡管全鏈路監(jiān)控的需求與日俱增，如何實(shí)現(xiàn)卻成為一道現(xiàn)實(shí)難題。
在追求全鏈路監(jiān)控的過程中，由于缺乏統(tǒng)一的標(biāo)準(zhǔn)，對現(xiàn)有系統(tǒng)進(jìn)行改造成為當(dāng)時較為普遍的解決方案。
然而，改造系統(tǒng)同樣面臨兩個嚴(yán)峻問題：
即便如BMC對系統(tǒng)實(shí)施改造，在半年內(nèi)也僅能完成兩套系統(tǒng)的改造工作。如果用戶規(guī)模持續(xù)增多、業(yè)務(wù)量持續(xù)走高，耗時將會更久。而通過網(wǎng)絡(luò)數(shù)據(jù)對系統(tǒng)進(jìn)行改造，可以實(shí)現(xiàn)3個月內(nèi)10套系統(tǒng)的改造升級工作。
日志改造需要網(wǎng)絡(luò)部門與開發(fā)部門協(xié)同合作。我們都知道，在企業(yè)內(nèi)部，開發(fā)部門屬于增效部門，運(yùn)維部門屬于降本部門，二者之間有天然的隔閡。
改造日志，勢必會增加開發(fā)成本、增加人天數(shù)。而利用網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行改造，將90%的工作在運(yùn)維部門內(nèi)部完成，極大地降低開發(fā)成本，提高運(yùn)維效率。
2014年，ThoughtWorks首席科學(xué)家Martin Fowler與James Lewis給出了微服務(wù)的完整定義：
隨著分布式鏈路架構(gòu)的日益成熟，云環(huán)境與微服務(wù)的天然契合性，為日志全鏈路監(jiān)控標(biāo)準(zhǔn)的產(chǎn)生奠定了一定基礎(chǔ)。
微服務(wù)即服務(wù)按照不同維度拆分，一次請求往往涉及多個服務(wù)，這些應(yīng)用服務(wù)由不同的團(tuán)隊(duì)開發(fā)、使用不同的編程語言，橫跨多個數(shù)據(jù)中心。因此，全鏈路監(jiān)控勢在必行，進(jìn)一步刺激了基于日志的全鏈路監(jiān)控標(biāo)準(zhǔn)與工具的產(chǎn)生。
微服務(wù)架構(gòu)中，業(yè)務(wù)鏈路極其復(fù)雜。如何快速發(fā)現(xiàn)問題、判斷故障節(jié)點(diǎn)、梳理服務(wù)鏈路、分析鏈路性能，是影響全鏈路監(jiān)控的主要問題。
而基于日志的全鏈路監(jiān)控，就主要圍繞這些問題，通過埋點(diǎn)與生成日志、收集與存儲日志、分析和統(tǒng)計(jì)調(diào)用鏈路數(shù)據(jù)來一一實(shí)現(xiàn)。
日志通常利用Trace ID、Parent ID等信息，對調(diào)用鏈路進(jìn)行查詢與問題定位。但是在調(diào)用的過程中，如果調(diào)用失敗，會直接中斷主流程，而調(diào)用過程又具有高依賴與頻繁依賴的特性，因此提升性能、增強(qiáng)穩(wěn)定性是解決日志全鏈路監(jiān)控的關(guān)鍵。
（span細(xì)節(jié)圖）
為了解決性能問題，眾多大廠紛紛入局，研發(fā)了許多開源的日志類監(jiān)控工具，如谷歌的Dapper、Zipkin、Sky Walking 、Pinpoint等。
但是這些開源監(jiān)控產(chǎn)品，通常通過代碼埋點(diǎn)進(jìn)行部署，傳遞的是底層數(shù)據(jù)，和業(yè)務(wù)的相關(guān)性較低。
除此以外，探針的性能、Collector的擴(kuò)展性、時間人工成本等因素，也影響著全鏈路監(jiān)控的應(yīng)用。
比如，在某大型股份制銀行長達(dá)兩年的云上分布式鏈路追蹤來看，其人工成本增加近150%，這對于某些中小型企業(yè)是難以承受的壓力。
而通過網(wǎng)絡(luò)數(shù)據(jù)，無需對系統(tǒng)進(jìn)行改造，僅需對數(shù)據(jù)進(jìn)行解碼，梳理各個節(jié)點(diǎn)的訪問關(guān)系，刻畫業(yè)務(wù)的調(diào)用路徑，相比日志更易落地。
▉ 結(jié)語
未來，隨著技術(shù)的發(fā)展，日志類全鏈路監(jiān)控的落地難題也許會被攻克。但就目前而言，無論是數(shù)據(jù)源、監(jiān)控路徑，亦或落地方式，基于網(wǎng)絡(luò)數(shù)據(jù)的全鏈路監(jiān)控明顯優(yōu)于日志。
需求決定市場，選擇網(wǎng)絡(luò)數(shù)據(jù)作為監(jiān)控?cái)?shù)據(jù)源，完全可以從源頭解決全鏈路監(jiān)控的一系列難題，從而維護(hù)網(wǎng)絡(luò)穩(wěn)定，發(fā)揮系統(tǒng)性能，推動企業(yè)業(yè)務(wù)的快速發(fā)展。
掃描下方二維碼，學(xué)習(xí)更多運(yùn)維技術(shù)知識
如果不能確保整個系統(tǒng)及其鏈路處于穩(wěn)定運(yùn)行的狀態(tài)，那么，企業(yè)的業(yè)務(wù)穩(wěn)定發(fā)展就無從談起。
21世紀(jì)以來，隨著云計(jì)算的興起，系統(tǒng)架構(gòu)發(fā)生了顯著的變化。分布式崛起，開始取代單體式，成為行業(yè)的主流選擇。微服務(wù)概念的提出，容器等云原生技術(shù)的發(fā)展，加劇了這一變化。
系統(tǒng)架構(gòu)變化之后，對系統(tǒng)進(jìn)行監(jiān)控的需求也隨之變化，監(jiān)控難度大幅增加。
目前，對系統(tǒng)進(jìn)行全鏈路監(jiān)控，根據(jù)數(shù)據(jù)源、監(jiān)控路徑、落地方式等不同，存在多種監(jiān)控方式。市場上最主流的監(jiān)控派別，是日志類和網(wǎng)絡(luò)數(shù)據(jù)類。
接下來，我們通過對比的方式，看看這兩種技術(shù)派別的主要差異。
▉ 數(shù)據(jù)源對比
- 采樣數(shù)據(jù) VS 全量數(shù)據(jù)
日志類的數(shù)據(jù)來源有兩類：
一種是傳統(tǒng)物理設(shè)備上的日志文件，這種日志文件能夠提供的數(shù)據(jù)格式、數(shù)據(jù)精細(xì)度、數(shù)據(jù)內(nèi)容，都是各個設(shè)備廠商預(yù)先設(shè)定的。
另外一種，是程序開發(fā)過程中或開發(fā)完成后，為捕獲程序或者系統(tǒng)本身的運(yùn)行信息，開發(fā)出來的日志系統(tǒng)。
日志系統(tǒng)本身不對應(yīng)用程序發(fā)起主動式訪問，只是伴隨著程序的運(yùn)行，將相關(guān)的運(yùn)行數(shù)據(jù)（機(jī)器本身或者程序運(yùn)行的狀態(tài)信息）輸送出來。
此外，日志屬于采樣數(shù)據(jù)，信息級別與功能均由人工定義，在存儲以及分析的過程中，時常因前端需求而更改，按照人為需求進(jìn)行目標(biāo)輸出，因此邊界十分明顯。
再來看看網(wǎng)絡(luò)數(shù)據(jù)。
網(wǎng)絡(luò)數(shù)據(jù)是應(yīng)用程序之間通過網(wǎng)絡(luò)進(jìn)行傳輸?shù)莫?dú)特過程數(shù)據(jù)。它能夠提供業(yè)務(wù)活動、應(yīng)用性能、安全性與IT基礎(chǔ)架構(gòu)等方面的信息。
獲取網(wǎng)絡(luò)數(shù)據(jù)的方式比較簡單，通過交換機(jī)鏡像的方式，就可以將網(wǎng)絡(luò)數(shù)據(jù)復(fù)制出來。
網(wǎng)絡(luò)數(shù)據(jù)獲取之后，送至分析服務(wù)器，即可實(shí)現(xiàn)性能監(jiān)控。
網(wǎng)絡(luò)數(shù)據(jù)是一種全量數(shù)據(jù)，通過旁路捕獲數(shù)據(jù)包，不消耗任何系統(tǒng)資源，可以實(shí)時反映設(shè)備、服務(wù)器、系統(tǒng)等運(yùn)行的狀態(tài)。
- 時間精度和實(shí)時性
日志時間由系統(tǒng)程序自動打印，一般精確到毫秒。
網(wǎng)絡(luò)數(shù)據(jù)的時間戳，由捕獲服務(wù)器的高性能網(wǎng)卡抓包時進(jìn)行標(biāo)記，最快可以實(shí)現(xiàn)納秒級。
盡管兩者同樣采用ntp時間同步，但兩者之間的時間準(zhǔn)確程度也會因網(wǎng)絡(luò)傳輸?shù)纫蛩禺a(chǎn)生毫秒級以上的差距。
在網(wǎng)絡(luò)傳輸過程中，由于Delayed ACK與Nagle算法的相互作用，會導(dǎo)致最大500毫秒的延遲。日志往往無法排查此類問題，而通過網(wǎng)絡(luò)數(shù)據(jù)可以進(jìn)行數(shù)據(jù)包回溯分析。因此，網(wǎng)絡(luò)數(shù)據(jù)比日志具備更高的實(shí)時性。
▉ 監(jiān)控路徑對比
作為兩種數(shù)據(jù)源，日志與網(wǎng)絡(luò)數(shù)據(jù)所監(jiān)控的定義與范圍有著天然的差別。
分布式追蹤領(lǐng)域有三個重要的概念：Metrics、Trace、Log：
- Metrics即指標(biāo)，反映組件實(shí)時狀況與健康度；
- Trace即鏈路，反映在單次請求的范圍內(nèi)如何處理信息；
- Log即日志，反映離散的事件或過程；
（Metrics、Tracing、Logging三者間的關(guān)系示意圖）全鏈路監(jiān)控，就是利用上述三者之間的關(guān)系，分步驟實(shí)現(xiàn)的。
一般來說，進(jìn)行全鏈路監(jiān)控有兩種做法：
- 第一種做法：首先通過指標(biāo)（Metrics），查看組件的健康程度、受影響的交易類型；再通過指標(biāo)關(guān)聯(lián)，查看整個交易路徑的健康度（Trace）；最后，定位具體的問題節(jié)點(diǎn)（Log），找出根因。
- 第二種做法：當(dāng)交易出現(xiàn)問題，首先查看出錯的具體路徑（Trace），再查看相對應(yīng)的指標(biāo)（Metrics），如服務(wù)器或應(yīng)用性能指標(biāo)等，最后查看詳細(xì)日志數(shù)據(jù)（Log）。
網(wǎng)絡(luò)數(shù)據(jù)，通常反映的是指標(biāo)。然而，無論是指標(biāo)還是日志，都必須經(jīng)過數(shù)據(jù)加工處理，才能進(jìn)入全鏈路追蹤體系。
Metrics輔助于應(yīng)用監(jiān)控，傾向于節(jié)省資源，會對數(shù)據(jù)進(jìn)行天然的“壓縮”。而Log傾向于無限增加，會頻繁地超出預(yù)期容量。
無論是日志類還是網(wǎng)絡(luò)數(shù)據(jù)類監(jiān)控，都可以采用以上兩種做法。只不過介于數(shù)據(jù)源的因素，網(wǎng)絡(luò)數(shù)據(jù)類監(jiān)控具有天然可操作性，而日志類監(jiān)控卻經(jīng)過了一個漫長的發(fā)展期，并衍生出許多新的問題。
▉ 落地方式對比
全鏈路監(jiān)控的需求，并不是一開始就有的。受制于網(wǎng)絡(luò)技術(shù)與業(yè)務(wù)發(fā)展等諸多因素，不同階段對全鏈路監(jiān)控的標(biāo)準(zhǔn)和需求也有著明顯的差異。
網(wǎng)絡(luò)發(fā)展初期，業(yè)務(wù)規(guī)模小，企業(yè)通常采用標(biāo)準(zhǔn)作業(yè)程序（SOP）。
此時，由于系統(tǒng)多為單體架構(gòu)，操作簡單、易部署，為節(jié)省資源、縮短時間成本，除核心系統(tǒng)外，沒有監(jiān)控其它系統(tǒng)的需求。因此，系統(tǒng)版本迭代較慢，不易擴(kuò)展，全鏈路監(jiān)控也就無從談起。
到了2010年左右，互聯(lián)網(wǎng)發(fā)展進(jìn)入飛躍期。隨著業(yè)務(wù)量逐漸增多，業(yè)務(wù)分支越來越細(xì)，垂直架構(gòu)逐漸興起。
然而，這一時期，系統(tǒng)與系統(tǒng)之間存在數(shù)據(jù)冗余，且同一個子系統(tǒng)中的業(yè)務(wù)無法實(shí)現(xiàn)關(guān)聯(lián)。盡管全鏈路監(jiān)控的需求與日俱增，如何實(shí)現(xiàn)卻成為一道現(xiàn)實(shí)難題。
在追求全鏈路監(jiān)控的過程中，由于缺乏統(tǒng)一的標(biāo)準(zhǔn)，對現(xiàn)有系統(tǒng)進(jìn)行改造成為當(dāng)時較為普遍的解決方案。
然而，改造系統(tǒng)同樣面臨兩個嚴(yán)峻問題：
- 第一大問題：改造周期過長。
即便如BMC對系統(tǒng)實(shí)施改造，在半年內(nèi)也僅能完成兩套系統(tǒng)的改造工作。如果用戶規(guī)模持續(xù)增多、業(yè)務(wù)量持續(xù)走高，耗時將會更久。而通過網(wǎng)絡(luò)數(shù)據(jù)對系統(tǒng)進(jìn)行改造，可以實(shí)現(xiàn)3個月內(nèi)10套系統(tǒng)的改造升級工作。
- 第二大問題：成本過高。
日志改造需要網(wǎng)絡(luò)部門與開發(fā)部門協(xié)同合作。我們都知道，在企業(yè)內(nèi)部，開發(fā)部門屬于增效部門，運(yùn)維部門屬于降本部門，二者之間有天然的隔閡。
改造日志，勢必會增加開發(fā)成本、增加人天數(shù)。而利用網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行改造，將90%的工作在運(yùn)維部門內(nèi)部完成，極大地降低開發(fā)成本，提高運(yùn)維效率。
2014年，ThoughtWorks首席科學(xué)家Martin Fowler與James Lewis給出了微服務(wù)的完整定義：
- 每個服務(wù)運(yùn)行在自己的進(jìn)程中；
- 微服務(wù)之間采用輕量級通信；
- 微服務(wù)應(yīng)基于業(yè)務(wù)能力進(jìn)行構(gòu)建；
- 采用自動化部署機(jī)制實(shí)現(xiàn)微服務(wù)的獨(dú)立部署；
- 服務(wù)的管理應(yīng)采用最小的中心化管理。
隨著分布式鏈路架構(gòu)的日益成熟，云環(huán)境與微服務(wù)的天然契合性，為日志全鏈路監(jiān)控標(biāo)準(zhǔn)的產(chǎn)生奠定了一定基礎(chǔ)。
微服務(wù)即服務(wù)按照不同維度拆分，一次請求往往涉及多個服務(wù)，這些應(yīng)用服務(wù)由不同的團(tuán)隊(duì)開發(fā)、使用不同的編程語言，橫跨多個數(shù)據(jù)中心。因此，全鏈路監(jiān)控勢在必行，進(jìn)一步刺激了基于日志的全鏈路監(jiān)控標(biāo)準(zhǔn)與工具的產(chǎn)生。
微服務(wù)架構(gòu)中，業(yè)務(wù)鏈路極其復(fù)雜。如何快速發(fā)現(xiàn)問題、判斷故障節(jié)點(diǎn)、梳理服務(wù)鏈路、分析鏈路性能，是影響全鏈路監(jiān)控的主要問題。
而基于日志的全鏈路監(jiān)控，就主要圍繞這些問題，通過埋點(diǎn)與生成日志、收集與存儲日志、分析和統(tǒng)計(jì)調(diào)用鏈路數(shù)據(jù)來一一實(shí)現(xiàn)。
日志通常利用Trace ID、Parent ID等信息，對調(diào)用鏈路進(jìn)行查詢與問題定位。但是在調(diào)用的過程中，如果調(diào)用失敗，會直接中斷主流程，而調(diào)用過程又具有高依賴與頻繁依賴的特性，因此提升性能、增強(qiáng)穩(wěn)定性是解決日志全鏈路監(jiān)控的關(guān)鍵。
（span細(xì)節(jié)圖）為了解決性能問題，眾多大廠紛紛入局，研發(fā)了許多開源的日志類監(jiān)控工具，如谷歌的Dapper、Zipkin、Sky Walking 、Pinpoint等。
但是這些開源監(jiān)控產(chǎn)品，通常通過代碼埋點(diǎn)進(jìn)行部署，傳遞的是底層數(shù)據(jù)，和業(yè)務(wù)的相關(guān)性較低。
除此以外，探針的性能、Collector的擴(kuò)展性、時間人工成本等因素，也影響著全鏈路監(jiān)控的應(yīng)用。
比如，在某大型股份制銀行長達(dá)兩年的云上分布式鏈路追蹤來看，其人工成本增加近150%，這對于某些中小型企業(yè)是難以承受的壓力。
而通過網(wǎng)絡(luò)數(shù)據(jù)，無需對系統(tǒng)進(jìn)行改造，僅需對數(shù)據(jù)進(jìn)行解碼，梳理各個節(jié)點(diǎn)的訪問關(guān)系，刻畫業(yè)務(wù)的調(diào)用路徑，相比日志更易落地。
▉ 結(jié)語
未來，隨著技術(shù)的發(fā)展，日志類全鏈路監(jiān)控的落地難題也許會被攻克。但就目前而言，無論是數(shù)據(jù)源、監(jiān)控路徑，亦或落地方式，基于網(wǎng)絡(luò)數(shù)據(jù)的全鏈路監(jiān)控明顯優(yōu)于日志。
需求決定市場，選擇網(wǎng)絡(luò)數(shù)據(jù)作為監(jiān)控?cái)?shù)據(jù)源，完全可以從源頭解決全鏈路監(jiān)控的一系列難題，從而維護(hù)網(wǎng)絡(luò)穩(wěn)定，發(fā)揮系統(tǒng)性能，推動企業(yè)業(yè)務(wù)的快速發(fā)展。
掃描下方二維碼，學(xué)習(xí)更多運(yùn)維技術(shù)知識
下載文檔
