什么是SkyWalking
Skywalking是由国内开源爱好者吴晟开源并提交到Apache孵化器的产品,它同时吸收了Zipkin /Pinpoint /CAT 的设计思路。特点是:支持多种插件,UI功能较强,支持非侵入式埋点。目前使用厂商最多,版本更新较快。
数据存储支持:Elasticsearch、MySQL、H2、TiDB。默认是H2,而且是存到内存。实际我们一般将其存到ES。
主页:http://skywalking.apache.org/
下载:https://skywalking.apache.org/downloads/
github:https://github.com/apache/skywalking
文档:https://github.com/apache/skywalking/tree/master/docs
配置:https://github.com/apache/skywalking/tree/master/docs/en/setup/backend
APM
emsp; APM全称Application Performance Management应用性能管理,目的是通过各种探针采集数据,收集关键指标,同时搭配数据呈现以实现对应用程序性能管理和故障管理的系统化解决方案.
Zabbix、Premetheus、open-falcon等监控系统主要关注服务器硬件指标与系统服务运行状态等,而APM系统则更重视程序内部执行过程指标和服务之间链路调用情况的监控,APM更有利于深入代码找到请求响应“慢”的根本问题,与Zabbix之类的监控是互补关系 目前市面上开源的APM系统主要有CAT、Zipkin、Pinpoint、SkyWalking,大都是参考Google的 Dapper
实现的.
链路追踪工具对比
链路追踪工具一般要有如下功能:
- 心跳检测(确定应用是否还在运行)
- 记录请求的执行流程、执行时间
- 资源监控(CPU、内存、带宽、磁盘)
- 告警功能(监控执行时间、成功率等通过邮件、钉钉、短信、微信等进行通知)
- 可视化页面
常用的工具有:
Zipkin
Twitter开源的调用链分析工具,目前基于springcloud sleuth得到了广泛的使用,特点是轻量,使用部署简单。
Pinpoint
韩国人开源的基于字节码注入的调用链分析,以及应用监控分析工具。特点是支持多种插件,UI功能强大,接入端无代码侵入。
SkyWalking
本土开源的基于字节码注入的调用链分析,以及应用监控分析工具。特点是支持多种插件,UI功能较强,接入端无代码侵入。目前已加入Apache孵化器。
CAT
大众点评开源的基于编码和配置的调用链分析,应用监控分析,日志采集,监控报警等一系列的监控平台工具。
各维度对比
对比项 | Zipkin | Pinpoint | SkyWalking | Cat |
---|---|---|---|---|
实现方式 | 拦截请求,发送(Http,MQ)数据到Zipkin服务 | Java探针,字节码增强 | Java探针,字节码增强 | 代码埋点(拦截器,注解,过滤器等) |
接入方式 | 基于linkerd或者sleuth方式 | javaagent字节码 | javaagent字节码 | 代码侵入 |
agent到collector协议 | http,MQ | thrift | gRPC | http/tcp |
OpenTracing | 支持 | 不支持 | 支持 | 不支持 |
颗粒度 | 接口级 | 方法级 | 方法级 | 代码级 |
全局调用统计 | 不支持 | 支持 | 支持 | 支持 |
traceid查询 | 支持 | 不支持 | 支持 | 不支持 |
报警 | 不支持 | 支持 | 支持 | 支持 |
JVM监控 | 不支持 | 不支持 | 支持 | 支持 |
UI功能 | 支持 | 支持 | 支持 | 支持 |
数据存储 | ES、MySQL等 | HBase | ES/H2/MySQL | MySQL/HDFS |
性能对比图
SkyWalking的功能特性
- 多种监控手段,通过语言探针和Service mesh 获得监控的数据
- 支持多种语言自动探针,包括 Java, .NET Core 和 Node.js
- 轻量高效,无需大数据平台和大量的服务器资源
- 模块化,UI,存储,集群管理都有多种机制可选
- 支持报警,告警
- 优秀的可视化解决方案
Skywalking结构
说明:
- Skywalking agent 和业务系统绑定在一起,负责收集各种监控数据
- Skywalking oapservice负责处理监控数据,比如接受Skywalking agent的监控数据,并且存储在数据库中,接受Skywalking webapp前端的请求,从数据库查询数据,并返回给前端,Skywalking oapservice通常会以集群的方式搭建
- Skywalking webapp ,UI服务,用于可视化展示数据
- 用户持久化监控数据的数据库,可以选用ElasticSearch、MySQL等
安装部署
官方网站
http://skywalking.apache.org/
下载
http://skywalking.apache.org/downloads/
启动
服务接入探针
脚本
# 生产环境
#!/bin/sh
# SkyWalking Agent配置
export SW_AGENT_NAME=boot-micrometer #Agent名字,一般使用`spring.application.name`
export SW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 #配置 Collector 地址。
export SW_AGENT_SPAN_LIMIT=2000 #配置链路的最大Span数量,默认为 300。
export JAVA_AGENT=-javaagent:/root/apache-skywalking-apm-bin/agent/skywalking-agent.jar
java $JAVA_AGENT -jar springcloudalibaba-0.0.1-SNAPSHOT.jar #jar启动
集成ide
# java应用启动时
-Xmx512m
-javaagent:E:/environment/SpringCloudAlibaba/skywalking/skywalking-agent/skywalking-agent.jar
-Dskywalking.agent.service_name=provider
-Dskywalking.collector.backend_service=127.0.0.1:11800
Skywalking跨多个微服务追踪 gateway(bug)
SkyWalking中三个概念
- 服务(Service) :表示对请求提供相同行为的一系列或一组工作负载,在使用Agent时,可以定义服务的名字;
- 服务实例(Service Instance) :上述的一组工作负载中的每一个工作负载称为一个实例, 一个服务实例实际就是操作系统上的一个真实进程;
- 端点(Endpoint) :对于特定服务所接收的请求路径, 如HTTP的URI路径和gRPC服务的类名 + 方法签名;
监控dashboard 仪表盘
dashboard:http://127.0.0.1:8080/
数据收集端口:
-
Http默认端口 12800
-
gRPC默认端口 11800
自定义SkyWalking链路
在默认情况下Skywalking是没有记录我们的业务方法的,如果需要添加业务方法的链路监控我们就需要添加如下的依赖
<dependency>
<groupId>org.apache.skywalking</groupId>
<artifactId>apm-toolkit-trace</artifactId>
<version>8.8.0</version>
</dependency>
然后在业务方法上添加@Trace注解。那么该方法就会被监控
查看这个方法的详情中没有返回信息和参数
可以通过@Tags和@Tag来解决这个问题
@Trace //表示当前方法会被skywalking追踪
@Tags({//显示指定的返回结果和参数
@Tag(key = "process",value = "returnedObj"),//key:方法名 value = returnedObj:是指定返回值
@Tag(key = "param",value = "arg[0]")//返回第一个参数
})
key:方法名 value = returnedObj:是(指定)返回值
arg[0]:参数
集成日志框架
将微服务的日志框架去集成SkyWalking,希望在微服务中日志中,能够记录当前调用链路的id,然后我们再根据这个id去SkyWalking的前端界面中进行搜索找到对应的调用链路记录。
因为springboot默认实现的日志框架是logback,这里也就拿logback举例
在微服务中导入maven坐标
<!-- skywalking 日志记录 -->
<dependency>
<groupId>org.apache.skywalking</groupId>
<artifactId>apm-toolkit-logback-1.x</artifactId>
<version>8.5.0</version>
</dependency>
在项目中 resources
目录下创建 logback-spring.xml
文件
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
<!-- 日志的格式化 -->
<encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
<layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level logger_name:%logger{36} - [%tid] - message:%msg%n</pattern>
</layout>
</encoder>
</appender>
<!-- 设置 Appender -->
<root level="INFO">
<appender-ref ref="console" />
</root>
</configuration>
在Skywalking UI的日志菜单中显示日志信息(常用)
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<!-- 控制台日志输出的格式中添加tid -->
<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
<!-- 日志的格式化 -->
<encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
<layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level logger_name:%logger{36} - [%tid] - message:%msg%n</pattern>
</layout>
</encoder>
</appender>
<!-- skywalking grpc 日志收集 8.4.0版本开始支持 -->
<!-- https://skywalking.apache.org/docs/skywalking-java/latest/en/setup/service-agent/java-agent/application-toolkit-logback-1.x/ -->
<!-- 通过grpc上报日志到skywalking oap-->
<appender name="grpc-log" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender">
<encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
<layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.mdc.TraceIdMDCPatternLogbackLayout">
<Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%tid] [%thread] %-5level %logger{36} -%msg%n</Pattern>
</layout>
</encoder>
</appender>
<!-- 设置 Appender -->
<root level="INFO">
<appender-ref ref="console" />
<appender-ref ref="grpc-log" />
</root>
</configuration>
告警服务
告警日志
Global全局维度
Services load:服务每分钟请求数
Slow Services:慢响应服务,单位ms
Un-Health services(Apdex):Apdex性能指标,1为满分。
- Apdex 一个由众多网络分析技术公司和测量工业组成的联盟组织,它们联合起来开发了“应用性能指数”即“Apdex”(Application Performance Index),用一句话来概括,Apdex是用户对应用性能满意度的量化值
- http://www.apdex.org/
Slow Endpoints: 慢响应端点,单位ms
Global Response Latency:百分比响应延时,不同百分比的延时时间,单位ms
Global Heatmap:服务响应时间热力分布图,根据时间段内不同响应时间的数量显示颜色深度
Service服务维度
Service Apdex(数字):当前服务的评分
Service Avg Response Times:平均响应延时,单位ms
Successful Rate(数字):请求成功率
Servce Load(数字):每分钟请求数
Service Apdex(折线图):不同时间的Apdex评分
Service Response Time Percentile:百分比响应延时
Successful Rate(折线图):不同时间的请求成功率
Servce Load(折线图):不同时间的每分钟请求数
Servce Instances Load:每个服务实例的每分钟请求数
Slow Service Instance:每个服务实例的最大延时
Service Instance Successful Rate:每个服务实例的请求成功率
Instance
Service Instance Load:当前实例的每分钟请求数
Service Instance Successful Rate:当前实例的请求成功率
Service Instance Latency:当前实例的响应延时
JVM CPU:jvm占用CPU的百分比
JVM Memory:JVM内存占用大小,单位m
JVM GC Time:JVM垃圾回收时间,包含YGC和OGC
JVM GC Count:JVM垃圾回收次数,包含YGC和OGC
Endpoint
Endpoint Load in Current Service:每个端点的每分钟请求数
Slow Endpoints in Current Service:每个端点的最慢请求时间,单位ms
Successful Rate in Current Service:每个端点的请求成功率
Endpoint Load:当前端点每个时间段的请求数据
Endpoint Avg Response Time:当前端点每个时间段的请求行响应时间
Endpoint Response Time Percentile:当前端点每个时间段的响应时间占比
Endpoint Successful Rate:当前端点每个时间段的请求成功率