分布式鏈路追蹤在字節(jié)跳動的實(shí)踐

點(diǎn)擊上方“服務(wù)端思維”，選擇“設(shè)為星標(biāo)”

回復(fù)”669“獲取獨(dú)家整理的精選資料集

回復(fù)”加群“加入全國服務(wù)端高端社群「后端圈」

綜述

字節(jié)跳動在發(fā)展過程中，逐漸形成了十分復(fù)雜的超大規(guī)模微服務(wù)體系，對后端整體的可觀測性解決方案提出了極高的要求。為了解決這個問題，基礎(chǔ)架構(gòu)智能運(yùn)維團(tuán)隊(duì)自研鏈路追蹤系統(tǒng)，將海量 Metrics/Trace/Log 數(shù)據(jù)進(jìn)行整合與統(tǒng)一，并在此基礎(chǔ)上實(shí)現(xiàn)了新一代的一站式全鏈路觀測診斷平臺，幫助業(yè)務(wù)解決監(jiān)控排障、鏈路梳理、性能分析等問題。本文將會介紹字節(jié)跳動鏈路追蹤系統(tǒng)的整體功能和技術(shù)架構(gòu)，以及實(shí)踐過程中我們的思考與總結(jié)。

什么是分布式鏈路追蹤(Trace) ？

M T L 的關(guān)系

可觀測性的三大基礎(chǔ)數(shù)據(jù)是 Metrics / Log / Trace。說到這三大件，可能大家會想到當(dāng)需要監(jiān)控變化趨勢和配置告警時就去用 Metrics；當(dāng)需要細(xì)查問題時去查 log；對于微服務(wù)數(shù)量較多的系統(tǒng)，還得有 Trace，Trace 也可以看做一種標(biāo)準(zhǔn)結(jié)構(gòu)化的 log，記錄了很多固定字段，例如上下游調(diào)用關(guān)系和耗時，查看上下游調(diào)用關(guān)系或者請求耗時在鏈路各節(jié)點(diǎn)上的分布可以查看 Trace。

但是如果帶著孤立的觀點(diǎn)去用這些數(shù)據(jù)的話，數(shù)據(jù)的價值會大大降低。舉例一個常見的場景，通過 Metrics 得知某服務(wù) SLA 降低，錯誤率上升，怎么去排查根因呢？先去找錯誤日志吧，可是我看到的錯誤日志是不是真的和這個錯誤率上升有關(guān)系呢？得翻翻代碼看看這些錯誤日志都是哪里打出來的，代表什么意思。再去找找有沒有錯誤 Trace？找出來的 Trace 也不太確定是不是和這個錯誤率上升有關(guān)系，還是得看代碼確認(rèn)下。終于通過一行行的代碼和數(shù)據(jù)比對，確認(rèn)到這個錯誤是下一層服務(wù)返回給我的，把那個服務(wù)的負(fù)責(zé)人拉進(jìn)來一起排查吧，然后這個群越拉越大，更多的人被拖進(jìn)來一層一層地查下去，最終定位到是某個底層服務(wù)上線了一個變更導(dǎo)致 Panic，錯誤層層向上傳播導(dǎo)致服務(wù) SLA 降低。

這個過程很不美好，需要工程師理解每一項(xiàng)數(shù)據(jù)的底層邏輯，才能充分利用它們?nèi)ソ鉀Q具體問題。而在復(fù)雜的大規(guī)模微服務(wù)系統(tǒng)中，沒有單個工程師能夠做到熟悉每一個微服務(wù)的底層邏輯，因此復(fù)雜微服務(wù)系統(tǒng)的排障和觀測往往是一項(xiàng)有挑戰(zhàn)的困難工作。

Trace 是數(shù)據(jù)的鏈接紐帶

如果所有微服務(wù)的監(jiān)控?cái)?shù)據(jù)都是遵循統(tǒng)一模型和語義規(guī)范并且天生高度關(guān)聯(lián)的呢？

在軟件系統(tǒng)中，每秒鐘有無數(shù)的 Context 在流動。這些 Context 可能是一個實(shí)時在線請求，也可能是一個異步處理任務(wù)。每個 Context 都會在多個微服務(wù)節(jié)點(diǎn)中持續(xù)傳播才能最終完成。所有的監(jiān)控?cái)?shù)據(jù)（包括 Metric, Log 等）都源自于某一個 Context。Trace 就是這個 Context 的數(shù)據(jù)載體，通過標(biāo)準(zhǔn)化的數(shù)據(jù)模型，記錄 Context 在多個微服務(wù)中的全部執(zhí)行過程，并沿途關(guān)聯(lián)上此 Context 上發(fā)生的所有事件（包括 Metric, Log 等）。

再回到剛才那個 Case，當(dāng)我們對某個 Metric 波動發(fā)生興趣時，可以直接將造成此波動的 Trace 關(guān)聯(lián)檢索出來，然后查看這些 Trace 在各個微服務(wù)中的所有執(zhí)行細(xì)節(jié)，發(fā)現(xiàn)是底層某個微服務(wù)在執(zhí)行請求過程中發(fā)生了 Panic，這個錯誤不斷向上傳播導(dǎo)致了服務(wù)對外 SLA 下降。如果可觀測平臺做得更完善一些，將微服務(wù)的變更事件數(shù)據(jù)也呈現(xiàn)出來，那么一個工程師就可以快速完成整個排障和根因定位的過程，甚至不需要人，通過機(jī)器就可以自動完成整個排障和根因定位過程。

Trace 不僅僅是用來查看耗時分布甘特圖的工具，也是海量監(jiān)控?cái)?shù)據(jù)的 Context 鏈接紐帶。基于可靠關(guān)聯(lián)的 Metric / Trace / Log 數(shù)據(jù)，也構(gòu)建出強(qiáng)大的可觀測性能力，回答監(jiān)控排障、SLO 調(diào)優(yōu)、架構(gòu)梳理、流量估算、智能化故障歸因等眾多復(fù)雜問題。

Trace 的采集以及跨服務(wù)進(jìn)程的 Context 傳遞一般是由微服務(wù)框架等基礎(chǔ)設(shè)施自動完成的，但是要實(shí)現(xiàn)最佳效果也需要所有研發(fā)工程師的理解和配合。研發(fā)工程師在編碼的過程中應(yīng)當(dāng)有意識地在所有代碼執(zhí)行過程中持續(xù)傳遞 Context。比如在 Golang 中，context.Context 需要在所有函數(shù)調(diào)用中作為參數(shù)持續(xù)傳遞；在 Java 中，一般默認(rèn)用 Threadlocal 作為 Context 的存儲載體，但是如果有多線程或者異步的場景，則需要開發(fā)者自行對 Context 進(jìn)行顯式的傳遞，否則上下文就斷了，難以實(shí)現(xiàn)有效的追蹤和監(jiān)控。

字節(jié)鏈路追蹤系統(tǒng)的挑戰(zhàn)與機(jī)遇

字節(jié)跳動在發(fā)展過程中，逐漸形成了十分復(fù)雜的超大規(guī)模微服務(wù)體系，對后端整體的可觀測性解決方案提出了極高的要求。

我們面臨的挑戰(zhàn)包括：

• 線上流量巨大
• 微服務(wù)數(shù)量巨大，調(diào)用關(guān)系復(fù)雜，迭代變化快
• 研發(fā)團(tuán)隊(duì)龐大，分工復(fù)雜

目前字節(jié)跳動有巨大的流量，眾多的活躍微服務(wù)、容器實(shí)例數(shù)，以及龐大的研發(fā)團(tuán)隊(duì)。一個復(fù)雜業(yè)務(wù)鏈路動輒涉及數(shù)百個微服務(wù)，有一線業(yè)務(wù)，有中臺，也有基礎(chǔ)設(shè)施，不同微服務(wù)由不同的研發(fā)團(tuán)隊(duì)開發(fā)，同時還有各類橫向團(tuán)隊(duì)負(fù)責(zé)整體架構(gòu)的質(zhì)量、穩(wěn)定性、安全和效率等相關(guān)工作。不同團(tuán)隊(duì)對鏈路追蹤系統(tǒng)都會有不一樣的訴求。

同時我們也有著難得的機(jī)遇：

• 微服務(wù)框架高度統(tǒng)一
• 微服務(wù)高度容器化，環(huán)境統(tǒng)一
• 存儲/中間件等基礎(chǔ)設(shè)施高度統(tǒng)一

得益于長期的統(tǒng)一基建工作，字節(jié)全公司范圍內(nèi)的所有微服務(wù)使用的底層技術(shù)方案統(tǒng)一度較高。絕大部分微服務(wù)都部署在公司統(tǒng)一的容器平臺上，采用統(tǒng)一的公司微服務(wù)框架和網(wǎng)格方案，使用公司統(tǒng)一提供的存儲組件及相應(yīng) SDK。高度的一致性對于基礎(chǔ)架構(gòu)團(tuán)隊(duì)建設(shè)公司級別的統(tǒng)一鏈路追蹤系統(tǒng)提供了有利的基礎(chǔ)。

字節(jié)鏈路追蹤系統(tǒng)的目標(biāo)

面對這樣的現(xiàn)狀，字節(jié)鏈路追蹤系統(tǒng)圍繞著一些目標(biāo)展開建設(shè)。我們的功能性目標(biāo)主要包括這幾個方面：

• 統(tǒng)一數(shù)據(jù)模型與語義：統(tǒng)一數(shù)據(jù)模型和語義規(guī)范，對所有主流框架/組件進(jìn)行默認(rèn)埋點(diǎn)中間件的替換升級，建立 Metrics / Trace / Log 可靠關(guān)聯(lián)關(guān)系。
• 開放自定義：統(tǒng)一模型的基礎(chǔ)上，充分開放自定義能力，滿足不同業(yè)務(wù)場景的監(jiān)控追蹤需求。
• 中心化配置管控：中心化動態(tài)管理采樣、染色、熔斷限流、索引、脫敏保密等各類策略。
• 一站式觀測平臺：提供從 SDK 到采集、計(jì)算、存儲、查詢和產(chǎn)品化交互的完整解決方案，基于高質(zhì)量基礎(chǔ)數(shù)據(jù)，構(gòu)建一站式觀測平臺，提升監(jiān)控排障、SLO 調(diào)優(yōu)、架構(gòu)梳理、容量管理等場景的能效。

在功能性目標(biāo)的背后，我們追求的技術(shù)目標(biāo)主要圍繞這幾個方面：

• 業(yè)務(wù)集成開銷最小化：集成開銷包括業(yè)務(wù)接入的改造成本和接入后帶來的 Overhead 開銷。大范圍的鏈路追蹤能夠成功覆蓋推廣，必須保證將集成開銷降到最低。
• 平衡存儲效率與檢索需求：需要以有限的機(jī)器預(yù)算完成較大數(shù)據(jù)量的處理和存儲，保證數(shù)據(jù)從產(chǎn)生到可被檢索的延遲在分鐘級以內(nèi)，檢索響應(yīng)速度在秒級以內(nèi)。
• 多機(jī)房容災(zāi)完備性：需要優(yōu)先考慮當(dāng)發(fā)生斷網(wǎng)或擁塞、機(jī)房宕機(jī)等災(zāi)難場景，業(yè)務(wù)急需觀測線上狀況時，保持可用。
• 最小化架構(gòu)與依賴復(fù)雜度：字節(jié)在海內(nèi)外有眾多機(jī)房，需盡可能最小化整體架構(gòu)的復(fù)雜度和第三方依賴的復(fù)雜度，否則多機(jī)房的部署運(yùn)維包括容災(zāi)完備性保障會非常困難。

字節(jié)鏈路追蹤系統(tǒng)的實(shí)現(xiàn)

數(shù)據(jù)采集

數(shù)據(jù)模型

統(tǒng)一的數(shù)據(jù)模型是 Trace 的基礎(chǔ)，字節(jié)鏈路追蹤系統(tǒng)的數(shù)據(jù)模型設(shè)計(jì)借鑒了 opentracing 和 CAT 等優(yōu)秀的開源解決方案，結(jié)合字節(jié)內(nèi)部實(shí)際生態(tài)和使用習(xí)慣，使用如下數(shù)據(jù)模型：

• Span: 一個有時間跨度的事件，例如一次 RPC 調(diào)用，一個函數(shù)執(zhí)行。
• Event: 一個沒有時間跨度的事件，例如一條 log，一次 panic。
• Metric: 一個帶多維 tag 的數(shù)值，例如一個消息體的大小，一個訂單的價格。
• Trace: 一個請求上下文在多個分布式微服務(wù)節(jié)點(diǎn)的完整執(zhí)行鏈路。
• Transaction: 一條 Trace 在單個服務(wù)節(jié)點(diǎn)上的所有 Span / Event / Metric 對象構(gòu)成的樹形結(jié)構(gòu)消息體。Transaction 是 Trace 數(shù)據(jù)的處理和存儲的最小單位，緊湊的數(shù)據(jù)結(jié)構(gòu)有利于節(jié)約成本和提高檢索性能。

下圖展示了使用字節(jié)鏈路追蹤系統(tǒng) SDK 埋 Trace 的代碼示例。注意其中 Context 貫穿整個請求生命周期，在進(jìn)程內(nèi)和跨進(jìn)程間持續(xù)傳遞，將數(shù)據(jù)串聯(lián)起來。

繼續(xù)這個示例，我們結(jié)合下圖闡述一下如何基于這套模型將 Metric / Trace / Log 進(jìn)行可靠關(guān)聯(lián)的。

Metric 關(guān)聯(lián) Trace:

• 每個 Span 會有內(nèi)置的頻次/耗時/失敗率 Metric 統(tǒng)計(jì)時序，Rpc/Mq 場景的 Span 還會有 SendSize/RecvSize/MqLag 等內(nèi)置統(tǒng)計(jì)時序。Span Tag 和 Metric Tag 一一對應(yīng)，以此為依據(jù)可以將 Span 時序指標(biāo)與 Trace 中的 Span 可靠關(guān)聯(lián)。
• 每個 Event 不僅會掛載在 Span 上，也會有內(nèi)置的頻次 Metric 統(tǒng)計(jì)時序。Event Tag 與 Metric Tag 一一對應(yīng)，以此為依據(jù)可以將 Event 時序指標(biāo)與 Trace 中的 Event 可靠關(guān)聯(lián)。
• 每個 Metric 不僅會掛載在 Span 上，也會按 Metric 類型輸出 rate/timer/store 等各類統(tǒng)計(jì)時序，兩邊 Tag 一一對應(yīng)，以此為依據(jù)可以將 Metric 時序指標(biāo)與 Trace 中的 Metric 對象可靠關(guān)聯(lián)。

Trace 關(guān)聯(lián) Log:

• Log SDK 會將 Context 中的 TraceID 和 SpanID 寫入日志頭中，通過 TraceID 和 SpanID 與 Trace 建立可靠關(guān)聯(lián)。

語義規(guī)范

僅有統(tǒng)一的抽象數(shù)據(jù)模型還不夠。如果每個服務(wù)都五花八門的隨意打 tag 沒有統(tǒng)一標(biāo)準(zhǔn)，那么即使有統(tǒng)一抽象模型也很難建設(shè)高質(zhì)量的觀測平臺。必須對 HTTP Server, RPC Server, RPC Client, MySQL Client, Redis Client, MQ Consumer, MQ Producer 等各類主流場景都進(jìn)行統(tǒng)一的語義規(guī)范，確保不同語言不同框架在相同場景下上報(bào)的數(shù)據(jù)遵循統(tǒng)一語義規(guī)范，才能夠真正獲取高質(zhì)量的可觀測性數(shù)據(jù)。

語義規(guī)范沒有唯一標(biāo)準(zhǔn)，下面給出字節(jié)內(nèi)部目前使用的部分語義規(guī)范作為參考示例。

通用基礎(chǔ)字段

場景化語義規(guī)范示例：RPC Client 場景

采樣策略

由于字節(jié)整體線上流量非常大，微服務(wù)數(shù)目眾多，不同微服務(wù)的性能敏感度、成本敏感度和數(shù)據(jù)需求各有不同，例如有些服務(wù)涉及敏感數(shù)據(jù)，必須有非常完整的追蹤數(shù)據(jù)；有些服務(wù)性能高度敏感，需要優(yōu)先控制采樣數(shù)最小化 Overhead；測試泳道、小流量灰度或者線上問題追查等場景會需要不同的采樣策略；常規(guī)流量和發(fā)生異常的流量也需要不同的采樣策略。因此靈活的采樣策略以及調(diào)控手段非常必要。字節(jié)鏈路追蹤系統(tǒng)主要提供了如下幾種采樣模式：

• 固定概率采樣+低流量接口兜底采樣：默認(rèn)以 Logid 作為采樣種子，按固定概率進(jìn)行采樣。對于流量較低的接口，按固定概率采樣難以命中的，SDK 會自動按一定的時間間隔進(jìn)行兜底采樣，確保低流量接口也有一定數(shù)目的請求被采集。
• 自適應(yīng)概率采樣：按單位時間對每個接口采集一定數(shù)目的 Transaction 為目標(biāo)，例如 100 條/min，SDK 自動根據(jù)當(dāng)前 QPS 動態(tài)計(jì)算采樣率進(jìn)行采樣。流量較低或不穩(wěn)定的服務(wù)建議采取這種模式。
• 染色采樣：對特定的請求添加染色標(biāo)記，SDK 檢測到染色標(biāo)對該請求進(jìn)行強(qiáng)制采樣。
• PostTrace 后置采樣: 當(dāng)一個 Trace 一開始未命中采樣，但在執(zhí)行過程中發(fā)生了一些令人感興趣的事（例如出錯或時延毛刺）時，可以在 Trace 中間狀態(tài)發(fā)起采樣。相較于先全采再后置采樣，此方案開銷極低。PostTrace 是前置概率采樣的一個重要補(bǔ)充，可以針對性地采集到異常鏈路，相比于先全采后 tail-based sampling 方案其開銷是極小的。但 PostTrace 的缺點(diǎn)只能采集到 PostTrace 時刻尚未結(jié)束的 Span，因此數(shù)據(jù)完整性相較前置采樣有一定損失。

我們結(jié)合一個示例來更好的理解什么是 PostTrace。左圖是一個請求，按照阿拉伯?dāng)?shù)字標(biāo)識的順序在微服務(wù)間發(fā)生了調(diào)用，本來這條 trace 沒有采樣，但是在階段 5 時發(fā)生了異常，觸發(fā)了 posttrace，這個 posttrace 信息可以從 5 回傳到 4，并傳播給后續(xù)發(fā)生的 6 和 7，最后再回傳到 1，最終可以采集到 1,4,5,6,7 這幾個環(huán)節(jié)的數(shù)據(jù)，但是之前已經(jīng)結(jié)束了的 2、3 環(huán)節(jié)則采集不到。右圖是我們線上的一個實(shí)際的 posttrace 展示效果，錯誤層層向上傳播最終采集到的鏈路的樣子。PostTrace 對于錯誤鏈傳播分析、強(qiáng)弱依賴分析等場景有很好的應(yīng)用。

這些采樣策略可以同時組合使用。需注意，采樣不影響 Metrics 和 Log。Metrics 是全量數(shù)據(jù)的聚合計(jì)算結(jié)果，不受采樣影響。業(yè)務(wù)日志也是全量采集，不受采樣影響。

中心化配置管控

為了提高效率，方便不同團(tuán)隊(duì)高效工作，字節(jié)鏈路追蹤系統(tǒng)提供了豐富的中心化配置管控能力，核心能力包括以下幾個方面：

• 采樣策略：支持業(yè)務(wù)按照不同的集群、接口、機(jī)房、部署階段設(shè)置不同的概率采樣策略；也可以動態(tài)設(shè)置染色、PostTrace 觸發(fā)條件。
• 自定義索引：不同的框架和場景會有不同的默認(rèn)索引字段，也支持業(yè)務(wù)按需在默認(rèn)索引的基礎(chǔ)上為自定義字段創(chuàng)建索引。
• 熔斷保護(hù)：SDK 默認(rèn)配備多種熔斷保護(hù)機(jī)制確保 Trace 采集不會占用過多資源影響主線功能，同時允許業(yè)務(wù)根據(jù)實(shí)際情況對相關(guān)的熔斷參數(shù)進(jìn)行動態(tài)調(diào)整。
• 脫敏保密：業(yè)務(wù)可以按需對 Trace 數(shù)據(jù)進(jìn)行脫敏和保密。

整體架構(gòu)

整體架構(gòu)

字節(jié)鏈路追蹤系統(tǒng)從數(shù)據(jù)接入側(cè)、消費(fèi)存儲到查詢整體模塊架構(gòu)如上圖所示。這里說一些技術(shù)細(xì)節(jié)：

• 私有協(xié)議數(shù)據(jù)流，性能更極致：從 SDK 到最終寫入存儲，整體數(shù)據(jù)流采用私有協(xié)議，數(shù)據(jù)流中各環(huán)節(jié)僅需解碼部分 header 即可完成處理，無需解碼所有內(nèi)容，可以節(jié)約大量的中間環(huán)節(jié)資源，降低時延。
• 底層本高吞吐的字節(jié)自研日志存儲：以較低的存儲成本實(shí)現(xiàn)較高的寫入速度和查詢性能，用于支持各類 Trace 在線檢索場景。
• 單元化架構(gòu)保障多機(jī)房容災(zāi)完備性：整體采用單元化架構(gòu)，節(jié)約機(jī)房間網(wǎng)絡(luò)帶寬，在部分機(jī)房間網(wǎng)絡(luò)故障或單機(jī)房宕機(jī)時保持高可用。
• 精細(xì)靈活的中心化調(diào)控能力：統(tǒng)一的配置中心向整個數(shù)據(jù)流各階段下發(fā)各類動態(tài)配置發(fā)并實(shí)時生效。
• 兼顧在線實(shí)時查詢與計(jì)算分析：如架構(gòu)圖所示，數(shù)據(jù)流主要分兩條，一條負(fù)責(zé)數(shù)據(jù)的在線存儲和實(shí)時查詢，要求鏈路盡可能短，追求性能極致，壓低時延，保證數(shù)據(jù)從產(chǎn)生到可檢索要盡可能快+高可用；另一條是計(jì)算分析流，對延遲的要求相對較低，但是需要滿足各類場景化的計(jì)算分析需求，與公司數(shù)倉平臺有較好的集成。
• 元數(shù)據(jù)采集與安全過期：從 Trace 數(shù)據(jù)流中可以采集到準(zhǔn)確度和時效性很高的元數(shù)據(jù)，例如每個微服務(wù)有哪些活躍接口，使用了哪些框架組件等信息，為多個第三方系統(tǒng)例如監(jiān)控告警和服務(wù)治理等平臺提供支持。

多機(jī)房容災(zāi)完備性

前面講目標(biāo)時提到，鏈路追蹤系統(tǒng)作為一個可觀測性基礎(chǔ)設(shè)施，需要優(yōu)先考慮當(dāng)發(fā)生斷網(wǎng)或擁塞、機(jī)房宕機(jī)等災(zāi)難場景，業(yè)務(wù)急需觀測線上狀況時，保持可用。

字節(jié)鏈路追蹤系統(tǒng)采用單元化部署機(jī)制，寫入數(shù)據(jù)流上各機(jī)房間無通信，頂層查詢模塊部署在匯聚機(jī)房（同時在主機(jī)房部署備用查詢節(jié)點(diǎn)），查詢時向各機(jī)房發(fā)起檢索并合并結(jié)果。

• 寫入流主機(jī)房間無數(shù)據(jù)通信，主機(jī)房間發(fā)生斷網(wǎng)時，功能不受損。
• 當(dāng)發(fā)生單機(jī)房宕機(jī)或孤島時，可執(zhí)行預(yù)案在查詢側(cè)屏蔽掉故障機(jī)房，保證其他機(jī)房數(shù)據(jù)可用。
• 當(dāng)頂層查詢模塊所在的機(jī)房宕機(jī)或斷網(wǎng)時，可執(zhí)行預(yù)案將查詢切到備用機(jī)房查詢節(jié)點(diǎn)繼續(xù)提供服務(wù)。

分析計(jì)算

除了基礎(chǔ)的實(shí)時檢索能力以外，場景化的數(shù)據(jù)聚合分析計(jì)算也是鏈路追蹤系統(tǒng)的一個重要需求，目前字節(jié)鏈路追蹤系統(tǒng)支持的分析計(jì)算場景主要包括：

• 拓?fù)溆?jì)算：為每個微服務(wù)（精確到接口/集群/機(jī)房粒度）計(jì)算上下游依賴鏈路拓?fù)涔羌埽瑵M足業(yè)務(wù)架構(gòu)梳理，全鏈路監(jiān)控等場景需求。
• 流量估算：聚合計(jì)算所有 Trace 并結(jié)合每條 Trace 的采樣率估算出鏈路的原始流量及調(diào)用比例，滿足活動擴(kuò)容評估，流量來源分析，成本分?jǐn)傆?jì)算等場景需求。
• 錯誤鏈分析：聚合計(jì)算含有錯誤的 Trace 的錯誤傳播路徑，滿足故障根因定位，錯誤影響面分析，易故障點(diǎn)優(yōu)化等場景需求。
• 鏈路性能分析：聚合計(jì)算滿足特定條件的 Trace 并分析各環(huán)節(jié)的耗時及調(diào)用比例等數(shù)據(jù)，滿足全鏈路性能優(yōu)化，耗時增加根因定位等場景需求。

不同的需求場景可以選擇不同的計(jì)算模式，目前字節(jié)鏈路追蹤系統(tǒng)采用的計(jì)算模式主要有三種：

• 近實(shí)時流式計(jì)算：從消息隊(duì)列中消費(fèi)數(shù)據(jù)按照時間窗口進(jìn)行流式聚合計(jì)算，近實(shí)時地不斷更新計(jì)算結(jié)果。例如拓?fù)溆?jì)算主要采取此模式，以獲取近實(shí)時的拓?fù)涔羌堋?/section>
• 即興抽樣計(jì)算：即興從在線存儲中按照特定條件抽樣檢索出有限數(shù)目（例如數(shù)百條）的 Trace 進(jìn)行聚合計(jì)算，快速獲得計(jì)算結(jié)果。
• 離線批計(jì)算：定時對離線數(shù)倉中的 Trace 進(jìn)行 MapReduce 批計(jì)算，輸出分析結(jié)果。

大部分場景的的 Trace 分析計(jì)算實(shí)質(zhì)都是批量 Trace 的 MapReduce 計(jì)算，基礎(chǔ)邏輯算子在不同的計(jì)算模式中可以復(fù)用。例如錯誤傳播鏈分析計(jì)算，既可以在故障時刻進(jìn)行即興抽樣計(jì)算快速得到分析結(jié)果，也可以通過離線批計(jì)算的方式進(jìn)行長期訂閱用于 SLO 持續(xù)優(yōu)化。

現(xiàn)階段實(shí)施效果

• 吞吐量：Transaction 數(shù) 10 Million/秒（默認(rèn)采樣率 0.1%），索引數(shù) 300 Million/秒
• 查詢性能：TraceID 檢索性能 P50 < 100 毫秒, P99 < 500 毫秒
• 數(shù)據(jù)產(chǎn)生到可檢索整體時延: AVG ≈ 1 分鐘，P99 < 2 分鐘
• 存儲資源：5 PB (2 副本 TTL 15 天)

實(shí)踐應(yīng)用案例

P99 慢請求根因追查

基于 Metrics, Trace, 底層調(diào)用分析和容器資源監(jiān)控進(jìn)行毛刺慢請求根因的快速定位。

全鏈路實(shí)時監(jiān)控

支持從任一微服務(wù)節(jié)點(diǎn)發(fā)起拓?fù)洳樵?，?shí)時觀測各節(jié)點(diǎn)的流量/延遲/錯誤率/資源使用率/告警/變更等，快速從全鏈路視角獲取整體狀態(tài)信息，用于日常巡檢、故障排查或壓測觀測等場景。

活動大促全鏈路容量預(yù)估

各業(yè)務(wù)線會經(jīng)常搞些活動來促進(jìn)用戶增長或留存，在準(zhǔn)備這些活動時，容量估算是一個必備階段，過程一般如下：

字節(jié)鏈路追蹤系統(tǒng)可以根據(jù)入口在歷史時段上的 QPS，各節(jié)點(diǎn)調(diào)用比例，資源使用率等指標(biāo)自動完成全鏈路各環(huán)節(jié) QPS 增量與資源增量需求的一鍵估算。

故障來源與影響面分析

當(dāng)發(fā)生異常時，可以從在線存儲中快速批量檢索到異常 Trace 進(jìn)行聚合計(jì)算，分析錯誤根源來自哪里，傳播到了哪里，影響到了哪些服務(wù)，并和昨日同時段錯誤率進(jìn)行對比，幫助工程師在遇到故障時快速定位根因。錯誤傳播鏈計(jì)算也支持通過離線訂閱的方式，對全時段所有異常 Trace 進(jìn)行長期計(jì)算，以助力于 SLO 長期優(yōu)化。

小結(jié)

Trace 是軟件系統(tǒng)監(jiān)控?cái)?shù)據(jù)的鏈接紐帶，建立 Metrics/Trace/Log 的可靠關(guān)聯(lián)關(guān)系，是構(gòu)建強(qiáng)大的可觀測性能力的基礎(chǔ)，基于優(yōu)質(zhì)的監(jiān)控?cái)?shù)據(jù)，可以回答監(jiān)控排障，SLO 調(diào)優(yōu)，架構(gòu)梳理，流量估算，智能化故障歸因等眾多復(fù)雜問題。

字節(jié)跳動在發(fā)展過程中，逐漸形成了十分復(fù)雜的超大規(guī)模微服務(wù)體系，我們面臨著很多挑戰(zhàn)，包括線上流量巨大，微服務(wù)數(shù)量巨大，迭代變化快，研發(fā)團(tuán)隊(duì)龐大，分工復(fù)雜等，但同時也有著難得的機(jī)遇，即全公司層面的微服務(wù)基礎(chǔ)設(shè)施十分統(tǒng)一。

面對這樣的現(xiàn)狀，字節(jié)鏈路追蹤系統(tǒng)圍繞著一些目標(biāo)展開建設(shè)，這些目標(biāo)有一些是項(xiàng)目建設(shè)之初就明確的，也有一些是在實(shí)踐過程中反思總結(jié)的，主要包括統(tǒng)一數(shù)據(jù)模型與語義，開放自定義，中心化配置管控，一站式觀測平臺；業(yè)務(wù)集成開銷最小化，平衡存儲效率與檢索需求，多機(jī)房容災(zāi)完備性和最小化架構(gòu)與依賴復(fù)雜度。

接下來分享了字節(jié)鏈路追蹤系統(tǒng)的整體實(shí)現(xiàn)。數(shù)據(jù)采集側(cè)的建設(shè)主要關(guān)注數(shù)據(jù)模型，語義統(tǒng)一，采樣策略以及熔斷保護(hù)等，并實(shí)現(xiàn)中心化配置管控。服務(wù)端的建設(shè)主要關(guān)注平衡成本和延遲，兼顧在線檢索和分析計(jì)算，保障多機(jī)房的容災(zāi)完備性。

最后分享了字節(jié)鏈路追蹤系統(tǒng)的一些實(shí)踐應(yīng)用，例如 P99 慢請求根因追查，全鏈路實(shí)時監(jiān)控，活動大促全鏈路容量預(yù)估和錯誤傳播分析等。

— 本文結(jié)束 —

●?漫談設(shè)計(jì)模式在 Spring 框架中的良好實(shí)踐

●?顛覆微服務(wù)認(rèn)知：深入思考微服務(wù)的七個主流觀點(diǎn)

●?人人都是 API 設(shè)計(jì)者

●?一文講透微服務(wù)下如何保證事務(wù)的一致性

●?要黑盒測試微服務(wù)內(nèi)部服務(wù)間調(diào)用，我該如何實(shí)現(xiàn)？

在看點(diǎn)這里