首先有必要说明一下为什么使用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机制运行时注入,即使以后更换监控方案也不需要对代码大动干戈。
我使用的是最新版6.5.0,该版本下Skywalking主要分为oap、webapp和agent三部分,oap和webapp分别用于汇总数据和展示,这两块共同组成了Skywalking的平台;agent是探针,部署在需要收集数据的应用服务器上,并将数据同步到Skywalking的平台。
在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/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。
微服务架构是通过业务来划分服务的,使用 REST 调用。对外暴露的一个接口,可能需要很多个服务协同才能完成这个接口功能,如果链路上任何一个服务出现问题或者网络超时,都会形成导致接口调用失败。为了在发生故障的时候,能够快速定位和解决问题,需要使用SkyWalking
windows
JDK8
idea
1.下载elasticsearch7
2.解压 运行bin/elasticsearch.bat
3.访问 localhost:9200 如下结果表示OK
{
"name" : "xxxx",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "xxxx",
"version" : {
"number" : "7.7.1",
"build_flavor" : "default",
"build_type" : "zip",
"build_hash" : "xxxxx",
"build_date" : "2020-05-28T16:30:01.040088Z",
"build_snapshot" : false,
"lucene_version" : "8.5.1",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
5.解压 运行 bin/startup.bat,这个时候实际上是启动了两个项目,一个收集器,一个web页面
6.访问localhost:8080,端口号webapp/webapp.yml中可以修改,第一次访问页面空白正常
7.在项目根目录下创建目录 jeecg-skywarking,并且将skywarking下的agent文件夹直接拷贝至该目录下
附上参数代码及描述
-javaagent:D:\JAVA\cloud\jeecg-yanshi\jeecg-skywarking\agent\skywalking-agent.jar
-Dskywalking.agent.service_name=jeecg-ys-gateway
-Dskywalking.collector.backend_service=localhost:11800
参数 | 描述 |
---|---|
javaagent | -配置 skywalking-agent.jar 的地址,需要修改 |
service_name | -配置 需要监控的服务名,需要修改 |
javaagent | -skywalking收集器服务的地址,照抄 |
9.启动项目,访问接口(多访问几次),再去localhost:8080看面板数据