Dapper監(jiān)控系統(tǒng)簡介
1.基本槪念
對系統(tǒng)行為進行監(jiān)控的過程非常的復雜，特別是在分布式系統(tǒng)中。為了理解這種復性，首先來看如圖2-30^1所示的?個過程。.
在圖中，用戶發(fā)出一個請求X,它期待得到系統(tǒng)對它做出的應答X。伹ft接收到該請 求的前端A發(fā)現(xiàn)該清求的處理需要涉及服務器B和服務器C,因此A又向B.和C發(fā)出兩個RPC (遠程過程調(diào)用)。B收到后立刻做出響應，但是C在接到后發(fā)現(xiàn)它還需要調(diào)用服 務器D和E才能完成請求X,因此C對p和E分別發(fā)出了 RPC, D和E接到后分別做出 了應答，收到jD和E的庳答之后C才向A做出響應，在接收到B和C的應答之后A ;才 對用戶請求X做出一個應答X。在監(jiān)控系統(tǒng)中記錄下所有這些消息不難，如何將這些消息記錄同特定的請求（本例中的X)關聯(lián)起來才是分布式監(jiān)控系統(tǒng)設計中需要解決的關鍵性問題之一。
1.基本槪念
對系統(tǒng)行為進行監(jiān)控的過程非常的復雜，特別是在分布式系統(tǒng)中。為了理解這種復性，首先來看如圖2-30^1所示的?個過程。.
在圖中，用戶發(fā)出一個請求X,它期待得到系統(tǒng)對它做出的應答X。伹ft接收到該請 求的前端A發(fā)現(xiàn)該清求的處理需要涉及服務器B和服務器C,因此A又向B.和C發(fā)出兩個RPC (遠程過程調(diào)用)。B收到后立刻做出響應，但是C在接到后發(fā)現(xiàn)它還需要調(diào)用服 務器D和E才能完成請求X,因此C對p和E分別發(fā)出了 RPC, D和E接到后分別做出 了應答，收到jD和E的庳答之后C才向A做出響應，在接收到B和C的應答之后A ;才 對用戶請求X做出一個應答X。在監(jiān)控系統(tǒng)中記錄下所有這些消息不難，如何將這些消息記錄同特定的請求（本例中的X)關聯(lián)起來才是分布式監(jiān)控系統(tǒng)設計中需要解決的關鍵性問題之一。
—般來說，有兩種方案可供選擇：黑盒（Black Box)方案及基于注釋的監(jiān)控 (Annotation-based Monitoring)方案。二者比較而言，黑盒方案比較輕便，但是在消息關 系判斷的過程中，黑盒方案主要是利用芒些統(tǒng)計學的知識來進行推斷，有時不是很準確。 基于注釋的方案利用應用程序或中間件給每條記錄賦予一個全局性的標示符，借此將相關 消息串聯(lián)起來?？紤]到實際的需求，Google的工程師最終選擇了基于注釋的方案，為/ 盡可能消除監(jiān)控系統(tǒng)的應用程序?qū)Ρ槐O(jiān)控系統(tǒng)的性能產(chǎn)生的不良影響，Google的工程師 設計并實現(xiàn)了一套輕量級的核心功能庫，這將在后面進行介紹。
Dapper監(jiān)控系統(tǒng)中有三個基本概念：監(jiān)控樹（Trace Tree)、區(qū)間（Span)和注釋 (Annotation)。如圖2-31[18]所示是一個典型的監(jiān)控樹，從中可以看到所謂的監(jiān)控樹實際上就 是一個同特定事件相關的所有消息，只不過這些消息是按照一定的規(guī)律以樹的形式組織起 來。樹中的每一個節(jié)點稱為一個區(qū)間，區(qū)間實際上就是一條記錄，所有這些記錄聯(lián)系在一 起就構(gòu)成了對某個事件的完整監(jiān)控。從圖2-31不難看出，每個區(qū)間包括如下的內(nèi)容：區(qū)間 名（Span Name)、區(qū)間 id (Span id)、父 id (Parent id)和監(jiān)控 id (Trace id)。區(qū)間名主要 是為了方便人們記憶和理解，因此要求這個區(qū)間名是人們可以讀懂的。區(qū)間id是為了在一 棵監(jiān)控樹中區(qū)分不同的區(qū)間。父id是區(qū)間中非常重要的一個內(nèi)容，正是通過父id才能夠?qū)?樹中不同區(qū)間的關系進行重建，沒有父id的區(qū)間稱為根區(qū)間（Root Span)。圖2-31中的 Frontend Request就是一個根區(qū)間。在圖中還能看出，區(qū)間的長度實際上包括了區(qū)間的開始 及結(jié)束時間信息。
監(jiān)控id在圖2-31中并沒有列出，一棵監(jiān)控樹中所有區(qū)間的監(jiān)控id是相同的，這個監(jiān)控 id是隨機分配的，且在整個Dapper監(jiān)控系統(tǒng)中是唯一的。正如區(qū)間id是用來在某個監(jiān)控樹 中區(qū)分不同的區(qū)間一樣，監(jiān)控id是用來在整個Dapper監(jiān)控系統(tǒng)中區(qū)分不同的監(jiān)控。注釋主 要用來輔助推斷區(qū)間關系，也可以包含一些自定義的內(nèi)容。圖2-32[18】展示了圖2-31中 HelperCall區(qū)間的更詳細信息。
在圖2-32中可以清楚地看到這個區(qū)間的區(qū)間名是“Helper.Call”,監(jiān)控id是100,區(qū)間id是5,父id是3-—個區(qū)間既可以只有一臺主機的信息，也可以包含來源于多個主機 的信息，事實上，每個RPC區(qū)間都包含來自客戶端（Client)和服務器端（Server)的注釋，這使得雙主機區(qū)間（Two-host Span)成為最常見的一種。圖2-32中的區(qū)間就包含了來自客戶端的注釋信息：“”、“Client Send”、“Client Recv” 和“”，也包含了來自服務器端的注釋信
息：“ServerRecv”、“foo”和“Server Send”。除了 “foo”是用戶自定義的注釋外，其他的注釋信息都是和時間相關的信息。Dapper不但支持用戶進行簡單的文本方式的注釋，還支持鍵-值對方式的注釋，這賦予了開發(fā)者更多的自由。
Dapper監(jiān)控系統(tǒng)中有三個基本概念：監(jiān)控樹（Trace Tree)、區(qū)間（Span)和注釋 (Annotation)。如圖2-31[18]所示是一個典型的監(jiān)控樹，從中可以看到所謂的監(jiān)控樹實際上就 是一個同特定事件相關的所有消息，只不過這些消息是按照一定的規(guī)律以樹的形式組織起 來。樹中的每一個節(jié)點稱為一個區(qū)間，區(qū)間實際上就是一條記錄，所有這些記錄聯(lián)系在一 起就構(gòu)成了對某個事件的完整監(jiān)控。從圖2-31不難看出，每個區(qū)間包括如下的內(nèi)容：區(qū)間 名（Span Name)、區(qū)間 id (Span id)、父 id (Parent id)和監(jiān)控 id (Trace id)。區(qū)間名主要 是為了方便人們記憶和理解，因此要求這個區(qū)間名是人們可以讀懂的。區(qū)間id是為了在一 棵監(jiān)控樹中區(qū)分不同的區(qū)間。父id是區(qū)間中非常重要的一個內(nèi)容，正是通過父id才能夠?qū)?樹中不同區(qū)間的關系進行重建，沒有父id的區(qū)間稱為根區(qū)間（Root Span)。圖2-31中的 Frontend Request就是一個根區(qū)間。在圖中還能看出，區(qū)間的長度實際上包括了區(qū)間的開始 及結(jié)束時間信息。
監(jiān)控id在圖2-31中并沒有列出，一棵監(jiān)控樹中所有區(qū)間的監(jiān)控id是相同的，這個監(jiān)控 id是隨機分配的，且在整個Dapper監(jiān)控系統(tǒng)中是唯一的。正如區(qū)間id是用來在某個監(jiān)控樹 中區(qū)分不同的區(qū)間一樣，監(jiān)控id是用來在整個Dapper監(jiān)控系統(tǒng)中區(qū)分不同的監(jiān)控。注釋主 要用來輔助推斷區(qū)間關系，也可以包含一些自定義的內(nèi)容。圖2-32[18】展示了圖2-31中 HelperCall區(qū)間的更詳細信息。
在圖2-32中可以清楚地看到這個區(qū)間的區(qū)間名是“Helper.Call”,監(jiān)控id是100,區(qū)間id是5,父id是3-—個區(qū)間既可以只有一臺主機的信息，也可以包含來源于多個主機 的信息，事實上，每個RPC區(qū)間都包含來自客戶端（Client)和服務器端（Server)的注釋，這使得雙主機區(qū)間（Two-host Span)成為最常見的一種。圖2-32中的區(qū)間就包含了來自客戶端的注釋信息：“
息：“ServerRecv”、“foo”和“Server Send”。除了 “foo”是用戶自定義的注釋外，其他的注釋信息都是和時間相關的信息。Dapper不但支持用戶進行簡單的文本方式的注釋，還支持鍵-值對方式的注釋，這賦予了開發(fā)者更多的自由。
