Sentry 監(jiān)控 - Distributed Tracing 分布式跟蹤
本文轉(zhuǎn)載自微信公眾號(hào)「黑客下午茶」，作者為少。轉(zhuǎn)載本文請(qǐng)聯(lián)系黑客下午茶公眾號(hào)。
目錄
- 什么是跟蹤?
- 為什么要跟蹤?
- 跟蹤(Traces)、事務(wù)(Transactions和跨度(Spans)
- 示例：調(diào)查緩慢的頁(yè)面加載
- 更多示例
- 跟蹤數(shù)據(jù)模型
- 更多信息
- 數(shù)據(jù)采樣
- 跟蹤中的一致性
分布式跟蹤(Distributed tracing)通過(guò)捕獲軟件系統(tǒng)之間的交互來(lái)提供相關(guān)錯(cuò)誤和事務(wù)的連接視圖。通過(guò)跟蹤，Sentry 可以跟蹤您的軟件性能并顯示跨多個(gè)系統(tǒng)的錯(cuò)誤影響。通過(guò)服務(wù)追溯問(wèn)題將您的前端連接到您的后端。
- https://docs.sentry.io/product/sentry-basics/tracing/distributed-tracing/
啟用性能監(jiān)控以擴(kuò)充您現(xiàn)有的錯(cuò)誤數(shù)據(jù)，跟蹤從前端到后端的交互。通過(guò)跟蹤，Sentry 可以跟蹤您的軟件性能，測(cè)量吞吐量和延遲等指標(biāo)，并顯示跨多個(gè)系統(tǒng)的錯(cuò)誤影響。跟蹤使 Sentry 成為更完整的監(jiān)控解決方案，幫助您更快地診斷問(wèn)題并衡量應(yīng)用程序的整體健康狀況。Sentry 中的跟蹤提供了以下見(jiàn)解：
- 特定錯(cuò)誤事件或 issue 發(fā)生了什么
- 導(dǎo)致應(yīng)用程序出現(xiàn)瓶頸或延遲 issue 的條件
- 消耗時(shí)間最多的端點(diǎn)或操作
什么是跟蹤?
首先，請(qǐng)注意跟蹤不是什么：跟蹤不是分析。盡管分析和跟蹤的目標(biāo)有相當(dāng)多的重疊，雖然它們都可用于診斷應(yīng)用程序中的問(wèn)題，但它們?cè)跍y(cè)量?jī)?nèi)容和數(shù)據(jù)記錄方式方面有所不同。
profiler 可以測(cè)量應(yīng)用程序操作的多個(gè)方面：執(zhí)行的指令數(shù)、各種進(jìn)程使用的內(nèi)存量、給定函數(shù)調(diào)用所花費(fèi)的時(shí)間量等等。生成的 profile 是這些測(cè)量值的統(tǒng)計(jì)匯總。
- https://en.wikipedia.org/wiki/Profiling_(computer_programming)
另一方面，tracing tool 關(guān)注發(fā)生了什么(以及何時(shí))，而不是發(fā)生了多少次或花費(fèi)了多長(zhǎng)時(shí)間。結(jié)果跟蹤(resulting trace)是在程序執(zhí)行期間發(fā)生的事件日志，通?？缍鄠€(gè)系統(tǒng)。盡管跟蹤最常見(jiàn) - 或者，就 Sentry 的跟蹤而言，總是 - 包括時(shí)間戳(timestamps)，允許計(jì)算持續(xù)時(shí)間，但測(cè)量性能并不是它們的唯一目的。它們還可以顯示互連系統(tǒng)交互的方式，以及一個(gè)系統(tǒng)中的問(wèn)題可能導(dǎo)致另一個(gè)系統(tǒng)出現(xiàn)問(wèn)題的方式。
- https://en.wikipedia.org/wiki/Tracing_(software)
為什么要跟蹤?
應(yīng)用程序通常由互連的組件組成，這些組件也稱為服務(wù)。作為一個(gè)例子，讓我們看一個(gè)現(xiàn)代 Web 應(yīng)用程序，它由以下組件組成，由網(wǎng)絡(luò)邊界分隔：
- Frontend (Single-Page Application) 前端
- Backend (REST API) 后端
- Task Queue 任務(wù)隊(duì)列
- Database Server 數(shù)據(jù)庫(kù)服務(wù)器
- Cron Job Scheduler 定時(shí)任務(wù)調(diào)度器
這些組件中的每一個(gè)都可以在不同的平臺(tái)上用不同的語(yǔ)言編寫(xiě)。每個(gè)都可以使用 Sentry SDK 單獨(dú)檢測(cè)以捕獲錯(cuò)誤數(shù)據(jù)或崩潰報(bào)告，但該檢測(cè)不能提供完整的圖片，因?yàn)槊總€(gè)部分都是單獨(dú)考慮的。跟蹤允許您將所有數(shù)據(jù)聯(lián)系在一起。
在我們的示例 Web 應(yīng)用程序中，跟蹤意味著能夠跟蹤從前端到后端和后端的請(qǐng)求，從請(qǐng)求創(chuàng)建的任何后臺(tái)任務(wù)(background tasks)或通知作業(yè)(notification jobs)中提取數(shù)據(jù)。這不僅可以讓您關(guān)聯(lián) Sentry 錯(cuò)誤報(bào)告，查看一個(gè)服務(wù)中的錯(cuò)誤如何傳播到另一個(gè)服務(wù)，而且還可以讓您更深入地了解哪些服務(wù)可能對(duì)應(yīng)用程序的整體性能產(chǎn)生負(fù)面影響。
在學(xué)習(xí)如何在您的應(yīng)用程序中啟用跟蹤之前，了解一些關(guān)鍵術(shù)語(yǔ)以及它們之間的關(guān)系會(huì)有所幫助。
跟蹤(Traces)、事務(wù)(Transactions和跨度(Spans)
trace 表示您要測(cè)量或跟蹤的整個(gè)操作的記錄 - 例如頁(yè)面加載、用戶在應(yīng)用程序中完成某些操作的實(shí)例或后端的 cron job。當(dāng)跟蹤包括多個(gè)服務(wù)中的工作時(shí)，例如上面列出的服務(wù)，它被稱為分布式跟蹤，因?yàn)楦櫡植荚谶@些服務(wù)中。
每個(gè) trace 由一個(gè)或多個(gè)稱為 transactions 的樹(shù)狀結(jié)構(gòu)組成，其節(jié)點(diǎn)稱為 spans。在大多數(shù)情況下，每個(gè) transaction 代表被調(diào)用服務(wù)的單個(gè)實(shí)例，并且該 transaction 中的每個(gè) span 代表該服務(wù)執(zhí)行單個(gè)工作單元，無(wú)論是調(diào)用該服務(wù)中的函數(shù)還是調(diào)用不同的服務(wù)。這是一個(gè)示例跟蹤，分解為事務(wù)(transactions)和跨度(spans)：
由于事務(wù)(transaction)具有樹(shù)結(jié)構(gòu)，因此頂級(jí)跨度(top-level spans)本身可以分解為更小的跨度(smaller spans)，這反映了一個(gè)函數(shù)可能調(diào)用許多其他更小的函數(shù)的方式;這是使用父子隱喻來(lái)表達(dá)的，因此每個(gè)跨度都可能是多個(gè)其他子跨度的父跨度。此外，由于所有樹(shù)都必須有一個(gè)根，因此每個(gè)事務(wù)中的一個(gè)跨度始終代表事務(wù)本身，而事務(wù)中的所有其他跨度都從該根跨度下降。這是上圖中事務(wù)之一的放大視圖：
為了使所有這些更具體，讓我們?cè)俅慰紤]我們的示例 Web 應(yīng)用程序。
示例：調(diào)查緩慢的頁(yè)面加載
假設(shè)您的 Web 應(yīng)用程序加載緩慢，您想知道原因。要使您的應(yīng)用程序首先進(jìn)入可用狀態(tài)，必須發(fā)生很多事情：對(duì)后端的多個(gè)請(qǐng)求，可能是一些工作 - 包括對(duì)數(shù)據(jù)庫(kù)或外部 API 的調(diào)用 - 在返回響應(yīng)之前完成，并由瀏覽器處理以呈現(xiàn)所有 將返回的數(shù)據(jù)轉(zhuǎn)化為對(duì)用戶有意義的內(nèi)容。那么這個(gè)過(guò)程的哪一部分會(huì)減慢速度?
假設(shè)在這個(gè)簡(jiǎn)化的示例中，當(dāng)用戶在瀏覽器中加載應(yīng)用程序時(shí)，每個(gè)服務(wù)中都會(huì)發(fā)生以下情況：
- Browser(瀏覽器)
- HTML、CSS 和 JavaScript 各 1 個(gè)請(qǐng)求
- 1 次渲染任務(wù)，觸發(fā) 2 次 JSON 數(shù)據(jù)請(qǐng)求 ^
- Backend(后端)
- 3 個(gè)提供靜態(tài)文件(HTML、CSS 和 JS)的請(qǐng)求
- 2 個(gè) JSON 數(shù)據(jù)請(qǐng)求 - 1 個(gè)需要調(diào)用數(shù)據(jù)庫(kù) - 1 個(gè)需要調(diào)用外部 API 并在將結(jié)果返回到前端之前處理結(jié)果^
- Database Server(數(shù)據(jù)庫(kù)服務(wù)器)
- 1 查詢以檢查身份驗(yàn)證
- 1 查詢獲取數(shù)據(jù)
- 1 個(gè)請(qǐng)求需要 2 次查詢
注意：外部 API 并未準(zhǔn)確列出，因?yàn)樗峭獠康?，因此您看不到它的?nèi)部。
在此示例中，整個(gè)頁(yè)面加載過(guò)程(包括上述所有過(guò)程)由單個(gè) trace 表示。該跟蹤將由以下事務(wù)(transactions)組成：
- 1 個(gè)瀏覽器事務(wù)(用于頁(yè)面加載)
- 5 個(gè)后端事務(wù)(每個(gè)請(qǐng)求一個(gè))
- 1 個(gè)數(shù)據(jù)庫(kù)服務(wù)器事務(wù)(用于單個(gè) DB 請(qǐng)求)
每個(gè)事務(wù)將被分解為跨度(spans)如下：
- 瀏覽器頁(yè)面加載事務(wù)：7 個(gè) span
- 2 個(gè)子 span，每個(gè) JSON 請(qǐng)求一個(gè)
- 1 個(gè)根 span 代表整個(gè)頁(yè)面加載
- HTML、CSS 和 JS 請(qǐng)求各 1 個(gè)(共 3 個(gè))
- 渲染任務(wù)的 1 個(gè) span，它本身包含
讓我們?cè)谶@里暫停一下以說(shuō)明一個(gè)重點(diǎn)：此處列出的瀏覽器事務(wù)中的一些(盡管不是全部)跨度與前面列出的后端事務(wù)有直接對(duì)應(yīng)關(guān)系。具體來(lái)說(shuō)，瀏覽器事務(wù)中的每個(gè)請(qǐng)求跨度對(duì)應(yīng)于后端中的一個(gè)單獨(dú)的請(qǐng)求事務(wù)。在這種情況下，當(dāng)一個(gè)服務(wù)中的跨度引起后續(xù)服務(wù)中的事務(wù)時(shí)，我們將原始跨度稱為事務(wù)及其根跨度的父跨度。在下圖中，波浪線代表這種父子關(guān)系。
在我們的示例中，除了初始瀏覽器頁(yè)面加載事務(wù)之外的每個(gè)事務(wù)都是另一個(gè)服務(wù)中一個(gè)跨度的子項(xiàng)，這意味著除了瀏覽器事務(wù)根之外的每個(gè)根跨度都有一個(gè)父跨度(盡管在不同的服務(wù)中)。
在 fully-instrumented 的系統(tǒng)(其中每個(gè)服務(wù)都啟用了跟蹤的系統(tǒng))中，這種模式將始終適用。唯一的無(wú)父 span 將是初始 transaction 的根;每隔一個(gè) span 都會(huì)有一個(gè)父級(jí)。此外，parents 和 children 將始終生活在同一個(gè)服務(wù)中，除非在子 span 是子 transaction 的根的情況下，在這種情況下，父 span 將在調(diào)用服務(wù)中，而子 transaction/child 根 span 將在被調(diào)用服務(wù)中。
換句話說(shuō)，一個(gè) fully-instrumented 的系統(tǒng)創(chuàng)建一個(gè)跟蹤，它本身就是一個(gè)連接的樹(shù)——每個(gè)事務(wù)都是一個(gè)子樹(shù)——在這棵樹(shù)中，子樹(shù)/事務(wù)之間的邊界正是服務(wù)之間的邊界。上圖顯示了我們示例的完整跟蹤樹(shù)的一個(gè)分支。
現(xiàn)在，為了完整起見(jiàn)，回到我們的 spans：
- 后端 HTML/CSS/JS 請(qǐng)求事務(wù)：每個(gè) 1 個(gè) span
- 代表整個(gè)請(qǐng)求的 1 個(gè)根跨度(瀏覽器跨度的子項(xiàng))^
- 帶有數(shù)據(jù)庫(kù)調(diào)用事務(wù)的后端請(qǐng)求：2 個(gè) span
- 1 個(gè)表示整個(gè)請(qǐng)求的根跨度(瀏覽器跨度的子項(xiàng))
- 1 個(gè)跨度用于查詢數(shù)據(jù)庫(kù)(數(shù)據(jù)庫(kù)服務(wù)器事務(wù)的父級(jí))^
- 帶有 API 調(diào)用事務(wù)的后端請(qǐng)求：3 個(gè) span
- 1 個(gè)表示整個(gè)請(qǐng)求的根跨度(瀏覽器跨度的子項(xiàng))
- API 請(qǐng)求的 1 個(gè)跨度(與數(shù)據(jù)庫(kù)調(diào)用不同，不是父跨度，因?yàn)?API 是外部的)
- 1 個(gè)跨度用于處理 API 數(shù)據(jù)^
- 數(shù)據(jù)庫(kù)服務(wù)器請(qǐng)求事務(wù)：3 個(gè) span
- 1 個(gè)代表整個(gè)請(qǐng)求的根跨度(上面后端跨度的子項(xiàng))
- 1 跨度用于身份驗(yàn)證查詢
- 1 個(gè)跨度用于查詢檢索數(shù)據(jù)的
總結(jié)一下這個(gè)例子：在檢測(cè)了所有服務(wù)之后，您可能會(huì)發(fā)現(xiàn)——出于某種原因——是數(shù)據(jù)庫(kù)服務(wù)器中的身份驗(yàn)證查詢(auth query)導(dǎo)致了速度變慢，占了完成整個(gè)頁(yè)面加載過(guò)程所需時(shí)間的一半以上。跟蹤無(wú)法告訴你為什么會(huì)發(fā)生這種情況，但至少現(xiàn)在你知道該去哪里找了!
更多示例
本節(jié)包含更多跟蹤示例，分為事務(wù)(transaction)和跨度(span)。
衡量特定的用戶動(dòng)作
如果您的應(yīng)用程序涉及電子商務(wù)，您可能希望測(cè)量從用戶單擊“提交訂單(Submit Order)”到訂單確認(rèn)出現(xiàn)之間的時(shí)間，包括跟蹤向支付處理器提交費(fèi)用和發(fā)送訂單確認(rèn)電子郵件。整個(gè)過(guò)程是一個(gè)跟蹤，通常您會(huì)有事務(wù) (T) 和跨度 (S) 用于：
- 瀏覽器全過(guò)程(T 和根跨度 S)
- 對(duì)后端的 XHR 請(qǐng)求* (S)
- 渲染確認(rèn) screen(S)^
- 您的后端對(duì)該請(qǐng)求的處理(T 和根跨度 S)
- 計(jì)算總數(shù)的函數(shù)(Function)調(diào)用 (S)
- 存儲(chǔ)訂單數(shù)據(jù)庫(kù)(DB)調(diào)用* (S)
- 對(duì)支付處理器的 API 調(diào)用 (S)
- 電子郵件確認(rèn)排隊(duì)* (S) ^
- 您的數(shù)據(jù)庫(kù)更新客戶訂單歷史的工作(T 和根跨度 S)
- 單個(gè) SQL 查詢 (S) ^
- 發(fā)送電子郵件的排隊(duì)任務(wù)(T 和根跨度 S)
- 用于填充電子郵件模板的函數(shù)調(diào)用 (S)
- 對(duì)電子郵件發(fā)送服務(wù)的 API 調(diào)用 (S)
注意：帶星號(hào)的跨度表示作為后續(xù)事務(wù)(及其根跨度)的父跨度。
監(jiān)控后臺(tái)進(jìn)程
如果您的后端定期輪詢外部服務(wù)的數(shù)據(jù)，對(duì)其進(jìn)行處理、緩存，然后將其轉(zhuǎn)發(fā)給內(nèi)部服務(wù)，則發(fā)生這種情況的每個(gè)實(shí)例都是一個(gè)跟蹤，您通常會(huì)有以下事務(wù) (T) 和跨度 (S)：
- 完成整個(gè)過(guò)程的 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)
- 在緩存中存儲(chǔ)新數(shù)據(jù) (S) ^
- 您的內(nèi)部服務(wù)對(duì)請(qǐng)求的處理(T 和根跨度 S)
- 服務(wù)可能為處理請(qǐng)求而做的任何事情 (S)
注意：帶星號(hào)的跨度表示作為后續(xù)事務(wù)(及其根跨度)的父跨度。
跟蹤數(shù)據(jù)模型
“給我看你的流程圖而隱藏你的表，我仍然莫名其妙。如果給我看你的表，那么我將不再需要你的流程圖，因?yàn)樗鼈兲黠@了。”
Fred Brooks, 《The Mythical Man-Month》(人月神話)
雖然這個(gè)理論很有趣，但最終任何數(shù)據(jù)結(jié)構(gòu)都是由它包含的數(shù)據(jù)類型定義的，數(shù)據(jù)結(jié)構(gòu)之間的關(guān)系由它們之間的鏈接如何記錄來(lái)定義。跟蹤、事務(wù)和跨度也不例外。
Traces(跟蹤)
Traces 本身并不是一個(gè)實(shí)體。相反，跟蹤被定義為共享一個(gè) trace_id 值的所有事務(wù)的集合。
Transactions(事務(wù))
Transactions 與其根跨度共享其大部分屬性(開(kāi)始和結(jié)束時(shí)間、標(biāo)簽等)，因此下面描述的跨度的相同選項(xiàng)在事務(wù)中可用，并且在任一位置設(shè)置它們是等效的。
Transactions 還有一個(gè)不包含在跨度中的附加屬性，稱為 transaction_name，它在 UI 中用于標(biāo)識(shí) transaction。transaction_name 值的常見(jiàn)示例包括后端請(qǐng)求事務(wù)的端點(diǎn)路徑(如 /store/checkout/ 或 api/v2/users/
Spans(跨度)
transaction 中的大部分?jǐn)?shù)據(jù)駐留在事務(wù)包含的單個(gè) span 中。span 數(shù)據(jù)包括：
- parent_span_id: 將 span 與其父 span 聯(lián)系起來(lái)
- op: 標(biāo)識(shí)跨度正在測(cè)量的操作類型或類別的短字符串
- start_timestamp: span 打開(kāi)時(shí)
- end_timestamp: span 關(guān)閉時(shí)
- description: span 操作的較長(zhǎng)描述，唯一標(biāo)識(shí) span，但跨 span 實(shí)例保持一致(可選)
- status: 指示操作狀態(tài)的短 code(可選)
- tags: key-value 對(duì)保存有關(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 請(qǐng)求的情況下用于 response code。最后，tags 和 data 允許您將更多上下文信息附加到 span，例如 function: middleware.auth.is_authenticated 用于函數(shù)調(diào)用或 request: {url: ..., headers: ... , body: ...} 用于 HTTP 請(qǐng)求。
更多信息
關(guān)于跟蹤、事務(wù)和跨度以及它們相互關(guān)聯(lián)的方式的一些更重要的點(diǎn)：
Trace Duration(跟蹤持續(xù)時(shí)間)
因?yàn)?trace 只是 transaction 的集合，所以 trace 沒(méi)有自己的開(kāi)始和結(jié)束時(shí)間。相反，trace 在其最早的 transaction 開(kāi)始時(shí)開(kāi)始，并在其最新的 transaction 結(jié)束時(shí)結(jié)束。因此，您無(wú)法直接明確地開(kāi)始或結(jié)束 trace。相反，您通過(guò)在該 trace 中創(chuàng)建第一個(gè) transaction 來(lái)創(chuàng)建 trace，并通過(guò)完成它包含的所有 transaction 來(lái)完成 trace。
Async Transactions(異步事務(wù))
由于異步進(jìn)程的可能性，子事務(wù)(child transaction)可能比包含其父跨度(parent span)的事務(wù)的壽命長(zhǎng)很多數(shù)量級(jí)。例如，如果后端 API 調(diào)用啟動(dòng)了一個(gè)長(zhǎng)時(shí)間運(yùn)行的處理任務(wù)，然后立即返回響應(yīng)，則后端事務(wù)將在異步任務(wù)事務(wù)完成之前很久完成(并且其數(shù)據(jù)將被發(fā)送到 Sentry)。異步性還意味著 transaction 發(fā)送到(和接收)Sentry 的順序與創(chuàng)建它們的順序沒(méi)有任何關(guān)系。(相比之下，同一 trace 中 transaction 的接收順序與完成順序相關(guān)，但由于傳輸時(shí)間的可變性等因素，相關(guān)性遠(yuǎn)非完美。)
Orphan Transactions(孤兒事務(wù))
理論上，在一個(gè) fully instrumented 的系統(tǒng)中，每個(gè) trace 應(yīng)該只包含一個(gè) transaction 和一個(gè) span(transaction的根)，沒(méi)有父項(xiàng)，即原始服務(wù)中的 transaction。但是，在實(shí)踐中，您可能不會(huì)在每一項(xiàng)服務(wù)中都啟用 trace，或者檢測(cè)的服務(wù)可能由于網(wǎng)絡(luò)中斷或其他不可預(yù)見(jiàn)的情況而無(wú)法報(bào)告 transaction。發(fā)生這種情況時(shí)，您可能會(huì)在跟蹤層次結(jié)構(gòu)中看到間隙。具體來(lái)說(shuō)，您可能會(huì)在 span 的中途看到其父 span 尚未記錄為任何已知 transaction 的一部分的 transaction。這種非發(fā)起、無(wú)父 transaction 被稱為孤兒事務(wù)。
Nested Spans(嵌套跨度)
盡管我們上面的示例在其層次結(jié)構(gòu)中有四個(gè)級(jí)別(跟蹤trace、事務(wù)transaction、跨度span、子跨度child span)，但跨度嵌套的深度沒(méi)有設(shè)置限制。但是，存在實(shí)際限制：發(fā)送到 Sentry 的事務(wù)有效負(fù)載具有最大允許大小，并且與任何類型的日志記錄一樣，需要在數(shù)據(jù)的粒度與其可用性之間取得平衡。
Zero-duration Spans(零持續(xù)時(shí)間跨度)
跨度可能具有相同的開(kāi)始時(shí)間和結(jié)束時(shí)間，因此被記錄為不占用時(shí)間。這可能是因?yàn)?span 被用作標(biāo)記(例如在瀏覽器的 Performance API 中完成的)，或者因?yàn)椴僮骰ㄙM(fèi)的時(shí)間少于測(cè)量分辨率(這將因服務(wù)而異)。
https://developer.mozilla.org/en-US/docs/Web/API/Performance/mark
Clock Skew(時(shí)鐘偏移)
如果您從多臺(tái)機(jī)器收集 transaction，您可能會(huì)遇到 clock skew，其中一個(gè) transaction 中的時(shí)間戳與另一個(gè) transaction 中的時(shí)間戳不一致。例如，如果您的后端進(jìn)行數(shù)據(jù)庫(kù)調(diào)用，則后端事務(wù)在邏輯上應(yīng)該在數(shù)據(jù)庫(kù)事務(wù)之前開(kāi)始。但是，如果每臺(tái)機(jī)器(分別托管后端和數(shù)據(jù)庫(kù)的機(jī)器)上的系統(tǒng)時(shí)間未同步到通用標(biāo)準(zhǔn)，則情況可能并非如此。排序也有可能是正確的，但是兩個(gè)記錄的時(shí)間范圍沒(méi)有以準(zhǔn)確反映實(shí)際發(fā)生的方式排列。為了減少這種可能性，我們建議使用網(wǎng)絡(luò)時(shí)間協(xié)議 (NTP) 或您的云提供商的時(shí)鐘同步服務(wù)。
如何發(fā)送數(shù)據(jù)
單個(gè) span 不會(huì)發(fā)送到 Sentry;相反，整個(gè) transaction 作為一個(gè)單位發(fā)送。這意味著 Sentry 的服務(wù)器不會(huì)記錄任何 span 數(shù)據(jù)，直到它們所屬的 transaction 被關(guān)閉和分派。然而，反過(guò)來(lái)就不是這樣了——盡管沒(méi)有 transaction 就不能發(fā)送 span，但 transaction 仍然有效，并且會(huì)被發(fā)送，即使它們包含的唯一 span 是它們的根 span。
數(shù)據(jù)采樣
當(dāng)您在跟蹤設(shè)置中啟用采樣時(shí)，您可以選擇要發(fā)送到 Sentry 的已收集交易的百分比。例如，如果您有一個(gè)每分鐘接收 1000 個(gè)請(qǐng)求的端點(diǎn)，0.25 的采樣率將導(dǎo)致每分鐘大約 250 個(gè)事務(wù) (25%) 被發(fā)送到 Sentry。(這個(gè)數(shù)字是近似的，因?yàn)槊總€(gè)請(qǐng)求要么被跟蹤，要么被獨(dú)立和偽隨機(jī)地跟蹤，概率為 25%。因此，以同樣的方式，100 個(gè)公平硬幣，在翻轉(zhuǎn)時(shí)會(huì)導(dǎo)致大約 50 個(gè)正面，SDK 將“決定” 在大約 250 個(gè)案例中收集跟蹤。)因?yàn)槟啦蓸影俜直?，所以您可以推斷您的總流量?/p>
在收集跟蹤時(shí)，我們建議對(duì)您的數(shù)據(jù)進(jìn)行采樣，原因有兩個(gè)。首先，雖然捕獲單個(gè)跟蹤的開(kāi)銷(xiāo)最小，但捕獲每個(gè)頁(yè)面加載或每個(gè) API 請(qǐng)求的跟蹤可能會(huì)給您的系統(tǒng)增加不希望的負(fù)載量。其次，啟用采樣可以讓您更好地管理發(fā)送到 Sentry 的事件數(shù)量，以便您可以根據(jù)組織的需求對(duì)其進(jìn)行定制。
選擇采樣率時(shí)，目標(biāo)是不要收集太多數(shù)據(jù)(鑒于上述原因)，而是收集足夠的數(shù)據(jù)，以便得出有意義的結(jié)論。如果您不確定要選擇什么速率，我們建議從一個(gè)較低的值開(kāi)始，并隨著您對(duì)流量模式和流量的了解逐漸增加，直到找到一個(gè)速率，使您能夠平衡性能和流量與數(shù)據(jù)準(zhǔn)確性之間的關(guān)系。
跟蹤中的一致性
對(duì)于涉及多個(gè)事務(wù)的跟蹤，Sentry 使用 “基于頭部(head-based)” 的方法：在原始服務(wù)中做出采樣決策，然后將該決策傳遞給所有后續(xù)服務(wù)。要了解這是如何工作的，讓我們回到上面的 webapp示例?？紤]兩個(gè)用戶 A 和 B，他們都在各自的瀏覽器中加載應(yīng)用程序。當(dāng) A 加載應(yīng)用程序時(shí)，SDK 偽隨機(jī)“決定”收集跟蹤，而當(dāng) B 加載應(yīng)用程序時(shí)，SDK “決定”不收集跟蹤。當(dāng)每個(gè)瀏覽器向您的后端發(fā)出請(qǐng)求時(shí)，它會(huì)在這些請(qǐng)求的標(biāo)題中包含“yes, please collect transactions)”或“no, don't collect transactions this time”的決定。
當(dāng)您的后端處理來(lái)自 A 瀏覽器的請(qǐng)求時(shí)，它會(huì)看到 “yes” 的決定，收集事務(wù)和跨度數(shù)據(jù)，并將其發(fā)送給 Sentry。此外，它在向后續(xù)服務(wù)(如您的數(shù)據(jù)庫(kù)服務(wù)器)發(fā)出的任何請(qǐng)求中都包含“yes”決定，這些服務(wù)同樣會(huì)收集數(shù)據(jù)，將數(shù)據(jù)發(fā)送給 Sentry，并將決定傳遞給它們調(diào)用的任何服務(wù)。通過(guò)這個(gè)過(guò)程，A的跟蹤中的所有相關(guān)事務(wù)都被收集并發(fā)送到 Sentry。
另一方面，當(dāng)您的后端處理來(lái)自 B 瀏覽器的請(qǐng)求時(shí)，它會(huì)看到 “no” 決定，因此它不會(huì)收集和發(fā)送事務(wù)和跨度數(shù)據(jù)到 Sentry。然而，它在將決策傳播到后續(xù)服務(wù)方面做與在 A 的情況下所做的相同的事情，告訴他們也不要收集或發(fā)送數(shù)據(jù)。然后他們又告訴他們調(diào)用的任何服務(wù)不要發(fā)送數(shù)據(jù)，這樣就不會(huì)收集到來(lái)自 B 跟蹤的事務(wù)。
簡(jiǎn)而言之：這種 head-based 的方法的結(jié)果是，決策在原始服務(wù)中作出一次，并傳遞給所有后續(xù)服務(wù)，要么收集給定跟蹤的所有事務(wù)，要么不收集任何事務(wù)，因此不應(yīng)存在任何不完整的跟蹤。
