Sentry 監(jiān)控 - Distributed Tracing 分布式跟蹤

作者： 為少 2021-09-30 23:12:52

安全

應(yīng)用安全

分布式 分布式跟蹤(Distributed tracing)通過捕獲軟件系統(tǒng)之間的交互來提供相關(guān)錯誤和事務(wù)的連接視圖。通過跟蹤，Sentry 可以跟蹤您的軟件性能并顯示跨多個系統(tǒng)的錯誤影響。

公司主營業(yè)務(wù)：網(wǎng)站建設(shè)、網(wǎng)站制作、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)建站是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)建站推出文山州免費(fèi)做網(wǎng)站回饋大家。

本文轉(zhuǎn)載自微信公眾號「黑客下午茶」，作者為少。轉(zhuǎn)載本文請聯(lián)系黑客下午茶公眾號。

目錄

• 什么是跟蹤?
  • 為什么要跟蹤?
  • 跟蹤(Traces)、事務(wù)(Transactions和跨度(Spans)
  • 示例：調(diào)查緩慢的頁面加載
  • 更多示例
  • 跟蹤數(shù)據(jù)模型
  • 更多信息
• 數(shù)據(jù)采樣
  • 跟蹤中的一致性

分布式跟蹤(Distributed tracing)通過捕獲軟件系統(tǒng)之間的交互來提供相關(guān)錯誤和事務(wù)的連接視圖。通過跟蹤，Sentry 可以跟蹤您的軟件性能并顯示跨多個系統(tǒng)的錯誤影響。通過服務(wù)追溯問題將您的前端連接到您的后端。

• https://docs.sentry.io/product/sentry-basics/tracing/distributed-tracing/

啟用性能監(jiān)控以擴(kuò)充您現(xiàn)有的錯誤數(shù)據(jù)，跟蹤從前端到后端的交互。通過跟蹤，Sentry 可以跟蹤您的軟件性能，測量吞吐量和延遲等指標(biāo)，并顯示跨多個系統(tǒng)的錯誤影響。跟蹤使 Sentry 成為更完整的監(jiān)控解決方案，幫助您更快地診斷問題并衡量應(yīng)用程序的整體健康狀況。Sentry 中的跟蹤提供了以下見解：

• 特定錯誤事件或 issue 發(fā)生了什么
• 導(dǎo)致應(yīng)用程序出現(xiàn)瓶頸或延遲 issue 的條件
• 消耗時間最多的端點(diǎn)或操作

什么是跟蹤?

首先，請注意跟蹤不是什么：跟蹤不是分析。盡管分析和跟蹤的目標(biāo)有相當(dāng)多的重疊，雖然它們都可用于診斷應(yīng)用程序中的問題，但它們在測量內(nèi)容和數(shù)據(jù)記錄方式方面有所不同。

profiler 可以測量應(yīng)用程序操作的多個方面：執(zhí)行的指令數(shù)、各種進(jìn)程使用的內(nèi)存量、給定函數(shù)調(diào)用所花費(fèi)的時間量等等。生成的 profile 是這些測量值的統(tǒng)計匯總。

• https://en.wikipedia.org/wiki/Profiling_(computer_programming)

另一方面，tracing tool 關(guān)注發(fā)生了什么(以及何時)，而不是發(fā)生了多少次或花費(fèi)了多長時間。結(jié)果跟蹤(resulting trace)是在程序執(zhí)行期間發(fā)生的事件日志，通?？缍鄠€系統(tǒng)。盡管跟蹤最常見 - 或者，就 Sentry 的跟蹤而言，總是 - 包括時間戳(timestamps)，允許計算持續(xù)時間，但測量性能并不是它們的唯一目的。它們還可以顯示互連系統(tǒng)交互的方式，以及一個系統(tǒng)中的問題可能導(dǎo)致另一個系統(tǒng)出現(xiàn)問題的方式。

• https://en.wikipedia.org/wiki/Tracing_(software)

為什么要跟蹤?

應(yīng)用程序通常由互連的組件組成，這些組件也稱為服務(wù)。作為一個例子，讓我們看一個現(xiàn)代 Web 應(yīng)用程序，它由以下組件組成，由網(wǎng)絡(luò)邊界分隔：

• Frontend (Single-Page Application) 前端
• Backend (REST API) 后端
• Task Queue 任務(wù)隊列
• Database Server 數(shù)據(jù)庫服務(wù)器
• Cron Job Scheduler 定時任務(wù)調(diào)度器

這些組件中的每一個都可以在不同的平臺上用不同的語言編寫。每個都可以使用 Sentry SDK 單獨(dú)檢測以捕獲錯誤數(shù)據(jù)或崩潰報告，但該檢測不能提供完整的圖片，因為每個部分都是單獨(dú)考慮的。跟蹤允許您將所有數(shù)據(jù)聯(lián)系在一起。

在我們的示例 Web 應(yīng)用程序中，跟蹤意味著能夠跟蹤從前端到后端和后端的請求，從請求創(chuàng)建的任何后臺任務(wù)(background tasks)或通知作業(yè)(notification jobs)中提取數(shù)據(jù)。這不僅可以讓您關(guān)聯(lián) Sentry 錯誤報告，查看一個服務(wù)中的錯誤如何傳播到另一個服務(wù)，而且還可以讓您更深入地了解哪些服務(wù)可能對應(yīng)用程序的整體性能產(chǎn)生負(fù)面影響。

在學(xué)習(xí)如何在您的應(yīng)用程序中啟用跟蹤之前，了解一些關(guān)鍵術(shù)語以及它們之間的關(guān)系會有所幫助。

跟蹤(Traces)、事務(wù)(Transactions和跨度(Spans)

trace 表示您要測量或跟蹤的整個操作的記錄 - 例如頁面加載、用戶在應(yīng)用程序中完成某些操作的實例或后端的 cron job。當(dāng)跟蹤包括多個服務(wù)中的工作時，例如上面列出的服務(wù)，它被稱為分布式跟蹤，因為跟蹤分布在這些服務(wù)中。

每個 trace 由一個或多個稱為 transactions 的樹狀結(jié)構(gòu)組成，其節(jié)點(diǎn)稱為 spans。在大多數(shù)情況下，每個 transaction 代表被調(diào)用服務(wù)的單個實例，并且該 transaction 中的每個 span 代表該服務(wù)執(zhí)行單個工作單元，無論是調(diào)用該服務(wù)中的函數(shù)還是調(diào)用不同的服務(wù)。這是一個示例跟蹤，分解為事務(wù)(transactions)和跨度(spans)：

由于事務(wù)(transaction)具有樹結(jié)構(gòu)，因此頂級跨度(top-level spans)本身可以分解為更小的跨度(smaller spans)，這反映了一個函數(shù)可能調(diào)用許多其他更小的函數(shù)的方式;這是使用父子隱喻來表達(dá)的，因此每個跨度都可能是多個其他子跨度的父跨度。此外，由于所有樹都必須有一個根，因此每個事務(wù)中的一個跨度始終代表事務(wù)本身，而事務(wù)中的所有其他跨度都從該根跨度下降。這是上圖中事務(wù)之一的放大視圖：

為了使所有這些更具體，讓我們再次考慮我們的示例 Web 應(yīng)用程序。

示例：調(diào)查緩慢的頁面加載

假設(shè)您的 Web 應(yīng)用程序加載緩慢，您想知道原因。要使您的應(yīng)用程序首先進(jìn)入可用狀態(tài)，必須發(fā)生很多事情：對后端的多個請求，可能是一些工作 - 包括對數(shù)據(jù)庫或外部 API 的調(diào)用 - 在返回響應(yīng)之前完成，并由瀏覽器處理以呈現(xiàn)所有 將返回的數(shù)據(jù)轉(zhuǎn)化為對用戶有意義的內(nèi)容。那么這個過程的哪一部分會減慢速度?

假設(shè)在這個簡化的示例中，當(dāng)用戶在瀏覽器中加載應(yīng)用程序時，每個服務(wù)中都會發(fā)生以下情況：

• Browser(瀏覽器)
  • HTML、CSS 和 JavaScript 各 1 個請求
  • 1 次渲染任務(wù)，觸發(fā) 2 次 JSON 數(shù)據(jù)請求 ^
• Backend(后端)
  • 3 個提供靜態(tài)文件(HTML、CSS 和 JS)的請求
  • 2 個 JSON 數(shù)據(jù)請求 - 1 個需要調(diào)用數(shù)據(jù)庫 - 1 個需要調(diào)用外部 API 并在將結(jié)果返回到前端之前處理結(jié)果^
• Database Server(數(shù)據(jù)庫服務(wù)器)
  • 1 查詢以檢查身份驗證
  • 1 查詢獲取數(shù)據(jù)
  • 1 個請求需要 2 次查詢

注意：外部 API 并未準(zhǔn)確列出，因為它是外部的，因此您看不到它的內(nèi)部。

在此示例中，整個頁面加載過程(包括上述所有過程)由單個 trace 表示。該跟蹤將由以下事務(wù)(transactions)組成：

• 1 個瀏覽器事務(wù)(用于頁面加載)
• 5 個后端事務(wù)(每個請求一個)
• 1 個數(shù)據(jù)庫服務(wù)器事務(wù)(用于單個 DB 請求)

每個事務(wù)將被分解為跨度(spans)如下：

• 瀏覽器頁面加載事務(wù)：7 個 span
  • 2 個子 span，每個 JSON 請求一個
  • 1 個根 span 代表整個頁面加載
  • HTML、CSS 和 JS 請求各 1 個(共 3 個)
  • 渲染任務(wù)的 1 個 span，它本身包含

讓我們在這里暫停一下以說明一個重點(diǎn)：此處列出的瀏覽器事務(wù)中的一些(盡管不是全部)跨度與前面列出的后端事務(wù)有直接對應(yīng)關(guān)系。具體來說，瀏覽器事務(wù)中的每個請求跨度對應(yīng)于后端中的一個單獨(dú)的請求事務(wù)。在這種情況下，當(dāng)一個服務(wù)中的跨度引起后續(xù)服務(wù)中的事務(wù)時，我們將原始跨度稱為事務(wù)及其根跨度的父跨度。在下圖中，波浪線代表這種父子關(guān)系。

在我們的示例中，除了初始瀏覽器頁面加載事務(wù)之外的每個事務(wù)都是另一個服務(wù)中一個跨度的子項，這意味著除了瀏覽器事務(wù)根之外的每個根跨度都有一個父跨度(盡管在不同的服務(wù)中)。

在 fully-instrumented 的系統(tǒng)(其中每個服務(wù)都啟用了跟蹤的系統(tǒng))中，這種模式將始終適用。唯一的無父 span 將是初始 transaction 的根;每隔一個 span 都會有一個父級。此外，parents 和 children 將始終生活在同一個服務(wù)中，除非在子 span 是子 transaction 的根的情況下，在這種情況下，父 span 將在調(diào)用服務(wù)中，而子 transaction/child 根 span 將在被調(diào)用服務(wù)中。

換句話說，一個 fully-instrumented 的系統(tǒng)創(chuàng)建一個跟蹤，它本身就是一個連接的樹——每個事務(wù)都是一個子樹——在這棵樹中，子樹/事務(wù)之間的邊界正是服務(wù)之間的邊界。上圖顯示了我們示例的完整跟蹤樹的一個分支。

現(xiàn)在，為了完整起見，回到我們的 spans：

• 后端 HTML/CSS/JS 請求事務(wù)：每個 1 個 span
  • 代表整個請求的 1 個根跨度(瀏覽器跨度的子項)^
• 帶有數(shù)據(jù)庫調(diào)用事務(wù)的后端請求：2 個 span
  • 1 個表示整個請求的根跨度(瀏覽器跨度的子項)
  • 1 個跨度用于查詢數(shù)據(jù)庫(數(shù)據(jù)庫服務(wù)器事務(wù)的父級)^
• 帶有 API 調(diào)用事務(wù)的后端請求：3 個 span
  • 1 個表示整個請求的根跨度(瀏覽器跨度的子項)
  • API 請求的 1 個跨度(與數(shù)據(jù)庫調(diào)用不同，不是父跨度，因為 API 是外部的)
  • 1 個跨度用于處理 API 數(shù)據(jù)^
• 數(shù)據(jù)庫服務(wù)器請求事務(wù)：3 個 span
  • 1 個代表整個請求的根跨度(上面后端跨度的子項)
  • 1 跨度用于身份驗證查詢
  • 1 個跨度用于查詢檢索數(shù)據(jù)的

總結(jié)一下這個例子：在檢測了所有服務(wù)之后，您可能會發(fā)現(xiàn)——出于某種原因——是數(shù)據(jù)庫服務(wù)器中的身份驗證查詢(auth query)導(dǎo)致了速度變慢，占了完成整個頁面加載過程所需時間的一半以上。跟蹤無法告訴你為什么會發(fā)生這種情況，但至少現(xiàn)在你知道該去哪里找了!

更多示例

本節(jié)包含更多跟蹤示例，分為事務(wù)(transaction)和跨度(span)。

衡量特定的用戶動作

如果您的應(yīng)用程序涉及電子商務(wù)，您可能希望測量從用戶單擊“提交訂單(Submit Order)”到訂單確認(rèn)出現(xiàn)之間的時間，包括跟蹤向支付處理器提交費(fèi)用和發(fā)送訂單確認(rèn)電子郵件。整個過程是一個跟蹤，通常您會有事務(wù) (T) 和跨度 (S) 用于：

• 瀏覽器全過程(T 和根跨度 S)
  • 對后端的 XHR 請求* (S)
  • 渲染確認(rèn) screen(S)^
• 您的后端對該請求的處理(T 和根跨度 S)
  • 計算總數(shù)的函數(shù)(Function)調(diào)用 (S)
  • 存儲訂單數(shù)據(jù)庫(DB)調(diào)用* (S)
  • 對支付處理器的 API 調(diào)用 (S)
  • 電子郵件確認(rèn)排隊* (S) ^
• 您的數(shù)據(jù)庫更新客戶訂單歷史的工作(T 和根跨度 S)
  • 單個 SQL 查詢 (S) ^
• 發(fā)送電子郵件的排隊任務(wù)(T 和根跨度 S)
  • 用于填充電子郵件模板的函數(shù)調(diào)用 (S)
  • 對電子郵件發(fā)送服務(wù)的 API 調(diào)用 (S)

注意：帶星號的跨度表示作為后續(xù)事務(wù)(及其根跨度)的父跨度。

監(jiān)控后臺進(jìn)程

如果您的后端定期輪詢外部服務(wù)的數(shù)據(jù)，對其進(jìn)行處理、緩存，然后將其轉(zhuǎn)發(fā)給內(nèi)部服務(wù)，則發(fā)生這種情況的每個實例都是一個跟蹤，您通常會有以下事務(wù) (T) 和跨度 (S)：

• 完成整個過程的 cron job(T 和根跨度 S)
  • API 調(diào)用外部服務(wù) (S)
  • Processing 函數(shù) (S)
  • 調(diào)用緩存服務(wù)* (S)
  • API 調(diào)用內(nèi)部服務(wù)* (S) ^
• 在您的緩存服務(wù)中完成的工作(T 和根跨度 S)
  • 檢查現(xiàn)有數(shù)據(jù)的緩存 (S)
  • 在緩存中存儲新數(shù)據(jù) (S) ^
• 您的內(nèi)部服務(wù)對請求的處理(T 和根跨度 S)
  • 服務(wù)可能為處理請求而做的任何事情 (S)

注意：帶星號的跨度表示作為后續(xù)事務(wù)(及其根跨度)的父跨度。

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

“給我看你的流程圖而隱藏你的表，我仍然莫名其妙。如果給我看你的表，那么我將不再需要你的流程圖，因為它們太明顯了?！?/p>

Fred Brooks, 《The Mythical Man-Month》(人月神話)

雖然這個理論很有趣，但最終任何數(shù)據(jù)結(jié)構(gòu)都是由它包含的數(shù)據(jù)類型定義的，數(shù)據(jù)結(jié)構(gòu)之間的關(guān)系由它們之間的鏈接如何記錄來定義。跟蹤、事務(wù)和跨度也不例外。

Traces(跟蹤)

Traces 本身并不是一個實體。相反，跟蹤被定義為共享一個 trace_id 值的所有事務(wù)的集合。

Transactions(事務(wù))

Transactions 與其根跨度共享其大部分屬性(開始和結(jié)束時間、標(biāo)簽等)，因此下面描述的跨度的相同選項在事務(wù)中可用，并且在任一位置設(shè)置它們是等效的。

Transactions 還有一個不包含在跨度中的附加屬性，稱為 transaction_name，它在 UI 中用于標(biāo)識 transaction。transaction_name 值的常見示例包括后端請求事務(wù)的端點(diǎn)路徑(如 /store/checkout/ 或 api/v2/users/ /)、cron job 事務(wù)的任務(wù)名稱(如 data.cleanup.delete_inactive_users)和 URL( 像 https://docs.sentry.io/performance-monitoring/distributed-tracing/) 用于頁面加載事務(wù)。

Spans(跨度)

transaction 中的大部分?jǐn)?shù)據(jù)駐留在事務(wù)包含的單個 span 中。span 數(shù)據(jù)包括：

• parent_span_id: 將 span 與其父 span 聯(lián)系起來
• op: 標(biāo)識跨度正在測量的操作類型或類別的短字符串
• start_timestamp: span 打開時
• end_timestamp: span 關(guān)閉時
• description: span 操作的較長描述，唯一標(biāo)識 span，但跨 span 實例保持一致(可選)
• status: 指示操作狀態(tài)的短 code(可選)
• tags: key-value 對保存有關(guān)跨度的附加數(shù)據(jù)(可選)
• data: 關(guān)于 span 的任意結(jié)構(gòu)的附加數(shù)據(jù)(可選)

op 和 description 屬性一起使用的示例是 op: sql.query 和 description: SELECT * FROM users WHERE last_active < %s。 status 屬性通常用于指示 span 操作的成功或失敗，或者在 HTTP 請求的情況下用于 response code。最后，tags 和 data 允許您將更多上下文信息附加到 span，例如 function: middleware.auth.is_authenticated 用于函數(shù)調(diào)用或 request: {url: ..., headers: ... , body: ...} 用于 HTTP 請求。

更多信息

關(guān)于跟蹤、事務(wù)和跨度以及它們相互關(guān)聯(lián)的方式的一些更重要的點(diǎn)：

Trace Duration(跟蹤持續(xù)時間)

因為 trace 只是 transaction 的集合，所以 trace 沒有自己的開始和結(jié)束時間。相反，trace 在其最早的 transaction 開始時開始，并在其最新的 transaction 結(jié)束時結(jié)束。因此，您無法直接明確地開始或結(jié)束 trace。相反，您通過在該 trace 中創(chuàng)建第一個 transaction 來創(chuàng)建 trace，并通過完成它包含的所有 transaction 來完成 trace。

Async Transactions(異步事務(wù))

由于異步進(jìn)程的可能性，子事務(wù)(child transaction)可能比包含其父跨度(parent span)的事務(wù)的壽命長很多數(shù)量級。例如，如果后端 API 調(diào)用啟動了一個長時間運(yùn)行的處理任務(wù)，然后立即返回響應(yīng)，則后端事務(wù)將在異步任務(wù)事務(wù)完成之前很久完成(并且其數(shù)據(jù)將被發(fā)送到 Sentry)。異步性還意味著 transaction 發(fā)送到(和接收)Sentry 的順序與創(chuàng)建它們的順序沒有任何關(guān)系。(相比之下，同一 trace 中 transaction 的接收順序與完成順序相關(guān)，但由于傳輸時間的可變性等因素，相關(guān)性遠(yuǎn)非完美。)

Orphan Transactions(孤兒事務(wù))

理論上，在一個 fully instrumented 的系統(tǒng)中，每個 trace 應(yīng)該只包含一個 transaction 和一個 span(transaction的根)，沒有父項，即原始服務(wù)中的 transaction。但是，在實踐中，您可能不會在每一項服務(wù)中都啟用 trace，或者檢測的服務(wù)可能由于網(wǎng)絡(luò)中斷或其他不可預(yù)見的情況而無法報告 transaction。發(fā)生這種情況時，您可能會在跟蹤層次結(jié)構(gòu)中看到間隙。具體來說，您可能會在 span 的中途看到其父 span 尚未記錄為任何已知 transaction 的一部分的 transaction。這種非發(fā)起、無父 transaction 被稱為孤兒事務(wù)。

Nested Spans(嵌套跨度)

盡管我們上面的示例在其層次結(jié)構(gòu)中有四個級別(跟蹤trace、事務(wù)transaction、跨度span、子跨度child span)，但跨度嵌套的深度沒有設(shè)置限制。但是，存在實際限制：發(fā)送到 Sentry 的事務(wù)有效負(fù)載具有最大允許大小，并且與任何類型的日志記錄一樣，需要在數(shù)據(jù)的粒度與其可用性之間取得平衡。

Zero-duration Spans(零持續(xù)時間跨度)

跨度可能具有相同的開始時間和結(jié)束時間，因此被記錄為不占用時間。這可能是因為 span 被用作標(biāo)記(例如在瀏覽器的 Performance API 中完成的)，或者因為操作花費(fèi)的時間少于測量分辨率(這將因服務(wù)而異)。

https://developer.mozilla.org/en-US/docs/Web/API/Performance/mark

Clock Skew(時鐘偏移)

如果您從多臺機(jī)器收集 transaction，您可能會遇到 clock skew，其中一個 transaction 中的時間戳與另一個 transaction 中的時間戳不一致。例如，如果您的后端進(jìn)行數(shù)據(jù)庫調(diào)用，則后端事務(wù)在邏輯上應(yīng)該在數(shù)據(jù)庫事務(wù)之前開始。但是，如果每臺機(jī)器(分別托管后端和數(shù)據(jù)庫的機(jī)器)上的系統(tǒng)時間未同步到通用標(biāo)準(zhǔn)，則情況可能并非如此。排序也有可能是正確的，但是兩個記錄的時間范圍沒有以準(zhǔn)確反映實際發(fā)生的方式排列。為了減少這種可能性，我們建議使用網(wǎng)絡(luò)時間協(xié)議 (NTP) 或您的云提供商的時鐘同步服務(wù)。

如何發(fā)送數(shù)據(jù)

單個 span 不會發(fā)送到 Sentry;相反，整個 transaction 作為一個單位發(fā)送。這意味著 Sentry 的服務(wù)器不會記錄任何 span 數(shù)據(jù)，直到它們所屬的 transaction 被關(guān)閉和分派。然而，反過來就不是這樣了——盡管沒有 transaction 就不能發(fā)送 span，但 transaction 仍然有效，并且會被發(fā)送，即使它們包含的唯一 span 是它們的根 span。

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

當(dāng)您在跟蹤設(shè)置中啟用采樣時，您可以選擇要發(fā)送到 Sentry 的已收集交易的百分比。例如，如果您有一個每分鐘接收 1000 個請求的端點(diǎn)，0.25 的采樣率將導(dǎo)致每分鐘大約 250 個事務(wù) (25%) 被發(fā)送到 Sentry。(這個數(shù)字是近似的，因為每個請求要么被跟蹤，要么被獨(dú)立和偽隨機(jī)地跟蹤，概率為 25%。因此，以同樣的方式，100 個公平硬幣，在翻轉(zhuǎn)時會導(dǎo)致大約 50 個正面，SDK 將“決定” 在大約 250 個案例中收集跟蹤。)因為您知道采樣百分比，所以您可以推斷您的總流量。

在收集跟蹤時，我們建議對您的數(shù)據(jù)進(jìn)行采樣，原因有兩個。首先，雖然捕獲單個跟蹤的開銷最小，但捕獲每個頁面加載或每個 API 請求的跟蹤可能會給您的系統(tǒng)增加不希望的負(fù)載量。其次，啟用采樣可以讓您更好地管理發(fā)送到 Sentry 的事件數(shù)量，以便您可以根據(jù)組織的需求對其進(jìn)行定制。

選擇采樣率時，目標(biāo)是不要收集太多數(shù)據(jù)(鑒于上述原因)，而是收集足夠的數(shù)據(jù)，以便得出有意義的結(jié)論。如果您不確定要選擇什么速率，我們建議從一個較低的值開始，并隨著您對流量模式和流量的了解逐漸增加，直到找到一個速率，使您能夠平衡性能和流量與數(shù)據(jù)準(zhǔn)確性之間的關(guān)系。

跟蹤中的一致性

對于涉及多個事務(wù)的跟蹤，Sentry 使用 “基于頭部(head-based)” 的方法：在原始服務(wù)中做出采樣決策，然后將該決策傳遞給所有后續(xù)服務(wù)。要了解這是如何工作的，讓我們回到上面的 webapp示例?？紤]兩個用戶 A 和 B，他們都在各自的瀏覽器中加載應(yīng)用程序。當(dāng) A 加載應(yīng)用程序時，SDK 偽隨機(jī)“決定”收集跟蹤，而當(dāng) B 加載應(yīng)用程序時，SDK “決定”不收集跟蹤。當(dāng)每個瀏覽器向您的后端發(fā)出請求時，它會在這些請求的標(biāo)題中包含“yes, please collect transactions)”或“no, don't collect transactions this time”的決定。

當(dāng)您的后端處理來自 A 瀏覽器的請求時，它會看到 “yes” 的決定，收集事務(wù)和跨度數(shù)據(jù)，并將其發(fā)送給 Sentry。此外，它在向后續(xù)服務(wù)(如您的數(shù)據(jù)庫服務(wù)器)發(fā)出的任何請求中都包含“yes”決定，這些服務(wù)同樣會收集數(shù)據(jù)，將數(shù)據(jù)發(fā)送給 Sentry，并將決定傳遞給它們調(diào)用的任何服務(wù)。通過這個過程，A的跟蹤中的所有相關(guān)事務(wù)都被收集并發(fā)送到 Sentry。

另一方面，當(dāng)您的后端處理來自 B 瀏覽器的請求時，它會看到 “no” 決定，因此它不會收集和發(fā)送事務(wù)和跨度數(shù)據(jù)到 Sentry。然而，它在將決策傳播到后續(xù)服務(wù)方面做與在 A 的情況下所做的相同的事情，告訴他們也不要收集或發(fā)送數(shù)據(jù)。然后他們又告訴他們調(diào)用的任何服務(wù)不要發(fā)送數(shù)據(jù)，這樣就不會收集到來自 B 跟蹤的事務(wù)。

簡而言之：這種 head-based 的方法的結(jié)果是，決策在原始服務(wù)中作出一次，并傳遞給所有后續(xù)服務(wù)，要么收集給定跟蹤的所有事務(wù)，要么不收集任何事務(wù)，因此不應(yīng)存在任何不完整的跟蹤。

名稱欄目：Sentry 監(jiān)控 - Distributed Tracing 分布式跟蹤
標(biāo)題來源：http://m.5511xx.com/article/cohojcj.html