Skywalking部署及使用

Skywalking部署及使用

前言

首先有必要說明一下爲何使用skywalking。

我對zipkin、cat和skywalking這幾個較爲主流的監控產品作了一些調研和對比，其中zipkin是我項目中以前已經在使用的，我也寫過一些相關的文章，而cat僅是經過資料收集並無實際的使用，可能會與實際狀況有必定誤差，整理之後狀況彙總以下表：

項目	Cat	Zipkin	Skywalking
調用鏈可視化	有	有	有
聚合報表	很是豐富	少	較豐富
服務依賴圖	簡單	簡單	好
埋點方式	侵入式	侵入式	非侵入，字節碼加強
VM監控指標	好	無	有
支持語言	java/.net	豐富	java/.net/Nodejs/php/go
存儲機制	mysql（報表）、本地文件/HDFS（調用鏈）	內存、es、mysql等	H二、es
社區支持	主要在國內	國外主流	Apache支持
使用案例	美團、攜程、陸金所	京東、阿里定製後不開源	華爲、小米、噹噹、微衆銀行
APM	是	否	是
開發基礎	eBay cal	Google Dapper	Google Dapper
是否支持webflux	否	是	是
Github stars(2019.12)	12.3K	12.2K	11.8K

而後根據上表說一下爲何我選擇用Skywalking來替換掉已經在用的zipkin，主要理由有如下幾點：

1. 個人微服務體系選用的服務網關是spring-cloud-gateway，是基於webflux實現的，不少監控並不支持，好比我司使用的商業化監控產品-聽雲，從資料來看cat也不支持；
2. 我想要監控接口級別的指標，如吞吐量、p99等，這些是目前zipkin不足的地方，而Skywalking這方面作得不錯；
3. 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以及如何和註冊中心結合達到高可用。固然，告警規則的配置也須要琢磨一下。