前言
首先有必要说明一下为什么使用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-es7-8.4.0.tar.gz
tar -zxf apache-skywalking-apm-es7-8.4.0.tar.gz
环境要求:skywalking版本7.0
elasticsearch版本7还得单独安装插件
Java 环境1.8
在服务器上解压该安装包,并进入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中selector本次安装选择mysql,在数据库中也创建了对应的数据库,但是没有创建对应的表,服务调用后在图形化界面也可以看到数据,不知数据存在哪里了?
- 执行./bin目录下的startup.sh则启动了采集数据收集的服务以及前端的服务
- skywalking服务端一共有三个端口 前端页面8080默认 采集数据的接收服务11800端口,前后台数据交互服务12800端口, 如需修改的话,
- 前端在./webapp目录下的配置文件中就可以修改前端的启动端口以及和后台服务的交互端口
后台的端口则在./config/application.yml中进行修改
存储可以支持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"
2 agent 的部署
- 复制skywalking介质中的./agent目录,有多少个服务我们就复制多少个agent,每个服务使用单独一个agent
- 进入./agent/config目录中修改agent的配置
其中agent.service_name是我们采集的服务名称,可以随便定义
collector.backend_service是agent往skywalking服务端推送采集数据的服务配置
3 agent的服务启动
- JAR file
Add-javaagent
argument to command line in which you start your app. eg:
java -javaagent:/path/to/skywalking-agent/skywalking-agent.jar -jar yourApp.jar
例如:nohup java -javaagent:$SW$1/skywalking-agent.jar -jar -Xms768m -Xmx768m $MICRO_PATH/jar/dqc-0.0.1-SNAPSHOT.jar --spring.profiles.active=$MICRO_ENV --$SERVER_IP=$IP_NUM> /dev/null 2>&1 &
插件使用
默认情况agent是不支持对spring-cloud-gateway
的监控的,需要插件的支持。我们要将optional-plugins
下的插件apm-spring-cloud-gateway-2.x-plugin-6.5.0.jar
拷贝到plugins
下,使agent可以加载到该插件,其他一些需要额外插件支持的中间件和框架也是同理操作。
部署完成以后效果如图
基本可以满足我的指标监控需求,值得一提的是如果配置一切正常却没有数据显示的话,一定要检查右下角的时间轴对不对,不要问我是怎么知道的。。。
目前的部署和使用还是基于虚拟机的,由于我的项目在生产环境已经上容器了,后续应用到线上前会研究一下如何在容器中部署和使用skywalking
以及如何和注册中心结合达到高可用。当然,告警规则的配置也需要琢磨一下。