這一篇是真正手把手級別的。文章會按實際部署順序推進先講清楚SkyWalking解決什么問題再帶你完成版本選型、存儲規(guī)劃、OAP和Web UI搭建、Java服務(wù)接入最后用控制臺實操幾個核心功能并把我在本地和生產(chǎn)環(huán)境里踩過的高頻坑一并整理出來。無論是第一次接觸APM還是已經(jīng)裝過但沒跑通按這篇順序走一遍應(yīng)該能少走很多彎路。1. 安裝SkyWalking之前先把“它到底解決什么問題”講透1.1 分布式監(jiān)控的三個傳統(tǒng)老大難很多團隊在做微服務(wù)化改造前監(jiān)控基本靠“日志平臺基礎(chǔ)資源監(jiān)控”硬撐。這套組合在單體階段還能用服務(wù)一拆馬上暴露三個痛點。第一個痛點是跨服務(wù)鏈路沒有關(guān)聯(lián)。同一個用戶請求在A服務(wù)、B服務(wù)、C服務(wù)各留了一段日志日志系統(tǒng)之間沒有全局TraceID串聯(lián)。線上出問題的時候你要從幾萬條日志里按時間戳人工拼湊完整調(diào)用鏈稍微復(fù)雜一點的請求排查半小時都是常態(tài)。第二個痛點是服務(wù)間調(diào)用關(guān)系不透明。十幾個服務(wù)互相調(diào)用誰依賴誰、調(diào)用頻率多高、哪個環(huán)節(jié)最容易成為瓶頸沒有人能準(zhǔn)確說清楚。等出了問題再手動畫依賴圖往往已經(jīng)來不及。第三個痛點是性能問題定位太慢。資源監(jiān)控只能告訴你“某個服務(wù)CPU高了、響應(yīng)慢了”但沒法告訴你“慢的是哪個接口、調(diào)用鏈路上哪一個環(huán)節(jié)耗時最多”。這兩者的差距在故障處理時是幾分鐘和幾個小時的差別。1.2 四大組件如何分工一句話講清整套架構(gòu)SkyWalking的架構(gòu)不復(fù)雜核心就是四個角色Agent探針、OAP Server分析引擎、Web UI可視化控制臺、Storage存儲后端。用交通系統(tǒng)來類比Agent是裝在每輛車上的GPS終端負(fù)責(zé)采集位置和速度然后上報OAP是交通指揮中心負(fù)責(zé)匯總、分析、研判UI是指揮中心的大屏把分析結(jié)果畫出來給交警看Storage就是指揮中心的檔案庫。每一層只管自己的事所以各組件可以獨立升級、獨立擴縮容。在API層面Agent采集的數(shù)據(jù)通過gRPC協(xié)議上報給OAP的11800端口UI通過HTTP協(xié)議從OAP的12800端口讀取數(shù)據(jù)。這個通信路徑很關(guān)鍵后面排查問題會反復(fù)用到。1.3 服務(wù)、實例、端點UI里繞不開的三個基礎(chǔ)概念用SkyWalking之前建議先把三個基礎(chǔ)概念搞清楚因為后面看拓?fù)鋱D、配告警規(guī)則、查Trace都離不開它們。服務(wù)Service指的是一個獨立部署的應(yīng)用比如order-service、user-service拓?fù)鋱D上的每個節(jié)點基本對應(yīng)一個服務(wù)。實例Instance是一個服務(wù)的具體運行進程同一個服務(wù)起了兩個副本就是兩個實例。端點Endpoint是服務(wù)對外暴露的具體接口比如HTTP接口的/order/create或者一個RPC方法。三者的層級關(guān)系是服務(wù)包含實例實例提供端點。理解這個模型之后你在界面上看到的所有指標(biāo)和鏈路數(shù)據(jù)最終都可以歸到這三層中的某一層。2. 版本、存儲和端口三個決策在裝之前就要敲定2.1 版本選型9.x還是8.xAgent怎么配我見過不少團隊裝SkyWalking很順利但跑了一兩個月開始頭疼追根溯源都是在安裝前沒做好版本決策。所以這一步值得花點時間想清楚。目前主線版本是9.xOAP服務(wù)端的JVM基線從JDK 8提升到了JDK 11存儲接口也做了重構(gòu)。如果是新項目直接上9.x最新穩(wěn)定版即可如果團隊是老環(huán)境且已經(jīng)穩(wěn)定運行在8.x也沒有新特性需求沒必要盲目升級。這里有一條血淚經(jīng)驗Agent版本和OAP版本要盡量保持大版本一致最理想是同一個小版本。新版Agent連接舊版OAP通常沒問題反過來舊版Agent連新版OAP就很容易出現(xiàn)協(xié)議不兼容表現(xiàn)是數(shù)據(jù)采集不上、UI頁面一片空白。我在生產(chǎn)環(huán)境吃過一次虧OAP是9.0Agent誤裝了8.15結(jié)果所有接入服務(wù)的Trace全部消失排查了一整天才定位到版本不匹配上。2.2 存儲后端H2能玩生產(chǎn)環(huán)境請上ElasticsearchSkyWalking默認(rèn)存儲后端是H2一個純Java的內(nèi)存數(shù)據(jù)庫好處是零配置、解壓即用適合本地演示和跑通流程壞處是數(shù)據(jù)無法大規(guī)模持久化、不支持集群。生產(chǎn)環(huán)境我建議直接上Elasticsearch以下簡稱ES。SkyWalking 9.x同時支持ES 7.x和8.x其中8.x需要SkyWalking 9.5.0以上版本。如果你的團隊已經(jīng)有ES集群直接復(fù)用就好如果沒有起一個單節(jié)點ES 7.17版本也夠用。除了ESSkyWalking還支持OpenSearch、MySQL、PostgreSQL、BanyanDB等存儲。這里不展開等確實需要時再按官方文檔選型。對絕大多數(shù)中小團隊來說最優(yōu)解就是ES。2.3 端口、JDK和防火墻最容易忽視的前置檢查部署前先確認(rèn)三件事。一是端口占用情況。OAP默認(rèn)使用11800gRPC和12800HTTP兩個端口UI默認(rèn)使用8080。如果機器上已經(jīng)有程序占用提前改端口或者換機器。二是防火墻和安全組。云服務(wù)器尤其要注意11800是Agent上報數(shù)據(jù)的通道12800是UI查詢數(shù)據(jù)的通道這兩個端口必須對需要訪問的主機開放。我之前在云環(huán)境踩過坑本地測試一切正常一接到測試環(huán)境就全是超時最后發(fā)現(xiàn)是安全組沒放行11800。三是JDK版本。SkyWalking 9.x的OAP服務(wù)端要求JDK 11以上建議直接用JDK 17避免版本兼容上的麻煩。3. 從解壓到跑通OAP服務(wù)端和UI的完整搭建記錄3.1 下載、解壓、認(rèn)清目錄結(jié)構(gòu)我的演示環(huán)境是LinuxmacOS操作完全一致Windows用戶把shell命令換成對應(yīng)的.bat腳本即可。建議準(zhǔn)備一臺至少4核8G的機器磁盤留20G以上因為ES索引和Agent采集數(shù)據(jù)都會占空間。下載用命令行即可cd /opt wget https://archive.apache.org/dist/skywalking/9.6.0/apache-skywalking-apm-9.6.0.tar.gz tar -zxvf apache-skywalking-apm-9.6.0.tar.gz mv apache-skywalking-apm-bin skywalking解壓后目錄結(jié)構(gòu)如下bin啟停腳本OAP和UI的入口都在這里configOAP核心配置application.yml就在這個目錄oap-libsOAP依賴的第三方類庫webappUI應(yīng)用及配置webapp/webapp.yml是UI關(guān)鍵配置agent內(nèi)置的Java Agent探針包后面接入業(yè)務(wù)服務(wù)會直接用這里講的是一次性把OAP和UI都裝好。官方也提供單獨webapp包但沒必要去拆一個發(fā)布包全部搞定。3.2 修改OAP配置從H2切換到Elasticsearch打開config/application.yml。如果只是本地演示用默認(rèn)H2存儲什么都不用改。我建議先讓H2跑通驗證整體流程后再切換。切到ES的配置方式如下storage: selector: ${SW_STORAGE:elasticsearch} elasticsearch: clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200} namespace: ${SW_STORAGE_ES_NAMESPACE:skywalking} indexShardsNumber: ${SW_STORAGE_ES_INDEX_SHARDS_NUMBER:2} indexReplicasNumber: ${SW_STORAGE_ES_INDEX_REPLICAS_NUMBER:0}一個特別提醒生產(chǎn)環(huán)境建議給ES索引設(shè)置namespace這樣SkyWalking創(chuàng)建的索引會統(tǒng)一帶前綴不會跟ES里其他業(yè)務(wù)索引混在一起。namespace一旦確定了就不要隨意改否則歷史數(shù)據(jù)全對不上。3.3 啟動OAP與UI、用curl驗證服務(wù)狀態(tài)切到bin目錄先后啟動OAP和UIcd /opt/skywalking/bin ./oapService.sh第一次啟動會初始化存儲稍等幾十秒?？吹饺罩纠锏腟erver started on port: 11800基本就說明OAP起來了。然后開另一個終端./webappService.shUI啟動后默認(rèn)監(jiān)聽8080端口瀏覽器訪問http://localhost:8080就能打開SkyWalking控制臺。如果頁面能打開但提示連接OAP超時檢查webapp.yml里的OAP地址配置server: port: 8080 collector: path: /graphql ribbon: listOfServers: 127.0.0.1:12800OAP和UI不在同一臺機器時listOfServers里的IP要改成OAP所在機器的內(nèi)網(wǎng)或公網(wǎng)IP。改完配置文件后必須重啟UI進程才會生效。想確認(rèn)OAP接口是否真的能用可以發(fā)一個GraphQL請求curl -s -X POST http://127.0.0.1:12800/graphql \ -H Content-Type: application/json \ -d {query:query p($i: ID!){service(input:{serviceId:$i}){id name}},variables:{i:1}}能返回JSON就說明OAP鏈路是通的。3.4 Docker一鍵體驗另一種快速上手方式如果你只是想先看個效果不想折騰二進制包可以用Docker Compose。官方有現(xiàn)成鏡像version: 3.8 services: oap: image: apache/skywalking-oap-server:9.6.0 ports: - 11800:11800 - 12800:12800 environment: SW_STORAGE: h2 ui: image: apache/skywalking-ui:9.6.0 ports: - 8080:8080 environment: SW_OAP_ADDRESS: http://oap:12800 depends_on: - oap不過我還是建議你至少按二進制方式完整裝一遍只有親手改過配置文件、看過目錄結(jié)構(gòu)后續(xù)排查問題才有體感。Docker方式適合快速驗證不適合學(xué)習(xí)原理。4. 把業(yè)務(wù)服務(wù)接進來Java Agent的安裝與配置全解4.1 零侵入背后的字節(jié)碼增強原理Java Agent能實現(xiàn)“零侵入”靠的是JDK的Instrumentation機制。在類加載過程中Agent會在目標(biāo)類的方法入口、出口、異常路徑上注入埋點邏輯自動采集Trace和指標(biāo)數(shù)據(jù)。對于業(yè)務(wù)代碼本身沒有任何感知。SkyWalking的Agent內(nèi)置了大量插件覆蓋Spring MVC、Tomcat、Netty、Dubbo、gRPC、JDBC、MyBatis、Kafka、RocketMQ等常見組件。這也是它開箱即用的原因——你甚至不需要為某個特定框架寫額外配置引入Agent后插件會自動生效。插件目錄在agent/plugins下默認(rèn)全部激活。4.2 一行javaagent參數(shù)接入Spring Boot服務(wù)Agent就在SkyWalking安裝包的agent目錄下?？梢园阉瓨涌截惖綐I(yè)務(wù)服務(wù)器上比如放在/opt/skywalking-agent/然后啟動命令變成這樣java -javaagent:/opt/skywalking-agent/skywalking-agent.jar \ -Dskywalking.agent.service_nameorder-service \ -Dskywalking.collector.backend_service192.168.1.10:11800 \ -jar app.jar三個關(guān)鍵參數(shù)逐一說清-javaagentJVM參數(shù)指定Agent jar包路徑。-Dskywalking.agent.service_name服務(wù)名稱。建議跟注冊中心或應(yīng)用名保持一致后面拓?fù)鋱D和告警都靠這個名字區(qū)分服務(wù)。-Dskywalking.collector.backend_serviceOAP地址格式是IP:11800。如果有多個OAP用英文逗號分隔。如果不想把參數(shù)寫死在啟動腳本里也可以改agent/config/agent.configagent.service_name${SW_AGENT_NAME:order-service} collector.backend_service${SW_AGENT_COLLECTOR_BACKEND_SERVICES:192.168.1.10:11800}配置文件的優(yōu)先級低于啟動參數(shù)啟動參數(shù)又低于環(huán)境變量。在容器化部署場景下用環(huán)境變量注入最方便export SW_AGENT_NAMEorder-service export SW_AGENT_COLLECTOR_BACKEND_SERVICES192.168.1.10:118004.3 多服務(wù)接入、配置管理、以及如何確認(rèn)接入成功接入多個服務(wù)時每個進程都要帶上對應(yīng)的javaagent參數(shù)服務(wù)名不要重復(fù)。接入后立刻去UI確認(rèn)拓?fù)漤搼?yīng)該能看到新服務(wù)節(jié)點出現(xiàn)“服務(wù)”列表能看到服務(wù)對應(yīng)的實例信息請求幾次業(yè)務(wù)接口后鏈路追蹤頁才能查到Trace數(shù)據(jù)。如果某個服務(wù)接入后UI不出現(xiàn)優(yōu)先排查三處第一agent/logs/skywalking-agent.log有沒有報錯第二服務(wù)名是否跟其他服務(wù)重名第三業(yè)務(wù)服務(wù)器到OAP的11800端口是否可達(dá)。這里有兩點建議一是Agent日志文件平時不起眼排查問題卻最有用我在生產(chǎn)排查時基本都先打開它二是如果多個服務(wù)共用同一臺機器每個服務(wù)進程的Agent內(nèi)存會疊加服務(wù)數(shù)量多的時候要注意機器內(nèi)存水位。5. 打開控制臺看數(shù)據(jù)拓?fù)洹race、指標(biāo)與告警實戰(zhàn)5.1 拓?fù)鋱D的使用思路UI首頁默認(rèn)就是拓?fù)湟晥D。它會根據(jù)采集到的統(tǒng)計數(shù)據(jù)自動把服務(wù)畫成節(jié)點節(jié)點之間連線代表調(diào)用關(guān)系線的顏色和粗細(xì)反映流量大小與健康狀態(tài)。這里有個很容易產(chǎn)生的誤區(qū)剛接入完Agent拓?fù)鋱D可能是空的。因為只有產(chǎn)生了實際調(diào)用SkyWalking才會生成拓?fù)潢P(guān)系。所以接入后記得去訪問幾次業(yè)務(wù)接口讓Agent采集到真實流量。拓?fù)鋱D的核心用法不是“看”而是“找”。線上反饋某個服務(wù)異常時先看拓?fù)鋱D上相關(guān)節(jié)點的連接是否異常往往幾秒鐘就能定位是誰在調(diào)用誰、哪個環(huán)節(jié)出了問題。5.2 鏈路追蹤定位慢接口當(dāng)一個接口變慢最常規(guī)的排查路徑是進入“追蹤”頁面按入口服務(wù)名過濾設(shè)置時間范圍搜索找到響應(yīng)時間異常的Trace點擊進入詳情詳情以樹狀結(jié)構(gòu)展示該請求經(jīng)過的所有Span每一個Span包含服務(wù)名、端點、耗時、開始時間、異常堆棧等信息哪個Span耗時最長瓶頸大概率就在那個服務(wù)節(jié)點上。舉例來說一次下單請求跨了網(wǎng)關(guān)、訂單服務(wù)、庫存服務(wù)、支付服務(wù)四個節(jié)點四個Span耗時分別是20ms、800ms、30ms、60ms那么瓶頸一眼鎖定在訂單服務(wù)內(nèi)部再結(jié)合該服務(wù)的日志或數(shù)據(jù)庫指標(biāo)進一步定位到具體代碼。界面上的“火焰圖”和“樹形圖”是兩種查看方式火焰圖更適合看耗時分布占比樹形圖更適合理解調(diào)用邏輯。兩者切換使用效率會高很多。5.3 指標(biāo)看板如何解讀在“服務(wù)”頁面可以查看每個服務(wù)和實例的指標(biāo)面板核心指標(biāo)有指標(biāo)含義平均響應(yīng)時間一段時間內(nèi)請求耗時均值TP99響應(yīng)時間99%的請求耗時在多少毫秒以內(nèi)吞吐量CPM每分鐘請求數(shù)活躍線程數(shù)服務(wù)實例的線程活躍情況我個人更關(guān)注TP99而不是平均響應(yīng)時間。平均值容易被長尾請求拉高而TP99能真實反映絕大多數(shù)用戶的體驗。曾經(jīng)有個服務(wù)平均RT看起來正常但TP99持續(xù)超3秒順著Trace查到最后是一個慢SQL在起作用。5.4 告警規(guī)則配置和Webhook推送SkyWalking內(nèi)置告警規(guī)則在OAP的config/alarm-settings.yml中。修改后需要重啟OAP才會生效。舉一個實際可用的配置服務(wù)平均響應(yīng)時間超過1000ms、連續(xù)觸發(fā)3次、沉默期5分鐘通過Webhook推送到外部系統(tǒng)。rules: service_resp_time_rule: metrics-name: service_resp_time op: threshold: 1000 period: 10 count: 3 silence-period: 5 message: 服務(wù) {name} 平均響應(yīng)時間超過 1000ms請檢查。 webhooks: - http://your-alert-system:8080/notify告警Webhook發(fā)送的payload是一段JSON里面包含服務(wù)名、指標(biāo)值、消息、觸發(fā)時間等信息。你可以用這個地址接收再轉(zhuǎn)發(fā)到釘釘、企業(yè)微信或者自建平臺。這個文件踩坑概率很高。YAML縮進非常嚴(yán)格冒號后必須有空格如果縮進錯導(dǎo)致OAP啟動失敗報錯信息還不一定直觀。建議改完配置后先找個YAML校驗工具過一遍再重啟。6. 排障工具箱我經(jīng)歷過的高頻問題和解決方式6.1 連接超時與端口不通這是最高頻的問題?，F(xiàn)象是UI能打開但服務(wù)頁面空白或者Agent日志里大量連接超時。排查方法是先測端口telnet 192.168.1.10 11800不通就看云安全組、iptables、firewalld。注意11800和12800應(yīng)該只對業(yè)務(wù)網(wǎng)段開放不要暴露公網(wǎng)。6.2 版本兼容性引發(fā)的沉默故障Agent和OAP版本不匹配的表現(xiàn)形式很迷惑人——服務(wù)正常啟動、業(yè)務(wù)無異常、UI也不報錯就是沒有數(shù)據(jù)。我在生產(chǎn)環(huán)境遇到過的版本兼容坑就是OAP是9.0、Agent是8.15所有Trace消失。規(guī)避辦法很簡單Agent和OAP用同一個發(fā)布版本的安裝包升級時同步升級。6.3 配置縮進與熱加載的靜態(tài)判斷application.yml和alarm-settings.yml都是靜態(tài)配置文件修改后必須重啟對應(yīng)進程。好多朋友改完配置等待自動生效最后白等半天。建議每次改配置后按“改配置-校驗YAML-重啟進程-查看日志”的順序操作。6.4 存儲索引與namespace沖突ES存儲下SkyWalking會自動創(chuàng)建大量以索引前綴開頭的索引。如果和其他業(yè)務(wù)共用ES集群且沒設(shè)namespace后期清理數(shù)據(jù)、管理索引模板都會很被動。設(shè)置namespace之后所有索引都會有統(tǒng)一前綴。要清理歷史數(shù)據(jù)時直接按前綴操作即可風(fēng)險更低。6.5 采樣率與內(nèi)存調(diào)優(yōu)默認(rèn)情況下Agent會對所有請求做全量采樣。線上大流量場景全量采樣會帶來不小的網(wǎng)絡(luò)和存儲開銷。可以通過agent.config里的采樣率參數(shù)調(diào)整agent.sample_n_per_3_secs${SW_AGENT_SAMPLE_PER_3_SECS:1}這個參數(shù)含義是每3秒采樣多少條請求。設(shè)置合理采樣率可以在成本和鏈路完整度之間做平衡。我的做法是核心服務(wù)保持適當(dāng)采樣率排查低頻問題時臨時調(diào)高問題解決后恢復(fù)。內(nèi)存方面OAP的堆內(nèi)存默認(rèn)由oapService.sh里的JVM參數(shù)控制。大流量場景下建議手動調(diào)大export OAP_JAVA_OPTS-Xmx4096m -Xms4096m6.6 時區(qū)、時間窗口、緩存等日常小坑數(shù)據(jù)不刷新不一定都是大問題小坑也會讓人卡半天時區(qū)UI默認(rèn)按瀏覽器本地時間展示服務(wù)器如果是UTC日志時間戳和界面時間對不上。時間窗口UI默認(rèn)查最近15分鐘剛接入的服務(wù)如果沒流量自然看不到數(shù)據(jù)。先手動請求幾次。緩存Agent配置或OAP配置修改后不會熱加載必須重啟進程。服務(wù)名重復(fù)多個接入服務(wù)配了同一個service_nameSkyWalking會當(dāng)成一個服務(wù)實例下混在一起看起來就特別亂。6.7 安全加固SkyWalking的UI和OAP端口不建議直接在公網(wǎng)暴露。至少做到幾點UI用Nginx反向代理并加基本認(rèn)證11800端口監(jiān)聽在內(nèi)網(wǎng)IP如果必須對外在網(wǎng)關(guān)上做IP白名單。這雖然不是功能性配置但對生產(chǎn)環(huán)境至關(guān)重要。最后用自己的真實體感收個尾。SkyWalking搭好以后我最大的感受不是“監(jiān)控圖變多了”而是排查思路被重塑了。以前是先查告警、再翻日志、再靠猜現(xiàn)在變成打開拓?fù)鋱D和Trace頁面先定位瓶頸服務(wù)和接口再拿日志做二次確認(rèn)。這套流程穩(wěn)定以后處理線上性能問題的時間基本能縮短一半以上。如果你正在為分布式系統(tǒng)的性能問題頭疼花半天時間把SkyWalking搭起來這筆投入非常值得。