什麼是分散式追蹤?

分散式追蹤是在資料請求在分散式系統中流動時加以觀察。現代微型服務架構通常具有多個小型獨立元件,這些元件不斷使用 API 通訊和交換資料,以執行複雜的工作。透過分散式追蹤,開發人員可以不同微型服務之間追蹤 (或以視覺方式追蹤) 請求路徑。這種可見性有助於疑難排解錯誤,或修復錯誤和效能問題。

分散式追蹤有哪些優點?

軟體開發人員可以在幾乎任何雲端原生環境中實作分散式追蹤系統,並記錄雲端應用程式產生的分散式追蹤。此外,追蹤工具支援多種程式設計語言和軟體堆疊,讓軟體團隊能夠在相同平台上監控和收集不同應用程式的效能資料。 

開發團隊使用分散式追蹤來改善可觀測性,並解決傳統軟體偵錯和監控工具無法解決的效能問題。 

以下是分散式追蹤的更多優點。

加速軟體疑難排解

現代應用程式依賴眾多微型服務,在分散式系統之間交換資料並滿足服務請求。針對以微型服務為基礎的架構中的效能問題進行疑難排解,比在整合型軟體應用程式中更具挑戰性。與整合型應用程式不同,特定軟體問題的根本原因可能不明顯,多個軟體模組之間的重疊和複雜互動會使診斷問題變得困難。 

透過分散式追蹤,軟體團隊可以監控通過連線各種微型服務和資料儲存之複雜路徑的資料。軟體團隊使用分散式追蹤工具,追蹤請求並精確地視覺化資料傳播路徑。軟體團隊可以迅速解決效能問題,並將服務中斷降至最低。 

改善開發人員協作

建置雲端應用程式通常會有多個開發人員參與,每個開發人員負責一或多個微型服務。如果開發人員無法跟踪微型服務交換的資料,軟體開發過程會變慢。透過分散式追蹤系統,開發人員可以藉由為微型服務提出的每個服務請求提供遙測資料 (例如日誌和追蹤) 來協作。開發人員可以準確回應測試和生產期間發現的錯誤和其他軟體問題。 

縮短上市時間

部署分散式追蹤平台的組織可以簡化並加速為最終使用者發佈軟體應用程式的努力。軟體團隊會檢閱分散式追蹤以獲得洞察,可加快軟體開發速度、將開發成本降至最低、了解使用者行為,並改善市場準備度。 

分散式追蹤有哪些不同的類型?

軟體團隊使用分散式追蹤工具來監控、分析和最佳化應用程式。

程式碼追蹤

程式碼追蹤是一種軟體程序,在執行特定功能時檢查應用程式中的原始程式碼流程。它可以協助開發人員了解程式碼的邏輯流程並識別未知問題。例如,開發人員使用程式碼追蹤來驗證服務請求是否已調用查詢資料庫的步驟。如果某些軟體功能無法回覆,追蹤系統會收集適當的錯誤狀態,並引起對回應時間的注意。 

程式追蹤

程式追蹤是一種方法,開發人員可以檢查由作用中應用程式呼叫之指示和變數的地址。當軟體應用程式執行時,它會處理位於特定分配記憶體空間中的每一行程式碼。應用程式也會處理儲存在機器記憶體中的變數。如果沒有自動化工具,檢查程式和資料記憶體中的變更會相當有挑戰性。透過程式追蹤,軟體團隊可以診斷深層的效能問題,例如記憶體溢位、資源消耗過量以及阻止邏輯操作。 

端對端追蹤

透過端對端追蹤,開發團隊可以沿著服務請求路徑追蹤資料轉換。當應用程式啟動請求時,它會將資料傳送到其他軟體元件以進一步處理。開發人員使用追蹤工具來追蹤和編譯關鍵資料從端到端所遭受的變更。它為通過應用程式的請求提供以應用程式為中心的檢視。

端對端分散式追蹤在微型服務架構中如何運作?

使用應用程式時,使用者會啟動服務請求,而不同的應用程式元件會處理請求。 

請考量使用者在線上電影預訂應用程式中預訂票證。使用者輸入其聯絡詳細資訊、電影詳細資訊和付款資訊,然後選擇立即預訂。系統會建立請求,前往:

  • 微型服務 A,驗證使用者輸入的資料。
  • 微型服務 B,從 A 取得資料並且在客戶資料庫中建立記錄。
  • 微型服務 C,從 B 取得資料並驗證付款。
  • 微型服務 D,從 C 取得資料、分配座位並產生電影票資料。
  • 微型服務 E,從 D 取得資料並建立格式化票證 PDF 文件。

然後將包含票證 PDF 的回應傳回給從 E 到 D 到 C 到 B 到 A 的微型服務鏈,直到最終送達使用者手上。上述範例很簡單,請求通常會通過數十個微型服務,甚至通過應用程式外部的第三方軟體元件鏈。這使得程序變得越來越複雜。

分散式追蹤系統可在分散式運算環境中追蹤服務請求與其他微型服務和軟體元件的這些互動。分散式追蹤代表時間表和請求產生與回應接收之間發生的所有動作。軟體團隊會使用追蹤,透過初始請求與其互動的多個微型服務追蹤資料移動。 

跨度

處理服務請求時,應用程式可能會採取數個動作。這些動作會在分散式追蹤中表示為跨度。例如,跨度可能是 API 呼叫、使用者驗證或啟用儲存存取權。如果單一請求導致數個動作,則初始 (或父系) 跨度可能分支為多個子跨度。這些巢狀的父子跨度層形成完成服務請求所採取步驟的連續邏輯表示。

追蹤 ID

分散式追蹤系統會為每個請求指派一個唯一的 ID 以便追蹤。每個跨度都會從其所屬的原始請求中繼承相同的追蹤 ID。跨度也會使用唯一的跨度 ID 標記,可協助追蹤系統合併其收集的中繼資料、日誌和指標。 

指標收集

當每個跨度通過不同的微型服務時,它會附加指標,為開發人員提供對軟體行為的深入且精確的洞察。您可以使用跨度收集錯誤率、時間戳記、回應時間和其他中繼資料。追蹤完成整個週期後,分散式追蹤工具會合併所收集的所有資料。 

例如,API 呼叫會根據回應時間、錯誤狀態以及由多個第三方服務執行的次要功能細分進行評估。追蹤工具會將資料轉換為視覺表單,突顯關鍵指標和效能摘要。這樣,現場可靠性工程師可以快速識別錯誤、檢查重要的資料元素,並與開發團隊合作,修復效能問題並確保符合服務水準協議 (SLA)。

什麼是分散式追蹤標準?

分散式追蹤標準為開發人員提供通用架構和軟體工具。這些標準可監控、視覺化和分析現代應用程式環境中的服務請求。透過標準化分散式追蹤工作流程,軟體團隊可以檢測請求追蹤,而不需要受限於供應商鎖定。 

以下各節描述引入的標準,在執行分散式追蹤時啟用互通性。

OpenTracing

OpenTracing 是由雲端原生運算基金會 (CNCF) 開發的開放原始碼分散式追蹤標準。OpenTracing 著重在讓開發人員使用檢測 API 產生追蹤。這可讓開發人員從程式碼基底、程式庫或其他相依性的不同部分產生分散式追蹤。

OpenCensus

OpenCensus 是由多語言程式庫組成,能夠擷取軟體指標並將其傳送到後端系統進行分析。開發人員可以使用提供的 API 來管理如何產生和收集追蹤。與 OpenTracing 不同,開發人員從單一專案儲存庫使用 OpenCensus,而不是個別的程式碼基底和程式庫。 

OpenTelemetry

OpenTelemetry 會統一 OpenTracing 和 OpenCensus。它結合了兩種標準的最佳功能,以提供全面的分散式追蹤架構。OpenTelemetry 提供廣泛的軟體開發套件、API、程式庫和其他檢測工具,讓實作分散式追蹤更輕鬆。 

分散式追蹤和記錄有什麼區別?

記錄是記錄應用程式執行時發生的特定事件的實務。記錄工具會收集時間戳記事件 (例如系統錯誤、使用者互動、通訊狀態和其他指標),以協助開發團隊偵測系統異常。記錄通常有兩種類型: 

  • 集中式記錄會收集所有記錄的活動,並將其儲存在單一位置。
  • 分散式記錄會將日誌檔儲存在雲端上的不同位置。 

這兩種記錄方法都提供事件的靜態概觀,向開發人員顯示在應用程式中發生的情況。相較之下,分散式追蹤提供稽核記錄,透過讓服務請求期間收集的各種遙測資料相互關聯來釐清事件發生的原因。分散式追蹤可能會使用記錄和其他資料收集方法來追蹤特定服務請求。 

分散式追蹤有哪些挑戰?

分散式追蹤簡化了開發人員在診斷、偵錯和修正軟體問題方面的努力。儘管如此,軟體團隊在選擇追蹤工具時仍然必須注意以下挑戰。

手動檢測

某些追蹤工具需要軟體團隊手動檢測其程式碼以產生必要的追蹤。當開發人員修改程式碼以追蹤請求時,會有編碼錯誤影響生產版本的風險。此外,缺乏自動化會使追蹤變得複雜,導致資料收集延遲並且可能不準確。 

前端涵蓋範圍有限

如果開發人員的追蹤工具僅限於後端分析,則開發人員可能無法完全監控效能問題。在某些情況下,分散式追蹤系統只會在第一個後端服務收到請求時開始收集資料。這意味著開發人員無法在對應的使用者工作階段期間偵測和檢查由前端服務引起的問題。

隨機抽樣

某些工具不允許軟體團隊優先追蹤,因此可觀測性限制為隨機抽樣的追蹤。由於範例資料有限,組織需要額外的軟體疑難排解方法來擷取遠離追蹤工具的主要問題。 

AWS 如何協助處理您的分散式追蹤要求?

AWS X-Ray 是一個分散式追蹤平台,可協助軟體開發人員追蹤使用者請求,並識別其雲端應用程式中的瓶頸。組織使用 X-Ray 來視覺化應用程式指標並改善工作負載可用性。使用 AWS X-Ray,您可以:

立即建立帳戶,開始在 AWS 上進行分散式追蹤。

AWS 的後續步驟

註冊免費帳戶

立即存取 AWS 免費方案。

註冊 
開始在主控台進行建置

開始在 AWS 管理主控台進行建置。

登入