SkyWalking 是一個開源的?應用性能監控系統(APM),專為云原生、微服務架構設計。其核心原理基于?分布式追蹤(Distributed Tracing)、指標收集(Metrics Collection)?和?日志關聯(Log Correlation),通過無侵入或輕量級的方式實現全鏈路監控。
一、整體架構與組件原理
SkyWalking 采用?四層架構?設計,各組件分工明確:
1. Agent(數據采集層)
- 功能:
- 無侵入式監控:通過字節碼增強技術(如 Java Agent)自動收集應用性能數據。
- 輕量級 SDK:為非 Java 語言(如 Node.js、Python)提供手動埋點 SDK。
- 采集內容:
- 請求鏈路數據(Trace):記錄請求在各服務間的調用路徑和耗時。
- 指標數據(Metrics):如響應時間、吞吐量、錯誤率。
- 環境元數據:服務拓撲關系、實例信息。
2. OAP Server(數據分析層)
- 接收核心服務(Receiver):
- 支持多種協議接收數據:如 gRPC、HTTP、Kafka、Zipkin 等。
- 數據格式轉換:將不同來源的數據統一為內部格式。
- 分析引擎(Analysis):
- 流處理:實時分析數據流,計算指標(如 P99 響應時間)。
- 關聯分析:將 Trace、Metrics 和日志關聯,構建服務拓撲圖。
- 告警引擎:基于規則觸發告警(如響應時間超過閾值)。
- 存儲服務(Storage):
- 支持多種存儲后端:Elasticsearch、H2、MySQL、TiDB 等。
3. UI(用戶交互層)
- 提供可視化界面,展示:
- 服務拓撲圖:直觀呈現服務間依賴關系。
- 性能指標面板:如 QPS、響應時間趨勢。
- 分布式追蹤詳情:查看完整調用鏈和瓶頸點。
- 告警歷史:查看和管理觸發的告警。
二、分布式追蹤原理
1. 基本概念
- Span(跨度):
- 表示調用鏈中的一個操作單元(如一次方法調用、SQL 查詢)。
- 包含元數據:操作名稱、開始 / 結束時間、標簽(如錯誤信息)。
- Trace(追蹤):
- 由多個 Span 組成的有向無環圖(DAG),表示一次完整請求的路徑。
- 上下文傳遞:
- 通過 HTTP Header 或消息隊列傳遞 TraceID 和 SpanID,跨服務追蹤。
2. 追蹤流程
plaintext
?
- 客戶端發起請求:生成全局唯一的 TraceID 和根 SpanID。
- 服務 A 處理請求:
- 記錄自身 Span 信息(如處理時間)。
- 將 TraceID 和 SpanID 通過 HTTP Header 傳遞給服務 B。
- 服務 B 接收請求:
- 提取 TraceID 和 SpanID,創建子 Span。
- 繼續傳遞上下文到服務 C。
- 數據聚合:
- 各服務將 Span 數據發送給 OAP Server。
- OAP Server 根據 TraceID 關聯所有 Span,還原完整調用鏈。
三、指標收集與分析
1. 指標類型
- 服務級指標:如 QPS、平均響應時間、錯誤率。
- 實例級指標:如 CPU / 內存使用率、線程數。
- 端點級指標:如特定 URL 或方法的性能。
2. 指標計算
- 原生指標:直接從 Agent 采集,如請求數、響應時間。
- 派生指標:通過計算得到,如:
- P99 響應時間:排序后 99% 位置的值,反映系統最差性能。
- 吞吐量:單位時間內的請求數。
- 錯誤率:失敗請求數占比。
3. 聚合與降維
- 時間窗口聚合:按分鐘 / 小時 / 天聚合指標,減少存儲壓力。
- TopN 算法:只保留最耗時或最頻繁的操作,忽略噪聲數據。
四、服務發現與拓撲構建
1. 自動服務發現
- 基于流量分析:通過分析請求路徑,自動識別服務間調用關系。
- 元數據上報:Agent 主動上報服務名稱、實例信息。
2. 拓撲圖生成
- 節點:表示服務或組件(如數據庫、消息隊列)。
- 邊:表示調用關系,邊的粗細表示調用頻率,顏色表示健康狀態。
- 動態更新:實時刷新拓撲圖,反映服務關系變化。
五、告警機制
1. 告警規則配置
- 內置規則:如響應時間超過閾值、錯誤率突增。
- 自定義規則:通過 YAML 配置,支持 PromQL 表達式:
rules:service_resp_time_rule:metrics-name: service_resp_time_percentile_99op: ">"threshold: 1000period: 10count: 3silence-period: 5
2. 告警發送
- 支持多種通知方式:郵件、Webhook、Slack、釘釘等。
- 告警分組與聚合:合并同類告警,避免頻繁通知。
六、性能優化與存儲策略
1. 數據采樣
- 固定比例采樣:如每 100 個請求采集 1 個(配置
agent.sample_n_per_3_secs
)。 - 智能采樣:對異常請求(如錯誤請求)全量采集,正常請求降采樣。
2. 存儲優化
- 冷熱分離:
- 熱數據(最近 7 天)存儲在高性能節點(如 ES 熱節點)。
- 冷數據(歷史數據)遷移到低成本存儲(如 ES 冷節點)。
- TTL 配置:自動刪除過期數據,避免存儲爆炸。
七、多語言支持
語言 | 支持方式 | 特點 |
---|---|---|
Java | 無侵入 Agent | 通過字節碼增強,無需修改代碼 |
Python | Skywalking-Python SDK | 需少量埋點,支持 Django、Flask 等框架 |
Node.js | Skywalking-NodeJS SDK | 支持 Express、Koa 等框架 |
Go | Skywalking-Go SDK | 手動埋點為主,提供 HTTP、gRPC 等中間件 |
C++ | Skywalking-C++ SDK | 適用于高性能場景,需手動集成 |
.NET | SkyAPM-dotnet | 支持ASP.NET?Core 等框架 |
八、與其他 APM 系統對比
特性 | SkyWalking | Jaeger | Zipkin |
---|---|---|---|
分布式追蹤 | ? | ? | ? |
自動服務發現 | ? | ?(需手動配置) | ?(需手動配置) |
服務拓撲可視化 | ? | ? | ? |
告警機制 | ? | ?(需依賴 Prometheus) | ?(需依賴外部系統) |
存儲支持 | ES/H2/MySQL/TiDB 等 | ES/Cassandra 等 | ES/MySQL 等 |
社區活躍度 | 高(Apache 頂級項目) | 中 | 中 |
通過以上機制,SkyWalking 實現了對分布式系統的全鏈路監控,幫助開發者快速定位性能瓶頸、故障根因,優化系統架構。其核心優勢在于無侵入式采集、高性能分析引擎和強大的可視化能力,特別適合云原生微服務環境。
二、SkyWalking 集群搭建
1. 環境準備
-
硬件要求(單節點參考,根據數據量調整):
組件 CPU 內存 存儲(SSD) 網絡 OAP Server 4 核 + 8GB+ 50GB+ 千兆網卡 Storage 按需 按需 按需 (如 ES 需高 IO) UI 2 核 + 4GB+ 20GB+ 公網可達 -
軟件依賴:
- Java 11+(OAP 和 UI 均需)
- 存儲組件(可選,推薦 Elasticsearch 7.x/8.x 或 Apache H2)
- ZooKeeper(用于集群管理,可選,適用于多 OAP 節點)
2. 部署流程(以 Elasticsearch 存儲為例)
步驟 1:下載安裝包
# 官網下載最新版(如9.4.0)
wget https://archive.apache.org/dist/skywalking/9.4.0/apache-skywalking-apm-9.4.0.tar.gz
tar -zxvf apache-skywalking-apm-9.4.0.tar.gz
cd apache-skywalking-apm-bin
步驟 2:配置 OAP Server
- 修改配置文件:
config/application.yml
# 存儲配置(以 Elasticsearch 為例)
storage:selector: ${SW_STORAGE:elasticsearch7}elasticsearch7:namespaces: ${SW_NAMESPACE:""}clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:192.168.1.100:9200,192.168.1.101:9200} # ES集群地址protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:"http"}user: ${SW_STORAGE_ES_USER:""} # 如有認證password: ${SW_STORAGE_ES_PASSWORD:""}compression: ${SW_STORAGE_ES_COMPRESSION:"false"}trustStorePath: ${SW_STORAGE_ES_SSL_JKS_PATH:""}trustStorePass: ${SW_STORAGE_ES_SSL_JKS_PASS:""}# 集群配置(多OAP節點時啟用ZooKeeper)
cluster:selector: ${SW_CLUSTER:zookeeper}zookeeper:namespace: ${SW_NAMESPACE:""}servers: ${SW_CLUSTER_ZK_SERVERS:192.168.1.102:2181,192.168.1.103:2181} # ZooKeeper地址
步驟 3:配置 UI
- 修改配置文件:
webapp/application.yml
-
server:port: 8080 # UI端口 management:port: 8081 # 管理端口 oapServer:# OAP集群地址(逗號分隔)hosts: ${SW_OAP_ADDRESS:http://192.168.1.104:12800,http://192.168.1.105:12800}
步驟 4:啟動集群
- 單節點啟動(測試環境):
-
# 啟動OAP(后臺運行) ./bin/oapService.sh start # 啟動UI ./bin/webappService.sh start
- 多節點集群(生產環境):
- 在所有 OAP 節點重復步驟 2(確保 ZooKeeper 和 ES 配置一致)。
- 依次啟動各節點的 OAP 服務,通過 ZooKeeper 實現節點發現。
- 啟動 UI 服務,指向任意 OAP 節點地址。
3. 數據采集配置(以 Java 應用為例)
- 下載 Agent
cd agents
# 或從官網下載對應語言的Agent(如Java、Python等)
配置 Agent:
vi config/agent.config
agent.name=your-application-name # 應用名稱
collector.backend_service=192.168.1.104:11800,192.168.1.105:11800 # OAP集群地址
啟動應用:
java -javaagent:/path/to/skywalking-agent/skywalking-agent.jar -Dskywalking.agent.service_name=your-app -jar your-app.jar
二、SkyWalking 集群維護
1. 日常監控與巡檢
- 核心指標:
- OAP 節點狀態:CPU / 內存利用率、GC 頻率、線程數。
- 存儲性能:ES 集群健康度、索引寫入延遲、磁盤利用率。
- UI 響應時間:頁面加載速度、接口調用成功率。
- 工具推薦:
- 用 Prometheus+Grafana 監控 SkyWalking 自身指標(需開啟 OAP 的 Prometheus exporter)。
- ES 內置監控工具(如 Dev Tools、Kibana)。
2. 數據管理
- 索引生命周期管理(ILM):
# 在OAP配置中啟用ILM(ES 7.x+推薦)
elasticsearch7:index:prefix: ${SW_NAMESPACE:"skywalking"}suffix: ${SW_DATAFLOW_SUFFIX:""}lifecycle:enable: truename: "skywalking-lifecycle" # ES中需提前創建生命周期策略rollover:max_docs: 5000000 # 單個索引最大文檔數max_size: 50gb # 單個索引最大存儲大小
- 數據清理:
- 定期刪除歷史索引(如保留 7 天數據),避免存儲爆炸。
- 對低頻查詢數據歸檔到冷存儲(如 ES Cold 節點)。
3. 集群擴展與升級
-
橫向擴展 OAP 節點:
- 新增服務器,復制 OAP 配置(保持 ZooKeeper 和 ES 地址一致)。
- 啟動新節點,自動加入集群(通過 ZooKeeper 協調)。
- 更新 UI 配置中的 OAP 地址列表。
-
版本升級:
- 停止所有 OAP 節點和 UI 服務。
- 備份存儲數據(如 ES 快照)。
- 替換新版本安裝包,更新配置(注意版本兼容性)。
- 按順序啟動 OAP 集群和 UI,驗證數據采集正常。
三、常見問題與處理
1. 數據采集失敗
- 可能原因:
- Agent 配置錯誤(如 OAP 地址錯誤、端口被防火墻攔截)。
- OAP 存儲連接失敗(ES 集群不可用、認證信息錯誤)。
- 解決方法:
- 檢查 Agent 日志(
logs/skywalking-agent.log
),確認是否連接到 OAP。 - 測試 OAP 節點與存儲組件的網絡連通性(如
telnet ES_IP 9200
)。 - 重啟 OAP 服務,查看啟動日志(
logs/oap-server.log
)中的錯誤信息。
- 檢查 Agent 日志(
2. UI 界面無數據
- 可能原因:
- 應用未正確關聯 Agent(服務名重復或未配置)。
- OAP 集群節點間數據同步失敗(ZooKeeper 故障)。
- 解決方法:
- 確認 Agent 的
agent.name
唯一且與 UI 中展示的服務名一致。 - 檢查 ZooKeeper 集群狀態,確保 OAP 節點正常注冊。
- 手動觸發一次數據采集(如調用應用接口),觀察 ES 中是否生成新索引。
- 確認 Agent 的
3. 存儲性能瓶頸
- 可能原因:
- ES 集群分片數不合理,導致寫入壓力集中。
- OAP 數據采集頻率過高,超過存儲處理能力。
- 解決方法:
- 調整 ES 索引分片數(如
PUT /skywalking-*/_settings?preserve_existing=true {"index.number_of_shards": 5}
)。 - 在 OAP 配置中降低采樣率(
sampling: ${SW_SAMPLING:1000}
,值越大采樣率越低)。
- 調整 ES 索引分片數(如
4. 集群節點失聯
- 可能原因:
- 節點間網絡中斷(如交換機故障、防火墻策略變更)。
- ZooKeeper 會話超時(配置
cluster.zookeeper.sessionTimeout
過小)。
- 解決方法:
- 檢查服務器間網絡連通性,修復中斷鏈路。
- 增大 ZooKeeper 會話超時時間(建議設置為 30 秒以上):
-
cluster:zookeeper:sessionTimeout: 30000 # 單位毫秒
?
四、最佳實踐
-
高可用架構:
- OAP 節點至少部署 3 個,通過 ZooKeeper 實現故障自動切換。
- 存儲組件(如 ES)采用多節點集群,啟用副本機制。
-
日志與告警:
- 配置 SkyWalking 自身告警(如通過 Webhook 發送到釘釘 / 郵件)。
- 對 OAP 和存儲組件的關鍵指標設置閾值(如 ES 磁盤利用率 > 80% 時告警)。
-
安全加固:
- 限制 UI 端口的公網訪問,通過 Nginx+SSL 代理。
- 對 ES 集群啟用認證(如 X-Pack),避免數據泄露。
?
?
?
?
?
?