分布式跟蹤系統調研

jopen 9年前發布 | 38K 次閱讀 分布式 分布式/云計算/大數據

原文  http://www.zenlife.tk/distributed-tracing.md

分布式跟蹤系統調研

介紹

把分布式系統中各個組件的工作匯總起來,就可以得到一個全面的跟蹤系統。

每個公司都會有一套自己的分布式跟蹤系統。Google的Dapper,推ter的zipkin,淘寶的鷹眼,新浪的Watchman,京東的Hydra,唯品會的Microscope,窩窩網的Tracing。

重要的基礎設施。

應用場景

一次競價請求中要經歷哪些事情?廣告位查不到會怎么樣?cookie mapping查不到會怎么樣?調用棧。

競價的平均QPS是多少?最高QPS是多少?波動情況如何?監控QPS。

為什么這個請求很慢?是哪一個環節出了問題?監控latency。

數據庫的請求量突然上漲了,如何排查來源是怎么樣的?鏈路分析。

這個操作需要依賴哪些東西?是數據庫還是消息隊列?如果某個redis掛了,哪些業務會受影響?依賴分析。

架構

(~~stolen from~~)Inspired by 鷹眼

分布式跟蹤系統調研

處理過程包括應用內部埋點,日志數據收集,在線和離線的數據分析,結果的存儲和展示。

埋點

不能造成性能負擔:一個價值未被驗證,卻會影響性能的東西,是很難在公司推廣的!

因為要寫log,業務QPS越高,性能影響越重。通過采樣和異步log解決。

type Span struct {
  TraceID   int64
  Name     string
  ID         int64
  ParentID   int64
  Annotation []Annotation
  Debug   bool
}

Span代表某個特定的方法調用,有一個名稱和一個id。由一系列的標注組成。

type Annotation struct {
  Timestamp int64
  Value  string
  Host    Endpoint
  Duration  int32
}

Trace是關聯到同一個請求的一系列的Span。

收集

每個機器上有一個deamon做日志收集。業務進程把自己的Trace發到daemon。

daemon把收集Trace往上一級發送。

多級的collector,類似pub/sub架構。可以負載均衡。

對聚合的數據進行實時分析和離線存儲。

離線分析需要將同一條調用鏈的日志匯總在一起。

分析

調用鏈跟蹤:把同一TraceID的Span收集起來,按時間排序就是timeline。把ParentID串起來就是調用棧。

拋異常或者超時,在日志里打印TraceID。利用TraceID查詢調用鏈情況,定位問題。

依賴度量:

  • 強依賴:調用失敗會直接中斷主流程
  • 高度依賴:一次鏈路中調用某個依賴的幾率高
  • 頻繁依賴:一次鏈路調用同一個依賴的次數多

分布式跟蹤系統調研

離線分析按TraceID匯總,通過Span的ID和ParentID還原調用關系,分析鏈路形態。

實時分析對單條日志直接分析,不做匯總,重組。得到當前QPS,延遲。

存儲

數據保留兩個星期。

展示

必須能讀才有價值。

技術選型

zipkin算是整套的解決方案,但是按照它的get start,裝不上!

打算自己組裝輪子。盡量采用Go語言的!

埋點肯定是自己做的。可以參考 這個 ,但是性能方面要注意下。

日志收集系統聽說有flume/scribe等。知乎開源的kid看了一下,很小巧,redis的pub/sub協議很不錯。heka的可擴展性比較好,實時分析應該可以直接做在里面。

展現如果有前端幫忙可以考慮ECharts或D3.js,不懂前端。graphite可以做數據展現。在osx下安裝,依賴好麻煩!

初步決定:Heka + Influxdb + Grafana

展望

tracing和monitor的區別。

monitor可分為系統監控和應用監控。系統監控比如CPU,內存,網絡,磁盤等等整體的系統負載的數據,細化可具體到各進程的相關數據。這 一類信息是直接可以從系統中得到的。應用監控需要應用提供支持,暴露了相應的數據。比如應用內部請求的QPS,請求處理的延時,請求處理的error數, 消息隊列的隊列長度,崩潰情況,進程垃圾回收信息等等。monitor主要目標是發現異常,及時報警。

tracing的基礎和核心都是調用鏈。相關的metric大多都是圍繞調用鏈分析得到的。tracing主要目標是系統分析。提前找到問題比出現問題后再去解決更好。

tracing和應用級的monitor技術棧上有很多共同點。都有數據的采集,分析,存儲和展式。只是具體收集的數據維度不同,分析過程不一樣。

tracing是一期的內容,本次調研用到的各組件都是有機會在其它地方使用的。這些輪子用熟之后,二期可以做更多監控方面的東西。

我們的目標是--讓我們的基礎設施更加完善和強大!

參考資料

  1. google的大規模分布式系統的跟蹤系統 Dapper ,經典論文
  2. 推ter的 zipkin ,開源,scala的,裝不上
  3. 淘寶的 鷹眼 技術分享PPT,干貨!
  4. 窩窩網介紹Tracing的一篇 博客
  5. 唯品會 Microscope
  6. 一個老外寫的PPT
  7. 埋點要用到的輪子
  8. Kids 知乎開源的日志聚合系統
  9. 介紹heka的一個PPT
  10. graphite,Scalable Realtime Graphing
  11. InfluxDB 是一個開源分布式時序、事件和指標數據庫
 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!