Google雲計算之Dapper

Dapper

• • 1.系統設計要求
  • 2.系統設計目标
  • 3.基本概念
  • 4.資訊彙總
  • 5.關鍵技術
  • 6.常用工具
  • 7.使用經驗

Dapper是Google開發的一種分布式監控系統

1.系統設計要求

• 廣泛可部署性

  設計出的監控系統應當能夠對盡可能多的Google服務進行監控

• 不間斷的監控

  Google的服務是全天候的，如果不能對Google 的背景同樣進行全天候的監控很可能會錯過某些無法再現的關鍵性故障

2.系統設計目标

• 低開銷

  這個是廣泛可部署性的必然要求。監控系統的開銷越低，對于原系統的影響就越小，系統的開發人員也就越願意接受這個監控系統。

• 可擴充性

  Google的服務增長速度是驚人的，設計出的系統至少在未來幾年裡要能夠滿足Google服務和叢集的需求。

• 應用層透明

  監控系統對程式員應當是不可見的。如果監控系統的使用需要程式開發人員對其底層的一些細節進行調整才能正常工作的話，這個監控系統肯定不是一個完善的監控系統。

3.基本概念

• 請求應答過程

  

  1. 使用者發出一個請求X，它期待得到系統對它做出的應答X
  2. 但是接收到該請求的前端A發現該請求的處理需要涉及伺服器B和伺服器C，是以A又向B和C發出兩個 RPC
  3. B收到後立刻做出響應，但是C在接到後發現它還需要調用伺服器D和E才能完成請求X，是以C對D和E分别發出了RPC
  4. D和E接到後分别做出了應答， 收到D和E的應答之後C才向A做出響應，在接收到B和C的應答之後A才對使用者請求X做出 一個應答X

  在監控系統中記錄下所有這些消息不難，如何将這些消息記錄同特定的請求 （本例中的X）關聯起來才是分布式監控系統設計中需要解決的關鍵性問題之一

  • 黑盒方案

    ：輕便，基于統計學，不準确

  • 基于注釋的監控方案

    ：利用應用程式或中間件給每條記錄賦予一個全局性的标示符
• 監控樹

  一個同特定事件相關的所有消息

  

  • 區間名

    ： 主要是為了友善人們記憶和了解

  • 區間id

    ： 為了 在一棵監控樹中區分不同的區間

  • 父id

    ： 是區間中非常重要的一個内容，正是通過父id才能 夠對樹中不同區間的關系進行重建， 沒有父id的區間稱為根區間

  • 監控id

    ： 一棵監控樹中所有區間的監控id是相同的，這個監控 id是随機配置設定的，且在整個Dapper監控系統中是唯一的， 監控id是用來在整個Dapper監控系統中區分不同的監控
• 區間

  區間實際上就是一條記錄，一個區間既可以隻有一台主機的資訊，也可以包含來源于多個主機的資訊，事實上每個RPC區間都包含來自用戶端（Client）和伺服器端（Server）的注釋

  

• 注釋

  注釋主要用來輔助推斷區間關系，也可以包含一些自定義的内容

4.資訊彙總

1. 将區間的資料被寫入到本地的日志檔案
2. 利用Dapper守護程序（Dapper daemon）和Dapper收集器（Dapper Collectors） 将所有機器上的本地日志檔案彙集在一起
3. 将彙集後的資料寫入到Bigtable存儲庫中

5.關鍵技術

• 輕量級核心功能庫

  主要是為了實作對應用層透明

  

  • 最關鍵的代碼基礎是基本RPC、線程和控制流函數庫的實作
  • 主要功能是實作區間建立、抽樣和在本地磁盤上記錄日志
  • 将複雜的功能實作限制在一個輕量級的核心功能庫中保證了Dapper的監控過程基本對應用層透明
• 二次抽樣技術

  主要是為了解決了低開銷及廣泛可部署性的問題

  • 第一次抽樣

    實踐中，設計人員發現當抽樣率低至1/1024時也能夠産生足夠多的有效監控資料，即在1024個請求中抽取1個進行監控也是可行的，進而可以捕獲有效資料

  • 第二次抽樣

    發生在資料寫入Bigtable前，具體方法是将監控id散列（hash，壓縮映射）成一個标量z（0≤z≤1），如果某個區間的z小于事先定義好的彙總抽樣系數，則保留這個區間并将它寫入Bigtable，否則丢棄

6.常用工具

• 存儲API

  Dapper的“存儲API”簡稱為 DAPI，提供了對分散在區域Dapper存儲庫（DEPOTS）的監控記錄的直接通路。

  • 通過監控id通路：利用全局唯一的監控id直接通路所需的監控資料
  • 塊通路：借助MapReduce對數以十億計的Dapper監控資料的并行通路
  • 索引通路：Dapper存儲庫支援單索引
• 使用者界面

  通過GUI界面對Dapper進行管理

1. 首先使用者需要選擇監控對象，包括監控的起止時間、區分監控模式的資訊及一個衡量開銷的标準

   

2. 使用者可以按其意願對這些執行模式進行排序并選擇某一個檢視更多的細節

   

3. 分布式執行模式圖形化描述呈現給使用者

   

4. 根據最初選擇的開銷度量标準，Dapper以頻度直方圖的形式将步驟（3）中選中的執行模式的開銷分布展示出來

   

5. 使用者選擇了某個監控樣例後，就會進入所謂的監控審查視圖

   

7.使用經驗

• 新服務部署中Dapper的使用

  利用Dapper對系統延遲情況進行一系列的跟蹤，進而發現存在的問題

• 定位長尾延遲

  端到端性能和關鍵路徑上的網絡延遲有着極大的關系

  

• 推斷服務間的依存關系

  Google的“服務依存關系”項目使用監控注釋和DPAI的MapReduce接口實作了服務依存關系确定的自動化

• 确定不同服務的網絡使用情況

  利用Dapper平台建構了一個連續不斷更新的控制台，用來顯示内部叢集網絡通信中最活躍的應用層終端

• 分層的共享式存儲系統

  沒有Dapper之類的工具的情況下對于這種共享式服務資源的争用也同樣難以調試

• 利用Dapper進行“火拼”

  Dapper使用者可以通過和Dapper守護程序的直接通信，将所需的最新資料彙總在一起