Skywalking部署及使用
前言
首先有必要說明一下爲什麼使用skywalking。
我對zipkin、cat和skywalking這幾個較爲主流的監控產品做了一些調研和對比，其中zipkin是我項目中之前已經在使用的，我也寫過一些相關的文章，而cat僅是通過資料收集並沒有實際的使用，可能會與實際情況有一定偏差，整理以後情況彙總如下表：
| 項目 | Cat | Zipkin | Skywalking |
|---|---|---|---|
| 調用鏈可視化 | 有 | 有 | 有 |
| 聚合報表 | 非常豐富 | 少 | 較豐富 |
| 服務依賴圖 | 簡單 | 簡單 | 好 |
| 埋點方式 | 侵入式 | 侵入式 | 非侵入，字節碼增強 |
| VM監控指標 | 好 | 無 | 有 |
| 支持語言 | java/.net | 豐富 | java/.net/Nodejs/php/go |
| 存儲機制 | mysql（報表）、本地文件/HDFS（調用鏈） | 內存、es、mysql等 | H2、es |
| 社區支持 | 主要在國內 | 國外主流 | Apache支持 |
| 使用案例 | 美團、攜程、陸金所 | 京東、阿里定製後不開源 | 華爲、小米、噹噹、微衆銀行 |
| APM | 是 | 否 | 是 |
| 開發基礎 | eBay cal | Google Dapper | Google Dapper |
| 是否支持webflux | 否 | 是 | 是 |
| Github stars(2019.12) | 12.3K | 12.2K | 11.8K |
然後根據上表說一下爲什麼我選擇用Skywalking來替換掉已經在用的zipkin，主要理由有以下幾點：
- 我的微服務體系選用的服務網關是spring-cloud-gateway，是基於webflux實現的，很多監控並不支持，比如我司使用的商業化監控產品-聽雲，從資料來看
cat也不支持； - 我想要監控接口級別的指標，如吞吐量、p99等，這些是目前
zipkin不足的地方，而Skywalking這方面做得不錯； - Skywalking是非侵入式的，通過-javaagent機制運行時注入，即使以後更換監控方案也不需要對代碼大動干戈。
Skywalking架構
我使用的是最新版6.5.0，該版本下Skywalking主要分爲oap、webapp和agent三部分，oap和webapp分別用於彙總數據和展示，這兩塊共同組成了Skywalking的平臺；agent是探針，部署在需要收集數據的應用服務器上，並將數據同步到Skywalking的平臺。
oap配置
在github的Skywalking項目中下載最新版安裝包apache-skywalking-apm-6.5.0.tar.gz
tar -zxvf apache-skywalking-apm-6.5.0.tar.gz在服務器上解壓該安裝包，並進入config文件夾，對application.yml進行設置，主要設置如下幾個部分
cluster:
standalone:我爲了試用部署的單機模式，所以使用默認的standalon，集羣部署的話還支持zookeeper、consul、etcd、nacos等。
core:
default:
# Mixed: Receive agent data, Level 1 aggregate, Level 2 aggregate
# Receiver: Receive agent data, Level 1 aggregate
# Aggregator: Level 2 aggregate
role: ${SW_CORE_ROLE:Mixed} # Mixed/Receiver/Aggregator
restHost: ${SW_CORE_REST_HOST:0.0.0.0}
restPort: ${SW_CORE_REST_PORT:12800}
restContextPath: ${SW_CORE_REST_CONTEXT_PATH:/}
gRPCHost: ${SW_CORE_GRPC_HOST:0.0.0.0}
gRPCPort: ${SW_CORE_GRPC_PORT:11800}這裏的restPort和gRPCPort分別代表通過rest方式和graphql方式訪問的端口，沒有特殊需求建議按默認配置。
storage:
elasticsearch:
nameSpace: ${SW_NAMESPACE:""} #會相應修改es中存儲的索引的前綴
clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:172.28.51.150:9200} #es訪問地址
protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:"http"} #支持http和https# trustStorePath: ${SW_SW_STORAGE_ES_SSL_JKS_PATH:"../es_keystore.jks"}# trustStorePass: ${SW_SW_STORAGE_ES_SSL_JKS_PASS:""}
user: ${SW_ES_USER:"elastic"}
password: ${SW_ES_PASSWORD:"XXXXX"}
indexShardsNumber: ${SW_STORAGE_ES_INDEX_SHARDS_NUMBER:2}
indexReplicasNumber: ${SW_STORAGE_ES_INDEX_REPLICAS_NUMBER:0}
# Those data TTL settings will override the same settings in core module.
recordDataTTL: ${SW_STORAGE_ES_RECORD_DATA_TTL:7} # Unit is day
otherMetricsDataTTL: ${SW_STORAGE_ES_OTHER_METRIC_DATA_TTL:45} # Unit is day
monthMetricsDataTTL: ${SW_STORAGE_ES_MONTH_METRIC_DATA_TTL:18} # Unit is month
# Batch process setting, refer to https://www.elastic.co/guide/en/elasticsearch/client/java-api/5.5/java-docs-bulk-processor.html
bulkActions: ${SW_STORAGE_ES_BULK_ACTIONS:1000} # Execute the bulk every 1000 requests
flushInterval: ${SW_STORAGE_ES_FLUSH_INTERVAL:10} # flush the bulk every 10 seconds whatever the number of requests
concurrentRequests: ${SW_STORAGE_ES_CONCURRENT_REQUESTS:2} # the number of concurrent requests
resultWindowMaxSize: ${SW_STORAGE_ES_QUERY_MAX_WINDOW_SIZE:10000}
metadataQueryMaxSize: ${SW_STORAGE_ES_QUERY_MAX_SIZE:5000}
segmentQueryMaxSize: ${SW_STORAGE_ES_QUERY_SEGMENT_SIZE:200}存儲可以支持es，H2和mysql，官方比較推薦的是es，所以我也根據自己的es進行了配置。需要說明的是這裏只支持6.3.2 ~ 7.0.0 (excluded)版本的es，使用7.x.x版本的es需要另外下載apache-skywalking-bin-es7.tar.gz包。
另外，爲了性能考慮，官方建議在es的elasticsearch.yml配置中增加以下內容
thread_pool.index.queue_size: 1000 #只適用於ElasticSearch 6
thread_pool.write.queue_size: 1000 #適用於ElasticSearch 6 and 7
index.max_result_window: 1000000 #trace頁面出錯時記得設置webapp配置
webapp的配置文件在/webapp/webapp.yml中
server:
port: 8080 #訪問頁面使用的端口
collector:
path: /graphql
ribbon:
ReadTimeout: 10000
# Point to all backend's restHost:restPort, split by ,
listOfServers: 127.0.0.1:12800這裏默認使用graphql方式訪問oap的數據收集端口，因此監聽的是12800端口，並且因爲我把oap和webapp部署在同一臺服務器上，地址默認就使用了127.0.0.1。
平臺啓動
在/bin目錄下已經有了完備的腳本，可以通過startup .sh同時啓動oap和webapp進程，該腳本實際做的事情也就是調用同目錄下的oapService.sh和webappService.sh腳本，腳本內容如下所示。因此如果我們考慮分開部署這兩個進程的話可以單獨調用對應的腳本來運行。
#!/usr/bin/env sh
PRG="$0"
PRGDIR=`dirname "$PRG"`
OAP_EXE=oapService.sh
WEBAPP_EXE=webappService.sh
"$PRGDIR"/"$OAP_EXE"
"$PRGDIR"/"$WEBAPP_EXE"agent的使用
agent的使用需要將/agent整個目錄拷貝到對應需要監控的服務器上，並修改/agent/config下的agent.config配置
# 不同的namespace會導致調用鏈路追蹤中斷
agent.namespace=${SW_AGENT_NAMESPACE:hmall}
# 頁面上展示的service的名稱，也可以通過-Dskywalking.agent.service_name=xxx指定
agent.service_name=${SW_AGENT_NAME:gateway}
# 平臺的調用地址，也可以通過-Dskywalking.collector.backend_service=127.0.0.1:80指定
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:172.28.51.141:11800}
# 忽略指定後綴的請求收集
agent.ignore_suffix=${SW_AGENT_IGNORE_SUFFIX:.jpg,.jpeg,.js,.css,.png,.bmp,.gif,.ico,.mp3,.mp4,.html,.svg}
# 每3秒的採樣率，負數代表100%
agent.sample_n_per_3_secs=${SW_AGENT_SAMPLE:-1}需要重點關注的配置如上所示，修改完成後在啓動java進程時增加-javaagent:/opt/apache-skywalking-apm-bin/agent/skywalking-agent.jar以加載agent。
插件使用
默認情況agent是不支持對spring-cloud-gateway的監控的，需要插件的支持。我們要將optional-plugins下的插件apm-spring-cloud-gateway-2.x-plugin-6.5.0.jar拷貝到plugins下，使agent可以加載到該插件，其他一些需要額外插件支持的中間件和框架也是同理操作。
總結
skywalking.jpg
skywalking2.jpg
部署完成以後效果如圖，基本可以滿足我的指標監控需求，值得一提的是如果配置一切正常卻沒有數據顯示的話，一定要檢查右下角的時間軸對不對，不要問我是怎麼知道的。。。
目前的部署和使用還是基於虛擬機的，由於我的項目在生產環境已經上容器了，後續應用到線上前會研究一下如何在容器中部署和使用skywalking以及如何和註冊中心結合達到高可用。當然，告警規則的配置也需要琢磨一下。