隨著虛擬化、云化技術(shù)越來越成熟,分布式系統(tǒng)的成本和架構(gòu)優(yōu)勢日漸凸顯,特別是微服務(wù)等設(shè)計(jì)理念在業(yè)務(wù)系統(tǒng)尤其是大型的互聯(lián)網(wǎng)公司中越來越流行,業(yè)務(wù)的調(diào)用關(guān)系越來越復(fù)雜。
而隨著業(yè)務(wù)的膨脹、服務(wù)的拆分,系統(tǒng)的模塊變得越來越多,不同的模塊可能由不同的團(tuán)隊(duì)/程序員來維護(hù)。一次客戶的業(yè)務(wù)請求,可能會涉及數(shù)個(gè)乃至數(shù)十個(gè)服務(wù)的協(xié)同處理,牽扯到多個(gè)團(tuán)隊(duì)/程序員的維護(hù)模塊,不同的緩存、數(shù)據(jù)庫、消息隊(duì)列等中間件。在這樣的云化應(yīng)用架構(gòu)下,請求鏈路的任何一條請求出現(xiàn)故障或性能問題,都將嚴(yán)重影響服務(wù)的用戶體驗(yàn)。如何能夠快速準(zhǔn)確的定位到線上故障根因?如何捕捉請求中的性能瓶頸并實(shí)施優(yōu)化?如何將離散的業(yè)務(wù)請求數(shù)據(jù)關(guān)聯(lián)在一起進(jìn)行有效的用戶體驗(yàn)分析?對于大型的、訪問量大的網(wǎng)站、社交、電商、游戲應(yīng)用,這類問題尤其突出,直接影響最終用戶對系統(tǒng)的感知和留存率。
傳統(tǒng)的應(yīng)用運(yùn)維問題定位以日志為主,通過對告警、系統(tǒng)資源、日志的逐一分析,定位故障根因或性能瓶頸。但是由于云化架構(gòu)的復(fù)雜性,業(yè)務(wù)請求鏈路的多樣性,傳統(tǒng)的應(yīng)用運(yùn)維模式已經(jīng)無法繼續(xù)支撐故障定位與性能分析的訴求。這個(gè)時(shí)候就需要APM系統(tǒng)來大展身手了。
APM的定義與演進(jìn)
APM (Application Performance Management) 即應(yīng)用性能管理,屬于IT運(yùn)維管理(ITOM)范疇。主要是針對企業(yè)關(guān)鍵業(yè)務(wù)的IT應(yīng)用性能和用戶體驗(yàn)的監(jiān)測、優(yōu)化,提高企業(yè)IT應(yīng)用的可靠性和質(zhì)量,保證用戶得到良好的服務(wù),降低IT總擁有成本(TCO)。APM隨著互聯(lián)網(wǎng)的發(fā)展,經(jīng)歷了以下三個(gè)階段:
第一階段的APM出現(xiàn)在互聯(lián)網(wǎng)興起的初期,由于網(wǎng)絡(luò)基礎(chǔ)設(shè)施的水平普遍較差,使應(yīng)用速度對網(wǎng)絡(luò)速度與基礎(chǔ)資源的性能非常敏感。這個(gè)階段的APM以網(wǎng)絡(luò)為中心,認(rèn)為網(wǎng)絡(luò)速度既應(yīng)用速度,APM主要監(jiān)控主機(jī)的CPU、I/O、內(nèi)存、網(wǎng)絡(luò)吞吐等為主。
第二階段的APM以監(jiān)控各種基礎(chǔ)組件為主,隨著互聯(lián)網(wǎng)的發(fā)展,網(wǎng)絡(luò)應(yīng)用變得越來越復(fù)雜,各種基礎(chǔ)組件越來越多,促使APM進(jìn)入以IT組件的健康狀態(tài)、可用性、性能監(jiān)控為中心第二個(gè)階段。
近幾年移動互聯(lián)網(wǎng)、云計(jì)算、大數(shù)據(jù)、物聯(lián)網(wǎng)等技術(shù)的迅猛發(fā)展,各種業(yè)務(wù)應(yīng)用不斷出現(xiàn),IT應(yīng)用復(fù)雜度呈現(xiàn)爆炸式增長,而互聯(lián)網(wǎng)產(chǎn)品本身“用戶至上”的屬性決定用戶體驗(yàn)成為各互聯(lián)網(wǎng)產(chǎn)品生存發(fā)展的關(guān)鍵因素。如何提升用戶體驗(yàn),保證服務(wù)和產(chǎn)品的可靠性、穩(wěn)定性、優(yōu)化服務(wù)等問題,對應(yīng)用性能管理提出了新的需求,應(yīng)用性能管理進(jìn)入以用戶體驗(yàn)為核心、專注業(yè)務(wù)交易與應(yīng)用架構(gòu)高度復(fù)雜性的第三階段。
基于APM 市場分析,Gardern對APM進(jìn)行了新的定義描述:
在新的標(biāo)準(zhǔn)下,APM市場發(fā)展迅速。APM通過對應(yīng)用服務(wù)的性能和可用性進(jìn)行監(jiān)控管理,幫助應(yīng)用/服務(wù)開發(fā)者發(fā)現(xiàn)和定位性能瓶頸和故障,保證應(yīng)用達(dá)到預(yù)期的服務(wù)水平及最終用戶體驗(yàn)。
分布式追蹤技術(shù)原理
現(xiàn)代的APM基本都是參考Google的Dapper體系來實(shí)現(xiàn)的。Dapper通過跟蹤請求的處理過程,來對應(yīng)用系統(tǒng)在前后端處理、服務(wù)端調(diào)用的性能消耗進(jìn)行跟蹤。Google基于Dapper的實(shí)現(xiàn)發(fā)表了論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》,給行業(yè)內(nèi)分布式跟蹤的實(shí)現(xiàn)提供了非常有價(jià)值的參考,該論文也成為了當(dāng)前分布式跟蹤系統(tǒng)的理論基礎(chǔ)。大家可以參考Dapper論文原版,進(jìn)行詳細(xì)了解,本文只對原理做簡單介紹。
如上圖所示,對于業(yè)務(wù)鏈條中的每一次請求調(diào)用,劃分為clientSend(客戶端發(fā)送請求)、clientRecv(客戶端收到響應(yīng))、serverRecv(服務(wù)端收到請求)、serverSend(服務(wù)端發(fā)送響應(yīng))等四個(gè)事件,并由這四個(gè)事件組織為一個(gè)稱作Span的數(shù)據(jù)結(jié)構(gòu)。通過定義Span之間的調(diào)用(父子)關(guān)系,可以對離散的Span數(shù)據(jù)進(jìn)行重組,以還原完整的調(diào)用鏈條。Span間的關(guān)系通過traceId、parentId、spanId來標(biāo)識。traceId是一次完整調(diào)用鏈路的唯一標(biāo)識,parentId標(biāo)識當(dāng)前Span的前一個(gè)調(diào)用Span,spanId用來唯一的標(biāo)識某一次調(diào)用。Span在跟蹤鏈路中的關(guān)聯(lián)關(guān)系可以用下圖表示:
基于Google Dapper這種通過traceid、parentid、spanid還原原始鏈路的思路,眾多大型互聯(lián)網(wǎng)公司都開發(fā)了自己的調(diào)用跟蹤系統(tǒng),如Twitter的Zipkin、淘寶的鷹眼、京東的Hydra、開源的PinPoint,總體思路雖然一致,但是植入點(diǎn)選擇上卻有一些分歧。
分布式追蹤采集技術(shù)兩大流派橫評
應(yīng)用性能管理系統(tǒng)主要由數(shù)據(jù)源、采集傳輸、分析計(jì)算、可視化查詢幾部分組成,其中最核心的部分就是數(shù)據(jù)源。通過從客戶端和服務(wù)端進(jìn)行數(shù)據(jù)采集,其中客戶端的數(shù)據(jù)采集技術(shù)主要包括主動式撥測與被動式埋點(diǎn)探測,在此不再展開詳細(xì)描述,本文主要對服務(wù)端的數(shù)據(jù)采集技術(shù)進(jìn)行簡單介紹。
服務(wù)端的數(shù)據(jù)采集主要分為兩大類:
·網(wǎng)絡(luò)旁路監(jiān)聽,通過在應(yīng)用或服務(wù)部署的生產(chǎn)網(wǎng)絡(luò)的交換機(jī)或網(wǎng)絡(luò)接口抓取應(yīng)用訪問流量進(jìn)行應(yīng)用性能分析。這種方式對于應(yīng)用或者服務(wù)的侵入性小,性能影響小。然而此方式采集粒度較大,無法提供代碼級的問題定位,且在安全傳輸協(xié)議下,無法針對請求或事物進(jìn)行分析。
·探針埋點(diǎn),通過在生產(chǎn)服務(wù)器上的應(yīng)用部署或者嵌入探針的方式進(jìn)行應(yīng)用性能數(shù)據(jù)采集。這種方式能夠提供非常完整與細(xì)粒度的監(jiān)控?cái)?shù)據(jù)采集,提供代碼級的問題定位。但此方式對于應(yīng)用來說是侵入性的,如果埋點(diǎn)代碼異常,會對應(yīng)用本身的性能和穩(wěn)定性產(chǎn)生一定影響。
在針對應(yīng)用與服務(wù)的埋點(diǎn)數(shù)據(jù)采集中,主要使用了探針埋點(diǎn)的方式。探針埋點(diǎn)的方式主要分為兩類,以Zipkin為代表的代碼侵入式埋點(diǎn)與以PinPoint為代表的字節(jié)碼增強(qiáng)式埋點(diǎn)。
Zipkin與侵入式采集 不依賴框架生態(tài)成熟
Zipkin是Twitter開源的分布式追蹤系統(tǒng),用戶幫助微服務(wù)收集排查潛在問題的時(shí)序數(shù)據(jù),提供調(diào)用跟蹤數(shù)據(jù)的收集、存儲、查詢以及依賴分析的能力。Zipkin是一個(gè)分布式跟蹤系統(tǒng),不具備用戶體驗(yàn)分析、應(yīng)用監(jiān)控統(tǒng)計(jì)等特性。Zipkin使用代碼侵入埋點(diǎn)的方式,官方提供基于Finagle框架的埋點(diǎn)方案,其他語言和框架的支持主要依賴社區(qū)貢獻(xiàn)。當(dāng)前支持包括Java、Scala、Node、Go、Python、Ruby、C#等主流語言和框架。代碼侵入式埋點(diǎn)指通過提供應(yīng)用開發(fā)的SDK,或者提供集成埋點(diǎn)代碼的框架的方式供應(yīng)用開發(fā)者調(diào)用。部分具備框架研發(fā)能力的企業(yè)像Google一樣將植入點(diǎn)選在開發(fā)框架或通信框架中,確保基于統(tǒng)一框架開發(fā)或通信的應(yīng)用天然具備埋點(diǎn)能力,除框架開發(fā)團(tuán)隊(duì)外無需關(guān)注埋點(diǎn)實(shí)現(xiàn)、調(diào)用方式。這種埋點(diǎn)方式優(yōu)勢在于使用框架后無需額外關(guān)注埋點(diǎn)能力,變相降低了埋點(diǎn)的成本。Twitter的Zipkin、淘寶的鷹眼選擇了這種埋點(diǎn)方式。
同時(shí),業(yè)界也有非常多的埋點(diǎn)裝備庫,支持使用埋點(diǎn)組件的方式實(shí)現(xiàn)調(diào)用鏈數(shù)據(jù)埋點(diǎn)。這種埋點(diǎn)方式,通過提供標(biāo)準(zhǔn)的服務(wù)框架,如:Servlet、Spring MVC、Http Client以及通用的中間件,如MySQL、Kafka等的裝備類的方式,通過編寫簡單代碼和配置,讓基于這些標(biāo)準(zhǔn)框架構(gòu)建的應(yīng)用可以輸出調(diào)用鏈報(bào)告數(shù)據(jù)。Brave為這種埋點(diǎn)方式提供了大量的標(biāo)準(zhǔn)框架實(shí)現(xiàn)。也提供了非常簡單且標(biāo)準(zhǔn)化的接口,支持在以上的封裝實(shí)現(xiàn)無法滿足業(yè)務(wù)要求時(shí),進(jìn)行定制與擴(kuò)展。
代碼侵入式埋點(diǎn)具有較好的擴(kuò)展性,方便用戶自定義采集的數(shù)據(jù)類型與層次。但是,不論提供框架埋點(diǎn)的方式還是提供裝備庫、SDK的方式,都需要代碼侵入,在應(yīng)用開發(fā)以及框架等升級場景下,應(yīng)用需要重新修改代碼。同時(shí),對于應(yīng)用開發(fā)人員來說,精準(zhǔn)的識別需要埋點(diǎn)的地方也具有一定難度,而且基于代碼侵入的埋點(diǎn)跟蹤級別較低,無法獲取足夠詳細(xì)的運(yùn)行態(tài)信息。
PinPoint與字節(jié)碼增強(qiáng)式采集
深入埋點(diǎn)實(shí)現(xiàn)非侵入
與Zipkin不同,PinPoint是一款開源的應(yīng)用程序性能管理(Application Performance Management)工具,使用字節(jié)碼增強(qiáng)的方式進(jìn)行數(shù)據(jù)源收集,目前只有官方提供的Java Agent探針。字節(jié)碼增強(qiáng)式埋點(diǎn)方式,提倡代碼的非侵入性,不同的編程語言,通過不同的技術(shù)在語言運(yùn)行環(huán)境或基礎(chǔ)庫上植入。對于Java應(yīng)用,利用字節(jié)碼增強(qiáng)技術(shù),在啟動JVM時(shí)通過不同的埋點(diǎn)插件覆蓋不同的通信協(xié)議、中間件、開發(fā)框架,對Java基礎(chǔ)調(diào)用代碼進(jìn)行函數(shù)級埋點(diǎn)。這種埋點(diǎn)方式優(yōu)勢在于能夠拿到堆棧級的調(diào)用信息與其他更多運(yùn)行態(tài)信息,幫助使用者無需日志等輔助手段即可快速完成問題定位。
PinPoint使用字節(jié)碼增強(qiáng)技術(shù)進(jìn)行APM數(shù)據(jù)采集,通過在應(yīng)用啟動時(shí)配置java agent探針的方式,主動干預(yù)應(yīng)用代碼行為,應(yīng)用開發(fā)者無需進(jìn)行代碼修改,由PinPoint來決定在哪些API進(jìn)行數(shù)據(jù)埋點(diǎn)。相比較PinPoint的字節(jié)碼增強(qiáng)技術(shù)與其他APM系統(tǒng)的代碼侵入式埋點(diǎn)來說,字節(jié)碼增強(qiáng)技術(shù)從理論上來說能夠在任何地方進(jìn)行埋點(diǎn),而類似Brave裝備庫等侵入式埋點(diǎn)的方式本身依賴中間件的實(shí)現(xiàn)方式,其提供的應(yīng)用層面的 API 還需要框架底層驅(qū)動的支持,才能實(shí)現(xiàn)攔截。
PinPoint 在實(shí)現(xiàn)之初就考慮到了性能優(yōu)化,如采用 Thrift 的二進(jìn)制變長編碼格式、使用 UDP 作為傳輸鏈路、在傳遞常量的時(shí)候使用數(shù)據(jù)參考字典、使用異步傳輸方式等。但任然存在一些性能問題與使用的約束,并且由于字節(jié)碼增強(qiáng)技術(shù)對開發(fā)人員有較高的要求,其在擴(kuò)展性和社區(qū)生態(tài)方面具有一定的劣勢。
華為APM的技術(shù)實(shí)踐 零侵入式的全周期呵護(hù)
華為APM結(jié)合PinPoint與Zipkin兩種典型系統(tǒng)的優(yōu)點(diǎn),提供更便捷、更高效、性價(jià)比更高的解決方案。
1. 非侵入式數(shù)據(jù)采集:一鍵式采集部署,更高效與健壯的數(shù)據(jù)采集能力
華為APM探針借鑒PinPoint采集探針優(yōu)勢,在采集數(shù)據(jù)模型、輸出組件性能、可靠性等方面進(jìn)行優(yōu)化,并統(tǒng)計(jì)業(yè)界各框架與中間件的使用廣泛性基礎(chǔ)上,增加插件支持能力。以保證在最小的資源占用下,為用戶提供最為有用的性能分析數(shù)據(jù)。
· 探針自動部署:華為APM支持與華為云容器引擎、云應(yīng)用編排等服務(wù)配合使用,可以在應(yīng)用部署時(shí)通過簡單勾選,實(shí)現(xiàn)采集探針的自動部署。
· 支持Zipkin模型:雖然PinPoint與Zipkin均基于Google Dapper的論文,理論基礎(chǔ)大致相同。但是在調(diào)用鏈的數(shù)據(jù)模型上還是有很大的差異性。在開放性以及社區(qū)活躍度等方面,Zipkin更具有優(yōu)勢。為支持Zipkin用戶接入,華為APM探針支持按照Zipkin的數(shù)據(jù)模型進(jìn)行調(diào)用鏈數(shù)據(jù)輸出。
· 數(shù)據(jù)分類優(yōu)化:對于APM調(diào)用性能統(tǒng)計(jì)分析(吞吐量、平均時(shí)延、TPN等),業(yè)界通用的方式為使用調(diào)用鏈數(shù)據(jù)進(jìn)行二次抽取匯聚。該方式下需要盡量多的調(diào)用鏈數(shù)據(jù)樣本,以使統(tǒng)計(jì)數(shù)據(jù)盡可能準(zhǔn)確,勢必消耗更多的應(yīng)用資源。為解決這個(gè)問題,華為APM探針對采集數(shù)據(jù)源進(jìn)行了分類:調(diào)用鏈數(shù)據(jù)與KPI數(shù)據(jù)。KPI數(shù)據(jù)針對每個(gè)業(yè)務(wù)請求按照周期進(jìn)行匯聚,輸出包含請求發(fā)起方、請求服務(wù)方、調(diào)用事務(wù)、調(diào)用狀態(tài)(耗時(shí)、成功或失敗等)等信息。由于KPI數(shù)據(jù)周期性輸出,且相比較調(diào)用鏈數(shù)據(jù)小得多,因此能夠在很小的資源負(fù)載下實(shí)現(xiàn)全量請求采集與統(tǒng)計(jì)。
· 數(shù)據(jù)精準(zhǔn)采集:調(diào)用鏈數(shù)據(jù)更多的關(guān)注調(diào)用超時(shí)(閾值支持自定義)或調(diào)用異常的調(diào)用鏈條。華為APM在基礎(chǔ)采樣率的基礎(chǔ)上,從客戶的實(shí)際運(yùn)維場景觸發(fā),提供精準(zhǔn)采集動態(tài)配置能力。精準(zhǔn)采集支持客戶針對應(yīng)用或交易事務(wù)設(shè)置超時(shí)閾值、周期采集異常調(diào)用樣本個(gè)數(shù)、周期內(nèi)正常調(diào)用樣本,以減少資源消耗的同時(shí)保證異常或超時(shí)請求的數(shù)據(jù)樣本滿足性能分析要求。
· 數(shù)據(jù)傳輸優(yōu)化:針對大數(shù)據(jù)量下數(shù)據(jù)輸出對資源的消耗較高的問題,對輸出組件進(jìn)行優(yōu)化,通過異步文件輸出與異步Pipe輸出、輸出數(shù)據(jù)Cache,減少數(shù)據(jù)類型等方式,優(yōu)化應(yīng)用資源占用。
· 采集逃生機(jī)制:在高并發(fā)峰值場景下,應(yīng)用業(yè)務(wù)請求多,資源消耗大。此時(shí),為保證業(yè)務(wù)正常運(yùn)行,華為APM支持用戶自定義配置逃生資源閾值。在應(yīng)用資源消耗達(dá)到閾值后,華為APM探針主動停止所有運(yùn)維數(shù)據(jù)采集,在資源消耗下降至閾值以下時(shí)自動恢復(fù)數(shù)據(jù)采集。逃生機(jī)制支持動態(tài)配置。
2. 數(shù)字化運(yùn)營:提供業(yè)務(wù)運(yùn)營體驗(yàn)管理與性能分析
實(shí)時(shí)跟蹤每條業(yè)務(wù)交易,快速分析交易的運(yùn)行狀態(tài)并提供診斷能力
· 自定義事務(wù):用戶可根據(jù)每條URL定義事務(wù)名稱,方便理解。
· 健康規(guī)則配置:可以對每條事務(wù)配置健康規(guī)則,如超過1s提示異常。
· 性能追蹤:精確采集異常性能數(shù)據(jù),可對比歷史基線數(shù)據(jù),也能找到應(yīng)用的異常方法,提升運(yùn)維效率。
3. 應(yīng)用程序分析:應(yīng)用關(guān)系與異常一目了然、故障下鉆
· 應(yīng)用發(fā)現(xiàn)與依賴關(guān)系:精確采集異常性能數(shù)據(jù),可對比歷史基線數(shù)據(jù),也能找到應(yīng)用的異常方法,提升運(yùn)維效率。
· 應(yīng)用KPI匯聚:微服務(wù)實(shí)例匯聚到應(yīng)用,KPI數(shù)據(jù)自動匯聚到應(yīng)用。
4. 應(yīng)用程序跟蹤:對異常業(yè)務(wù)調(diào)用鏈追蹤,快速問題定界
支持平臺、資源、應(yīng)用的監(jiān)控和微服務(wù)調(diào)用鏈分析:
· 海量數(shù)據(jù)規(guī)模支撐:支持百萬容器監(jiān)控,秒級查詢響應(yīng)。
· 故障下鉆:通過單擊故障節(jié)點(diǎn)可自動下鉆到故障的微服務(wù)實(shí)例、也可以關(guān)聯(lián)到失敗的調(diào)用鏈和調(diào)用棧,查看失敗函數(shù)的入?yún)⒑头祷刂怠?/p>
評論
查看更多