一击狮、0xcc開篇
2020年3月佛析，得物技術(shù)團(tuán)隊在三個月的時間內(nèi)完成了整個交易體系的重構(gòu)，交付了五彩石項(xiàng)目彪蓬，業(yè)務(wù)系統(tǒng)也進(jìn)入了微服務(wù)時代寸莫。系統(tǒng)服務(wù)拆分之后，雖然每個服務(wù)都會有不同的團(tuán)隊各司其職档冬，但服務(wù)之間的依賴也變得復(fù)雜膘茎，對服務(wù)治理等相關(guān)的基礎(chǔ)建設(shè)要求也更高。
對服務(wù)進(jìn)行監(jiān)控是服務(wù)治理捣郊、穩(wěn)定性建設(shè)中的一個重要的環(huán)節(jié)辽狈，它能幫助提早發(fā)現(xiàn)問題慈参，預(yù)估系統(tǒng)水位呛牲，以及對故障進(jìn)行分析等等。從 2019 年末到現(xiàn)在驮配，得物的應(yīng)用服務(wù)監(jiān)控系統(tǒng)經(jīng)歷了三大演進(jìn)階段娘扩，如今着茸，整個得物的應(yīng)用微服務(wù)監(jiān)控體系已經(jīng)全面融入云原生可觀測性技術(shù) OpenTelemetry。
回顧過去十年間琐旁，應(yīng)用服務(wù)監(jiān)控行業(yè)的競爭也很激烈涮阔，相關(guān)產(chǎn)品如雨后春筍般涌現(xiàn)，如推特在 2012 年開源的 Zipkin灰殴，韓國最大的搜索引擎和門戶網(wǎng)站 Naver 開源的 Pinpoint敬特，近幾年 Uber 公司開源的 Jaeger，以及我們國內(nèi)吳晟開源的 SkyWalking牺陶。
有人說伟阔，這些其實(shí)都?xì)w功于 Google 在 2010 年基于其內(nèi)部大規(guī)模分布式鏈路追蹤系統(tǒng) Dapper 實(shí)踐而發(fā)表的論文，它的設(shè)計理念是一切分布式調(diào)用鏈追蹤系統(tǒng)的始祖掰伸，但其實(shí)早在二十年前（2002年）皱炉，當(dāng)年世界上最大的電商平臺 eBay 就已擁有了調(diào)用鏈追蹤系統(tǒng) CAL(Centralized Application Logging)。2011 年狮鸭，原eBay的中國研發(fā)中心的資深架構(gòu)師吳其敏跳槽至大眾點(diǎn)評合搅，并且深入吸收消化了 CAL 的設(shè)計思想，主導(dǎo)研發(fā)并開源了CAT(Centralized Application Tracking）歧蕉。
CAT 作為國人主導(dǎo)的開源系統(tǒng)灾部，其本地化工作也是做得非常到位，而憑借著架構(gòu)簡單廊谓，開箱即用的特點(diǎn)梳猪，CAT 也是我們得物使用的第一個應(yīng)用監(jiān)控系統(tǒng)。
二蒸痹、 0x01 第一階段
從0～1基于CAT的實(shí)時應(yīng)用監(jiān)控
在得物五彩石項(xiàng)目交付之前春弥，系統(tǒng)僅有基礎(chǔ)設(shè)施層面的監(jiān)控，CAT 的引入叠荠，很好地彌補(bǔ)了應(yīng)用監(jiān)控盲區(qū)匿沛。它支持提供各個維度的性能監(jiān)控報表，健康狀況檢測榛鼎，異常統(tǒng)計逃呼，對故障問題排查起到了積極推動的作用，同時也提供簡單的實(shí)時告警的能力者娱。
CAT 擁有指標(biāo)分鐘級別的聚合統(tǒng)計的能力抡笼，從 UI 上不難看出，它擁有豐富的報表統(tǒng)計能力和問題排障能力黄鳍。
但隨著公司業(yè)務(wù)規(guī)模逐步擴(kuò)大推姻，微服務(wù)粒度也不可避免地變小，我們發(fā)現(xiàn)框沟，CAT 已經(jīng)逐步無法滿足我們的使用場景了：
- 無法直觀呈現(xiàn)全鏈路視圖：
問題排障與日常性能分析的場景也越來越復(fù)雜藏古，對于一個核心場景增炭，其內(nèi)部的調(diào)用鏈路通常復(fù)雜多變，站在流量角度上看拧晕，需要完整地知道它的來源隙姿，上下游鏈路，異步調(diào)用等等厂捞，這對于 CAT 來說可能略顯超綱输玷。
- 缺少圖表定制化能力：
CAT 雖供多維度報表分析，但定制化能力非常有限靡馁，在當(dāng)時饲嗽，業(yè)內(nèi)的圖表組件定制化解決方案逐步向 Grafana + Prometheus 靠攏，但若使用 CAT奈嘿，則無法享受強(qiáng)大的圖表繪制能力貌虾。與此同時，隨著云原生社區(qū)可觀測性項(xiàng)目 OpenTracing 的崛起裙犹，大約不到半年時間我們逐步下線了 CAT尽狠，向 OpenTracing 生態(tài)演進(jìn)。
三叶圃、 0x02 第二階段
持續(xù)創(chuàng)造 基于OpenTracing全鏈路采樣監(jiān)控
OpenTracing 為全鏈路追蹤 Trace 定制了完整的一套協(xié)議標(biāo)準(zhǔn)袄膏，本身并不提供實(shí)現(xiàn)細(xì)節(jié)。在 OpenTracing 協(xié)議中掺冠，Trace 被認(rèn)為是 Span 的有向無環(huán)圖（DAG）沉馆。官方也例舉了以下 8 個 Span 的因果關(guān)系和他們組成的單 Trace示例圖：
在當(dāng)時， OpenTracing 相關(guān)的開源社區(qū)也是異车抡福活躍斥黑，它使用 Jaeger 來解決數(shù)據(jù)的收集，調(diào)用鏈則使用了甘特圖展示：
在 OpenTracing 生態(tài)中眉厨，我們對鏈路的采樣使用頭部采樣策略锌奴， 對于指標(biāo) Metrics，OpenTracing 并沒有制定它的規(guī)范憾股，但在 Google SRE Book 里鹿蜀，關(guān)于 Monitoring Distributed System 章節(jié)中提到了四類黃金指標(biāo)：
吞吐量：如每秒請求數(shù)，通常的實(shí)現(xiàn)方式是服球，設(shè)定一個計數(shù)器茴恰，每完成一次請求將自增。通過計算時間窗口內(nèi)的變化率來計算出每秒的吞吐量斩熊。
延遲：處理請求的耗時往枣。
錯誤率/錯誤數(shù)：如 HTTP 500 錯誤。當(dāng)然，有些即便是 HTTP 200 狀態(tài)也需要根據(jù)特定業(yè)務(wù)邏輯來區(qū)分當(dāng)前請求是否屬于“錯誤”請求婉商。
飽和度：類似服務(wù)器硬件資源如CPU,內(nèi)存,網(wǎng)絡(luò)的使用率等等。
所以渣叛，我們決定使用 Micrometer 庫來對各個組件進(jìn)行吞吐量丈秩，延遲和錯誤率的埋點(diǎn)，從而對 DB 類淳衙，RPC類的組件做性能監(jiān)控蘑秽。因此也可以說，我們第二階段的監(jiān)控是以指標(biāo)監(jiān)控為主箫攀，調(diào)用鏈監(jiān)控為輔的應(yīng)用性能監(jiān)控肠牲。
3.1 使用 Endpoint 貫穿指標(biāo)埋點(diǎn)幫助性能分析
在指標(biāo)埋點(diǎn)過程中，我們在所有的指標(biāo)中引入了“流量入口（Endpoint）”標(biāo)簽靴跛。這個標(biāo)簽的引入缀雳，實(shí)現(xiàn)了根據(jù)不同流量入口來區(qū)分關(guān)聯(lián) DB，緩存梢睛，消息隊列肥印，遠(yuǎn)程調(diào)用類的行為。通過流量入口绝葡，貫穿了一個實(shí)例的所有組件指標(biāo)深碱，基本滿足了以下場景的監(jiān)控：
- RPC 調(diào)用排障，調(diào)用方除了擁有下游接口信息藏畅，也可溯源自身觸發(fā)該調(diào)用的接口敷硅。
- 接口高耗時分析，根據(jù)指標(biāo)愉阎，可還原出單位時間窗口的耗時分解圖快速查看耗時組件绞蹦。
3.2 關(guān)于選型的疑問
你可能會問，鏈路監(jiān)控領(lǐng)域在業(yè)內(nèi)有現(xiàn)成的 APM 產(chǎn)品榜旦，比如 Zipkin, Pinpoint, SkyWalking 等坦辟，為什么當(dāng)時會選擇 OpenTracing + Prometheus 自行埋點(diǎn)？主要有兩大因素：
第一章办，在當(dāng)時锉走，CAT 無法滿足全鏈路監(jiān)控和一些定制化的報表分析，而得物交易鏈路五彩石項(xiàng)目交付也趨于尾聲藕届，貿(mào)然去集成外部一款龐大的 APM 產(chǎn)品在沒有充分的驗(yàn)證下挪蹭，會給服務(wù)帶來穩(wěn)定性風(fēng)險，在極其有限的時間周期內(nèi)不是個理智的選擇休偶。
第二梁厉，監(jiān)控組件是隨著統(tǒng)一的基礎(chǔ)框架來發(fā)布，同時，由另一團(tuán)隊牽頭開發(fā)的全鏈路影子庫路由組件借助了 OpenTracing 隨行數(shù)據(jù)透傳機(jī)制词顾，且與監(jiān)控組件是強(qiáng)耦合關(guān)系八秃，而基礎(chǔ)框架將統(tǒng)籌監(jiān)控，壓測和其他模塊肉盹，借助Spring Boot Starter 機(jī)制昔驱，一定程度上做到了功能的開箱即用，無縫集成上忍。而使用字節(jié)碼增強(qiáng)方式的 Pinpoint, SkyWalking骤肛，無法很好地做到與基礎(chǔ)框架集成，若并行開發(fā)窍蓝，也會多出基礎(chǔ)框架與 Java Agent 兩邊的管理和維護(hù)成本腋颠，減緩迭代速度。
在之后將近兩年的時間里吓笙，應(yīng)用服務(wù)監(jiān)控覆蓋了得物技術(shù)部使用的將近 70% 的組件淑玫，為得物App在 2021 年實(shí)現(xiàn)全年 99.97% 的 SLA 提供了強(qiáng)有力的支持。現(xiàn)在看來面睛，基于 OpenTracing + Prometheus 生態(tài)混移，很好地解決了分布式系統(tǒng)的調(diào)用鏈監(jiān)控，借助 Grafana 圖表工具侮穿，做到了靈活的指標(biāo)監(jiān)控歌径，融合基礎(chǔ)框架，讓業(yè)務(wù)方開箱即用…然而亲茅，我們說第二階段是基于 OpenTracing 全鏈路采樣監(jiān)控回铛，隨著業(yè)務(wù)的高速發(fā)展，這套架構(gòu)的不足點(diǎn)也逐漸顯露出來克锣。
3.3 架構(gòu)特點(diǎn)
-
體驗(yàn)層面
- 指標(biāo)：覆蓋面廣茵肃，維度細(xì)，能清晰地根據(jù)各模塊各維度來統(tǒng)計分析袭祟，基本做到了監(jiān)控靈活的圖表配置需求验残。但不可否認(rèn)它是一種時序聚合數(shù)據(jù)，無法細(xì)化為個體巾乳。假如在某個時間點(diǎn)發(fā)生過幾次高耗時操作您没，當(dāng)吞吐量達(dá)到一定時，平均耗時指標(biāo)曲線仍然趨于平穩(wěn)胆绊，沒有明顯的突出點(diǎn)氨鹏，導(dǎo)致問題發(fā)現(xiàn)能力降低。
- 鏈路：1%的采樣率使得業(yè)務(wù)服務(wù)基本不會因調(diào)用鏈發(fā)送量大而導(dǎo)致性能問題压状，但同時也往往無法從錯誤仆抵，高耗時的場景中找到正好采樣的鏈路。期間，我們曾經(jīng)考慮將頭部采樣策略改為尾部采樣镣丑，但面臨著非常高昂的 SDK 改造成本和復(fù)雜調(diào)用情況下（如異步）采樣策略的回溯舔糖，且無法保證發(fā)生每個高耗時，錯誤操作時能還原整個完整的調(diào)用鏈路莺匠。
- 集成方式：業(yè)務(wù)和基礎(chǔ)框架均采用 Maven 來構(gòu)建項(xiàng)目金吗，使用 Spring Boot Starter "all in one"開箱即用方式集成，極大降低了集成成本的同時慨蛙，也給依賴沖突問題埋下了隱患。
項(xiàng)目迭代層面
迭代周期分化矛盾纪挎，與基礎(chǔ)框架的集成是當(dāng)時快速推廣落地全鏈路監(jiān)控的不二選擇期贫，通過這種方式，Java 服務(wù)的接入率曾一度接近100%异袄，但在業(yè)務(wù)高速發(fā)展的背景下通砍，基礎(chǔ)框架的迭代速度已經(jīng)遠(yuǎn)遠(yuǎn)跟不上業(yè)務(wù)迭代速度了，這也間接制約了整個監(jiān)控系統(tǒng)的迭代烤蜕。
- 數(shù)據(jù)治理層面
數(shù)據(jù)治理成本逐步偏高封孙，由于基礎(chǔ)框架和業(yè)務(wù)系統(tǒng)的迭代節(jié)奏天然的不一致，且每個業(yè)務(wù)系統(tǒng)也有自身的迭代節(jié)奏讽营，放眼全網(wǎng)后端服務(wù)上看虎忌，基礎(chǔ)框架版本參差不齊。
盡管監(jiān)控系統(tǒng)在每一次迭代時都會盡可能保證最大的向后兼容橱鹏，但將近兩年的迭代周期里膜蠢，不同版本造成的數(shù)據(jù)差異也極大制約了監(jiān)控門戶系統(tǒng)天眼的迭代，開發(fā)人員長時間奔波于數(shù)據(jù)上的妥協(xié)莉兰，在很多功能的實(shí)現(xiàn)上曲線救國挑围。
- 穩(wěn)定性層面
相關(guān)預(yù)案依托于 Spring 框架 Bean 的自動裝配邏輯，業(yè)務(wù)方理解成本低糖荒，便于變更杉辙，但缺少細(xì)粒度的預(yù)案，比如運(yùn)行時期間特定邏輯降級等等捶朵。
- 2021 年下半年開始蜘矢，為了充分平衡以上的收益與風(fēng)險，我們決定將監(jiān)控采集端與基礎(chǔ)框架解耦综看，獨(dú)立迭代硼端。在此之前，在 CNCF（云原生計算基金會）的推動下寓搬，OpenTracing 也與 OpenCensus 合并成為了一個新項(xiàng)目 OpenTelemetry珍昨。
四、 0x03 第三階段
向前一步 基于OpenTelemetry全鏈路應(yīng)用性能監(jiān)控
OpenTelemetry 的定位在于可觀測性領(lǐng)域中對遙測數(shù)據(jù)采集和語義規(guī)范的統(tǒng)一，有 CNCF (云原生計算基金會)的加持镣典，近兩年里隨著越來越多的人關(guān)注和參與兔毙，整個體系也越發(fā)成熟穩(wěn)定。
其實(shí)兄春，我們在2020年底就已開始關(guān)注 OpenTelemetry 項(xiàng)目澎剥，只不過當(dāng)時該項(xiàng)目仍處于萌芽階段， Trace, Metrics API 還在 Alpha 階段，有很多不穩(wěn)定因素，考慮到需盡快投入生產(chǎn)使用帅容，筆者曾在 2021 年中到年末期間也或多或少參與了 OpenTelemetry 社區(qū)相關(guān) issue 的討論颤陶，遙測模塊的開發(fā)，底層數(shù)據(jù)協(xié)議的一致和一些 BUG 的修復(fù)。在這半年期間，相關(guān) API 和 SDK 隨著越來越多的人參與也逐步趨于穩(wěn)定。
OpenTelemetry架構(gòu)（圖源自 opentelemetry.io）
4.1 邁入 Trace2.0 時代
OpenTelemetry 的定位致力于將可觀測性三大要素 Metrics,Trace,Log 進(jìn)行統(tǒng)一绞佩，在遙測 API 制定上，提供了統(tǒng)一的上下文以便 SDK 實(shí)現(xiàn)層去關(guān)聯(lián)猪钮。如 Metrics 與 Trace 的關(guān)聯(lián)品山，筆者認(rèn)為體現(xiàn)在 OpenTelemetry 在 Metrics 的實(shí)現(xiàn)上包含了對 OpenMetrics 標(biāo)準(zhǔn)協(xié)議的支持，其中 Exemplar 格式的數(shù)據(jù)打通了 Trace 與 Metrics 的橋梁：
OpenMetrics 是建立在 Prometheus 格式之上的規(guī)范烤低，做了更細(xì)粒度的調(diào)整肘交，且基本向后兼容 Prometheus 格式。
在這之前扑馁，Metrics 指標(biāo)類型的數(shù)據(jù)無法精確關(guān)聯(lián)到具體某個或某些 Trace 鏈路酸些，只能根據(jù)時間戳粗略關(guān)聯(lián)特定范圍內(nèi)的鏈路。這個方案的缺陷源自指標(biāo)采集器 vmagent 每隔 10s~30s 的 Pull 模式中檐蚜，指標(biāo)的時間戳取決于采集時刻魄懂，與 Trace 調(diào)用時間并不匹配。
Exemplar 數(shù)據(jù)在直方圖度量格式末尾會追加當(dāng)前上下文中的 Trace ID,Span ID 信息闯第，如下：
shadower_virtual_field_map_operation_seconds_bucket{holder="Filter:Factory",key="WebMvcMetricsFilter",operation="get",tcl="AppClassLoader",value="Servlet3FilterMappingResolverFactory",le="0.2"} 3949.0 1654575981.216 # {span_id="48f29964fceff582",trace_id="c0a80355629ed36bcd8fb1c6c89dedfe"} 1.0 1654575979.751
為了采集 Exemplar 格式指標(biāo)市栗，同時又需防止分桶標(biāo)簽“l(fā)e”產(chǎn)生的高基數(shù)問題，我們二次開發(fā)了指標(biāo)采集 vmagent咳短，額外過濾攜帶 Exemplar 數(shù)據(jù)的指標(biāo)填帽，并將這類數(shù)據(jù)異步批量發(fā)送到了 Kafka，經(jīng)過 Flink 消費(fèi)后落入 Clickhouse 后咙好，由天眼監(jiān)控門戶系統(tǒng)提供查詢接口和UI篡腌。
分位線統(tǒng)計與Exemplar 數(shù)據(jù)關(guān)聯(lián)UI示意圖
在數(shù)據(jù)上報層，OpenTelemetry Java SDK 使用了比 JDK 原生的阻塞隊列性能更好的 Mpsc (多生產(chǎn)單消費(fèi)）隊列勾效，它使用大量的 long 類型字段來做內(nèi)存區(qū)域填充嘹悼，用空間換時間解決了偽共享問題叛甫，減少了并發(fā)情況下的寫競爭來提高性能。
在流量高峰時期杨伙，鏈路數(shù)據(jù)的發(fā)送隊列這一塊的性能從火焰圖上看 CPU 占比平均小于2%其监，日常服務(wù)CPU整體水位與0采樣相比幾乎沒有明顯差距，因此我們經(jīng)過多方面壓測對比后限匣，決定在生產(chǎn)環(huán)境客戶端側(cè)開放鏈路數(shù)據(jù)的全量上報抖苦，實(shí)現(xiàn)了在得物技術(shù)史上的全鏈路 100% 采樣，終結(jié)了一直以來因?yàn)榈筒蓸勇蕦?dǎo)致問題排查困難的問題米死，至此锌历，在第三階段，得物的全鏈路追蹤技術(shù)正式邁入 Trace2.0 時代峦筒。
得益于 OpenTelemetry 整體的可插拔式 API 設(shè)計究西，我們二次開發(fā)了 OpenTelemetry Java Instrumentation 項(xiàng)目 Shadower Java，擴(kuò)展了諸多功能特性：
4.2 引入控制平面管理客戶端采集行
使用控制平面勘天，通過客戶端監(jiān)聽機(jī)制來確保配置項(xiàng)的下發(fā)動作怔揩，包括：
- 實(shí)時動態(tài)采樣控制
- 診斷工具 Arthas 行為控制
- 實(shí)時全局降級預(yù)案
- 遙測組件運(yùn)行時開關(guān)
- 實(shí)時 RPC 組件出入?yún)⑹占_關(guān)
- 實(shí)時高基數(shù)指標(biāo)標(biāo)簽的降級控制
- 按探針版本的預(yù)案管理
- 基于授權(quán)數(shù)的灰度接入策略捉邢。
- ... ...
控制平面的引入脯丝，彌補(bǔ)了無降級預(yù)案的空白，也提供了更加靈活的配置伏伐，支持了不同流量場景下快速變更數(shù)據(jù)采集方案：
4.3 獨(dú)立的啟動模塊
為了解決業(yè)務(wù)方因集成基礎(chǔ)框架而長期面臨的依賴沖突問題宠进，以及多版本共存引起的數(shù)據(jù)格式分散與兼容問題，我們自研了無極探針工具箱 Promise, 它是個通用的 javaagent launcher, 結(jié)合遠(yuǎn)端存儲藐翎，支持可配置化任意 javaagent 的下載材蹬，更新，安裝和啟動：
[plugins]
enables = shadower,arthas,pyroscope,chaos-agent
[shadower]
artifact_key = /javaagent/shadower-%s-final.jar
boot_class = com.shizhuang.apm.javaagent.bootstrap.AgentBootStrap
classloader = system
default_version = 115.16
[arthas]
artifact_key = /tools/arthas-bin.zip
;boot_class = com.taobao.arthas.agent334.AgentBootstrap
boot_artifact = arthas-agent.jar
premain_args = .attachments/arthas/arthas-core.jar;;ip=127.0.0.1
[pyroscope]
artifact_key = /tools/pyroscope.jar
[chaos-agent]
artifact_key = /javaagent/chaos-agent.jar
boot_class = com.chaos.platform.agent.DewuChaosAgentBootstrap
classloader = system
apply_envs = dev,test,local,pre,xdw
4.4 基于 Otel API 的擴(kuò)展
4.4.1 豐富的組件度量
在第二階段 OpenTracing 時期吝镣，我們使用 Endpoint 貫穿了多個組件的指標(biāo)埋點(diǎn)堤器，這個優(yōu)秀的特性也延續(xù)至第三階段，我們基于底層 Prometheus SDK 設(shè)計了一套完善的指標(biāo)埋點(diǎn) SDK末贾，并且借助字節(jié)碼插樁的便捷闸溃，優(yōu)化并豐富了更多了組件庫。（在此階段拱撵，OpenTelemetry SDK 主版本是 1.3.x 辉川，相關(guān) Metrics SDK 還處于Alpha 階段）
Otel 的 Java Instrumnetation 主要使用 WeakConcurrentMap 來做異步鏈路上下文數(shù)據(jù)傳遞和同線程上下文關(guān)聯(lián)的容器，由于 Otel 對許多流行組件庫做了增強(qiáng)拴测，因此 WeakConcurrentMap 的使用頻率也是非常高的乓旗，針對這個對象的 size 做監(jiān)控，有助于排查因探針導(dǎo)致的內(nèi)存泄露問題集索，且它的增長率一旦達(dá)到我們設(shè)定的閾值便會告警屿愚，提早進(jìn)行人工干預(yù)汇跨，執(zhí)行相關(guān)預(yù)案，防止線上故障發(fā)生渺鹦。
部分自監(jiān)控面板
4.4.2 擴(kuò)展鏈路透傳協(xié)
- 引入RPC ID
為了更好地關(guān)聯(lián)上下游應(yīng)用扰法，讓每個流量都有“身份”，我們擴(kuò)展了TextMapPropagator 接口毅厚，讓每個流量在鏈路上都知道請求的來源塞颁，這對跨區(qū)域，環(huán)境調(diào)用排障場景起到關(guān)鍵性作用吸耿。
此外祠锣，對于跨端場景，我們參考了阿里鷹眼調(diào)用鏈RPCID模型咽安，增加了RpcID字段伴网，這個字段在每次發(fā)生跨端調(diào)用時末尾數(shù)值會自增，而對于下游應(yīng)用妆棒，字段本身的層級自增：
該字段擁有以下作用：
支持提供精簡化的調(diào)用鏈路視圖澡腾，查詢臃腫鏈路（如那些涉及緩存，DB調(diào)用大于 2000 Span的鏈路）時只提供 RPC 調(diào)用節(jié)點(diǎn)和調(diào)用層次關(guān)系糕珊。
鏈路保真动分，客戶端鏈路數(shù)據(jù)上報隊列并不是個無界限隊列，當(dāng)客戶端自身調(diào)用頻繁時红选，若上報隊列堆積達(dá)到閾值即會丟棄澜公，這會造成整個鏈路的不完整，當(dāng)然這是預(yù)期內(nèi)的現(xiàn)象喇肋，但若沒有RpcID字段坟乾，鏈路視圖將無法關(guān)聯(lián)丟失的節(jié)點(diǎn)，從而導(dǎo)致整個鏈路層級混亂失真蝶防。
- 自定義 Trace ID
為了實(shí)現(xiàn)鏈路詳情頁高效的檢索效率甚侣，我們擴(kuò)展 TraceID 生成邏輯，ID的前8位使用實(shí)例IP间学，中8位使用當(dāng)前時間戳殷费，后16位采用隨機(jī)數(shù)生成。
32位自定義traceId：c0a8006b62583a724327993efd1865d8
c0a8006b 62583a72 4327993efd1865d8
| | |
高8位(IP) 中8位(Timestmap) 低16位(Random)
這樣的好處有兩點(diǎn)：
通過 TraceID 反向解析時間戳菱鸥，鎖定時間范圍宗兼，有助于提高存儲庫 Clickhouse 的檢索效率，此外也能幫助決定當(dāng)前的 Trace 應(yīng)該查詢熱庫還是冷庫氮采。
綁定實(shí)例 IP殷绍，有助于關(guān)聯(lián)當(dāng)前 Trace 流量入口所屬的實(shí)例，在某些極端場景鹊漠，當(dāng)鏈路上的節(jié)點(diǎn)檢索不到時主到，也能通過實(shí)例和時間兩個要素來做溯源茶行。
- 異步調(diào)用識別
業(yè)務(wù)系統(tǒng)為了提高服務(wù)吞吐量，充分運(yùn)用硬件資源登钥，異步調(diào)用場景可謂無處不在畔师。我們基于Otel實(shí)現(xiàn)的異步鏈路上下文傳遞的基礎(chǔ)上，額外擴(kuò)充了"async_flag"字段來標(biāo)識當(dāng)前節(jié)點(diǎn)相對于父節(jié)點(diǎn)的調(diào)用關(guān)系牧牢，從而在展示層上能迅速找出發(fā)生異步調(diào)用的場景
4.4.3 更清晰的調(diào)用鏈結(jié)構(gòu)
在 Otel 支持的部分組件中看锉，有些操作不涉及到網(wǎng)絡(luò)調(diào)用，或者具有非常頻繁的操作塔鳍，如 MVC 過程伯铣，數(shù)據(jù)庫連接獲取等，通常來說這類節(jié)點(diǎn)在鏈路詳情主視圖中的意義不大轮纫，因此我們對這類節(jié)點(diǎn)的產(chǎn)生邏輯進(jìn)行了優(yōu)化調(diào)整腔寡，使得整個鏈路主體結(jié)構(gòu)聚焦于“跨端”，同時掌唾，對部分核心組件關(guān)鍵內(nèi)部方法細(xì)節(jié)做了增強(qiáng)放前，以“事件”的形式掛載于它們的父節(jié)點(diǎn)上，便于更細(xì)粒度的排查：
RPC調(diào)用關(guān)鍵內(nèi)部事件
DB 調(diào)用連接獲取事件
4.4.4 profiling 的支持
1）線程棧分析的集成糯彬。通過集成 Arthas 這類工具凭语，可以很方便地查看某個實(shí)例線程的實(shí)時堆棧信息，同時對采樣間隔做控制情连，避免頻繁抓取影響業(yè)務(wù)自身性能叽粹。
2）通過集成 pyroscope览效，打通高延遲性能排查最后一公里却舀。Pyroscope 對 async profiler 做了二次開發(fā)，同時也支持 Otel 去集成锤灿，但截至目前挽拔，官方并沒有實(shí)現(xiàn)完整的 Profiling 行為的生命周期，而 Profiling 行為一定程度上會影響性能但校，于是我們對官方 Pyroscope 的生命周期做了擴(kuò)展螃诅，實(shí)現(xiàn)“停止”行為的同時，采用時間輪算法來檢測特定操作的耗時状囱，當(dāng)達(dá)到期望的閾值將觸發(fā)開啟 profiling, 待操作結(jié)束或超過最大閾值則停止术裸。
關(guān)于性能診斷相關(guān)的運(yùn)用，請期待后續(xù)診斷專題亭枷。
五袭艺、 0xff 結(jié)語
縱觀得物在應(yīng)用監(jiān)控采集領(lǐng)域的三大里程碑迭代，第一階段的 CAT 則是 0~1 的過程叨粘，它提供了應(yīng)用服務(wù)對自身觀測的途徑猾编，讓業(yè)務(wù)方第一次真實(shí)地了解了服務(wù)運(yùn)行狀況瘤睹，而第二階段開始，隨著業(yè)務(wù)發(fā)展的飛速提升答倡，業(yè)務(wù)方對監(jiān)控系統(tǒng)的要求就不僅只是從無到有了轰传，而是要精細(xì)，準(zhǔn)確瘪撇。
因此获茬，快速迭代的背景下，功能與架構(gòu)演進(jìn)層面的矛盾倔既，加上外部云原生大背景下可觀測領(lǐng)域的發(fā)展因素锦茁，促使我們進(jìn)行了基于 OpenTelemetry 體系的第三階段的演進(jìn)。功能叉存，產(chǎn)品層面均取得了優(yōu)異的結(jié)果码俩。如今，我們即將進(jìn)行下一階段的演進(jìn)歼捏，深度結(jié)合調(diào)用鏈與相關(guān)診斷工具稿存，以第三階段為基礎(chǔ)，讓得物全鏈路追蹤技術(shù)正式邁入性能分析診斷時代瞳秽。
六瓣履、 關(guān)于我們
得物監(jiān)控團(tuán)隊提供一站式的可觀測性平臺，負(fù)責(zé)鏈路追蹤练俐、時序數(shù)據(jù)庫袖迎、日志系統(tǒng)，包括自定義大盤腺晾、應(yīng)用大盤燕锥、業(yè)務(wù)監(jiān)控、智能告警悯蝉、AIOPS等排障分析归形。
參考文章：
- Dapper, a Large-Scale Distributed Systems Tracing Infrastructure
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36356.pdf
- 大眾點(diǎn)評開源分布式監(jiān)控平臺 CAT 深度剖析-阿里云開發(fā)者社區(qū)
https://developer.aliyun.com/article/269295
趣談“分布式鏈路追蹤“組件發(fā)展史https://xie.infoq.cn/article/8e06e8d9e43d1768e021225cb
Jaeger Sampling
https://www.jaegertracing.io/docs/1.39/sampling/A brief history of OpenTelemetry (So Far) | Cloud Native Computing Foundation
https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/
- The OpenMetrics project -Creating a standard for exposing metrics data
Merging OpenTracing and OpenCensus: A Roadmap to Convergence
Monitoring Distributed Systems
*文/櫛楓忻垣
關(guān)注得物技術(shù)，每周一三五晚18:30更新技術(shù)干貨
要是覺得文章對你有幫助的話鼻由，歡迎評論轉(zhuǎn)發(fā)點(diǎn)贊～
