首先有必要说明一下为什么使用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
以及如何和注册中心结合达到高可用。当然,告警规则的配置也需要琢磨一下。
我是个双鱼座的小王子,沉浸在自己的代码世界里,去探索这未知的世界,希望遇到更多的小伙伴一起前行!