【skywalking】skywalking从应用系统里面采集的信息、如何采集以及链路追踪如何展示

1. skywalking从应用系统里面采集的信息有哪些？
   1.1 skywalking基础架构
   服务端和客户端，服务端负责收集日志数据并且展示，架构图中主要分为四个部分，如下：
   上面的Agent：（探针）使用字节码，使用这种技术把我们的监控代码直接以字节码的方式注入到目标应用的代码中，从而实现对实际程序运行情况进行和监控和统计上报，还可以统计某个应用方法执行时间，比如java文件运行行后均有一个截断器，修改字节码，对应用进行监控，对执行制定的方法可以注释@trace、@Tags或@Tag
   ：Agent 运行在各个服务实例中，负责采集服务实例的 Trace 、Metrics 等数据，然后通过 gRPC 方式上报给 SkyWalking 后端。
   中间的OAP：grpcserver负责接收 Agent 发送的 Tracing 和Metric的数据信息，然后进行流式分析(Analysis Core) ，将分析得到的结果写入持久化存储中存储到外部存储器( Storage )，JettyServer负责接收UI发送的http请求，最终提供UI查询( Query )功能。
   左面的UI：负责提供web控制台，查看链路，查看各种指标，性能等等。
   右面Storage：负责数据的存储，支持多种存储类型。
   Agent负责收集日志传输数据，通过GRPC的方式传递给OAP进行分析并且存储到数据库中，最终通过UI界面将分析的统计报表、服务依赖、拓扑关系图展示出来。
   

   1.2 分布式调用链标准(OpenTracing)
   OpenTracing 是一个轻量级的标准化层，它位于应用程序/类库和追踪或日志分析程序之间。它的出现是为了解决不同的分布式追踪系统 API 不兼容的问题。

OpenTracing 的数据模型，主要有以下三个：

Trace：一个完整请求链路

Span：一次调用过程(需要有开始时间和结束时间)的逻辑单元

操作名称：例如访问的具体 RPC 服务，访问的 URL 地址等；

起始时间；2021-1-25 22:00:00

结束时间；2021-1-30 22:00:00

Span Tag：一组键值对构成的Span标签集合，其中键必须为字符串类型，值可以是字符串、bool 值或者数字；

Span Log：一组 Span 的日志集合；

SpanContext：Trace 的全局上下文信息；

References：Span 之间的引用关系，下面详细说明 Span 之间的引用关系；

SpanContext：Trace 的全局上下文信息，如里面有traceId

 如图所示，一次下单的完整请求就是一个 Trace。TraceId是这个请求的全局标识。内部的每一次调用就称为一个 Span，每个 Span 都要带上全局的 TraceId，这样才可把全局 TraceId 与每个调用关联起来。这个 TraceId 是通过 SpanContext 传输的，既然要传输，显然都要遵循协议来调用。如图所示，如果我们把传输协议比作车，把 SpanContext 比作货，把 Span 比作路应该会更好理解一些。

理解了这三个概念，接下来我们就看看分布式追踪系统是如何采集图中的微服务调用链。

我们可以看到底层有一个 Collector 一直在默默无闻地收集数据，那么每一次调用 Collector 会收集哪些信息呢。

1、全局 trace_id：这是显然的，这样才能把每一个子调用与最初的请求关联起来
2、span_id: 图中的 0，1，1.1，2，这样就能标识是哪一个调用
3、parent_span_id：比如 b 调用 d 的 span_id 是 1.1，那么它的 parent_span_id 即为 a 调用 b 的 span_id 即 1，这样才能把两个紧邻的调用关联起来。

有了这些信息，Collector 收集的每次调用的信息如下：

根据这些图表信息显然可以据此来画出调用链的可视化视图如下：

2. skywaling从应用系统如何采集
   链路追踪系统SkyWalking的原理
   2.1 怎么自动采集 span 数据

SkyWalking 采用了插件化 + javaagent 的形式来实现了 span 数据的自动采集，这样可以做到对代码的无侵入性。插件化意味着可插拔，扩展性好。如下图所示：

2.2 如何跨进程传递 context

我们知道数据一般分为 header 和 body，就像 http 有 header 和 body，RocketMQ 也有 MessageHeader，Message Body。body 一般放着业务数据，所以不宜在 body 中传递 context，应该在 header 中传递 context，如图所示：

dubbo 中的 attachment 就相当于 header，所以我们把 context 放在 attachment 中，这样就解决了 context 的传递问题。

2.3 traceId 如何保证全局唯一

要保证全局唯一 ，我们可以采用分布式或者本地生成的 ID。使用分布式的话，需要有一个发号器，每次请求都要先请求一下发号器，会有一次网络调用的开销。所以 SkyWalking 最终采用了本地生成 ID 的方式，它采用了大名鼎鼎的 snowflow 算法，性能很高。

不过 snowflake 算法有一个众所周知的问题：时间回拨，这个问题可能会导致生成的 id 重复。那么 SkyWalking 是如何解决时间回拨问题的呢。

3. skywalking工具如何展示?
   拓扑图：微服务之间的依赖
   追踪：服务 接口 业务应用 节点之间的关系 url 执行时间
   

4. 如何做出来？
   下载skywalking源码，然后搞两台服务器，开发UI界面？？？