日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
全鏈路根因定位，虎牙APM可觀測平臺建設(shè)實(shí)踐

隨著虎牙業(yè)務(wù)量的大規(guī)模增長，分布式應(yīng)用服務(wù)架構(gòu)日益復(fù)雜，排障定位變得越來越困難，原有傳統(tǒng)監(jiān)控方式已無法跟上業(yè)務(wù)發(fā)展需要?；⒀佬陆ㄔO(shè)了一套APM平臺，結(jié)合虎牙直播業(yè)務(wù)特性，也緊靠業(yè)界標(biāo)準(zhǔn)做了高度自研擴(kuò)展，幫助研發(fā)和運(yùn)維提高工作效率，保障線上應(yīng)用服務(wù)穩(wěn)定運(yùn)行。

創(chuàng)新互聯(lián)專注于企業(yè)成都營銷網(wǎng)站建設(shè)、網(wǎng)站重做改版、陵川網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5高端網(wǎng)站建設(shè)、商城系統(tǒng)網(wǎng)站開發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為陵川等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

本次分享將通過以下幾個部分來介紹整體思路和實(shí)踐過程：

一、項(xiàng)目背景

圖片

1.當(dāng)時痛點(diǎn)

虎牙當(dāng)時各團(tuán)隊(duì)的應(yīng)用監(jiān)控方案多樣，有自建應(yīng)用接口日志采集監(jiān)控，也有直接使用各類開源Trace系統(tǒng)，這樣就導(dǎo)致跨團(tuán)隊(duì)的鏈路無法相互打通，同時也缺乏統(tǒng)一的產(chǎn)品設(shè)計(jì)，極大地影響了整體排障效率。

2.切入點(diǎn)

從客戶端到后端分布式應(yīng)用服務(wù)的全鏈路打通，提供透明零成本的接入方案快速覆蓋業(yè)務(wù)，對Metric/Trace/Log監(jiān)控?cái)?shù)據(jù)進(jìn)行整合并分析錯誤和異常，最終做到全鏈路根因定位。

3.目標(biāo)

建設(shè)APM可觀測項(xiàng)目落地，根據(jù)錯誤的發(fā)現(xiàn)、定位和影響面分析等核心指標(biāo)來指導(dǎo)方向和衡量效果，最終幫助用戶提高排障效率。

二、方案實(shí)踐

1.設(shè)計(jì)方案思考

圖片

數(shù)據(jù)采集：接入透明零成本是用戶愿意接的關(guān)鍵

數(shù)據(jù)關(guān)聯(lián)：Metric & Trace & Log的可觀測關(guān)聯(lián)模型設(shè)計(jì)

全鏈路：客戶端 -> Nginx/信令 -> 分布式應(yīng)用服務(wù) -> 數(shù)據(jù)庫/緩存

根因定位：根據(jù)關(guān)聯(lián)模型數(shù)據(jù)的實(shí)時自動化分析來發(fā)現(xiàn)和定位問題

2.可觀測模型分析

圖片

根據(jù)應(yīng)用服務(wù)處理請求的過程設(shè)計(jì)以下模型：

  • Handle模型

描述該應(yīng)用服務(wù)處理了什么請求，調(diào)用什么處理方法，使用什么資源等，包括相關(guān)Metric/Span/Log數(shù)據(jù)采集，Trace上下文隨請求處理在線程本地變量中進(jìn)行透明傳遞。

  • RPC模型

描述該應(yīng)用服務(wù)有什么RPC、Http、數(shù)據(jù)庫、緩存等請求調(diào)用，包括相關(guān)Metric/Span/Log數(shù)據(jù)采集，Trace上下文隨請求頭在跨服務(wù)進(jìn)程之間傳遞。

  • 可觀測模型關(guān)聯(lián)
  • 縱向：應(yīng)用服務(wù)進(jìn)程內(nèi)、跨進(jìn)程的請求調(diào)用鏈路關(guān)聯(lián)
  • 橫向：隊(duì)列、線程池、連接池等資源數(shù)據(jù)和請求關(guān)聯(lián)

總結(jié)：設(shè)計(jì)包含從Handle和RPC數(shù)據(jù)采集，到縱向和橫向整體關(guān)聯(lián)的全鏈路可觀測模型，我們根據(jù)模型進(jìn)一步設(shè)計(jì)了SDK和服務(wù)端的整體架構(gòu)。

3.SDK架構(gòu)介紹

圖片

  • 零成本接入
  • Java：字節(jié)碼織入技術(shù)來自動識別多種框架并埋點(diǎn)
  • C++：集成在Taf框架埋點(diǎn)
  • 客戶端：集成在信令SDK埋點(diǎn)
  • 基于業(yè)界標(biāo)準(zhǔn)

基于Opentracing標(biāo)準(zhǔn)選擇了Jaeger tracing的實(shí)現(xiàn)，通過自研設(shè)計(jì)和實(shí)現(xiàn)了Metric采集、聚合和關(guān)聯(lián)等邏輯。

  • 分層和插件化

整體SDK架構(gòu)分層清晰，基于Opentracing標(biāo)準(zhǔn)接口，相關(guān)底層和框架層都可以擴(kuò)展實(shí)現(xiàn)一些個性功能，通過插件化設(shè)計(jì)來按需加載使用。

  • 全量和采樣

Metric指標(biāo)全量采集并聚合后上報(bào)。Trace Span明細(xì)需要采樣，支持遠(yuǎn)程控制的動態(tài)前置采樣，以及有損后置采樣方案。

4.服務(wù)端架構(gòu)介紹

圖片

采集、上報(bào)和控制

  • Server App：Trace SDK在應(yīng)用服務(wù)框架層進(jìn)行自動化采集和上報(bào)
  • Client App：集成在信令SDK層進(jìn)行自動化采集和上報(bào)
  • Sdk Control：sdk遠(yuǎn)程控制服務(wù)，包括采樣策略、日志打印、功能啟停等控制
  • Collector：數(shù)據(jù)接收服務(wù)，處理流控、驗(yàn)證、清洗、轉(zhuǎn)換等邏輯

存儲、分析和告警

  • Trace Sinker：spans明細(xì)數(shù)據(jù)的解析和存儲，按自研模型設(shè)置具體明細(xì)tags和logs
  • Metric Sinker：指標(biāo)數(shù)據(jù)解析和存儲，按自研模型設(shè)置相應(yīng)的指標(biāo)維度tags
  • Meta Data Analyzer：分析出鏈路元數(shù)據(jù)，包含：請求uri、接口名、服務(wù)名、進(jìn)程實(shí)例等
  • Error Analyzer：分析時間線錯誤和異常來發(fā)現(xiàn)問題，再通過指標(biāo)關(guān)聯(lián)和鏈路追蹤來定位根因

可視化和告警輸出

  • Web Server：產(chǎn)品后端的API服務(wù)，負(fù)責(zé)數(shù)據(jù)檢索和業(yè)務(wù)邏輯處理
  • Web/H5 App：產(chǎn)品前端的頁面展示、交互處理等可視化能力
  • Wechat/SMS：企業(yè)微信、短信等方式的告警輸出

5.錯誤分析 - 應(yīng)用性能根因定位

圖片

上圖右邊可以看到對請求處理流程的進(jìn)一步解析，核心在于如何把請求處理追蹤和線程資源進(jìn)行關(guān)聯(lián)，我們設(shè)計(jì)了反映服務(wù)處理能力的指標(biāo)：線程負(fù)載率

上圖左邊的算法示例可以看到能發(fā)現(xiàn)應(yīng)用服務(wù)GiftServer出現(xiàn)了線程負(fù)載高，應(yīng)用性能不足問題，通過各請求的負(fù)載率分布來進(jìn)一步分析，可以發(fā)現(xiàn)是由于/sendGift請求處理導(dǎo)致，而它里面的RPC請求/payMoney是根因問題。

效果示例：

圖片

6.錯誤分析 - 全鏈路根因定位

圖片

  • Metric錯誤檢測

如上圖綠色框內(nèi)是對應(yīng)用服務(wù)內(nèi)部Handle和RPC模型各類指標(biāo)進(jìn)行錯誤檢測：

Request Metrics    // 請求指標(biāo)
uri: /payMoney    // 請求uri或方法名
totalCount: 1000    // 總請求數(shù)
errorCount: 200    // 錯誤請求數(shù)
latency avg: 2000ms    // 請求平均耗時
errorRate: 20%    // 請求錯誤率
...

發(fā)現(xiàn)請求錯誤率和平均耗時增加并在幾個周期內(nèi)連續(xù)出現(xiàn)，按對應(yīng)的告警分析規(guī)則就會判定為異常并產(chǎn)生實(shí)時告警發(fā)送給用戶。

  • Metric關(guān)聯(lián)分析

如上圖指標(biāo)的tag會記錄相應(yīng)維度信息來建立指標(biāo)關(guān)聯(lián)，并通過的指標(biāo)和鏈路關(guān)聯(lián)來進(jìn)行錯誤根因分析：

service: GiftServer    // 應(yīng)用服務(wù)名
host: 192.168.1.1:8080  // 服務(wù)實(shí)例ip port
peerService: MoneyServer  // rpc對端服務(wù)名
peerHost: 192.168.1.2:8081  // rpc對端實(shí)例ip port
type: rpc      // 請求類型


service: MoneyServer    // 應(yīng)用服務(wù)名
host: 192.168.1.2:8081  // 服務(wù)實(shí)例ip port 
peerService: Mysql    // rpc對端服務(wù)名
peerHost: 192.168.1.3:3306  // rpc對端實(shí)例ip port
type: mysql      // 請求類型


建立關(guān)聯(lián)：
請求: /sendGift 調(diào)用 /payMoney
服務(wù): GiftServer 調(diào)用 MoneyServer
實(shí)例: 192.168.1.1:8080 調(diào)用192.168.1.2:8081
  • Metric & Trace & Log

如上圖底部所示，通過從Metric宏觀錯誤告警到下鉆Trace/Log明細(xì)的關(guān)聯(lián)分析，建設(shè)實(shí)時全鏈路根因定位的平臺能力。

三、效果展示

1.全鏈路根因分析

圖片

如上圖全鏈路拓?fù)鋱D展示錯誤根因節(jié)點(diǎn)和被影響鏈路節(jié)點(diǎn)，點(diǎn)擊節(jié)點(diǎn)可以進(jìn)一步按被調(diào)、主調(diào)和實(shí)例視圖來查看宏觀指標(biāo)情況，其中我們定位到是/hikari/getConnection耗時比較長導(dǎo)致，我們還可以點(diǎn)擊鏈路按鈕來進(jìn)一步下鉆分析。

2.鏈路 - Trace明細(xì)分析

點(diǎn)擊鏈路按鈕后打開Trace鏈路明細(xì)頁面，可以看到每次請求的明細(xì)鏈路情況，點(diǎn)擊其中一條出錯的Trace，就可以看到如上圖所示的請求調(diào)用鏈視圖。可以快速分析定位到根因是獲取鏈接/hikari/getConnection的耗時長，導(dǎo)致上游的/getUser請求處理超時。

3.指標(biāo) - 應(yīng)用性能分析

圖片

點(diǎn)擊指標(biāo)按鈕后可以看具體的應(yīng)用進(jìn)程性能，通過右圖表請求處理的線程負(fù)載占比可以看到請求 /getUser 調(diào)用 /hikari/getConnection的線程負(fù)載率占比較高，左圖表線程狀態(tài)分析發(fā)現(xiàn)其根因是由于大多數(shù)工作線程阻塞在獲取連接的操作上。

4.指標(biāo) - 請求性能分析

圖片

來進(jìn)一步看更多的請求性能指標(biāo)，通過右圖表請求調(diào)用關(guān)系時延可以看到請求 /getUser 調(diào)用 /hikari/getConnection的平均耗時很大，左圖表可以分析具體的請求耗時區(qū)間分布占比情況，通過以上各種時序折線圖幫助我們快速分析具體的指標(biāo)異常和變化趨勢。

5.告警分析 - 單節(jié)點(diǎn)聚集性問題

圖片

如上圖一站式排障流程，錯誤詳情頁面由上至下展示了錯誤基礎(chǔ)信息、錯誤類型分布圖等，這里可重點(diǎn)介紹一下中間的多節(jié)點(diǎn)調(diào)用聚合性根因定位：

鏈路 /getUser(sim-client)  // URI接口(應(yīng)用服務(wù)名)
-> /getUser(sim-first)
-> /getUser(sim-second:10.66.109.165:8001)  // URI接口(應(yīng)用服務(wù)名:實(shí)例ip:端口)


根因 Read timed out...  // trace span log存儲的異常信息，也可進(jìn)一步看異常堆棧

主調(diào)影響范圍如下表：

主調(diào)服務(wù):實(shí)例ip:端口

超時率(%)

請求數(shù)

平均耗時(ms)

sim-client:10.116.18.223:8000

37.94

833

1070

sim-client:10.116.18.223:8000

33.52

880

1014

sim-client:10.116.18.223:8000

32.18

895

997

總結(jié)：從上面信息可以直接看出多個節(jié)點(diǎn)主調(diào)發(fā)生超時異常，是由于鏈路的根因節(jié)點(diǎn)sim-second:10.66.109.165:8001導(dǎo)致，并能快速把范圍性影響的根因聚集到具體出錯節(jié)點(diǎn)上。該場景的核心就是把請求全鏈路 & 多節(jié)點(diǎn)聚集性進(jìn)行關(guān)聯(lián)分析。

6.告警分析 - 應(yīng)用性能瓶頸問題

如上圖一站式排障流程，錯誤詳情頁面由上至下展示了錯誤基礎(chǔ)信息、線程負(fù)載率時序圖等，還是重點(diǎn)介紹中間的請求負(fù)載根因定位：

線程池名 tomcat.threadpool  // 關(guān)聯(lián)當(dāng)前服務(wù)框架的工作線程池
線程池快照 最大容量(200) 執(zhí)行中(200) 阻塞中(190)  // 關(guān)聯(lián)線程池資源指標(biāo)

線程負(fù)載分布如下表：

請求URI

負(fù)載率(%)

請求數(shù)

平均耗時(ms)

/getUser

98.82

606

17417

/getUser 調(diào)用 /hikari/getConnection

93.24

610

16632

/getUser 調(diào)用 /hikari/xiwi/SELECT

5

606

983

總結(jié)：從上面信息可以一直看出工作線程池已經(jīng)跑滿，而且大部分線程執(zhí)行中遇到了阻塞等待，從負(fù)載率具體請求分布來看，根因是由于/getUser 調(diào)用 /hikari/getConnection占比較高導(dǎo)致。該場景的核心就是把請求處理 & 線程 & 連接進(jìn)行關(guān)聯(lián)分析。

四、開放賦能

圖片

自從APM可觀測平臺上線運(yùn)營后，除了用戶對產(chǎn)品一些反饋需求，也收到了很多對于平臺能力開放的需求，因此我們建設(shè)了APM開放平臺，用于開放能力賦能公司其他團(tuán)隊(duì)，如上圖所示：

Case1：Metric時序數(shù)據(jù)

賦能AIOps異常檢測，提供各應(yīng)用服務(wù)的請求時序數(shù)據(jù)給AI模型訓(xùn)練，對部分個性服務(wù)和指標(biāo)提供AI告警。

Case2：Trace明細(xì)數(shù)據(jù)

賦能自動化測試請求追蹤，自動化測試可以快速從客戶端到服務(wù)端全鏈路獲取錯誤根因，集成在自身系統(tǒng)邏輯中。

Case3：Trace包裹傳遞

賦能全鏈路請求染色，如對某個用戶進(jìn)行染色后，會保障用戶uid隨著trace上下文在整個請求鏈路進(jìn)行透明傳遞，各應(yīng)用服務(wù)都可通過trace sdk的api獲取用戶uid來打印日志或其他操作。

總結(jié)：APM可觀測平臺這塊在虎牙統(tǒng)一可觀測規(guī)劃上屬于應(yīng)用監(jiān)控/鏈路追蹤，我們也在推進(jìn)基礎(chǔ)設(shè)施監(jiān)控、業(yè)務(wù)監(jiān)控一起做一些整合，關(guān)鍵切入點(diǎn)還是在于各監(jiān)控平臺元數(shù)據(jù)的關(guān)聯(lián)分析，后續(xù)有機(jī)會再介紹這塊的思考和實(shí)踐。

Q&A

Q1：對應(yīng)用有沒有性能影響？

A1：Metric數(shù)據(jù)對應(yīng)用性能影響非常小，主要是在異步線程中做相關(guān)聚合運(yùn)算，也就是說會把請求明細(xì)span按模型的指標(biāo)定義來做聚合，生成請求量、耗時分布、錯誤量等指標(biāo)，一個周期內(nèi)10000次請求也只會對指標(biāo)值做改變，如：請求量: 10000次。但Trace span明細(xì)數(shù)據(jù)量是和請求量相關(guān)的，也就是采樣率100%的情況下當(dāng)前節(jié)點(diǎn)會上報(bào)10000個span，在測試中發(fā)現(xiàn)對應(yīng)用進(jìn)程會有不少性能開銷，如果都上報(bào)的話對網(wǎng)絡(luò)流量和存儲也會開銷比較大，而大多數(shù)的明細(xì)span在實(shí)踐中價值不大，所以會采用一些前置采樣加有損后置采樣的策略來降低對整體性能和成本的影響。

Q2：鏈路span是怎么跟那個時候的日志和指標(biāo)關(guān)聯(lián)？

A2：SDK會根據(jù)Handle和RPC模型把Metric指標(biāo)設(shè)置各種維度tag，這些tag會跟Trace span tag保持對應(yīng)來關(guān)聯(lián)請求調(diào)用鏈指標(biāo)和資源指標(biāo)，而Trace span log會關(guān)聯(lián)保存一些詳細(xì)異常日志和框架層日志。例如PPT分享的錯誤分析之應(yīng)用性能根因定位和全鏈路根因定位里有詳細(xì)介紹這塊的實(shí)現(xiàn)原理，進(jìn)一步在PPT效果展示中也可以看到把Metric&Trace&Log進(jìn)行關(guān)聯(lián)分析后的產(chǎn)品效果和應(yīng)用場景。

Q3：開發(fā)人員自定義的日志可以采集嗎？

A3：Java主要使用基于slf4j的log4j或logback實(shí)現(xiàn)，我們對此在SDK開發(fā)了一個MDC(Mapped Diagnostic Context)擴(kuò)展，在日志里自動帶上traceId、spanId等信息，而C++也把相應(yīng)能力集成在框架日志組件中。這些自定義日志落盤后會被采集上報(bào)，在Log日志平臺中可查詢展示，我們也跟日志平臺在產(chǎn)品層做了打通聯(lián)動，會自動帶上trace id條件來查詢該請求鏈路上的所有自定義日志明細(xì)。

匡凌軒虎牙直播 基礎(chǔ)保障部 SRE平臺負(fù)責(zé)人

  • 負(fù)責(zé)虎牙應(yīng)用發(fā)布、元數(shù)據(jù)、計(jì)量計(jì)費(fèi)、監(jiān)控和告警等平臺建設(shè)，主導(dǎo)應(yīng)用監(jiān)控和鏈路追蹤項(xiàng)目的從零到一實(shí)踐落地；曾任職歡聚時代集團(tuán)，負(fù)責(zé)YY直播Web研發(fā)團(tuán)隊(duì)，主導(dǎo)業(yè)務(wù)高可用、高并發(fā)分布式服務(wù)架構(gòu)設(shè)計(jì)和實(shí)現(xiàn)，保障過多屆年度盛典等海量用戶業(yè)務(wù)場景。

網(wǎng)站標(biāo)題：全鏈路根因定位，虎牙APM可觀測平臺建設(shè)實(shí)踐
網(wǎng)站路徑：http://www.dlmjj.cn/article/djopggj.html