基于 SkyWalking 实现服务链路追踪

SkyWalking简介

SkyWalking是一个开源的观测平台,用于从服务和云原生等基础设施中收集、分析、聚合以及可视化数据。SkyWalking 提供了一种简便的方式来清晰地观测分布式系统,甚至可以观测横跨不同云的系统。SkyWalking 更像是一种现代的应用程序性能监控(Application Performance Monitoring,即APM)工具,专为云原生,基于容器以及分布式系统而设计

SkyWalking 在逻辑上分为四部分:探针、平台后端、存储和用户界面。其架构图如下:

  • 探针:基于不同的来源探针可能是不一样的,但作用都是收集数据,将数据格式化为 SkyWalking 适用的格式。例如在Java中则是做字节码植入,无侵入式的收集,并通过 HTTP 或者 gRPC 方式发送数据到平台后端
  • 平台后端:是一个支持集群模式运行的后台,用于数据聚合、数据分析以及驱动数据流从探针到用户界面的流程。平台后端还提供了各种可插拔的能力,如不同来源数据(如来自 Zipkin)格式化,不同存储系统以及集群管理。你甚至还可以使用观测分析语言来进行自定义聚合分析。
  • 存储:是开放式的,可以选择一个既有的存储系统,如 ElasticSearch、H2 或 MySQL 集群(Sharding-Sphere 管理),也可以选择自己实现一个存储系统。
  • 用户界面:也就是SkyWalking的可视化界面,UI非常炫酷且强大,同样它也是可定制以匹配你已存在的后端的

SkyWalking 为观察和监控分布式系统提供了许多不同场景下的解决方案。例如为Java、C#及Node.js提供语言自动探针,无侵入式的收集。同时也为一些编译型语言C++、GO等提供了手动打点 SDK(目前还未支持)。除此之外,还可以使用服务网格基础探针来收集数据,以帮助了解整个分布式系统。

在SkyWalking中也存在服务、服务实例及端点概念,因为SkyWalking就是提供了这些概念的观测能力:

  • 服务(Service):表示对请求提供相同行为的一系列或一组工作负载。在使用打点代理或 SDK 的时候,你可以定义服务的名字。如果不定义的话,SkyWalking 将会使用你在平台上定义的名字,如 Istio。
  • 服务实例(Service Instance):上述的一组工作负载中的每一个工作负载称为一个实例。就像 Kubernetes 中的 pods 一样,服务实例未必就是操作系统上的一个进程。但当你在使用打点代理的时候, 一个服务实例实际就是操作系统上的一个真实进程。
  • 端点(Endpoint):对于特定服务所接收的请求路径,如 HTTP 的 URI 路径和 gRPC 服务的类名 + 方法签名

综上,SkyWalking 优势如下:

  • 多种监控手段,语言探针和服务网格(Service Mesh)
  • 模块化,UI、存储、集群管理多种机制可选
  • 支持告警
  • 优秀的可视化方案

更多内容可以参考官方文档:


搭建 SkyWalking 服务 - Linux

对SkyWalking有一个大致的了解后,本小节我们来在CentOS7上搭建 SkyWalking 服务。首先我们需要获取到SkyWalking的下载地址,官方下载地址如下:

http://skywalking.apache.org/downloads/

这里我选择当前最新的6.6.0版本的二进制包:

复制下载地址到服务器上进行下载并解压,具体步骤如下:

[[email protected] ~]# cd /usr/local/src
[[email protected] /usr/local/src]# wget http://mirrors.tuna.tsinghua.edu.cn/apache/skywalking/6.6.0/apache-skywalking-apm-6.6.0.tar.gz
[[email protected] /usr/local/src]# mkdir ../skywalking && tar -zxvf apache-skywalking-apm-6.6.0.tar.gz -C ../skywalking --strip-components 1
[[email protected] /usr/local/src]# cd ../skywalking/
[[email protected] /usr/local/skywalking]# ll -rh  # 解压后的目录文件如下
total 88K
drwxr-xr-x 2 root root   53 Dec 28 18:22 webapp
-rw-rw-r-- 1 1001 1002 2.0K Dec 24 14:10 README.txt
drwxrwxr-x 2 1001 1002  12K Dec 24 14:28 oap-libs
-rwxrwxr-x 1 1001 1002  32K Dec 24 14:10 NOTICE
drwxrwxr-x 3 1001 1002 4.0K Dec 28 18:22 licenses
-rwxrwxr-x 1 1001 1002  29K Dec 24 14:10 LICENSE
drwxr-xr-x 2 root root  221 Dec 28 18:22 config
drwxr-xr-x 2 root root  241 Dec 28 18:22 bin
drwxrwxr-x 8 1001 1002  143 Dec 24 14:21 agent
[[email protected] /usr/local/skywalking]# 

运行bin目录下的startup.sh脚本即可启动skywalking服务:

[[email protected] /usr/local/skywalking]# bin/startup.sh
SkyWalking OAP started successfully!
SkyWalking Web Application started successfully!
[[email protected] /usr/local/skywalking]#

SkyWalking控制台服务默认监听8080端口,若有防火墙需要开放该端口:

[[email protected] /usr/local/skywalking]# firewall-cmd --zone=public --add-port=8080/tcp --permanent
success
[[email protected] /usr/local/skywalking]# firewall-cmd --reload
success
[[email protected] /usr/local/skywalking]#

若希望允许远程传输,则还需要开放11800(gRPC)和12800(rest)端口,远程agent将通过该端口传输收集的数据:

[[email protected] /usr/local/skywalking]# firewall-cmd --zone=public --add-port=11800/tcp --permanent
success
[[email protected] /usr/local/skywalking]# firewall-cmd --zone=public --add-port=12800/tcp --permanent
success
[[email protected] /usr/local/skywalking]# firewall-cmd --reload
success
[[email protected] /usr/local/skywalking]#

正常启动成功后,使用浏览器访问主页如下:


搭建 SkyWalking 服务 - Windows

Windows下的搭建就更简单了,首先下载Windows平台下的包:

解压后目录文件如下:

双击bin目录下的startup.bat文件就可以运行SkyWalking服务了:

这里之所以介绍Windows下的搭建,是因为当SkyWalking收集服务部署在远程服务器上时,本地要进行调试的话得用到agent目录下的jar包:

agent文件夹,可以单独复制出放在项目系统所在服务器的任意目录下。agent文件夹下的skywalking-agent.jar即为监控代理程序,只需要在jvm的启动命令中加载该jar包,即可完成监控代理。


服务链路追踪

在本文中主要介绍如何使用SkyWalking来实现服务链路追踪,关于服务链路追踪的概念在下文中已进行过说明,这里就不再赘述了:

目前有多种工具可以实现服务链路追踪,主流的工具对比可以参考如下文章:

以上小节完成了SkyWalking平台服务的搭建,接下来进入项目整合环节,将SkyWalking提供的agent与我们的项目进行整合,以达到监控目的。这里事先创建了两个简单的Spring Cloud项目,分别是consumer和producer:

这两个项目中均包含基础的组件依赖:nacos-discovery、openfeign及web。因为SkyWalking是通过Java agent这种语言探针的方式进行数据的收集和上传,所以不需要像zipkin那样添加额外的依赖和配置。

consumer将调用producer提供的接口,以达到后续在SkyWalking上展示一个简单的调用链路效果。故在producer中编写一个接口,代码如下:

@Slf4j
@RestController
@RequestMapping("/producer")
public class ProducerController {

    @GetMapping
    public String producer() {
        log.info("received a request");
        return "this message from producer";
    }
}

而consumer也有一个接口,该接口内则是调用了producer的接口。代码如下:

@Slf4j
@RestController
@RequiredArgsConstructor
@RequestMapping("/consumer")
public class ConsumerController {

    private final ProducerClient producerClient;

    @GetMapping
    public String consumer() {
        log.info("consumer something");
        // 通过feign调用
        String result = producerClient.producer();
        return "consumer: " + result;
    }
}

ProducerClient代码如下:

@FeignClient("producer")
public interface ProducerClient {

    @GetMapping("/producer")
    String producer();
}

完成代码编写后,接下来我们需要为每个服务配置一个agent,首先创建两个与producer和consumer服务对应的目录:

然后将skywalking里的agent目录下的所有文件拷贝出来,分别粘贴到这两个新建的目录中:

接着分别编辑这两个目录下的config/agent.config文件,该文件是agent的配置文件。修改其中的服务名称,以及skywalking平台后端服务的连接地址。producer配置示例如下:

# The service name in UI 服务名称
agent.service_name=${SW_AGENT_NAME:producer}

# Backend service addresses. 收集后端服务的地址
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:192.168.0.71:11800}

consumer里的配置文件也需要按照如上示例进行修改,这里之所以分别拷贝了两个agent是为了让不同的服务使用不同的配置文件。

如果不想为每个服务都单独拷贝一个agent目录,则可以通过添加JVM启动参数来覆写配置项,这两种方式视实际情况选择即可。如下示例:

-javaagent:E:\skywalking\apache-skywalking-apm-bin\agent\skywalking-agent.jar
-Dskywalking.agent.service_name=consumer
-Dskywalking.collector.backend_service=192.168.0.71:11800

配置好agent之后,在IDEA中添加Spring Boot引导类的JVM参数,指定skywalking-agent.jar的目录路径:

完成以上步骤后,分别启动producer和comsumer服务,请求/consumer接口,因为skywalking是懒加载的,需要进行请求才会连接收集服务:

接着到SkyWalking的“追踪”页面上,就可以查看到调用链路信息了。如下图所示:

点击链路上的节点可以查看到对应的详情:


其他功能

服务拓扑图:

端点监控:

服务实例监控:

如果集成agent成功后,却依旧发现监控页面上没有数据,日志里又没有错误信息的话,很有可能是时间范围没有选择正确:

原文地址:https://blog.51cto.com/zero01/2463116

时间: 2024-09-29 03:16:31

基于 SkyWalking 实现服务链路追踪的相关文章

个推基于 Zipkin 的分布式链路追踪实践

作者:个推应用平台基础架构高级研发工程师 阿飞 01业务背景 随着微服务架构的流行,系统变得越来越复杂,单体的系统被拆成很多个模块,各个模块通过轻量级的通信协议进行通讯,相互协作,共同实现系统功能. 单体架构时,一个请求的调用链路很清晰,一般由负载均衡器将用户请求转发到后端服务,由后端服务进行业务处理,需要的数据从外部的存储中获取,处理完请求后,再经由负载均衡器返回给用户. 而在微服务架构中,一个请求往往需要多个模块共同协作处理,不同模块可能还依赖于不同的外部存储,各个模块的实现技术还不尽相同,

spring cloud 入门系列八:使用spring cloud sleuth整合zipkin进行服务链路追踪

好久没有写博客了,主要是最近有些忙,今天忙里偷闲来一篇. =======我是华丽的分割线========== 微服务架构是一种分布式架构,微服务系统按照业务划分服务单元,一个微服务往往会有很多个服务单元,一个请求往往会有很多个单元参与,一旦请求出现异常,想要去定位问题点真心不容易,因此需要有个东西去跟踪请求链路,记录一个请求都调用了哪些服务单元,调用顺序是怎么样的以及在各个服务单元处理的时间长短.常见的服务链路追踪组件有google的dapper.twitter的zipkin.阿里的鹰眼等,它们

Laravel + go-micro + grpc 实践基于 Zipkin 的分布式链路追踪系统 摘自https://mp.weixin.qq.com/s/JkLMNabnYbod-b4syMB3Hw?

分布式调用链跟踪系统,属于监控系统的一类.系统架构逐步演进时,后期形态往往是一个平台由很多不同的服务.组件构成,用户请求过来后,可能会经过其中多个服务,如图 不过,出问题时往往很难排查,如整个请求变慢.偶尔报错.不可用等,我们很难得知具体是由哪一个或哪些服务引起的,通常开发同学都会互相甩锅,最后不得不花大量时间人肉 tracing 项目初期时,可以简单处理,通过生成唯一 request_id ,在各个方法记录日志,方便排查问题.中后期系统拆分为各个子服务时,要么继续推进原有的 request_i

业余草 SpringCloud教程 | 第九篇: 服务链路追踪(Spring Cloud Sleuth)(Finchley版本)

这篇文章主要讲述服务追踪组件zipkin,Spring Cloud Sleuth集成了zipkin组件. 一.简介 Add sleuth to the classpath of a Spring Boot application (see below for Maven and Gradle examples), and you will see the correlation data being collected in logs, as long as you are logging re

服务链路追踪

原文地址:https://www.cnblogs.com/Brake/p/12112295.html

链路追踪和应用性能监控有哪些区别?

概要 阿里云上最近推出了一款新产品 链路追踪 ,专注于帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈,提高微服务时代下的开发诊断效率. 分布式应用环境下的链路追踪,并不是一个新话题.在早些时间,阿里云产品 业务实时监控服务 也有类似功能推出.那么链路追踪和业务实时监控服务在产品功能层面到底有什么样的区别和联系?本文将给出概要说明. 以下从产品定位,接入方式,以及使用成本 三个方面来比较 业务实时监控服务 和 链路追踪两款产品. 产品定位 从功能定位上看,业务实时监控服务定位于重量级的应用性能

基于zipkin分布式链路追踪系统预研第一篇

分布式服务追踪系统起源于Google的论文“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”(译文可参考此处),Twitter的zipkin是基于此论文上线较早的分布式链路追踪系统了,而且由于开源快速被各社区所研究,也诞生了很多的版本. 在这里也是对zipkin进行研究,先贴出Twitter zipkin结构图. 结构比较简单,大概流程为: Trace数据的收集至Scribe(Facebook开源的日志传输通路)或

阿里云发布链路追踪服务Tracing Analysis

摘要: 近日,在杭州云栖大会上,阿里云发布了链路追踪服务Tracing Analysis,成本是自建链路追踪系统的1/5或更少,可为分布式应用的开发者提供完整的调用链路还原.调用请求量统计.链路拓扑.应用依赖分析等工具,帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈,提高微服务时代下的开发诊断效率. 近日,在杭州云栖大会上,阿里云发布了链路追踪服务Tracing Analysis,成本是自建链路追踪系统的1/5或更少,可为分布式应用的开发者提供完整的调用链路还原.调用请求量统计.链路拓扑.应

基于SkyWalking的分布式跟踪系统 - 微服务监控

上一篇文章我们搭建了基于SkyWalking分布式跟踪环境,今天聊聊使用SkyWalking监控我们的微服务(DUBBO) 服务案例 假设你有个订单微服务,包含以下组件 MySQL数据库分表分库(2台) 生产者(2台) dubbo-provider 消费者 dubbo-consumer 网络拓扑图如下 生产者的关键代码 @Service public class OrderServiceImpl implements OrderService { @Autowired protected Ord