1. <legend id="jwpzh"></legend>

    2. <optgroup id="jwpzh"></optgroup>

      <optgroup id="jwpzh"></optgroup>
      1. 回到主頁

        干貨 | EasyOps中秒級定位故障的分布式鏈路追蹤是如何實現的?

        Paul Huang

        · 操作指南

        概述

        在微服務的世界,作為業務運維,總是會遇到幾個監控的難題:

        1、遇到故障如何快速準確定位到是哪個組件有問題

        2、如何準確繪制出業務拓撲圖

        3、如何快速找到當前的業務瓶頸

        以上難題都可以通過分布式追蹤解決

        作者簡介:Paul畢業于中山大學,曾在騰訊做過業務運維,在網易做過游戲開發。 目前是優維平臺研發組組長,負責平臺的基礎架構工作。

        背景

        分布式鏈路追蹤功能是優維科技EasyOps平臺的智能監控模塊的一個重要功能。

        首先,讓我們來看一個EasyOps中自動繪制的業務拓撲圖。

        通過分布式追蹤,可以很直觀地看出來組件與組件之間的關系。

        當收到客戶投訴時,可以通過分布式追蹤定位到錯誤的服務(下圖標紅部分)。

        技術原理

        EasyOps的分布式追蹤參考了Google的Dapper論文[1],基于開源項目Zipkin[2]研發了一套分布式追蹤的解決方案,目標是通過分布式追蹤及時發現生產環境故障以及縮短故障排查時長。

        以上是一次常見的RPC調用圖,客戶端向服務端請求時會給服務器把這次請求的分布式追蹤上下文帶上(下文稱為帶內傳輸)??蛻舳税l送/接收RPC請求和服務器發送/接收RPC請求后,都會給服務器發送一條日志,上報分布式追蹤的信息(下文稱為帶外上報)。通過cs, cr, sr, ss四個時間戳,我們可以算出這一次微服務調用的幾個關鍵時間:

        ? 請求總耗時:cr – cs

        ? 服務端邏輯耗時:ss - sr

        ? 客戶端到服務器RTT:sr – cs

        ? 服務器到客戶端RTT:cr - ss

        帶內傳輸:

        微服務與微服務之間通過唯一的TraceId來傳播本次請求的上下文,HTTP常在請求頭里面用B3協議來傳播上下文。

        ? TraceId: 64位或128位唯一請求ID,隨機生成。

        ? SpanId: 64位RPC唯一ID,每產生一次RPC請求,隨機生成一個新的SpanId來追蹤。

        ? ParentSpanId: 當前RPC請求的父節點,用于把整個調度鏈串起來。

        ? Sampled: 標記這次請求是否需要采樣。請求是否采樣由第一個收到請求的Tracer決定。

        帶外上報:

        帶外上報會把整個分布式追蹤的字段報到服務器(如服務名、IP端口、錯誤信息等)。上報方式有幾種:HTTP, KAFKA, 日志上報。

        接入方式:

        EasyOps分布式追蹤完全兼容Zipkin上報格式[3],提供Java, C#, Go, Python, JavaScript, Ruby, Scala, C,C++等十多種語言的sdk。以下摘取自Zipkin官方文檔[4]。

        • 官方支持SDK

        • 開源社區貢獻SDK:

        實操演示

        三步完成性能分析排查:

        第一步: QA發現前臺實例搜索很慢,從chrome調試窗口拿到這次請求的TraceId

        第二步:進入分布式追蹤,搜索該分布式追蹤的TraceId

        第三步:分析原因,是查詢數據庫這一步耗時5秒多,定位到是SQL語句寫得不合理導致的,提交給開發進行優化。

        所有文章
        ×

        還剩一步!

        確認郵件已發至你的郵箱。?請點擊郵件中的確認鏈接,完成訂閱。

        好的

        美女一级牲交视频