一. 介紹
1. 基本信息
SkyWalking 創建於2015年，提供分布式追蹤功能。從5.x開始，項目進化為一個完成功能的Application Performance Monitoring系統。
他被用於追蹤、監控和診斷分布式系統，特別是使用微服務架構，雲原生或容積技術。提供以下主要功能：
- 分布式追蹤和上下文傳輸
- 應用、實例、服務性能指標分析
- 根源分析
- 應用拓撲分析
- 應用和服務依賴分析
- 慢服務檢測
- 性能優化
特點
- 性能好：針對單實例5000tps的應用，在全量采集的情況下，只增加 10% 的CPU開銷
- 支持多語言探針
- 支持自動及手動探針：其中手動探針通過OpenTrackingApi、@Trace注解、trackId集成到日志中。
2. SkyWalking的主要部分及其功能
SkyWalking主要由三大部分組成：Agent，Collector，Web；
- Agent：作用是使用JavaAgent字節碼增強技術將Agent的代碼織入程序中，完成Agent無代碼侵入地獲取程序內方法的上下文並進行增強和收集信息並發送給Collector；與Collector進行心跳，表明Agent客戶端的存活。
- Collector：作用是維護存活的Agent實例，並收集從Agent發送至Collector的數據，進行處理及持久化；
Web：作用是將Collector收集的參數進行不同維度的展示
下面是 SkyWalking 6.x 的架構圖：
說明： SkyWalking 的核心是數據分析和度量結果的存儲平台，通過 HTTP 或 gRPC 方式向 SkyWalking Collecter 提交分析和度量數據，SkyWalking Collecter 對數據進行分析和聚合，存儲到 Elasticsearch、H2、MySQL、TiDB 等其一即可，最后我們可以通過 SkyWalking UI 的可視化界面對最終的結果進行查看。Skywalking 支持從多個來源和多種格式收集數據：多種語言的 Skywalking Agent 、Zipkin v1/v2 、Istio 勘測、Envoy 度量等數據格式。
整體架構看似模塊有點多，但在實際上還是比較清晰的，主要就是通過收集各種格式的數據進行存儲，然后展示。所以搭建 Skywalking 服務我們需要關注的是 SkyWalking Collecter、SkyWalking UI 和 存儲設備，SkyWalking Collecter、SkyWalking UI 官方下載安裝包內已包含，最終我們只需考慮存儲設備即可。
SW總體可以分為四部分：
1.Skywalking Agent：使用Javaagent做字節碼植入，無侵入式的收集，並通過HTTP或者gRPC方式發送數據到Skywalking Collector。
2. Skywalking Collector ：鏈路數據收集器，對agent傳過來的數據進行整合分析處理並落入相關的數據存儲中。
3. Storage：Skywalking的存儲，時間更迭，sw已經開發迭代到了6.x版本，在6.x版本中支持以ElasticSearch、Mysql、TiDB、H2、作為存儲介質進行數據存儲。
4. UI ：Web可視化平台，用來展示落地的數據。
Skywalking Agent配置
通過了解配置，可以對一個組件功能有一個大致的了解。讓我們一起看一下skywalking的相關配置。
解壓開skywalking的壓縮包，在agent/config文件夾中可以看到agent的配置文件。
從skywalking支持環境變量配置加載，在啟動的時候優先讀取環境變量中的相關配置。
skywalking agent使用javaagent無侵入式的配合collector實現對分布式系統的追蹤和相關數據的上下文傳遞。
Skywalking Collector關鍵配置
Collector支持集群部署，zookeeper、kubernetes（如果你的應用是部署在容器中的）、consul（GO語言開發的服務發現工具）是sw可選的集群管理工具，結合大家具體的部署方式進行選擇。詳細配置大家可以去Skywalking官網下載介質包進行了解。
Collector端口設置
downsampling: 采樣匯總統計維度，會分別按照分鍾、【小時、天、月】（可選）來統計各項指標數據。
通過設置TTL相關配置項可以對數據進行自動清理。
Skywalking 在6.X中簡化了配置。collector提供了gRPC和HTTP兩種通信方式。
UI使用rest http通信，agent在大多數場景下使用grpc方式通信，在語言不支持的情況下會使用http通信。
關於綁定IP和端口需要注意的一點是，通過綁定IP，agent和collector必須配置對應ip才可以正常通信。
Collector存儲配置
在application.yml中配置的storage模塊配置中選擇要使用的數據庫類型，並填寫相關的配置信息。
Collector Receiver
Receiver是Skywalking在6.x提出的新的概念，負責從被監控的系統中接受指標數據。用戶完全可以參照OpenTracing規范來上傳自定義的監控數據。Skywalking官方提供了service-mesh、istio、zipkin的相關能力。
現在Skywalking支持服務端采樣，配置項為sampleRate，比例采樣，如果配置為5000則采樣率就是50%。
關於采樣設置的一點注意事項
關於服務采樣配置的一點建議，如果Collector以集群方式部署，比如：Acollector和Bcollector，建議Acollector.sampleRate = Bcollector.sampleRate。如果采樣率設置不相同可能會出現數據丟失問題。
假設Agent端將所有數據發送到后端Collector處，A采樣率設置為30%，B采樣率為50%。
假設有30%的數據，發送到A上，這些數據被全部正確接受並存儲，極端情況（與期望的采樣數據量相同）下，如果剩下20%待采樣的數據發送到了B，這個時候一切都是正常的，如果這20%中有一部分數據被送到了A那么，這些數據將是被忽略的，由此就會造成數據丟失。
二、業務調用鏈路監控
Service Topology監控
調用鏈路監控可以從兩個角度去看待。我們先從整體上來認識一下我們所監控的系統。
通過給服務添加探針並產生實際的調用之后，我們可以通過Skywalking的前端UI查看服務之間的調用關系。
我們簡單模擬一次服務之間的調用。新建兩個服務，service-provider以及service-consumer，服務之間簡單的通過Feign Client 來模擬遠程調用。
從圖中可以看到:
有兩個服務節點：provider & consumer
有一個數據庫節點：localhost【mysql】
一個注冊中心節點
consumer消費了provider提供出來的接口。
一個系統的拓撲圖讓我們清晰的認識到系統之間的應用的依賴關系以及當前狀態下的業務流轉流程。細心的可能發現圖示節點consumer上有一部分是紅色的，紅色是什么意思呢？
紅色代表當前流經consumer節點的請求有一斷時間內是響應異常的。當節點全部變紅的時候證明服務現階段內就徹底不可用了。運維人員可以通過Topology迅速發現某一個服務潛在的問題，並進行下一步的排查並做到預防。
Skywalking Trace監控
Skywalking通過業務調用監控進行依賴分析，提供給我們了服務之間的服務調用拓撲關系、以及針對每個endpoint的trace記錄。
我們在之前看到consumer節點服務中發生了錯誤，讓我們一起來定位下錯誤是發生在了什么地方又是什么原因呢？
在每一條trace的信息中都可以看到當前請求的時間、GloableId、以及請求被調用的時間。我們分別看一看正確的調用和異常的調用。
Trace調用鏈路監控
圖示展示的是一次正常的響應，這條響應總耗時19ms，它有4個span：
span1 /getStore = 19ms 響應的總流轉時間
span2 /demo2/stores = 14ms feign client 開始調用遠程服務后的響應的總時間
span3 /stores = 14ms 接口服務響應總時間
span4 Mysql = 1ms 服務提供端查詢數據庫的時間
這里span2和span3的時間表現相同，其實是不同的，因為這里時間取了整。
在每個Span中可以查看當前Span的相關屬性。
組件類型: SpringMVC、Feign
Span狀態: false
HttpMethod: GET
Url: http://192.168.16.125:10002/demo2/stores
這是一次正常的請求調用Trace日志，可能我們並不關心正常的時候，畢竟一切正常不就是我們期待的么！
我們再來看下，異常狀態下我們的Trace以及Span又是什么樣的呢。
發生錯誤的調用鏈中Span中的is error標識變為true，並且在名為Logs的TAB中可以看到錯誤發生的具體原因。根據異常情況我們就可以輕松定位到影響業務的具體原因，從而快速定位問題，解決問題。
通過Log我們看到連接被拒，那么可能是我們的網絡出現了問題（可能性小，因為實際情況如果網絡出現問題我們連這個trace都看不到了），也有可能是服務端配置問題無法正確建立連接。通過異常日志，我們迅速就找到了問題的關鍵。
實際情況是，我把服務方停掉了，做了一次簡單的模擬。可見，通過拓撲圖示我們可以清晰的看到眾多服務中哪個服務是出現了問題的，通過trace日志我們可以很快就定位到問題所在，在最短的時間內解決問題。
三、服務性能指標監控
Skywalking還可以查看具體Service的性能指標，根據相關的性能指標可以分析系統的瓶頸所在並提出優化方案。
Skywalking 性能監控
在服務調用拓撲圖上點擊相應的節點我們可以看到該服務的
SLA: 服務可用性（主要是通過請求成功與失敗次數來計算）
CPM: 每分鍾調用次數
Avg Response Time: 平均響應時間
從應用整體外部來看我們可以監測到應用在一定時間段內的
服務可用性指標SLA
每分鍾平均響應數
平均響應時間
服務進程PID
服務所在物理機的IP、HostName、Operation System
Service JVM信息監控
還可以監控到Service運行時的CPU、堆內存、非堆內存使用率、以及GC情況。這些信息來源於JVM。注意這里的數據可不是機器本身的數據。
四、服務告警
前文我們提到了通過查看拓撲圖以及調用鏈路可以定位問題，可是運維人員又不可能一直盯着這些數據，那么我們就需要告警能力，在異常達到一定閾值的時候主動的提示我們去查看系統狀態。
在Sywalking 6.x版本中新增了對服務狀態的告警能力。它通過webhook的方式讓我們可以自定義我們告警信息的通知方式。諸如:郵件通知、微信通知、短信通知等。
Skywalking 服務告警
先來看一下告警的規則配置。在alarm-settings.xml中可以配置告警規則，告警規則支持自定義。
一份告警配置由以下幾部分組成：
service_resp_time_rule：告警規則名稱 ***_rule （規則名稱可以自定義但是必須以’_rule’結尾
indicator-name：指標數據名稱： 定義參見http://t.cn/EGhfbmd
op: 操作符： > , < , = 【當然你可以自己擴展開發其他的操作符】
threshold：目標值：指標數據的目標數據 如sample中的1000就是服務響應時間，配合上操作符就是大於1000ms的服務響應
period: 告警檢查周期：多久檢查一次當前的指標數據是否符合告警規則
counts: 達到告警閾值的次數
silence-period：忽略相同告警信息的周期
message：告警信息
webhooks：服務告警通知服務地址
Skywalking通過HttpClient的方式遠程調用在配置項webhooks中定義的告警通知服務地址。
了解了SW所傳送的數據格式我們就可以對告警信息進行接收處理，實現我們需要的告警通知服務啦！
我們將一個服務停掉，並將另外一個服務的某個對外暴露的接口讓他休眠一定的時間。然后調用一定的次數觀察服務的狀態信息以及告警情況。
總結：
本文簡單的通過skwaylking的配置來對skywlaking的功能進行一次初步的了解，對skwaylking新提出的概念以及新功能進行簡單的詮釋，方便大家了解和使用。通過使用APM工具，可以讓我們方便的查看微服務架構中系統瓶頸以及性能問題等。
二、如何安裝SkyWalking（Java）（本機）
1、在安裝SkyWalking之前，需要選擇數據的存在方式並進行搭建環境，SkyWalking支持兩種存儲方式：H2、mysql和ES
2、獲取Apache的最新發布的穩定版本或者下載github上面的源碼在穩定版本的tag上進行編譯完成之后會獲取到如下圖所示的文件結構
下載skywalking6.0.0
http://skywalking.apache.org/downloads/
http://mirrors.tuna.tsinghua.edu.cn/apache/skywalking/6.5.0/apache-skywalking-apm-6.5.0.zip，解壓即可。
下載jdk8
https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
經測試高於jdk8不支持。
3、安裝collector模塊
修改collector的配置：找到config目錄下的application.yml文件，找到以下的配置，
MySQL配置方法：
找個mysql-connector-java-5.1.47.jar
放入apache-skywalking-apm-incubating\oap-libs
經測試mysql/j版本是6.x.x和8.x.x會有問題
mysql配置
打開apache-skywalking-apm-incubating\config\application.yml
注釋掉storage:h2 解鎖mysql
打開apache-skywalking-apm-incubating\config\datasource-settings.properties
修改mysql的配置
加入dataSource.useSSL=false (可選)
mysql: properties: jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://10.200.110.4:3306/duan"} dataSource.user: ${SW_DATA_SOURCE_USER:duan} dataSource.password: ${SW_DATA_SOURCE_PASSWORD:123456} dataSource.cachePrepStmts: ${SW_DATA_SOURCE_CACHE_PREP_STMTS:true} dataSource.prepStmtCacheSize: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_SIZE:250} dataSource.prepStmtCacheSqlLimit: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_LIMIT:2048} dataSource.useServerPrepStmts: ${SW_DATA_SOURCE_USE_SERVER_PREP_STMTS:true} dataSource.useSSL: false metadataQueryMaxSize: ${SW_STORAGE_MYSQL_QUERY_MAX_SIZE:5000}
ES配置方法：
storage: elasticsearch: clusterName: CollectorDBCluster //修改集群名稱為你的ES的集群名稱 clusterNodes: localhost:9300 //修改集群節點為你的ES的集群節點地址
然后啟動bin目錄下的startup.sh就可以將collector和Web模塊啟動起來了。訪問本地的8080端口即可登錄頁面，賬號密碼都為admin。
核對webapp
apache-skywalking-apm-incubating\webapp\webapp.yml
server:
port為網站端口，默認的8080容易與其他軟件沖突，建議改一下比如18080
server:
ip設置為0.0.0.0 (可選)
collector:ribbon:listOfServers設置為127.0.0.1:12800(多個以逗號隔開)
保證18080,10800,11800,12800端口不被占用
啟動前先初始化 執行oapServiceInit.bat
然后執行：startup.bat，啟動skywalking
web模塊如果啟動正常，可以通過訪問：http://10.200.110.100:18080/，看到如下頁面：
collector模塊如果啟動正常，會在MySQL中創建很多表及數據：
創建windows服務
復制oapService.bat為oapService1.bat
注釋::start "%OAP_PROCESS_TITLE%" 注意，后面%_EXECJAVA%開始的部分不要注釋掉
復制webappService.bat為webappService1.bat
注釋::start "%WEBAPP_PROCESS_TITLE%" 注意，后面%_EXECJAVA%開始的部分不要注釋掉
然后用nssm將其發布成windows服務
nssm install SkywalkingOap
nssm install SkywalkingWebapp
4、agent
4.1、agent配置
使用javaagent無侵入式的配合collector實現對分布式系統的追蹤和相關數據的上下文傳遞。
配置文件位置
apache-skywalking-apm-incubating\agent\config\agent.config
配置說明
- agent.namespace: 跨進程鏈路中的header，不同的namespace會導致跨進程的鏈路中斷
- agent.service_name:一個服務（項目）的唯一標識，這個字段決定了在sw的UI上的關於service的展示名稱--是應用程序名（//改為你的項目名字）
- agent.sample_n_per_3_secs: 客戶端采樣率，默認是-1代表全采樣
- agent.authentication: 與collector進行通信的安全認證，需要同collector中配置相同
- agent.ignore_suffix: 忽略特定請求后綴的trace
- collecttor.backend_service: agent需要同collector進行數據傳輸的IP和端口--是agent的地址
- logging.level: agent記錄日志級別
這個配置可在.net core程序中重寫
3.2、agent啟動
D:\gitspace\appsflyer-reflux\build\libs>java -javaagent:D:\soft\skywalking\apache-skywalking-apm-bin\agent\skywalking-agent.jar -jar appsflyer-reflux-201905241004.jar