如何使用分布式链路追踪

这篇文章主要介绍"如何使用分布式链路追踪"，在日常操作中，相信很多人在如何使用分布式链路追踪问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答"如何使用分布式链路追踪"的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

分布式链路追踪概述

在具体介绍分布式链路追踪系统之前，我们首先需要理解下什么是链路追踪?在本专栏前面关于监控系统的介绍中可以知道，监控系统的观测数据主要来源于统计指标、日志以及链路追踪这三个方面。而这些数据从类型上又可以划分为两种：请求级别、聚合级别。

请求级别的数据主要来源于真实的请求，例如一次HTTP调用、RPC调用等，本文要介绍的链路追踪就是这种类型。而聚合级别则是接口请求的度量指标或者一些参数数据的聚合，如QPS、CPU使用率等数值。日志和统计指标数据既可以是请求级别，也可以是聚合级别，因为它们可能来自源于真实的请求，也可能是系统自身诊断时记录下来的信息。

而对于链路追踪来说，它主要的逻辑就是将请求链路的完整行为记录下来，以便可以通过可视化的形式实现链路查询、性能分析、依赖关系、拓扑图等分布式链路追踪相关的功能。如下图所示：

在上图中假设微服务系统中的一次接口调用总共有两个微服务参与，其调用关系分别是A->B->C，其中B服务还与Redis这样的第三方服务产生了调用关系、C服务则还需要调用MySQL数据库服务。所以实际上链路追踪所做的事情就是详细记录A->B(B->Redis)->C(C->MySQL)这条完整链路上的详细调用信息，例如接口响应结果、耗时等。

那么这条调用链路上的数据到底是怎样被记录的呢?接下来我们继续以上面的调用链为例分析下链路追踪信息的具体组成和传递形式，以便进一步理解分布式链路追踪系统的原理和概念。具体逻辑示意图如下：

如上图所示，分布式链路追踪所监控的对象就是一次次调用所产生的链路，图中1-8所示的就是一条完整的链路(Trace)，系统会通过唯一的标识(TraceId)对此进行记录。而链路中的每一个依赖调用都会生成一个调用踪迹信息(Span)，最开始生成的Span叫做根Span(Root Span)，后续生成的Span都会将前一个Span 的标示(Sid)作为本Span信息的父ID(Pid)。

这样以此类推，Span信息就会随着链路的执行被进程内或跨进程进行上下文传递，通过Span数据链就能将一次次链路调用所产生的踪迹信息串联起来，而每一个Span之上附着的日志信息(Annotation)就是我们进行调用链监控分析的数据来源。这就是分布式链路追踪的基本原理。

而说到这里，你可能会有疑问：监控这么大的数据量，是不是会很消耗系统资源?的确如此，所以大部分链路追踪系统，都会存在一个叫做采样率(Sampling)的设定，用来控制系统采集链路信息的比例，从而提升系统性能。因为很多时候，大量的链路信息都是相同的，我们需要关注的可能也只是相对耗时较高、出错次数较多的链路，而并没有必要100%的进行采集。

SkyWalking简介

前面我们从基本原理的角度说明了链路追踪是什么，那么接下来我们将介绍下目前最流行的分布式链路追踪系统——SkyWalking。

SkyWalking是一款优秀的开源APM(Application Performance Management)系统，它不仅提供了链路追踪，链路分析等分布式追踪功能，还支持性能指标分析、应用和服务依赖性分析、服务拓扑图分析、报警等一系列应用性能监控相关的功能，可以帮助我们有效地定位问题。

而从数据收集上看，SkyWalking支持多种不同的数据来源及格式，包括支持Java、.NET Core、NodeJS、PHP和Python等不同语言的无侵入式Agent探针，以及对Service Mesh(服务网格)架构的支持等。其具体结构如下图所示：

如上图所示，SkyWalking的核心由链路收集服务器(Receiver Cluster)、聚合服务器(AggregatorCluster)组成。其中Receiver Cluster是整个后端服务接入的入口，专门用于收集服务的各种指标及链路信息。

而AggregatorCluster则用于汇总、聚合收集器收集到的数据，并最终将聚合数据存储到数据库中，而具体存储方式可以有多种，例如常见的ElasticSearch、MySQL、TIDB等，我们可以根据实际需要进行选择。这些聚合数据后面可以用于告警设置，也可以被GUI/CLI等可视化系统以HTTP的形式访问后进行可视化展示。

此外，从数据采集逻辑上看，SkyWalking支持多种语言探针及项目协议，能够覆盖目前大部分主流的分布式技术栈，具体来说主要有以下3种：

• Metrics System：统计系统。支持直接从Prometheus中拉取度量指标数据到SkyWalking，也支持程序自身通过micrometer推送数据;

• Agents：业务探针。指在各个业务系统中集成探针服务来进行链路追踪，即链路数据采集。SkyWalking支持Java、Go、.NET、PHP、NodeJS、Python、Nginx LUA等多种语言的探针。此外，它还支持通过gRPC或者HTTP的方式来传递数据;

• Service Mesh：SkyWalking还支持对新一代微服务架构Service Mesh的监控，可以通过特定的Service Mesh协议采集数据面、控制面的数据，实现对服务网格链路数据的观测;

上面的内容简单介绍了SkyWalking的基本情况，并就其系统架构进行了简单分析。实际上SkyWalking最近两年发展得非常快，社区也非常活跃，在微服务链路追踪、应用性能监控领域被使用得也越来越广泛，由于篇幅原因，这里无法进行更深入的分享，感兴趣的读者可以通过官方文档或社区进行深入了解!

SkyWalking安装部署

前面的内容分别介绍了分布式链路追踪的基本原理，并着重介绍了SkyWalking!很显然，写到这里就结束的话，本文就没有啥价值了，因为只是说了一堆正确的废话，看了也就忘了!这显然也不符合我分享的风格，接下来我们就从实验的角度来玩一下SkyWalking。

以下内容需要进行实际实验操作，如果在地铁上不方便可以先收藏，有时间再具体实验玩下!

对于SkyWalking的部署主要涉及到后端OAP Server和前端UI，根据实际需要可以将它们部署在物理机、虚拟机或者Kubernetes集群之中。这里为了演示环境的一致性，我们选择将SkyWalking的后端服务及UI分别部署到Kubernetes集群中。

而具体安装SkyWalking的方式可以通过官方提供的Kubernetes部署文件采用Helm方式安装，也可以手动编写Kubernetes部署文件，这里为了便于学习，我们采用后一种方式。具体步骤如下：

1)、在Kubernetes集群中创建一个单独运行SkyWalking容器的Namespace。命令如下：

#通过kubectl连接Kubernetes集群后执行，创建namespace命令 $ kubectl create ns skywalking

命令执行完成后，可以查看Namespace是否创建成功，命令如下：

#查看namespace创建情况 $ kubectl get ns NAME                   STATUS   AGE default                Active   10d kube-node-lease        Active   10d kube-public            Active   10d kube-system            Active   10d kubernetes-dashboard   Active   10d skywalking             Active   46s

可以看到此时skywalking空间已经成功创建!

2)、编写SkyWalking-UI及OAP Server服务Kubernetes部署文件

在编写具体的Kubernetes部署文件的过程中需要指定SkyWalking-UI及OAP Server的容器镜像，一般来说可以通过源码手动打包也可以直接使用官方已经打包好的镜像。这里为了方便演示，采用Docker官方镜像仓库中已经打包好的镜像。具体如图所示：

如果上面两张图所示，我们分别在Docker Hub官方镜像仓库中找到了SkyWalking-UI及OAP Server的官方发布的容器镜像版本，接下来编写具体的部署文件。

编写SkyWalking服务端Kubernetes部署文件(skywalking-aop.yml)，具体内容如下：

apiVersion: apps/v1 kind: Deployment metadata:   name: oap   namespace: skywalking spec:   replicas: 1   selector:     matchLabels:       app: oap       release: skywalking   template:     metadata:       labels:         app: oap         release: skywalking     spec:       containers:         - name: oap           #指定OAP Server容器镜像及版本信息           image: apache/skywalking-oap-server:8.3.0-es7           imagePullPolicy: IfNotPresent           ports:             - containerPort: 11800               name: grpc             - containerPort: 12800               name: rest --- apiVersion: v1 kind: Service metadata:   name: oap   namespace: skywalking   labels:     service: oap spec:   ports:     #restful端口     - port: 12800 name: rest      #rpc端口     - port: 11800       name: grpc     - port: 1234       name: page   selector:     app: oap

以上是一个标准的Kubernetes部署文件，关于文件中相关指令的具体含义可查阅Kubernetes相关的资料。

编写SkyWalking-UI部署文件(skywalking-ui.yml)，具体内容如下：

apiVersion: apps/v1 kind: Deployment metadata:   name: ui-deployment   namespace: skywalking   labels:     app: ui spec:   replicas: 1   selector:     matchLabels:       app: ui   template:     metadata:       labels:         app: ui     spec:       containers:         - name: ui           image: apache/skywalking-ui:8.3.0           ports:             - containerPort: 8080               name: page           env:             - name: SW_OAP_ADDRESS               value: oap:12800 --- apiVersion: v1 kind: Service metadata:   name: ui   namespace: skywalking   labels:     service: ui spec:   ports:     - port: 8080       name: page       nodePort: 31234   type: NodePort   selector:     app: ui

3)、根据编写的部署文件，执行Kubernetes部署命令

根据前面步骤中编写的Kubernetes发布文件，这里我们根据编写的发布文件直接执行部署命令，具体如下：

#进入发布文件的存储目录，直接一次性执行全部文件部署命令 $ kubectl apply -f . deployment.apps/oap created service/oap created deployment.apps/ui-deployment created service/ui created

执行完成后通过命令查看具体部署的情况，命令如下：

#查看skywalking空间中的Pod、Service对象的运行情况 $ kubectl get all -n skywalking NAME                                 READY   STATUS    RESTARTS   AGE pod/oap-5f6d6bc4f6-k4mvv             1/1     Running   0          36h pod/ui-deployment-868c66449d-fffrt   1/1     Running   0          36h  NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                        AGE service/oap   ClusterIP   10.110.112.244           12800/TCP,11800/TCP,1234/TCP   36h service/ui    NodePort    10.100.154.93            8080:31234/TCP                 36h  NAME                            READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/oap             1/1     1            1           36h deployment.apps/ui-deployment   1/1     1            1           36h  NAME                                       DESIRED   CURRENT   READY   AGE replicaset.apps/oap-5f6d6bc4f6             1         1         1       36h replicaset.apps/ui-deployment-868c66449d   1         1         1       36h

可以看到部署的SkyWalking服务都已经正常运行!如果是第一次部署，拉取镜像的过程可能会比较慢一点。如果在部署过程中存在问题，也可以查看Pod对象的运行日志，例如：

#可以查看aop的启动日志 $ kubectl logs pod/oap-5f6d6bc4f6-k4mvv -n skywalking

4)、查看SkyWalking-UI的Web访问地址

经过上述步骤，我们已经成功将SkyWalking-UI、OAP Server两个服务运行在Kubernetes集群之中。接下来通过SkyWalking-UI服务的映射端口(k8s部署文件中定义是31234端口)访问Web UI，具体可通过http://NodeIP:31234进行访问，例如：

#这里的IP为Kubernetes集群向外暴露的节点入口IP http://10.211.55.12:31234/

如果不知道Kubernetes集群节点入口IP地址，可以通过以下命令进行查看：

#查询SkyWalking-UI所部署的Kubernetes集群Node节点的IP地址 $ kubectl describe node kubernetes Name:               kubernetes Roles:              master ... Addresses:   InternalIP:  10.211.55.12   Hostname:    kubernetes ...

访问后的界面显示效果如下图所示：

如上图所示，此时可以看到SkyWalking已成功运行，由于尚无服务接入所以暂时还看不到有任何监控数据!

到此，关于"如何使用分布式链路追踪"的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注网站，小编会继续努力为大家带来更多实用的文章！