SkyWalking分散式系統應用程式性能監控工具-上
概述
微服務系統監控三要素
現在系統基本都是微服務架構，對於複雜微服務鏈路調用如下問題如何解決？
- 一個請求經過了這些服務後其中出現了一個調用失敗的問題，如何定位問題發生的地方？
- 如何計算每個節點訪問流量？
- 流量波動的時候，增加哪些節點集群服務？
為了解決分散式應用、微服務系統面臨的這些挑戰，APM系統（Application Performance Management，即應用性能管理，簡單來說就是應用監控）為之誕生，核心滿足微服務系統監控的三要素如下：
- Logging ： 就是記錄系統行為的離散事件，例如，服務在處理某個請求時列印的錯誤日誌，我們可以將這些日誌資訊記錄到 ElasticSearch 或是其他存儲中，然後通過 Kibana 或是其他工具來分析這些日誌了解服務的行為和狀態。大多數情況下，日誌記錄的數據很分散，並且相互獨立，比如錯誤日誌、請求處理過程中關鍵步驟的日誌等等
- Metrics ：是系統在一段時間內某一方面的某個度量，例如，電商系統在一分鐘內的請求次數。我們常見的監控系統中記錄的數據都屬於這個範疇，例如 Promethus、Open-Falcon 等，這些監控系統最終給運維人員展示的是一張張二維的折線圖。Metrics 是可以聚合的，例如，為電商系統中每個 HTTP 介面添加一個計數器，計算每個介面的 QPS，之後我們就可以通過簡單的加和計算得到系統的總負載情況。
- Tracing ：即我們常說的分散式鏈路追蹤。在微服務架構系統中一個請求會經過很多服務處理，調用鏈路會非常長，要確定中間哪個服務出現異常是非常麻煩的一件事。通過分散式鏈路追蹤，運維人員就可以構建一個請求的視圖，這個視圖上展示了一個請求從進入系統開始到返迴響應的整個流程。這樣，就可以從中了解到所有服務的異常情況、網路調用，以及系統的性能瓶頸等。
OpenTracing
早在在 2010 年 4 月Google發表了一篇論文《Dapper, a Large-Scale Distributed Systems TracingInfrastructure》闡述分散式追蹤的概念，OpenTracing用於分散式跟蹤和上下文傳播的一致的、表達的、提供了一個標準的與供應商無關的api框架，這意味著如果開發者想要嘗試一種不同的分散式追蹤系統，開發者只需要簡單地修改Tracer配置即可，而不需要替換整個分散式追蹤系統；OpenTracing API目前也支援眾多語言。了解OpenTracing API可以有利於更好學習本篇的主角SkyWalking。
開源APM系統
目前市面上開源的APM系統主要有CAT、Zipkin、Pinpoint，大都是參考Google的Dapper實現的
- CAT： 是由中國美團點評開源的，基於Java語言開發，目前提供Java、C/C++、Node.js、Python、Go等語言的客戶端，監控數據會全量統計，中國很多公司在用，例如美團點評、攜程、拼多多等，CAT跟下邊要介紹的Zipkin都需要在應用程式中埋點，對程式碼侵入性強，我們傾向於選擇對程式碼無侵入的產品，所以淘汰了CAT
- Zipkin： 由Twitter公司開發並開源，Java語言實現，侵入性相對於CAT要低一點，需要對web.xml之類的配置文件做修改，但依然對程式碼有侵入，也沒有選擇
- Pinpoint： 一個韓國團隊開源的產品，運用了位元組碼增強技術，只需要在啟動時添加啟動參數即可，對程式碼無侵入，目前支援Java和PHP語言，底層採用HBase來存儲數據，探針收集的數據粒度非常細，但性能損耗大，因其出現的時間較長，完成度也很高，應用的公司較多。
SkyWalking介紹
Apache SkyWalking 官網地址 //skywalking.apache.org/ 最新版本9.1.0
Apache SkyWalking 文檔地址 //skywalking.apache.org/docs/
Apache SkyWalking v9.1.0文檔地址 //skywalking.apache.org/docs/main/v9.1.0/readme/
Apache SkyWalking GitHub源碼地址 //github.com/apache/skywalking
Apache SkyWalking用於分散式系統的應用程式性能監控工具，特別為微服務、雲本地和基於容器(Kubernetes)架構設計。Service Mesh和FaaS已就緒，內置服務網格和FaaS可觀察性，收集和分析Istio + Envoy Service Mesh和OpenFunction作為FaaS平台的數據。
SkyWalking基本可以滿足對於分散式系統APM的所有需要的功能，功能非常強大、性能表現優秀、對業務程式碼無侵入， 增長勢頭強勁，社區活躍，中文文檔齊全，支援多語言探針， SkyWalking 支援Dubbo、gRPC、SOFARPC 等很多框架，包含了雲原生架構下的分散式系統的監控、跟蹤、診斷、日誌記錄功能，可以在瀏覽器上觀察分散式系統應用程式發生的一切。
-
核心功能
- 服務、服務實例、端點(URI)指標分析
- 根本原因分析。在運行時上分析由進程內代理和ebpf分析器支援的程式碼。
- 業務拓撲圖分析
- 服務實例和端點(URI)依賴關係分析
- 服務和端點檢測速度慢
- 性能優化
- 分散式跟蹤和上下文傳播
- 資料庫訪問指標。檢測慢速資料庫訪問語句(包括SQL語句)
- 消息隊列性能和消耗延遲監視
- 瀏覽器性能監控
- 基礎設施(虛擬機、網路、磁碟等)監控
- 跨指標、跟蹤和日誌的協作
- 告警
-
特點
- 多語言支援，符合技術棧的Agent包括net Core、PHP、NodeJS、Golang、LUA、Rust和c++代理，積極開發和維護。用於C、c++、Golang和Rust的eBPF分析器作為附加。
- 為多種開源項目提供了插件，為 Tomcat、 HttpClient、Spring、RabbitMQ、MySQL 等常見基礎設施和組件提供了自動探針。
- 微內核 + 插件的架構，存儲、集群管理、使用插件集合都可以進行自由選擇。
- 優秀的可視化效果。
基本概念
SkyWalking是一個開源的可觀測平台的APM系統，用於收集、分析、聚合和可視化來自服務和雲原生基礎設施的數據。SkyWalking提供了一種簡單的方式來維護分散式系統的清晰視圖，甚至跨雲。它是一個現代化的APM，專門為本地雲、基於容器的分散式系統設計。
- 服務：表示一組/一組工作負載，它們為傳入請求提供相同的行為，如一個微服務。在使用儀器代理或sdk時自定義服務名稱。SkyWalking也可以使用你在Istio等平台中定義的名稱。
- 服務實例：Service組中的每個工作負載都被稱為一個實例，如運行某個微服務實例。
- 端點：服務中用於傳入請求的路徑，例如HTTP URI路徑或gRPC服務類+方法簽名。
- 進程：作業系統進程，在某些場景中，某個服務實例運行多個進程。
SkyWalking涵蓋了所有3個可觀察性領域，包括跟蹤、指標和日誌：
- 跟蹤：SkyWalking原生數據格式，包括Zipkin v1和v2，以及Jaeger。
- 指標：SkyWalking集成了服務網格平台，如Istio、Envoy和Linkerd，將可觀測性構建到數據平面或控制平面。此外，SkyWalking本機代理可以在度量模式下運行，這大大提高了性能。
- 日誌記錄：包括從磁碟或網路收集的日誌。本機代理可以自動將跟蹤上下文與日誌綁定，或者使用skywalk通過文本內容綁定跟蹤和日誌。
架構
使用skywalk，用戶可以了解服務和端點之間的拓撲關係，查看每個服務/服務實例/端點的指標，設置告警規則。SkyWalking邏輯上分為四個部分:探針、平台後端、存儲和UI。
- Agent（探針）：探針收集數據並根據SkyWalking的要求對數據進行重新格式化(不同的探測器支援不同的來源)；Agent 運行在各個服務實例中，負責採集服務實例的 Trace 、Metrics 等數據，然後通過 gRPC 方式上報給 SkyWalking 後端。
- OAP：SkyWalking 的後端服務，支援數據聚合、分析和流處理，包括跟蹤、指標和日誌。
- 接收 Agent 上報上來的 Trace、Metrics 等數據，交給 Analysis Core （涉及SkyWalking OAP 中的多個模組）進行流式分析，最終將分析得到的結果寫入持久化存儲中。
- 響應 SkyWalking UI 介面發送來的查詢請求，將前面持久化的數據查詢出來，組成正確的響應結果返回給 UI 介面進行展示。
- 存儲：SkyWalking數據可以選擇存儲在已實現的ElasticSearch, H2, MySQL, TiDB, InfluxDB的持久化系統，一般線上使用ElasticSearch 集群作為其後端存儲。
- UI:可視化和管理SkyWalking 數據，前後端分離，該 UI 介面負責將用戶的查詢操作封裝為 GraphQL 請求提交給 OAP 後端觸發後續的查詢操作，待拿到查詢結果之後會在前端負責展示。
部署
下載
# 官網下載最新版本9.1.0
wget //dlcdn.apache.org/skywalking/9.1.0/apache-skywalking-apm-9.1.0.tar.gz
# 接下文件
tar -xvf apache-skywalking-apm-9.1.0.tar.gz
# 進入目錄
cd apache-skywalking-apm-bin/
部署ES
持久化存儲我們選擇ES，由於前面有兩篇文章都講過ES部署，一篇使用docker部署，一篇使用二進位文件部署，有興趣可以前往去看。這裡我們就直接使用
部署SkyWalking
SkyWalk部署很簡單，部署方式有很多，官方提供二進位、Docker、K8S的部署指引，Docker和K8s部署詳細可以查閱官網
# oap-server
docker run --name oap --restart always -d -e SW_STORAGE=elasticsearch -e SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200 apache/skywalking-oap-server:9.1.0
# UI
docker run --name oap --restart always -d -e SW_OAP_ADDRESS=//oap:12800 apache/skywalking-ui:9.1.0
學習則選擇二進位部署方式，默認配置可以直接運行，但使用的存儲是H2記憶體資料庫，重啟後數據丟失，修改oap-server配置文件中存儲模式即可， vi config/application.yml
SkyWalk的webapp也即是UI默認的8080埠，這裡就不修改
# 啟動
sh ./bin/startup.sh
# 啟動後skywalking-oap-server會先判斷是否有相應的表，沒有則創建，創建的表也比較多，需要稍等一會，下面日誌已經使用elasticsearch做持久化存儲
2022-07-23 10:46:17,966 - org.apache.skywalking.oap.server.starter.config.ApplicationConfigLoader - 118 [main] INFO [] - Provider=elasticsearch config=clusterNodes has been set as 192.168.5.52:9200
訪問//192.168.5.52:8080/ ，出現UI介面，當然9.x比8.x多出很多功能，包括服務網格、函數，可視化能力也是越來越強
Agent應用
下載
# 選擇目前最新版本8.11.0
wget //dlcdn.apache.org/skywalking/java-agent/8.11.0/apache-skywalking-java-agent-8.11.0.tgz
# 解壓後skywalk-agent.jar在根目錄下，agent.config在config目錄下
說明
- Agent可用於JDK 8 - 17。
- 在config/agent.config service_name。可以是英文中的任何字元串。
- agent在config/agent.config backend_service。默認點為127.0.0.1:11800，僅適用於本地後端，如果是遠程配置遠程地址。
- 將-javaagent:/path/to/skywalk -package/agent/skywalk-agent.jar添加到JVM參數。並確保將它添加到-jar參數之前。
Agent包目錄如下：
配置
使用前面的庫存微服務和訂單微服務模組，將agent.config 拷貝到兩個項目的resources目錄下
庫存微服務修改agent.config下面兩個配置
agent.service_name=${SW_AGENT_NAME:ecom-storage-service}
# Backend service addresses.
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:192.168.5.52:11800}
啟動jvm參數增加
-javaagent:F:\commoms\skywalking-agent\skywalking-agent.jar
-Dskywalking_config=F:\dev\simple-ecommerce\ecom-storage-service\src\main\resources\agent.config
訂單微服務修改agent.config下面兩個配置
agent.service_name=${SW_AGENT_NAME:ecom-order-service}
# Backend service addresses.
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:192.168.5.52:11800}
啟動jvm參數增加
-javaagent:F:\commoms\skywalking-agent\skywalking-agent.jar
-Dskywalking_config=F:\dev\simple-ecommerce\ecom-order-service\src\main\resources\agent.config
啟動庫存微服務和訂單微服務，啟動日誌中載入agent.config和使用skywalk-agent.jar
訪問訂單介面，//localhost:4070/order/create/1000/1001/2 ，訪問庫存介面//localhost:4080/list ，在普通服務的Service 頁面中查看到兩個微服務
在Topology查看微服務之間拓撲關係，可以設置查詢的深度
在跟Trace查看跟蹤列表資訊，選擇查詢條件，可以切換樹結構、表格、統計
點進列表的記錄後還可以查看到詳細資訊，包括使用那個組件都有，但識別不一定很準確
普通服務的Service 頁面選擇服務如訂單服務，顯示訂單服務的各項概覽資訊，可切換到實例、斷點、拓撲、追蹤、性能分析、日誌等功能頁面
自定義SkyWalking鏈路追蹤
如果想要對項目里的業務方法實現鏈路追蹤，方便排查問題，做法如下，先引入依賴
<dependency>
<groupId>org.apache.skywalking</groupId>
<artifactId>apm-toolkit-trace</artifactId>
<version>8.11.0</version>
</dependency>
然後在業務方法加上@Trace+@Tags註解，如果只需要一個Tag也可以直接@Trace+@Tag
@Override
@GlobalTransactional
@Trace
@Tags({@Tag(key = "order",value = "returnedObj"),
@Tag(key = "param1", value = "arg[0]"),
@Tag(key = "param2", value = "arg[1]")})
public Order create(String userId, String commodityCode, int orderCount) {
String xid = RootContext.getXID();
log.info("order xid：{}",xid);
storageFeignService.deduct(commodityCode,orderCount);
// int i = 1/0;
Order order = new Order();
order.setUserId(userId);
order.setCommodityCode(commodityCode);
order.setCount(orderCount);
order.setMoney(orderCount*10);
orderMapper.insert(order);
return order;
}
重新啟動庫存和訂單微服務，再次訪問訂單介面，//localhost:4070/order/create/1000/1001/2
選擇服務後再選擇相應的功能頁面
點擊查詢詳細，這時候就可以查看業務方法的參數值和返回值資訊
**本人部落格網站 **IT小神 www.itxiaoshen.com
