鏈路跟蹤與無(wú)侵入排查實(shí)戰(zhàn))
如果你也經(jīng)歷過(guò)微服務(wù)環(huán)境下的深夜排查用戶反饋下單慢你打開(kāi)三臺(tái)服務(wù)器的日志先按時(shí)間戳對(duì)齊再逐個(gè)服務(wù)找堆棧最后還得靠猜“大概是哪個(gè)環(huán)節(jié)”卡住了那這篇關(guān)于SpringBoot集成Skywalking鏈路跟蹤的內(nèi)容就是來(lái)解決這個(gè)問(wèn)題的。這是SpringBoot綜合實(shí)戰(zhàn)系列的第三十二篇。這一篇不寫(xiě)業(yè)務(wù)接口也不講數(shù)據(jù)庫(kù)優(yōu)化而是把一個(gè)日常排查利器裝進(jìn)你的項(xiàng)目里Skywalking。它通過(guò)Java Agent探針實(shí)現(xiàn)無(wú)侵入接入不需要改業(yè)務(wù)代碼、不需要給每個(gè)服務(wù)手動(dòng)加依賴啟動(dòng)參數(shù)里加一行-javaagent你的SpringBoot應(yīng)用就能自動(dòng)上報(bào)調(diào)用鏈路、服務(wù)拓?fù)浜椭虚g件指標(biāo)。我會(huì)從“為什么需要鏈路跟蹤”講起把Skywalking的各個(gè)組件、后端部署步驟、SpringBoot接入方式、自定義埋點(diǎn)和日志關(guān)聯(lián)完整演示一遍最后附帶一個(gè)真實(shí)排查案例和一份踩坑記錄。適合正在做微服務(wù)改造、被“跨服務(wù)問(wèn)題定位難”折磨過(guò)的后端開(kāi)發(fā)者也適合想在項(xiàng)目里搭可觀測(cè)性基礎(chǔ)設(shè)施的技術(shù)同學(xué)。1. 一次“半小時(shí)排查”引發(fā)的思考鏈路跟蹤到底在解決什么1.1 日志碎片化時(shí)代的“拼圖游戲”單體應(yīng)用時(shí)代一次請(qǐng)求的日志都在同一個(gè)進(jìn)程里grep一下就完了。微服務(wù)拆開(kāi)之后一次下單請(qǐng)求可能經(jīng)過(guò)網(wǎng)關(guān)、訂單服務(wù)、庫(kù)存服務(wù)、優(yōu)惠券服務(wù)中間還夾著MQ異步消息。日志散落在不同機(jī)器的不同文件里時(shí)間戳稍微偏移一點(diǎn)你拼出來(lái)的“調(diào)用順序”可能就是錯(cuò)的。我見(jiàn)過(guò)太多團(tuán)隊(duì)在這種場(chǎng)景下的排查姿勢(shì)先在A服務(wù)找到“調(diào)用庫(kù)存服務(wù)超時(shí)”再跑去B服務(wù)翻對(duì)應(yīng)時(shí)間段的日志如果碰巧兩個(gè)服務(wù)都沒(méi)打traceId就要靠請(qǐng)求參數(shù)和時(shí)間窗口去關(guān)聯(lián)。運(yùn)氣好十分鐘運(yùn)氣不好一下午。這種“拼圖游戲”最可怕的地方在于——每次都要從頭拼一遍經(jīng)驗(yàn)根本無(wú)法沉淀。鏈路跟蹤解決的就是這個(gè)核心問(wèn)題把一個(gè)請(qǐng)求經(jīng)過(guò)的所有服務(wù)、所有中間件調(diào)用自動(dòng)串成一條帶唯一ID的調(diào)用鏈告訴你每一跳花了多久、在哪里失敗、失敗原因是什么。它能幫你把排查從“按時(shí)間戳猜”變成“按瀑布圖精確定位”。1.2 誰(shuí)最需要鏈路跟蹤如果你還在做單體應(yīng)用鏈路跟蹤的價(jià)值確實(shí)沒(méi)那么大單進(jìn)程里一臺(tái)Arthas基本夠用。但只要你滿足下面任意一條就應(yīng)該認(rèn)真考慮這件事服務(wù)拆成了三個(gè)以上且存在跨服務(wù)同步調(diào)用Feign、RestTemplate、Dubbo等。線上偶發(fā)慢請(qǐng)求日志里看不到明顯的Exception只能靠“感覺(jué)”判斷是數(shù)據(jù)庫(kù)慢還是外部調(diào)用慢。團(tuán)隊(duì)協(xié)作時(shí)經(jīng)常出現(xiàn)“A服務(wù)說(shuō)是B服務(wù)的鍋B服務(wù)甩給C”的扯皮。想給技術(shù)團(tuán)隊(duì)建立一套統(tǒng)一的、不受業(yè)務(wù)代碼污染的可觀測(cè)性底座。只要命中其中一條鏈路跟蹤就不是錦上添花而是排查效率的剛需。1.3 為什么選Skywalking而不是Zipkin和Jaeger市面上的APM方案不少我周?chē)娜肆牡米疃嗟木褪荶ipkin、Jaeger、Skywalking三家。它們的定位略有差異我整理了一個(gè)對(duì)比供你選型參考維度SkywalkingZipkin/SleuthJaeger接入方式Java Agent無(wú)侵入依賴SDK/注解侵入性強(qiáng)Agent或SDK功能覆蓋拓?fù)?、追蹤、指?biāo)、告警一體以追蹤為主以追蹤為主存儲(chǔ)ES、MySQL、H2等ES、MySQL、CassandraES、Cassandra中文資料活躍踩坑文章多較少一般學(xué)習(xí)成本低基本不用改代碼中要寫(xiě)配置和依賴中個(gè)人感受Spring Cloud Sleuth Zipkin那套勝在和Spring生態(tài)天然融合但每個(gè)服務(wù)都要引入依賴、寫(xiě)配置已有的老項(xiàng)目接入成本偏高。Skywalking最打動(dòng)我的一點(diǎn)是“探針注入”它基于Java Agent機(jī)制在類(lèi)加載階段做字節(jié)碼增強(qiáng)應(yīng)用代碼一行都不用動(dòng)。這個(gè)特性對(duì)老舊項(xiàng)目尤其友好——不用發(fā)版不用等排期改個(gè)JVM啟動(dòng)參數(shù)就能把鏈路數(shù)據(jù)采起來(lái)。2. 別急著寫(xiě)代碼Skywalking的四個(gè)角色先對(duì)齊2.1 Agent探針藏在JVM里的“臥底”Skywalking的Agent是一段獨(dú)立運(yùn)行的Java程序通過(guò)-javaagent參數(shù)掛載到你的SpringBoot進(jìn)程里。掛載之后它會(huì)在類(lèi)加載的時(shí)候?qū)δ繕?biāo)類(lèi)的字節(jié)碼做增強(qiáng)在HTTP入口、Feign調(diào)用、JDBC執(zhí)行等關(guān)鍵位置自動(dòng)織入“埋點(diǎn)邏輯”。拿Tomcat內(nèi)嵌場(chǎng)景舉例SpringBoot啟動(dòng)時(shí)Agent發(fā)現(xiàn)你要加載org.apache.catalina.core.StandardHostValve這類(lèi)Servlet容器類(lèi)就會(huì)在它的invoke方法前后插入耗時(shí)記錄和上下文傳遞邏輯。之后你完全感覺(jué)不到它的存在但它已經(jīng)在默默記錄每一次請(qǐng)求的入口、出口和中間經(jīng)過(guò)的組件。這才是“無(wú)侵入”的真正含義——不是少寫(xiě)幾行代碼而是從機(jī)制上繞開(kāi)了對(duì)業(yè)務(wù)代碼的觸碰。探針底層的字節(jié)碼增強(qiáng)用的是Byte Buddy這是Java生態(tài)里比較成熟的字節(jié)碼操作庫(kù)對(duì)類(lèi)加載器兼容性處理得比較好。2.2 OAP、存儲(chǔ)和UI大腦、記憶與儀表盤(pán)Agent采集到數(shù)據(jù)之后需要有個(gè)地方接收、分析、存儲(chǔ)、展示這就要靠另外三個(gè)組件OAPObservability Analysis Platform接收Agent通過(guò)gRPC上報(bào)的數(shù)據(jù)做指標(biāo)聚合、鏈路關(guān)系分析相當(dāng)于整個(gè)系統(tǒng)的大腦。存儲(chǔ)OAP把處理好的數(shù)據(jù)寫(xiě)入存儲(chǔ)層。默認(rèn)內(nèi)置H2生產(chǎn)環(huán)境一般換成Elasticsearch。Web UI一個(gè)獨(dú)立的前端應(yīng)用負(fù)責(zé)把拓?fù)洹⒆粉?、指?biāo)可視化成儀表盤(pán)。在實(shí)際部署中OAP、存儲(chǔ)、UI這三者可以拆開(kāi)部署在不同機(jī)器上。Agent只跟OAP通信OAP只跟存儲(chǔ)和UI打交道鏈路很清晰。2.3 一次請(qǐng)求在Skywalking里的完整旅程為了讓你對(duì)整體流程有畫(huà)面感我按順序描述一遍用戶請(qǐng)求打到SpringBoot應(yīng)用Agent在入口Span上生成全局鏈路IDTraceId。應(yīng)用內(nèi)部調(diào)用另一個(gè)服務(wù)或訪問(wèn)數(shù)據(jù)庫(kù)時(shí)Agent自動(dòng)創(chuàng)建子Span記錄組件類(lèi)型、目標(biāo)地址、耗時(shí)、狀態(tài)碼。請(qǐng)求結(jié)束后Agent把完整調(diào)用鏈分批通過(guò)gRPC上報(bào)到OAP默認(rèn)端口11800。OAP解析數(shù)據(jù)把鏈路以Span為單位入庫(kù)并計(jì)算服務(wù)間依賴關(guān)系、RT分布、成功率等指標(biāo)。UI通過(guò)OAP的HTTP接口默認(rèn)12800查詢數(shù)據(jù)渲染成你看到的拓?fù)鋱D和追蹤瀑布圖。只要理解了這條數(shù)據(jù)流后面排查“數(shù)據(jù)為什么沒(méi)出來(lái)”“為什么只有一個(gè)服務(wù)有數(shù)據(jù)”就會(huì)順手很多。3. 跑起來(lái)再說(shuō)OAPUI后端部署與存儲(chǔ)切換3.1 下載發(fā)行包并啟動(dòng)默認(rèn)版本后端部署最省心的方式是從Apache Skywalking官網(wǎng)下載二進(jìn)制發(fā)行包里面自帶OAP、UI和Agent三件套目錄結(jié)構(gòu)大概是skywalking/ ├── bin/ # 啟動(dòng)腳本 ├── config/ # OAP配置 ├── oap-libs/ # OAP運(yùn)行依賴 ├── webapp/ # UI前端 └── agent/ # Java探針Linux/Mac啟動(dòng)cd skywalking ./bin/startup.shWindows啟動(dòng)cd skywalking bin\startup.batstartup.sh會(huì)同時(shí)拉起OAP和UI兩個(gè)進(jìn)程。默認(rèn)配置下OAP的gRPC端口是11800HTTP查詢端口是12800UI端口是8080。注意8080很容易被你的業(yè)務(wù)應(yīng)用占用如果啟動(dòng)后發(fā)現(xiàn)UI訪問(wèn)不了先進(jìn)去看日志多半是端口沖突。3.2 驗(yàn)證安裝是否成功啟動(dòng)后訪問(wèn)http://localhost:8080如果能看到Skywalking的儀表盤(pán)首頁(yè)說(shuō)明后端已經(jīng)跑起來(lái)了。沒(méi)有頁(yè)面的話按下面順序排查看logs/skywalking-oap-server.log搜“oap server started”或“started successfully”關(guān)鍵字?？磜ebapp/logs目錄下的日志確認(rèn)UI的Tomcat是否正常啟動(dòng)。檢查端口占用lsof -i:8080、lsof -i:11800、lsof -i:12800哪個(gè)被占就改哪個(gè)。這一步只需要“能打開(kāi)頁(yè)面”就行頁(yè)面里暫時(shí)沒(méi)有數(shù)據(jù)是正常的因?yàn)檫€沒(méi)有任何Agent接入。3.3 把存儲(chǔ)從H2切到Elasticsearch默認(rèn)情況OAP使用H2文件數(shù)據(jù)庫(kù)適合本地演示但別用在生產(chǎn)數(shù)據(jù)量大了之后查詢明顯變慢而且H2畢竟不是為海量時(shí)序數(shù)據(jù)設(shè)計(jì)的。生產(chǎn)環(huán)境我建議用Elasticsearch。切存儲(chǔ)的操作在config/application.yml的storage段進(jìn)行。核心就兩個(gè)地方storage: selector: ${SW_STORAGE:elasticsearch} elasticsearch: clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:127.0.0.1:9200} namespace: ${SW_NAMESPACE:prod_log_trace}順手給ES加一個(gè)namespace可以避免和其他系統(tǒng)共用ES時(shí)索引沖突Skywalking會(huì)在索引名前面拼上這個(gè)前綴。這里要特別提醒一個(gè)版本問(wèn)題Skywalking和ES的版本是有兼容矩陣的。以Skywalking 9.x為例和ES 7.x搭配最成熟ES 8.x要用對(duì)應(yīng)的新版本支持。別想當(dāng)然地“ES越新越好”我有一個(gè)朋友就是把ES從7升到8之后OAP一直刷索引創(chuàng)建失敗最后查官方文檔才發(fā)現(xiàn)版本沒(méi)對(duì)齊。具體兼容性請(qǐng)以官方文檔的Compatibility列表為準(zhǔn)不要賭。4. SpringBoot接入Agent探針無(wú)侵入的關(guān)鍵一步4.1 命令行與IDEA本地調(diào)試的接入方式后端就緒后SpringBoot這邊要做的唯一操作就是給JVM加啟動(dòng)參數(shù)。先看命令行方式j(luò)ava -javaagent:/opt/skywalking/agent/skywalking-agent.jar \ -Dskywalking.agent.service_nameorder-service \ -Dskywalking.collector.backend_service127.0.0.1:11800 \ -jar order-service.jar如果你在IDEA里做本地聯(lián)調(diào)不用每次敲命令直接在Run/Debug Configurations里找到你的SpringBoot啟動(dòng)類(lèi)在VM options里填入同樣的參數(shù)-javaagent:D:/skywalking/agent/skywalking-agent.jar -Dskywalking.agent.service_nameorder-service -Dskywalking.collector.backend_service127.0.0.1:11800Windows下-javaagent路徑如果有空格整體要加雙引號(hào)。這個(gè)坑很小但等你排查到深夜就會(huì)發(fā)現(xiàn)它有多煩人。參數(shù)說(shuō)明-javaagent指向skywalking-agent.jar的絕對(duì)路徑。-Dskywalking.agent.service_name該服務(wù)在鏈路平臺(tái)里的顯示名。建議和spring.application.name保持一致團(tuán)隊(duì)內(nèi)必須約定統(tǒng)一命名規(guī)范否則UI里會(huì)出現(xiàn)一堆莫名其妙的名字。-Dskywalking.collector.backend_serviceOAP的gRPC地址即11800端口。多OAP節(jié)點(diǎn)用逗號(hào)分隔。4.2 Docker和K8s的接入方式容器化環(huán)境不能手改啟動(dòng)命令最常用的辦法是利用JVM的JAVA_TOOL_OPTIONS環(huán)境變量。Docker啟動(dòng)時(shí)指定docker run -d \ -e JAVA_TOOL_OPTIONS-javaagent:/opt/skywalking/agent/skywalking-agent.jar -Dskywalking.agent.service_nameorder-service -Dskywalking.collector.backend_serviceskywalking-oap:11800 \ -v /opt/skywalking/agent:/opt/skywalking/agent \ order-service:latestK8s的話在Deployment的env里加一條JAVA_TOOL_OPTIONS環(huán)境變量把Agent路徑通過(guò)emptyDir掛載進(jìn)去即可。這樣Pod每次重建時(shí)探針都在同一路徑下配置也統(tǒng)一。4.3 怎么確認(rèn)探針真的生效了接完Agent重啟應(yīng)用后最關(guān)心的第一件事就是“數(shù)據(jù)到底上報(bào)沒(méi)有”。我一般按三步驗(yàn)證看應(yīng)用啟動(dòng)日志Skywalking掛載成功時(shí)會(huì)有Skywalking agent相關(guān)輸出沒(méi)看到就是-javaagent參數(shù)沒(méi)生效?？碼gent/logs/skywalking-api.log這個(gè)日志文件記錄了Agent的運(yùn)行狀態(tài)?？吹絞RPC連接成功類(lèi)信息說(shuō)明和OAP的網(wǎng)絡(luò)是通的。到UI的“服務(wù)列表”或“拓?fù)鋱D”頁(yè)面選對(duì)應(yīng)服務(wù)名多打幾個(gè)接口等十幾秒再看。第一次注冊(cè)有延遲別急著懷疑配置。如果前兩步都正常但UI里就是沒(méi)數(shù)據(jù)最可能的原因是我在第七節(jié)要講的幾個(gè)坑先繼續(xù)往下看。5. 進(jìn)階玩法自定義埋點(diǎn)、采樣控制與日志TID關(guān)聯(lián)5.1 哪些鏈路信息不用寫(xiě)代碼就能拿到Skywalking的插件體系非常豐富以下場(chǎng)景默認(rèn)就能被自動(dòng)增強(qiáng)HTTP入口SpringMVC / SpringBoot內(nèi)嵌Tomcat / 網(wǎng)關(guān)Spring Cloud Gateway。服務(wù)間調(diào)用Feign、RestTemplate、OkHttp、HttpClient、Dubbo。數(shù)據(jù)訪問(wèn)JDBC、MyBatis、JPASQL語(yǔ)句和綁定參數(shù)都能記錄。緩存與消息Redis、Kafka、RocketMQ、RabbitMQ注意插件版本和中間件版本的對(duì)應(yīng)關(guān)系。這也是我推薦用它兜底的原因團(tuán)隊(duì)里有人忘了打日志、忘了埋點(diǎn)探針也會(huì)默默把數(shù)據(jù)采出來(lái)。尤其在接手一個(gè)沒(méi)做過(guò)可觀測(cè)性建設(shè)的“歷史遺留系統(tǒng)”時(shí)這套自動(dòng)插件機(jī)制能讓你少寫(xiě)幾千行代碼。5.2 用Trace和Tag補(bǔ)上業(yè)務(wù)關(guān)鍵方法自動(dòng)增強(qiáng)覆蓋的是框架層調(diào)用但“優(yōu)惠計(jì)算里的某個(gè)核心算法耗時(shí)高”這類(lèi)問(wèn)題框架插件是看不到的。這時(shí)候就需要在關(guān)鍵業(yè)務(wù)方法上做自定義埋點(diǎn)。pom.xml里引入工具包dependency groupIdorg.apache.skywalking/groupId artifactIdapm-toolkit-trace/artifactId version9.2.0/version /dependency然后在方法上打注解import org.apache.skywalking.apm.toolkit.trace.Trace; import org.apache.skywalking.apm.toolkit.trace.Tag; import org.apache.skywalking.apm.toolkit.trace.Tags; Service public class PriceService { Trace Tags({ Tag(key skuId, value arg[0]), Tag(key skuCount, value arg[1]), Tag(key resultPrice, value returnedObj) }) public BigDecimal calcPrice(String skuId, int count) { // 復(fù)雜的業(yè)務(wù)計(jì)算 return result; } }Trace讓該方法變成一個(gè)獨(dú)立的SpanTag把方法參數(shù)、返回值塞進(jìn)Span標(biāo)簽里。這樣排查時(shí)你能直接看到“這個(gè)sku、這個(gè)數(shù)量下的計(jì)算結(jié)果”而不只是“優(yōu)惠計(jì)算耗時(shí)1秒”。工具包版本盡量和Agent版本保持一致避免出現(xiàn)注解類(lèi)兼容問(wèn)題。5.3 采樣率調(diào)整從“全量”到“夠用”鏈路跟蹤的數(shù)據(jù)量很大一個(gè)高并發(fā)系統(tǒng)如果全量上報(bào)所有請(qǐng)求存儲(chǔ)壓力和OAP壓力會(huì)直線上升。Skywalking的Agent在agent/config/agent.config里提供了采樣相關(guān)配置。老版本里常見(jiàn)的是agent.sample_n_per_3_secs意思是每3秒最多上報(bào)N條請(qǐng)求-1表示全量新版本可能改用sample_rate形式的百分比設(shè)置。具體字段名以你當(dāng)前Agent版本里的注釋為準(zhǔn)思路是一樣的。我個(gè)人建議測(cè)試環(huán)境全量生產(chǎn)環(huán)境先全量跑一周觀察OAP和ES的負(fù)載再把采樣率調(diào)低到能覆蓋峰值流量的水平。采樣率調(diào)低后單條請(qǐng)求的追蹤查詢可能查不到但服務(wù)指標(biāo)的統(tǒng)計(jì)依然準(zhǔn)確不影響告警和整體觀測(cè)。5.4 日志里帶上traceId日志平臺(tái)和鏈路平臺(tái)對(duì)賬鏈路平臺(tái)能看到調(diào)用鏈但如果你不知道這條鏈對(duì)應(yīng)業(yè)務(wù)日志里的哪幾行排查還是割裂的。解決辦法是把TraceId打進(jìn)日志里讓它和普通業(yè)務(wù)日志同屏出現(xiàn)。最通用的做法是用MDC。定義個(gè)過(guò)濾器import org.apache.skywalking.apm.toolkit.trace.TraceContext; import org.slf4j.MDC; public class TraceIdFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { MDC.put(tid, TraceContext.traceId()); try { chain.doFilter(request, response); } finally { MDC.remove(tid); } } }在logback-spring.xml里把tid加到輸出模式中pattern%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%X{tid}] %logger{36} - %msg%n/pattern之后日志里每一行都會(huì)帶上類(lèi)似[f68d1d0e3a3344c5a8f0...]的鏈路ID在日志平臺(tái)搜索這個(gè)ID就能看到該鏈路過(guò)經(jīng)的所有日志反過(guò)來(lái)在Skywalking里也能用同樣的ID找到對(duì)應(yīng)的Trace詳情。新版Skywalking也提供了logback官方converter配置方式更簡(jiǎn)潔但包路徑隨版本變化建議直接參考官方文檔。6. 真實(shí)排查實(shí)錄用追蹤視圖定位“下單慢”的根因6.1 現(xiàn)象與初步判斷線上場(chǎng)景大概是這樣的工作日晚上八點(diǎn)左右用戶集中反饋下單接口“轉(zhuǎn)圈很久”平均RT從平時(shí)的500ms飆到3秒以上但接口沒(méi)有大面積報(bào)錯(cuò)只有零星超時(shí)。按照老辦法我第一反應(yīng)是去翻訂單服務(wù)的日志結(jié)果只看到一堆Read timed out根本不知道是下游哪個(gè)服務(wù)慢更不知道是不是所有用戶都受影響。這時(shí)候鏈路平臺(tái)的價(jià)值就顯現(xiàn)出來(lái)了。6.2 拓?fù)鋱D與追蹤頁(yè)的使用打開(kāi)Skywalking的“拓?fù)鋱D”頁(yè)面一眼看到order-service指向coupon-service的連線明顯變粗、顏色變紅說(shuō)明它們之間的調(diào)用流量和錯(cuò)誤率都異常。接著去“追蹤”頁(yè)面按服務(wù)、接口名和時(shí)間范圍過(guò)濾按耗時(shí)降序排列挑一條3.2秒的樣本點(diǎn)進(jìn)去。追蹤瀑布圖把一次請(qǐng)求拆成了清晰的Span列表入口Span/api/order/create總耗時(shí)3.2秒。JDBC Span查訂單表耗時(shí)120ms正常。Feign Span調(diào)用coupon-service耗時(shí)1.5秒狀態(tài)為超時(shí)。coupon-service內(nèi)部Span本身耗時(shí)1.5秒其中“計(jì)算優(yōu)惠”的Span占用1.1秒。Feign重試Span超時(shí)后又重試了一次再次耗時(shí)1.5秒?？吹竭@里其實(shí)已經(jīng)很明白了瓶頸不在訂單服務(wù)自己的能力而在優(yōu)惠券服務(wù)的“計(jì)算優(yōu)惠”邏輯。這條鏈路如果沒(méi)有Skywalking你得先懷疑訂單服務(wù)、再懷疑網(wǎng)關(guān)、再懷疑數(shù)據(jù)庫(kù)繞一大圈才能接觸到真相。6.3 根因確認(rèn)與處理方案再點(diǎn)開(kāi)coupon-service的實(shí)例指標(biāo)頁(yè)發(fā)現(xiàn)該實(shí)例在高峰期GC耗時(shí)飆升Young GC頻繁Full GC也有好幾次。配合鏈路里“計(jì)算優(yōu)惠”邏輯的大量CPU計(jì)算和緩存未命中根因就釘死了優(yōu)惠券服務(wù)的JVM堆配置偏小加上優(yōu)惠計(jì)算邏輯里存在一個(gè)不合理的全量遍歷高峰期觸發(fā)了頻繁GC導(dǎo)致Feign響應(yīng)等待時(shí)間超長(zhǎng)同時(shí)又疊加了調(diào)用方的超時(shí)重試下單接口雪上加霜。處理方案分兩步先把coupon-service的堆內(nèi)存調(diào)大、把優(yōu)惠計(jì)算中的全量遍歷改成增量緩存再把Feign的超時(shí)時(shí)間從默認(rèn)值調(diào)成更合理的閾值同時(shí)配置熔斷降級(jí)。上線后再次觀察拓?fù)鋱D紅色連線恢復(fù)正常晚高峰RT回落。這個(gè)案例最有價(jià)值的點(diǎn)在于Skywalking把“偶發(fā)的慢請(qǐng)求”從概率事件變成了可定量分析的數(shù)據(jù)。你不用再靠運(yùn)氣和感覺(jué)鏈路里每一跳的耗時(shí)、每一次重試、每一段GC回溯全部有據(jù)可查。7. 踩坑全記錄從探針不上報(bào)到數(shù)據(jù)錯(cuò)亂的問(wèn)題排查鏈路7.1 探針“靜默失敗”應(yīng)用正常但UI查不到數(shù)據(jù)最詭異的場(chǎng)景是SpringBoot應(yīng)用起來(lái)了日志也顯示Agent掛載成功但UI里就是看不到服務(wù)。按下面的排查順序走基本能定位確認(rèn)-javaagent是否真的生效。有時(shí)候IDEA的VM options寫(xiě)在了錯(cuò)誤的Run Configuration里應(yīng)用正常啟動(dòng)不代表參數(shù)生效。檢查Agent日志agent/logs/skywalking-api.log搜error。常見(jiàn)報(bào)錯(cuò)是Connection refused指向OAP的11800端口不通。這時(shí)候分別telnet測(cè)試11800和12800兩個(gè)端口再檢查防火墻和安全組。查看OAP日志確認(rèn)是否接收到了segment。OAP啟動(dòng)后如果有大量IndexNotFoundException多半是存儲(chǔ)沒(méi)建好或者版本不對(duì)。檢查服務(wù)名是否和已有服務(wù)重復(fù)。如果多個(gè)實(shí)例用了同樣的service_nameSkywalking默認(rèn)會(huì)合并展示初次接入時(shí)容易誤判為“數(shù)據(jù)沒(méi)上報(bào)”。切記Skywalking的Agent默認(rèn)是“靜默失敗”的即使上報(bào)失敗也不影響業(yè)務(wù)進(jìn)程。這既是好事也是壞事排查時(shí)別指望它會(huì)主動(dòng)彈錯(cuò)誤提示。7.2 JDK版本和SpringBoot 3.x的兼容問(wèn)題SpringBoot 3.x強(qiáng)制要求JDK17而JDK9之后Java模塊系統(tǒng)對(duì)字節(jié)碼增強(qiáng)有了更多限制。如果你用老版本Skywalking Agent掛載到Java 17的應(yīng)用里非常容易出現(xiàn)ClassFormatError、UnsupportedClassVersionError或者在啟動(dòng)階段直接報(bào)transform失敗。解決思路不是改代碼而是版本對(duì)齊JDK17/21配SpringBoot 3.x的項(xiàng)目請(qǐng)使用較新的Skywalking發(fā)行版配套Agent版本對(duì)JDK17的支持才完善。如果你只想快速跑通演示也可以先用JDK8 SpringBoot 2.x的組合成功率最高少折騰。7.3 ES版本不匹配導(dǎo)致OAP啟動(dòng)失敗這個(gè)問(wèn)題在前面提過(guò)但值得單獨(dú)列入踩坑清單?，F(xiàn)象是OAP啟動(dòng)后控制臺(tái)不斷刷新類(lèi)似NoNodeAvailableException或index not found的異常ES索引一個(gè)都建不起來(lái)。正確做法是提前查官方兼容矩陣。Skywalking 9.x系列和ES 7.x的搭配經(jīng)歷了大量生產(chǎn)驗(yàn)證最穩(wěn)妥想用ES 8.x的確認(rèn)你的Skywalking版本確實(shí)支持后再動(dòng)手。同時(shí)注意如果ES集群?jiǎn)⒂昧税踩J(rèn)證記得在application.yml里把用戶名密碼也配上不然客戶端會(huì)一直認(rèn)證失敗。7.4 數(shù)據(jù)亂序與鏈路斷半截的隱蔽原因有一種比較隱蔽的坑服務(wù)正常鏈路也有但Span耗時(shí)是負(fù)數(shù)上下游順序顛倒或者一條完整的調(diào)用鏈斷成了兩截。原因多半出在基礎(chǔ)設(shè)施層。最常見(jiàn)的是多實(shí)例部署時(shí)宿主機(jī)時(shí)鐘沒(méi)有同步。Skywalking計(jì)算Span耗時(shí)依賴時(shí)間戳如果A服務(wù)的服務(wù)器比B服務(wù)慢了十幾秒鏈路里就會(huì)出現(xiàn)“下游比上游先結(jié)束”“耗時(shí)是負(fù)數(shù)”的詭異數(shù)據(jù)。解決方法是把NTP時(shí)鐘同步這件事納入服務(wù)器基線配置不然后患無(wú)窮。另一個(gè)原因是跨線程調(diào)用沒(méi)有被正確處理。比如你用Async或自定義線程池發(fā)起了異步任務(wù)老的線程池場(chǎng)景沒(méi)有插件支持鏈路上下文就無(wú)法自動(dòng)傳遞。新版插件對(duì)RocketMQ、Kafka這類(lèi)中間件處理了上下文傳播但對(duì)自研線程池還是要靠TraceCrossThread這類(lèi)工具注解來(lái)手工傳遞。7.5 探針性能損耗從“無(wú)感”到“需要調(diào)優(yōu)”Skywalking官方宣稱(chēng)探針損耗很低實(shí)際用下來(lái)一般場(chǎng)景確實(shí)無(wú)感但不代表完全沒(méi)成本。如果你把所有HTTP參數(shù)、所有SQL都采集下來(lái)在高并發(fā)核心鏈路里RT和CPU都會(huì)有小幅上升。我的經(jīng)驗(yàn)是分三步控制先把采樣率從一個(gè)保守值開(kāi)始調(diào)觀察一周再放寬然后關(guān)掉不需要的插件在agent/config/agent.config里按需啟用最后對(duì)敏感參數(shù)做好脫敏尤其是用戶手機(jī)號(hào)、身份證等信息不要直接打成標(biāo)簽。鏈路觀測(cè)要服務(wù)于排查能力不是把原始數(shù)據(jù)全存下來(lái)才算成功。8. 寫(xiě)在最后我在生產(chǎn)環(huán)境用了半年的幾點(diǎn)體會(huì)接入Skywalking這件事技術(shù)難度比我最初想象的低得多真正難的其實(shí)是讓它持續(xù)產(chǎn)生價(jià)值。初期大家會(huì)覺(jué)得拓?fù)鋱D很酷天天圍觀新鮮感一過(guò)沒(méi)人看面板了鏈路平臺(tái)就被晾在一邊。直到后來(lái)有一次線上故障靠著鏈路數(shù)據(jù)十分鐘就定位到問(wèn)題團(tuán)隊(duì)才明白這個(gè)系統(tǒng)的意義不是“好看”而是把隱形的依賴關(guān)系和使用體驗(yàn)變成可以回溯的數(shù)據(jù)資產(chǎn)。從那之后我們把“關(guān)鍵業(yè)務(wù)方法加Trace”“日志輸出帶TID”寫(xiě)進(jìn)了開(kāi)發(fā)規(guī)范新服務(wù)上線前會(huì)專(zhuān)門(mén)檢查Skywalking里有沒(méi)有這個(gè)服務(wù)的鏈路數(shù)據(jù)。給正準(zhǔn)備接入的朋友三個(gè)務(wù)實(shí)的建議第一服務(wù)命名規(guī)范一定提前定好別讓每個(gè)人自己起名第二先拿一個(gè)不重要的邊緣服務(wù)試水跑通全鏈路后再推廣到核心服務(wù)第三告警規(guī)則要配幾條比如服務(wù)成功率下降、平均RT突增把鏈路指標(biāo)變成主動(dòng)通知而不是被動(dòng)翻查。鏈路跟蹤不是什么高深技術(shù)但它能把團(tuán)隊(duì)從“反復(fù)猜問(wèn)題在哪”的消耗里解脫出來(lái)。希望這篇實(shí)戰(zhàn)記錄能幫你把Skywalking順利跑起來(lái)省下更多本該用來(lái)寫(xiě)業(yè)務(wù)代碼的時(shí)間。 SpringBoot集成Skywalking：微服務(wù)鏈路跟蹤與無(wú)侵入排查實(shí)戰(zhàn)
如果你也經(jīng)歷過(guò)微服務(wù)環(huán)境下的深夜排查用戶反饋下單慢你打開(kāi)三臺(tái)服務(wù)器的日志先按時(shí)間戳對(duì)齊再逐個(gè)服務(wù)找堆棧最后還得靠猜“大概是哪個(gè)環(huán)節(jié)”卡住了那這篇關(guān)于SpringBoot集成Skywalking鏈路跟蹤的內(nèi)容就是來(lái)解決這個(gè)問(wèn)題的。這是SpringBoot綜合實(shí)戰(zhàn)系列的第三十二篇。這一篇不寫(xiě)業(yè)務(wù)接口也不講數(shù)據(jù)庫(kù)優(yōu)化而是把一個(gè)日常排查利器裝進(jìn)你的項(xiàng)目里Skywalking。它通過(guò)Java Agent探針實(shí)現(xiàn)無(wú)侵入接入不需要改業(yè)務(wù)代碼、不需要給每個(gè)服務(wù)手動(dòng)加依賴啟動(dòng)參數(shù)里加一行-javaagent你的SpringBoot應(yīng)用就能自動(dòng)上報(bào)調(diào)用鏈路、服務(wù)拓?fù)浜椭虚g件指標(biāo)。我會(huì)從“為什么需要鏈路跟蹤”講起把Skywalking的各個(gè)組件、后端部署步驟、SpringBoot接入方式、自定義埋點(diǎn)和日志關(guān)聯(lián)完整演示一遍最后附帶一個(gè)真實(shí)排查案例和一份踩坑記錄。適合正在做微服務(wù)改造、被“跨服務(wù)問(wèn)題定位難”折磨過(guò)的后端開(kāi)發(fā)者也適合想在項(xiàng)目里搭可觀測(cè)性基礎(chǔ)設(shè)施的技術(shù)同學(xué)。1. 一次“半小時(shí)排查”引發(fā)的思考鏈路跟蹤到底在解決什么1.1 日志碎片化時(shí)代的“拼圖游戲”單體應(yīng)用時(shí)代一次請(qǐng)求的日志都在同一個(gè)進(jìn)程里grep一下就完了。微服務(wù)拆開(kāi)之后一次下單請(qǐng)求可能經(jīng)過(guò)網(wǎng)關(guān)、訂單服務(wù)、庫(kù)存服務(wù)、優(yōu)惠券服務(wù)中間還夾著MQ異步消息。日志散落在不同機(jī)器的不同文件里時(shí)間戳稍微偏移一點(diǎn)你拼出來(lái)的“調(diào)用順序”可能就是錯(cuò)的。我見(jiàn)過(guò)太多團(tuán)隊(duì)在這種場(chǎng)景下的排查姿勢(shì)先在A服務(wù)找到“調(diào)用庫(kù)存服務(wù)超時(shí)”再跑去B服務(wù)翻對(duì)應(yīng)時(shí)間段的日志如果碰巧兩個(gè)服務(wù)都沒(méi)打traceId就要靠請(qǐng)求參數(shù)和時(shí)間窗口去關(guān)聯(lián)。運(yùn)氣好十分鐘運(yùn)氣不好一下午。這種“拼圖游戲”最可怕的地方在于——每次都要從頭拼一遍經(jīng)驗(yàn)根本無(wú)法沉淀。鏈路跟蹤解決的就是這個(gè)核心問(wèn)題把一個(gè)請(qǐng)求經(jīng)過(guò)的所有服務(wù)、所有中間件調(diào)用自動(dòng)串成一條帶唯一ID的調(diào)用鏈告訴你每一跳花了多久、在哪里失敗、失敗原因是什么。它能幫你把排查從“按時(shí)間戳猜”變成“按瀑布圖精確定位”。1.2 誰(shuí)最需要鏈路跟蹤如果你還在做單體應(yīng)用鏈路跟蹤的價(jià)值確實(shí)沒(méi)那么大單進(jìn)程里一臺(tái)Arthas基本夠用。但只要你滿足下面任意一條就應(yīng)該認(rèn)真考慮這件事服務(wù)拆成了三個(gè)以上且存在跨服務(wù)同步調(diào)用Feign、RestTemplate、Dubbo等。線上偶發(fā)慢請(qǐng)求日志里看不到明顯的Exception只能靠“感覺(jué)”判斷是數(shù)據(jù)庫(kù)慢還是外部調(diào)用慢。團(tuán)隊(duì)協(xié)作時(shí)經(jīng)常出現(xiàn)“A服務(wù)說(shuō)是B服務(wù)的鍋B服務(wù)甩給C”的扯皮。想給技術(shù)團(tuán)隊(duì)建立一套統(tǒng)一的、不受業(yè)務(wù)代碼污染的可觀測(cè)性底座。只要命中其中一條鏈路跟蹤就不是錦上添花而是排查效率的剛需。1.3 為什么選Skywalking而不是Zipkin和Jaeger市面上的APM方案不少我周?chē)娜肆牡米疃嗟木褪荶ipkin、Jaeger、Skywalking三家。它們的定位略有差異我整理了一個(gè)對(duì)比供你選型參考維度SkywalkingZipkin/SleuthJaeger接入方式Java Agent無(wú)侵入依賴SDK/注解侵入性強(qiáng)Agent或SDK功能覆蓋拓?fù)?、追蹤、指?biāo)、告警一體以追蹤為主以追蹤為主存儲(chǔ)ES、MySQL、H2等ES、MySQL、CassandraES、Cassandra中文資料活躍踩坑文章多較少一般學(xué)習(xí)成本低基本不用改代碼中要寫(xiě)配置和依賴中個(gè)人感受Spring Cloud Sleuth Zipkin那套勝在和Spring生態(tài)天然融合但每個(gè)服務(wù)都要引入依賴、寫(xiě)配置已有的老項(xiàng)目接入成本偏高。Skywalking最打動(dòng)我的一點(diǎn)是“探針注入”它基于Java Agent機(jī)制在類(lèi)加載階段做字節(jié)碼增強(qiáng)應(yīng)用代碼一行都不用動(dòng)。這個(gè)特性對(duì)老舊項(xiàng)目尤其友好——不用發(fā)版不用等排期改個(gè)JVM啟動(dòng)參數(shù)就能把鏈路數(shù)據(jù)采起來(lái)。2. 別急著寫(xiě)代碼Skywalking的四個(gè)角色先對(duì)齊2.1 Agent探針藏在JVM里的“臥底”Skywalking的Agent是一段獨(dú)立運(yùn)行的Java程序通過(guò)-javaagent參數(shù)掛載到你的SpringBoot進(jìn)程里。掛載之后它會(huì)在類(lèi)加載的時(shí)候?qū)δ繕?biāo)類(lèi)的字節(jié)碼做增強(qiáng)在HTTP入口、Feign調(diào)用、JDBC執(zhí)行等關(guān)鍵位置自動(dòng)織入“埋點(diǎn)邏輯”。拿Tomcat內(nèi)嵌場(chǎng)景舉例SpringBoot啟動(dòng)時(shí)Agent發(fā)現(xiàn)你要加載org.apache.catalina.core.StandardHostValve這類(lèi)Servlet容器類(lèi)就會(huì)在它的invoke方法前后插入耗時(shí)記錄和上下文傳遞邏輯。之后你完全感覺(jué)不到它的存在但它已經(jīng)在默默記錄每一次請(qǐng)求的入口、出口和中間經(jīng)過(guò)的組件。這才是“無(wú)侵入”的真正含義——不是少寫(xiě)幾行代碼而是從機(jī)制上繞開(kāi)了對(duì)業(yè)務(wù)代碼的觸碰。探針底層的字節(jié)碼增強(qiáng)用的是Byte Buddy這是Java生態(tài)里比較成熟的字節(jié)碼操作庫(kù)對(duì)類(lèi)加載器兼容性處理得比較好。2.2 OAP、存儲(chǔ)和UI大腦、記憶與儀表盤(pán)Agent采集到數(shù)據(jù)之后需要有個(gè)地方接收、分析、存儲(chǔ)、展示這就要靠另外三個(gè)組件OAPObservability Analysis Platform接收Agent通過(guò)gRPC上報(bào)的數(shù)據(jù)做指標(biāo)聚合、鏈路關(guān)系分析相當(dāng)于整個(gè)系統(tǒng)的大腦。存儲(chǔ)OAP把處理好的數(shù)據(jù)寫(xiě)入存儲(chǔ)層。默認(rèn)內(nèi)置H2生產(chǎn)環(huán)境一般換成Elasticsearch。Web UI一個(gè)獨(dú)立的前端應(yīng)用負(fù)責(zé)把拓?fù)洹⒆粉?、指?biāo)可視化成儀表盤(pán)。在實(shí)際部署中OAP、存儲(chǔ)、UI這三者可以拆開(kāi)部署在不同機(jī)器上。Agent只跟OAP通信OAP只跟存儲(chǔ)和UI打交道鏈路很清晰。2.3 一次請(qǐng)求在Skywalking里的完整旅程為了讓你對(duì)整體流程有畫(huà)面感我按順序描述一遍用戶請(qǐng)求打到SpringBoot應(yīng)用Agent在入口Span上生成全局鏈路IDTraceId。應(yīng)用內(nèi)部調(diào)用另一個(gè)服務(wù)或訪問(wèn)數(shù)據(jù)庫(kù)時(shí)Agent自動(dòng)創(chuàng)建子Span記錄組件類(lèi)型、目標(biāo)地址、耗時(shí)、狀態(tài)碼。請(qǐng)求結(jié)束后Agent把完整調(diào)用鏈分批通過(guò)gRPC上報(bào)到OAP默認(rèn)端口11800。OAP解析數(shù)據(jù)把鏈路以Span為單位入庫(kù)并計(jì)算服務(wù)間依賴關(guān)系、RT分布、成功率等指標(biāo)。UI通過(guò)OAP的HTTP接口默認(rèn)12800查詢數(shù)據(jù)渲染成你看到的拓?fù)鋱D和追蹤瀑布圖。只要理解了這條數(shù)據(jù)流后面排查“數(shù)據(jù)為什么沒(méi)出來(lái)”“為什么只有一個(gè)服務(wù)有數(shù)據(jù)”就會(huì)順手很多。3. 跑起來(lái)再說(shuō)OAPUI后端部署與存儲(chǔ)切換3.1 下載發(fā)行包并啟動(dòng)默認(rèn)版本后端部署最省心的方式是從Apache Skywalking官網(wǎng)下載二進(jìn)制發(fā)行包里面自帶OAP、UI和Agent三件套目錄結(jié)構(gòu)大概是skywalking/ ├── bin/ # 啟動(dòng)腳本 ├── config/ # OAP配置 ├── oap-libs/ # OAP運(yùn)行依賴 ├── webapp/ # UI前端 └── agent/ # Java探針Linux/Mac啟動(dòng)cd skywalking ./bin/startup.shWindows啟動(dòng)cd skywalking bin\startup.batstartup.sh會(huì)同時(shí)拉起OAP和UI兩個(gè)進(jìn)程。默認(rèn)配置下OAP的gRPC端口是11800HTTP查詢端口是12800UI端口是8080。注意8080很容易被你的業(yè)務(wù)應(yīng)用占用如果啟動(dòng)后發(fā)現(xiàn)UI訪問(wèn)不了先進(jìn)去看日志多半是端口沖突。3.2 驗(yàn)證安裝是否成功啟動(dòng)后訪問(wèn)http://localhost:8080如果能看到Skywalking的儀表盤(pán)首頁(yè)說(shuō)明后端已經(jīng)跑起來(lái)了。沒(méi)有頁(yè)面的話按下面順序排查看logs/skywalking-oap-server.log搜“oap server started”或“started successfully”關(guān)鍵字?？磜ebapp/logs目錄下的日志確認(rèn)UI的Tomcat是否正常啟動(dòng)。檢查端口占用lsof -i:8080、lsof -i:11800、lsof -i:12800哪個(gè)被占就改哪個(gè)。這一步只需要“能打開(kāi)頁(yè)面”就行頁(yè)面里暫時(shí)沒(méi)有數(shù)據(jù)是正常的因?yàn)檫€沒(méi)有任何Agent接入。3.3 把存儲(chǔ)從H2切到Elasticsearch默認(rèn)情況OAP使用H2文件數(shù)據(jù)庫(kù)適合本地演示但別用在生產(chǎn)數(shù)據(jù)量大了之后查詢明顯變慢而且H2畢竟不是為海量時(shí)序數(shù)據(jù)設(shè)計(jì)的。生產(chǎn)環(huán)境我建議用Elasticsearch。切存儲(chǔ)的操作在config/application.yml的storage段進(jìn)行。核心就兩個(gè)地方storage: selector: ${SW_STORAGE:elasticsearch} elasticsearch: clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:127.0.0.1:9200} namespace: ${SW_NAMESPACE:prod_log_trace}順手給ES加一個(gè)namespace可以避免和其他系統(tǒng)共用ES時(shí)索引沖突Skywalking會(huì)在索引名前面拼上這個(gè)前綴。這里要特別提醒一個(gè)版本問(wèn)題Skywalking和ES的版本是有兼容矩陣的。以Skywalking 9.x為例和ES 7.x搭配最成熟ES 8.x要用對(duì)應(yīng)的新版本支持。別想當(dāng)然地“ES越新越好”我有一個(gè)朋友就是把ES從7升到8之后OAP一直刷索引創(chuàng)建失敗最后查官方文檔才發(fā)現(xiàn)版本沒(méi)對(duì)齊。具體兼容性請(qǐng)以官方文檔的Compatibility列表為準(zhǔn)不要賭。4. SpringBoot接入Agent探針無(wú)侵入的關(guān)鍵一步4.1 命令行與IDEA本地調(diào)試的接入方式后端就緒后SpringBoot這邊要做的唯一操作就是給JVM加啟動(dòng)參數(shù)。先看命令行方式j(luò)ava -javaagent:/opt/skywalking/agent/skywalking-agent.jar \ -Dskywalking.agent.service_nameorder-service \ -Dskywalking.collector.backend_service127.0.0.1:11800 \ -jar order-service.jar如果你在IDEA里做本地聯(lián)調(diào)不用每次敲命令直接在Run/Debug Configurations里找到你的SpringBoot啟動(dòng)類(lèi)在VM options里填入同樣的參數(shù)-javaagent:D:/skywalking/agent/skywalking-agent.jar -Dskywalking.agent.service_nameorder-service -Dskywalking.collector.backend_service127.0.0.1:11800Windows下-javaagent路徑如果有空格整體要加雙引號(hào)。這個(gè)坑很小但等你排查到深夜就會(huì)發(fā)現(xiàn)它有多煩人。參數(shù)說(shuō)明-javaagent指向skywalking-agent.jar的絕對(duì)路徑。-Dskywalking.agent.service_name該服務(wù)在鏈路平臺(tái)里的顯示名。建議和spring.application.name保持一致團(tuán)隊(duì)內(nèi)必須約定統(tǒng)一命名規(guī)范否則UI里會(huì)出現(xiàn)一堆莫名其妙的名字。-Dskywalking.collector.backend_serviceOAP的gRPC地址即11800端口。多OAP節(jié)點(diǎn)用逗號(hào)分隔。4.2 Docker和K8s的接入方式容器化環(huán)境不能手改啟動(dòng)命令最常用的辦法是利用JVM的JAVA_TOOL_OPTIONS環(huán)境變量。Docker啟動(dòng)時(shí)指定docker run -d \ -e JAVA_TOOL_OPTIONS-javaagent:/opt/skywalking/agent/skywalking-agent.jar -Dskywalking.agent.service_nameorder-service -Dskywalking.collector.backend_serviceskywalking-oap:11800 \ -v /opt/skywalking/agent:/opt/skywalking/agent \ order-service:latestK8s的話在Deployment的env里加一條JAVA_TOOL_OPTIONS環(huán)境變量把Agent路徑通過(guò)emptyDir掛載進(jìn)去即可。這樣Pod每次重建時(shí)探針都在同一路徑下配置也統(tǒng)一。4.3 怎么確認(rèn)探針真的生效了接完Agent重啟應(yīng)用后最關(guān)心的第一件事就是“數(shù)據(jù)到底上報(bào)沒(méi)有”。我一般按三步驗(yàn)證看應(yīng)用啟動(dòng)日志Skywalking掛載成功時(shí)會(huì)有Skywalking agent相關(guān)輸出沒(méi)看到就是-javaagent參數(shù)沒(méi)生效?？碼gent/logs/skywalking-api.log這個(gè)日志文件記錄了Agent的運(yùn)行狀態(tài)?？吹絞RPC連接成功類(lèi)信息說(shuō)明和OAP的網(wǎng)絡(luò)是通的。到UI的“服務(wù)列表”或“拓?fù)鋱D”頁(yè)面選對(duì)應(yīng)服務(wù)名多打幾個(gè)接口等十幾秒再看。第一次注冊(cè)有延遲別急著懷疑配置。如果前兩步都正常但UI里就是沒(méi)數(shù)據(jù)最可能的原因是我在第七節(jié)要講的幾個(gè)坑先繼續(xù)往下看。5. 進(jìn)階玩法自定義埋點(diǎn)、采樣控制與日志TID關(guān)聯(lián)5.1 哪些鏈路信息不用寫(xiě)代碼就能拿到Skywalking的插件體系非常豐富以下場(chǎng)景默認(rèn)就能被自動(dòng)增強(qiáng)HTTP入口SpringMVC / SpringBoot內(nèi)嵌Tomcat / 網(wǎng)關(guān)Spring Cloud Gateway。服務(wù)間調(diào)用Feign、RestTemplate、OkHttp、HttpClient、Dubbo。數(shù)據(jù)訪問(wèn)JDBC、MyBatis、JPASQL語(yǔ)句和綁定參數(shù)都能記錄。緩存與消息Redis、Kafka、RocketMQ、RabbitMQ注意插件版本和中間件版本的對(duì)應(yīng)關(guān)系。這也是我推薦用它兜底的原因團(tuán)隊(duì)里有人忘了打日志、忘了埋點(diǎn)探針也會(huì)默默把數(shù)據(jù)采出來(lái)。尤其在接手一個(gè)沒(méi)做過(guò)可觀測(cè)性建設(shè)的“歷史遺留系統(tǒng)”時(shí)這套自動(dòng)插件機(jī)制能讓你少寫(xiě)幾千行代碼。5.2 用Trace和Tag補(bǔ)上業(yè)務(wù)關(guān)鍵方法自動(dòng)增強(qiáng)覆蓋的是框架層調(diào)用但“優(yōu)惠計(jì)算里的某個(gè)核心算法耗時(shí)高”這類(lèi)問(wèn)題框架插件是看不到的。這時(shí)候就需要在關(guān)鍵業(yè)務(wù)方法上做自定義埋點(diǎn)。pom.xml里引入工具包dependency groupIdorg.apache.skywalking/groupId artifactIdapm-toolkit-trace/artifactId version9.2.0/version /dependency然后在方法上打注解import org.apache.skywalking.apm.toolkit.trace.Trace; import org.apache.skywalking.apm.toolkit.trace.Tag; import org.apache.skywalking.apm.toolkit.trace.Tags; Service public class PriceService { Trace Tags({ Tag(key skuId, value arg[0]), Tag(key skuCount, value arg[1]), Tag(key resultPrice, value returnedObj) }) public BigDecimal calcPrice(String skuId, int count) { // 復(fù)雜的業(yè)務(wù)計(jì)算 return result; } }Trace讓該方法變成一個(gè)獨(dú)立的SpanTag把方法參數(shù)、返回值塞進(jìn)Span標(biāo)簽里。這樣排查時(shí)你能直接看到“這個(gè)sku、這個(gè)數(shù)量下的計(jì)算結(jié)果”而不只是“優(yōu)惠計(jì)算耗時(shí)1秒”。工具包版本盡量和Agent版本保持一致避免出現(xiàn)注解類(lèi)兼容問(wèn)題。5.3 采樣率調(diào)整從“全量”到“夠用”鏈路跟蹤的數(shù)據(jù)量很大一個(gè)高并發(fā)系統(tǒng)如果全量上報(bào)所有請(qǐng)求存儲(chǔ)壓力和OAP壓力會(huì)直線上升。Skywalking的Agent在agent/config/agent.config里提供了采樣相關(guān)配置。老版本里常見(jiàn)的是agent.sample_n_per_3_secs意思是每3秒最多上報(bào)N條請(qǐng)求-1表示全量新版本可能改用sample_rate形式的百分比設(shè)置。具體字段名以你當(dāng)前Agent版本里的注釋為準(zhǔn)思路是一樣的。我個(gè)人建議測(cè)試環(huán)境全量生產(chǎn)環(huán)境先全量跑一周觀察OAP和ES的負(fù)載再把采樣率調(diào)低到能覆蓋峰值流量的水平。采樣率調(diào)低后單條請(qǐng)求的追蹤查詢可能查不到但服務(wù)指標(biāo)的統(tǒng)計(jì)依然準(zhǔn)確不影響告警和整體觀測(cè)。5.4 日志里帶上traceId日志平臺(tái)和鏈路平臺(tái)對(duì)賬鏈路平臺(tái)能看到調(diào)用鏈但如果你不知道這條鏈對(duì)應(yīng)業(yè)務(wù)日志里的哪幾行排查還是割裂的。解決辦法是把TraceId打進(jìn)日志里讓它和普通業(yè)務(wù)日志同屏出現(xiàn)。最通用的做法是用MDC。定義個(gè)過(guò)濾器import org.apache.skywalking.apm.toolkit.trace.TraceContext; import org.slf4j.MDC; public class TraceIdFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { MDC.put(tid, TraceContext.traceId()); try { chain.doFilter(request, response); } finally { MDC.remove(tid); } } }在logback-spring.xml里把tid加到輸出模式中pattern%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%X{tid}] %logger{36} - %msg%n/pattern之后日志里每一行都會(huì)帶上類(lèi)似[f68d1d0e3a3344c5a8f0...]的鏈路ID在日志平臺(tái)搜索這個(gè)ID就能看到該鏈路過(guò)經(jīng)的所有日志反過(guò)來(lái)在Skywalking里也能用同樣的ID找到對(duì)應(yīng)的Trace詳情。新版Skywalking也提供了logback官方converter配置方式更簡(jiǎn)潔但包路徑隨版本變化建議直接參考官方文檔。6. 真實(shí)排查實(shí)錄用追蹤視圖定位“下單慢”的根因6.1 現(xiàn)象與初步判斷線上場(chǎng)景大概是這樣的工作日晚上八點(diǎn)左右用戶集中反饋下單接口“轉(zhuǎn)圈很久”平均RT從平時(shí)的500ms飆到3秒以上但接口沒(méi)有大面積報(bào)錯(cuò)只有零星超時(shí)。按照老辦法我第一反應(yīng)是去翻訂單服務(wù)的日志結(jié)果只看到一堆Read timed out根本不知道是下游哪個(gè)服務(wù)慢更不知道是不是所有用戶都受影響。這時(shí)候鏈路平臺(tái)的價(jià)值就顯現(xiàn)出來(lái)了。6.2 拓?fù)鋱D與追蹤頁(yè)的使用打開(kāi)Skywalking的“拓?fù)鋱D”頁(yè)面一眼看到order-service指向coupon-service的連線明顯變粗、顏色變紅說(shuō)明它們之間的調(diào)用流量和錯(cuò)誤率都異常。接著去“追蹤”頁(yè)面按服務(wù)、接口名和時(shí)間范圍過(guò)濾按耗時(shí)降序排列挑一條3.2秒的樣本點(diǎn)進(jìn)去。追蹤瀑布圖把一次請(qǐng)求拆成了清晰的Span列表入口Span/api/order/create總耗時(shí)3.2秒。JDBC Span查訂單表耗時(shí)120ms正常。Feign Span調(diào)用coupon-service耗時(shí)1.5秒狀態(tài)為超時(shí)。coupon-service內(nèi)部Span本身耗時(shí)1.5秒其中“計(jì)算優(yōu)惠”的Span占用1.1秒。Feign重試Span超時(shí)后又重試了一次再次耗時(shí)1.5秒?？吹竭@里其實(shí)已經(jīng)很明白了瓶頸不在訂單服務(wù)自己的能力而在優(yōu)惠券服務(wù)的“計(jì)算優(yōu)惠”邏輯。這條鏈路如果沒(méi)有Skywalking你得先懷疑訂單服務(wù)、再懷疑網(wǎng)關(guān)、再懷疑數(shù)據(jù)庫(kù)繞一大圈才能接觸到真相。6.3 根因確認(rèn)與處理方案再點(diǎn)開(kāi)coupon-service的實(shí)例指標(biāo)頁(yè)發(fā)現(xiàn)該實(shí)例在高峰期GC耗時(shí)飆升Young GC頻繁Full GC也有好幾次。配合鏈路里“計(jì)算優(yōu)惠”邏輯的大量CPU計(jì)算和緩存未命中根因就釘死了優(yōu)惠券服務(wù)的JVM堆配置偏小加上優(yōu)惠計(jì)算邏輯里存在一個(gè)不合理的全量遍歷高峰期觸發(fā)了頻繁GC導(dǎo)致Feign響應(yīng)等待時(shí)間超長(zhǎng)同時(shí)又疊加了調(diào)用方的超時(shí)重試下單接口雪上加霜。處理方案分兩步先把coupon-service的堆內(nèi)存調(diào)大、把優(yōu)惠計(jì)算中的全量遍歷改成增量緩存再把Feign的超時(shí)時(shí)間從默認(rèn)值調(diào)成更合理的閾值同時(shí)配置熔斷降級(jí)。上線后再次觀察拓?fù)鋱D紅色連線恢復(fù)正常晚高峰RT回落。這個(gè)案例最有價(jià)值的點(diǎn)在于Skywalking把“偶發(fā)的慢請(qǐng)求”從概率事件變成了可定量分析的數(shù)據(jù)。你不用再靠運(yùn)氣和感覺(jué)鏈路里每一跳的耗時(shí)、每一次重試、每一段GC回溯全部有據(jù)可查。7. 踩坑全記錄從探針不上報(bào)到數(shù)據(jù)錯(cuò)亂的問(wèn)題排查鏈路7.1 探針“靜默失敗”應(yīng)用正常但UI查不到數(shù)據(jù)最詭異的場(chǎng)景是SpringBoot應(yīng)用起來(lái)了日志也顯示Agent掛載成功但UI里就是看不到服務(wù)。按下面的排查順序走基本能定位確認(rèn)-javaagent是否真的生效。有時(shí)候IDEA的VM options寫(xiě)在了錯(cuò)誤的Run Configuration里應(yīng)用正常啟動(dòng)不代表參數(shù)生效。檢查Agent日志agent/logs/skywalking-api.log搜error。常見(jiàn)報(bào)錯(cuò)是Connection refused指向OAP的11800端口不通。這時(shí)候分別telnet測(cè)試11800和12800兩個(gè)端口再檢查防火墻和安全組。查看OAP日志確認(rèn)是否接收到了segment。OAP啟動(dòng)后如果有大量IndexNotFoundException多半是存儲(chǔ)沒(méi)建好或者版本不對(duì)。檢查服務(wù)名是否和已有服務(wù)重復(fù)。如果多個(gè)實(shí)例用了同樣的service_nameSkywalking默認(rèn)會(huì)合并展示初次接入時(shí)容易誤判為“數(shù)據(jù)沒(méi)上報(bào)”。切記Skywalking的Agent默認(rèn)是“靜默失敗”的即使上報(bào)失敗也不影響業(yè)務(wù)進(jìn)程。這既是好事也是壞事排查時(shí)別指望它會(huì)主動(dòng)彈錯(cuò)誤提示。7.2 JDK版本和SpringBoot 3.x的兼容問(wèn)題SpringBoot 3.x強(qiáng)制要求JDK17而JDK9之后Java模塊系統(tǒng)對(duì)字節(jié)碼增強(qiáng)有了更多限制。如果你用老版本Skywalking Agent掛載到Java 17的應(yīng)用里非常容易出現(xiàn)ClassFormatError、UnsupportedClassVersionError或者在啟動(dòng)階段直接報(bào)transform失敗。解決思路不是改代碼而是版本對(duì)齊JDK17/21配SpringBoot 3.x的項(xiàng)目請(qǐng)使用較新的Skywalking發(fā)行版配套Agent版本對(duì)JDK17的支持才完善。如果你只想快速跑通演示也可以先用JDK8 SpringBoot 2.x的組合成功率最高少折騰。7.3 ES版本不匹配導(dǎo)致OAP啟動(dòng)失敗這個(gè)問(wèn)題在前面提過(guò)但值得單獨(dú)列入踩坑清單?，F(xiàn)象是OAP啟動(dòng)后控制臺(tái)不斷刷新類(lèi)似NoNodeAvailableException或index not found的異常ES索引一個(gè)都建不起來(lái)。正確做法是提前查官方兼容矩陣。Skywalking 9.x系列和ES 7.x的搭配經(jīng)歷了大量生產(chǎn)驗(yàn)證最穩(wěn)妥想用ES 8.x的確認(rèn)你的Skywalking版本確實(shí)支持后再動(dòng)手。同時(shí)注意如果ES集群?jiǎn)⒂昧税踩J(rèn)證記得在application.yml里把用戶名密碼也配上不然客戶端會(huì)一直認(rèn)證失敗。7.4 數(shù)據(jù)亂序與鏈路斷半截的隱蔽原因有一種比較隱蔽的坑服務(wù)正常鏈路也有但Span耗時(shí)是負(fù)數(shù)上下游順序顛倒或者一條完整的調(diào)用鏈斷成了兩截。原因多半出在基礎(chǔ)設(shè)施層。最常見(jiàn)的是多實(shí)例部署時(shí)宿主機(jī)時(shí)鐘沒(méi)有同步。Skywalking計(jì)算Span耗時(shí)依賴時(shí)間戳如果A服務(wù)的服務(wù)器比B服務(wù)慢了十幾秒鏈路里就會(huì)出現(xiàn)“下游比上游先結(jié)束”“耗時(shí)是負(fù)數(shù)”的詭異數(shù)據(jù)。解決方法是把NTP時(shí)鐘同步這件事納入服務(wù)器基線配置不然后患無(wú)窮。另一個(gè)原因是跨線程調(diào)用沒(méi)有被正確處理。比如你用Async或自定義線程池發(fā)起了異步任務(wù)老的線程池場(chǎng)景沒(méi)有插件支持鏈路上下文就無(wú)法自動(dòng)傳遞。新版插件對(duì)RocketMQ、Kafka這類(lèi)中間件處理了上下文傳播但對(duì)自研線程池還是要靠TraceCrossThread這類(lèi)工具注解來(lái)手工傳遞。7.5 探針性能損耗從“無(wú)感”到“需要調(diào)優(yōu)”Skywalking官方宣稱(chēng)探針損耗很低實(shí)際用下來(lái)一般場(chǎng)景確實(shí)無(wú)感但不代表完全沒(méi)成本。如果你把所有HTTP參數(shù)、所有SQL都采集下來(lái)在高并發(fā)核心鏈路里RT和CPU都會(huì)有小幅上升。我的經(jīng)驗(yàn)是分三步控制先把采樣率從一個(gè)保守值開(kāi)始調(diào)觀察一周再放寬然后關(guān)掉不需要的插件在agent/config/agent.config里按需啟用最后對(duì)敏感參數(shù)做好脫敏尤其是用戶手機(jī)號(hào)、身份證等信息不要直接打成標(biāo)簽。鏈路觀測(cè)要服務(wù)于排查能力不是把原始數(shù)據(jù)全存下來(lái)才算成功。8. 寫(xiě)在最后我在生產(chǎn)環(huán)境用了半年的幾點(diǎn)體會(huì)接入Skywalking這件事技術(shù)難度比我最初想象的低得多真正難的其實(shí)是讓它持續(xù)產(chǎn)生價(jià)值。初期大家會(huì)覺(jué)得拓?fù)鋱D很酷天天圍觀新鮮感一過(guò)沒(méi)人看面板了鏈路平臺(tái)就被晾在一邊。直到后來(lái)有一次線上故障靠著鏈路數(shù)據(jù)十分鐘就定位到問(wèn)題團(tuán)隊(duì)才明白這個(gè)系統(tǒng)的意義不是“好看”而是把隱形的依賴關(guān)系和使用體驗(yàn)變成可以回溯的數(shù)據(jù)資產(chǎn)。從那之后我們把“關(guān)鍵業(yè)務(wù)方法加Trace”“日志輸出帶TID”寫(xiě)進(jìn)了開(kāi)發(fā)規(guī)范新服務(wù)上線前會(huì)專(zhuān)門(mén)檢查Skywalking里有沒(méi)有這個(gè)服務(wù)的鏈路數(shù)據(jù)。給正準(zhǔn)備接入的朋友三個(gè)務(wù)實(shí)的建議第一服務(wù)命名規(guī)范一定提前定好別讓每個(gè)人自己起名第二先拿一個(gè)不重要的邊緣服務(wù)試水跑通全鏈路后再推廣到核心服務(wù)第三告警規(guī)則要配幾條比如服務(wù)成功率下降、平均RT突增把鏈路指標(biāo)變成主動(dòng)通知而不是被動(dòng)翻查。鏈路跟蹤不是什么高深技術(shù)但它能把團(tuán)隊(duì)從“反復(fù)猜問(wèn)題在哪”的消耗里解脫出來(lái)。希望這篇實(shí)戰(zhàn)記錄能幫你把Skywalking順利跑起來(lái)省下更多本該用來(lái)寫(xiě)業(yè)務(wù)代碼的時(shí)間。