2. 程式人生 > >聊聊分布式鏈路追蹤

聊聊分布式鏈路追蹤

阿新 • • 發佈：2019-01-07
語言 位或 ear har 能夠 name 請求 sum ipv4

原文鏈接：http://lidawn.github.io/2018/12/26/distribute-tracing/

起因

最近一直在做分布式鏈路追蹤的調研和實踐，整理一下其中的知識點。

什麽是鏈路追蹤

分布式系統變得日趨復雜，越來越多的組件開始走向分布式化，如微服務、分布式數據庫、分布式緩存等，使得後臺服務構成了一種復雜的分布式網絡。在服務能力提升的同時，復雜的網絡結構也使問題定位更加困難。在一個請求在經過諸多服務過程中，出現了某一個調用失敗的情況，查詢具體的異常由哪一個服務引起的就變得十分抓狂，問題定位和處理效率是也會非常低。

分布式鏈路追蹤就是將一次分布式請求還原成調用鏈路，將一次分布式請求的調用情況集中展示，比如各個服務節點上的耗時、請求具體到達哪臺機器上、每個服務節點的請求狀態等等。

Dapper

目前業界的鏈路追蹤系統，如Twitter的Zipkin，Uber的Jaeger，阿裏的鷹眼，美團的Mtrace等都基本被啟發於google發表的Dapper。 Dapper闡述了分布式系統，特別是微服務架構中鏈路追蹤的概念、數據表示、埋點、傳遞、收集、存儲與展示等技術細節。

Trace、Span、Annotations

為了實現鏈路追蹤，dapper提出了trace，span，annotation的概念。
Trace的含義比較直觀，就是鏈路，指一個請求經過後端所有服務的路徑，可以用下面樹狀的圖形表示。每一條鏈路都用一個全局唯一的traceid來標識。

技術分享圖片

Span之間存在著父子關系，上遊的span是下遊的父span，例如圖中"frontend.request"會調用"backend.dosomething","backend.dosomething"便成為"frontend.request"的子span。

技術分享圖片

鏈路中的rpc調用由span來表示，對應著樹狀圖中的邊，每個span由spanid和parentid來標識，spanid在一條鏈路中唯一。
下圖是dapper論文中給出的一個"hepler.call"調用的span詳解。
一個span一般由client和server兩個部分的信息組成。按照時間順序來解釋，client節點（或者是調用方）首先發出請求，產生"client send"(cs)事件，緊接著server節點（或者是提供方）收到請求，產生"server receive"(sr)事件，server處理完成之後回復給client，產生"server send"事件，最後client收到回復，產生"client receive"事件。
Client與server兩個節點的span信息合並成一次完整的調用，即一個完整的span。

技術分享圖片

Dapper中還定義了annotation的概念，用於用戶自定義事件，如圖二中的"foo"，用來輔助定位問題。
值得一提的是，zipkin中把cs,cr,ss,sr這幾個事件稱之為annotation，而對應dapper中的annotation在zipkin v1的數據模型中被稱之為binaryAnnotation。

帶內數據與帶外數據

鏈路信息的還原依賴於兩種數據，一種是各個節點產生的事件,如cs,ss,稱之為帶外數據，這些數據可以由節點獨立生成，並且需要集中上報到存儲端。
另一種數據是traceid,spanid,parentid，用來標識trace，span，以及span在一個trace中的位置。這些數據需要從鏈路的起點一直傳遞到終點，稱之為帶內數據。 通過帶內數據的傳遞，可以將一個鏈路的所有過程串起來；通過帶外數據，可以在存儲端分析更多鏈路的細節。

采樣

由於每一個請求就會生成一個鏈路，為了減少性能消耗，避免存儲資源的浪費，dapper並不會上報所有的span數據，而是使用采樣的方式。通過采集端自適應地調整采樣率，控制span上報的數量，可以在發現性能瓶頸的同時，有效減少性能損耗。采樣率的概念在其他的追蹤系統中也被廣泛使用。在zipkin小節中將更具體闡述zipkin的采樣機制。

存儲

鏈路中的span數據經過收集和上報後會集中存儲在一個地方，Dapper使用了BigTable數據倉庫，如下圖所示，由於每種trace的span個數不盡相同，使得BigTable稀疏表格布局很適合這種場景，並且分散的span進行存儲時按照traceid和spanid便可以插入到對應的行列中，使得收集程序可以無需做任何計算且無狀態。同時鏈路的查詢也十分方便，即取表中的一行。

技術分享圖片

Zipkin

Zipkin是dapper的一種開源實現，也是業界做鏈路追蹤系統的一個重要參考，其系統也可以即插即用。

架構

Zipkin的架構中包含Reporter，Transport，Colletor，Storage，API，UI幾個部分。

技術分享圖片

其中Reporter集成在每個服務的代碼中，負責Span的生成，帶內數據(traceid等)的傳遞，帶外數據(span)的上報，采樣控制。
Transport部分為帶外數據上報的通道，zipkin支持http和kafka兩種方式。
Colletor負責接收帶外數據，並插入到集中存儲中。
Storage為存儲組件，適配底層的存儲系統，zipkin提供默認的in-memory存儲，並支持Mysql，Cassandra，ElasticSearch存儲系統。
API提供查詢、分析和上報鏈路的接口。接口的定義見zipkin-api。
UI用於展示頁面展示。

技術分享圖片

Zipkin將Colletor/Storage/API/UI打包為jar包，可以直接下載運行。

數據模型

這裏的數據模型為zipkin v2版本的數據模型。

Span

trace_id為16位或32位的hex字符串，id、parent_id為16位hex字符串， 如果沒有父span，parent_id為空。
kind標識服務節點的類型，有通信模型，cs和生產者消費者模型。
name為span的名字，如rpc調用的名字。
timestamp為span生成的時間戳，微秒。
duration為span的持續時間，client端，即為cr-ss的時間。
local_endpoint為本地節點信息，包含節點名稱，ip與端口。
remote_endpoint為遠端節點信息。
annotations為事件列表，每個事件用事件時間戳和名字表示。
tags為用戶自定義的kv信息，如{"user-id":"lidawn"}。
debug表示是否為調試，該選項會無視采樣概率，使所有span上報。
shared這個字段暫時沒有太理解==。

message Span {
  bytes trace_id = 1;
  bytes parent_id = 2;
  bytes id = 3;
  enum Kind {
    SPAN_KIND_UNSPECIFIED = 0;
    CLIENT = 1;
    SERVER = 2;
    PRODUCER = 3;
    CONSUMER = 4;
  }
  Kind kind = 4;
  string name = 5;
  fixed64 timestamp = 6;
  uint64 duration = 7;
  Endpoint local_endpoint = 8;
  Endpoint remote_endpoint = 9;
  repeated Annotation annotations = 10;
  map<string, string> tags = 11;
  bool debug = 12;
  bool shared = 13;
}

message Endpoint {
  string service_name = 1;
  bytes ipv4 = 2;
  bytes ipv6 = 3;
  int32 port = 4;
}

message Annotation {
  fixed64 timestamp = 1;
  string value = 2;
}

帶內數據與采樣機制

Zipkin中對帶內數據的傳遞有更加詳細的描述。帶內數據被稱為b3-propagation，包含TraceId,SpanId,ParentSpanId,Sampled四個字段，每個server在生成span之後會得到TraceId,SpanId,ParentSpanId，穿遞到下遊server之後，下遊server可以知道自己接下來要生成的span屬於哪一條trace，並處在trace的哪一個位置。

由於帶內數據涉及到進程之間通信，所以一般是由框架來做帶內數據傳遞，這樣可以減少代碼的侵入性。如果服務之間使用http通信，則可以使用X-開頭的自定義http head來傳遞帶內數據。或者如grpc框架，使用clientContext機制在調用之間傳遞自定義的字段。目前開源的zipkin客戶端一般只支持http和grpc兩種方式。

Zipkin的采樣字段Sampled有四種狀態Defer/Deny/Accept/Debug，采樣的一個重要前提是下遊要尊重上遊的采樣決定，不能隨意更改sampled字段。
Defer代表該span的采樣狀態還未決定，下遊收到該狀態時則可以對sampled字段重新賦值。
Deny代表該span不上報。
Accept代表span需要上報。
Debug一般用於開發環境，強制上報。

Root_span的sampled字段由系統的采樣率來決定。如采樣率為50%，則一半的帶內數據中sampled字段為accept，其他為deny。

數據埋點及上報過程

根據zipkin的span定義，模擬一個簡單的調用過程，分析數據埋點和上報過程。

技術分享圖片

  1. server-1發起對server-2的調用，生成一個root_span, 生成trace_id，id，parent_id為空，並記錄kind為CLIENT，name，timestamp，local_endpoint(server-1)信息，並將trace_id，id，parent_id，sampled信息傳遞給server-2。
  2. server-2收到server-1的請求，並收到trace_id，id，parent_id，sampled信息，生成一個相同的span，並記錄kind為SERVER，name，timestamp，local_endpoint(server-2)信息。
  3. server-2發起對server-3的調用，生成一個新的span，該span為root_span的子span。 並記錄kind為CLIENT，name，timestamp，local_endpoint(server-2)信息，並將trace_id，id，parent_id，sampled信息傳遞給server-3。
  4. server-3收到server-2的請求，並收到trace_id，id，parent_id，sampled信息，生成一個相同的span，並記錄kind為SERVER，name，timestamp，local_endpoint(server-3)信息。
  5. server-3回復server-2的調用，記錄duration，並上報span。
  6. server-2收到server-3的回復，記錄duration，並上報span。
  7. server-2回復server-1的調用，記錄duration，並上報span。
  8. server-1收到server-2的回復，記錄duration，並上報span。

整個過程中上報4個臨時的span，最終在zipkin中被合並和存儲為兩個span。

Open-Tracing

由於各種分布式追蹤系統層出不窮，且有著相似的API語法，但各種語言的開發人員依然很難將他們各自的系統和特定的分布式追蹤系統進行整合。在這種情況下，OpenTracing規範出現了。
OpenTracing通過提供平臺無關、廠商無關的API，使得開發人員能夠方便的添加（或更換）追蹤系統的實現。OpenTracing通過定義的API，可實現將監控數據記錄到一個可插拔的tracer上。

Opentracing api的定義可以查看中文文檔, 其並沒有具體的實現。對於現有的系統，如zipkin適配opentracing，則需要額外基於現有的client編寫適配代碼。

以上。

參考

  1. Zipkin - https://zipkin.io
  2. Dapper - https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36356.pdf
  3. Jaeger - https://www.jaegertracing.io/
  4. 鷹眼 - https://cn.aliyun.com/aliware/news/monitoringsolution
  5. Mtrace - https://tech.meituan.com/mt_mtrace.html
  6. Zipkin-b3-propagation - https://github.com/openzipkin/b3-propagation
  7. Zipkin-api - https://zipkin.io/zipkin-api/#/default/post_spans
  8. Zipkin-proto - https://github.com/openzipkin/zipkin-api/blob/master/zipkin.proto
  9. OpenTracing - https://opentracing.io
  10. OpenTracing中文 - https://wu-sheng.gitbooks.io/opentracing-io/content/
原文鏈接：http://lidawn.github.io/2018/12/26/distribute-tracing/

聊聊分布式鏈路追蹤

相關推薦

聊聊分布式鏈路追蹤

語言 位或 ear har 能夠 name 請求 sum ipv4 原文鏈接：http://lidawn.github.io/2018/12/26/distribute-tracing/ 起因 最近一直在做分布式鏈路追蹤的調研和實踐，整理一下其中的知識點。 什麽是鏈路追蹤

Laravel + go-micro + grpc 實踐基於 Zipkin 的分布式鏈路追蹤系統 摘自https://mp.weixin.qq.com/s/JkLMNabnYbod-b4syMB3Hw?

啟動 quest -o 我們 clone maven 變慢 關鍵詞 擴展 分布式調用鏈跟蹤系統，屬於監控系統的一類。系統架構逐步演進時，後期形態往往是一個平臺由很多不同的服務、組件構成，用戶請求過來後，可能會經過其中多個服務，如圖 不過，出問題時往往很難排查，如整

分布式鏈路追蹤（Sleuth、Zipkin）

ice mysql 順序 sum mes ram 系統 註冊 分布式 技術背景 在微服務架構中，隨著業務發展，系統拆分導致系統調用鏈路愈發復雜，一個看似簡單的前端請求可能最終需要調用很多次後端服務才能完成，那麽當整個請求出現問題時，我們很難得知到底是哪個服務出了問題導致的

分布式鏈路監控與追蹤系統

分享圖片 延遲 ESS 原理 開放源代碼 image spring ram ati 1.分布式鏈路監控與追蹤產生背景2.SpringCloud Sleuth + Zipkin3.分布式服務追蹤實現原理4.搭建Zipkin服務追蹤系統5.搭建Zipkin集成RabbitMQ異

【第七章】分布式鏈路跟蹤(Sleuth)

default -o github nta 5.1 append comment 等等 1.2 當我們進行微服務架構開發時，通常會根據業務來劃分微服務，各業務之間通過REST進行調用。一個用戶操作，可能需要很多微服務的協同才能完成，如果在業務調用鏈路上任何一個微服務出現問題

使用zipkin做分布式鏈路監控

java介紹 Zipkin 為一個分布式的調用鏈跟蹤系統( distributed tracing system ) ,設計來源於 google dapper paper官方網站 http://zipkin.io/快速入門 安裝方式一：使用zipkin官方提供的jar啟動服務 zipkin官方提供了一個現成的

spring cloud 分布式鏈路跟蹤(集成zipkin)

ava 分享圖片 復雜 客戶 我們 集成 客戶端 erp -a 篇寫了分布式鏈路追蹤 spring cloud 分布式鏈路追蹤 這樣的鏈路追蹤雖然可以解決問題 但日誌太過於分散 如果微服務過多 就會變的相當復雜 zipkin就可以幫我們把鏈路調用的過程全部收集起來 它

螞蟻金服分布式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析

xxxxx cdd 3.1.1 extension art 構圖 mage acea 了解 2019新春支付寶紅包技術大揭秘在線峰會將於03-07日開始，點擊這裏報名屆時即可參與大牛互動。 SOFAScalable Open Financial Architecture

Zipkin 分布式數據追蹤系統

.org str uniq max mmu record which clas var Zipkin 是一個分布式數據追蹤系統，適用於微服務架構下的調用鏈路數據采集及分析工作。 可通過一個 Web 前端輕松的收集和分析數據，例如用戶每次請求服務的處理時間等，可方便的監測系統

從構建分布式秒殺系統聊聊分布式鎖

調用 you tel bre policy 學習 感悟 ant 操作 前言 最近懶成一坨屎，學不動系列一波接一波，大多還都是底層原理相關的。上周末抽時間重讀了周誌明大濕的 JVM 高效並發部分，每讀一遍都有不同的感悟。路漫漫，借此，把前段時間搞著玩的秒殺案例中的分布式鎖深

聊聊分布式開發 Spring Cloud

dash git pc通信 封裝 dubbo 消息中間件 十分 希望 當前 概述 本文章只是簡單介紹了微服務開發的一些關鍵詞，如果需要知道具體實現和可以評論留言 我會及時的增加連接寫出具體實現(感覺沒人看 就沒寫具體實現)。 持續更新中。。。。。。 SpringClo

spring cloud分布式使用日誌鏈路跟蹤

html 參考 服務 文件 add 當我 一點 pub https 首先要明白一點，為什麽要使用鏈路跟蹤？ 當我們微服務之間調用的時候可能會出錯，但是我們不知道是哪個服務的問題，這時候就可以通過日誌鏈路跟蹤發現哪個服務出錯。 它還有一個好處：當我們在企業中，可能每個人都負責

spring cloud分布式整合zipkin的鏈路跟蹤

pre configure .cn pub erp https 分析 java clas 為什麽使用zipkin？ 上篇主要寫了：spring cloud分布式日誌鏈路跟蹤 從上篇中可以看出服務之間的調用，假設現在有十幾臺服務，那麽在查找日誌的時候比較繁瑣、復雜，而且在查看

鷹眼系統;全鏈路監控系統；分布式監控系統

tor detail dapper git ans class log bsp http 有一些大公司的開源方案： https://www.jianshu.com/p/a125bea43abe 阿裏的鷹眼系統： https://cn.aliyun.com/aliware/n

jaegeropentracing的Java-client完整分布式追蹤鏈

ans cli thp sta XML agent client tst ati jaegeropentracing的Java-client完整分布式追蹤鏈，在分布式系統中透傳trace信息 之前文章記錄了jaegeropentracing的Java-client追蹤鏈在單

spring cloud分布式日誌鏈路跟蹤

logging 通過 page 源碼分析 刷新 出錯 gin 好處 自動創建 首先要明白一點，為什麽要使用鏈路跟蹤？ 當我們微服務之間調用的時候可能會出錯，但是我們不知道是哪個服務的問題，這時候就可以通過日誌鏈路跟蹤發現哪個服務出錯。 它還有一個好處：當我們在企業中，可能每

分布式技術追蹤 2017年第十九期

pla 如何 距離 無法 演變 什麽是 雲平臺 架構流程 增加 分布式系統實踐 1. BigData－‘基於代價優化’究竟是怎麽一回事？ http://dwz.cn/5Vq8T8 摘要: 很多同學應該都有認識, SQL的join操作很可能是性能殺手, 如果寫的不好, 性能可

【架構師之路】集群/分布式環境下5種session處理策略

復制 協調 部分 ont 描述 分析 bsp 優化 vol 轉自：http://www.cnblogs.com/jhli/p/6557929.html 在搭建完集群環境後，不得不考慮的一個問題就是用戶訪問產生的session如何處理。如果不做任何處理的話，用戶將出現頻繁

分布式技術追蹤 2017年第二十四期

基本原理 提升 管理系 elastic solr 基本 參考 高可用 搜索 分布式系統實踐 1. Google和Linkedin的老司機是如何管理海量數據的 http://dwz.cn/66Tkqx 摘要: 一直都聽說數據倉庫裏需要元數據管理, 但是沒看見過具體的設計. 這

分布式技術追蹤 2017年第二十八期

容器技術 切換 個數 sysbench 美團點評 發展 sql net 出了 分布式系統實踐 1. 給 spark 開發者介紹下Flink ：Flink vs Spark http://dwz.cn/6hnu9B 摘要: 當Spark如火如荼的時候, 天上突然掉下了一個Fl