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