Skywalking部署及使用

对zipkin、cat和skywalking这几个较为主流的监控产品做了一些调研和对比，其中zipkin是我项目中之前已经在使用的，我也写过一些相关的文章，而cat仅是通过资料收集并没有实际的使用，可能会与实际情况有一定偏差，整理以后情况汇总如下表：

然后根据上表说一下为什么我选择用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以及如何和注册中心结合达到高可用。当然，告警规则的配置也需要琢磨一下。