关于java:链路追踪Skywalking保姆级安装教程

• 可能了解服务监控三要素
• 可能了解罕用的 APM 零碎劣势差别
• 可能基于 IDEA 集成 Skywalking Agent
• 能基于生产环境应用 Skywalking Agent

• 把握 Rocketbot

  • 性能剖析
  • 链路追踪
  • 仪表盘利用
  • Webhook

1 Skywalking 概述

随着互联网架构的扩张，分布式系统变得日趋简单，越来越多的组件开始走向分布式化，如微服务、音讯收发、分布式数据库、分布式缓存、分布式对象存储、跨域调用，这些组件独特形成了繁冗的分布式网络。

咱们思考下这些问题：

1: 一个申请通过了这些服务后其中呈现了一个调用失败的问题，如何定位问题产生的中央？2: 如何计算每个节点拜访流量？3: 流量稳定的时候，减少哪些节点集群服务？

这些问题要想得到解决，肯定是有数据撑持，绝不是靠开发人员或者运维人员的直觉。为了解决分布式应用、微服务零碎面临的这些挑战，APM 零碎营运而生。

1.1 微服务系统监控三要素

• Logging 就是 记录零碎行为的离散事件，例如，服务在解决某个申请时打印的谬误日志，咱们能够将这些日志信息记录到 ElasticSearch 或是其余存储中，而后通过 Kibana 或是其余工具来剖析这些日志理解服务的行为和状态。大多数状况下，日志记录的数据很扩散，并且互相独立，比方谬误日志、申请处理过程中关键步骤的日志等等。
• Metrics 是 零碎在一段时间内某一方面的某个度量，可聚合的数据，且通常是固定类型的时序数据，例如，电商零碎在一分钟内的申请次数。咱们常见的监控零碎中记录的数据都属于这个领域，例如 Promethus、Open-Falcon 等，这些监控零碎最终给运维人员展现的是一张张二维的折线图。Metrics 是能够聚合的，例如，为电商零碎中每个 HTTP 接口增加一个计数器，计算每个接口的 QPS，之后咱们就能够通过简略的加和计算失去零碎的总负载状况。
• Tracing 即咱们常说的分布式链路追踪，记录单个申请的解决流程，其中包含服务调用和解决时长等信息。在微服务架构零碎中一个申请会通过很多服务解决，调用链路会十分长，要确定两头哪个服务出现异常是十分麻烦的一件事。通过分布式链路追踪，运维人员就能够构建一个申请的视图，这个视图上展现了一个申请从进入零碎开始到返回响应的整个流程。这样，就能够从中理解到所有服务的异常情况、网络调用，以及零碎的性能瓶颈等。

1.2 什么是链路追踪

谷歌在 2010 年 4 月发表了一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》介绍了分布式追踪的概念，之后很多互联网公司都开始依据这篇论文打造本人的分布式链路追踪零碎。APM 零碎的核心技术就是分布式链路追踪。

论文在线地址：https://storage.googleapis.co…，

国内的翻译版：https://bigbully.github.io/Da…

在此文中论述了 Google 在生产环境下对于分布式链路追踪零碎 Drapper 的设计思路与应用教训。随后各大厂商基于这篇论文都开始自研自家的分布式链路追踪产品。如阿里的 Eagle eye(鹰眼)、zipkin，京东的“Hydra”、公众点评的“CAT”、新浪的“Watchman”、唯品会的“Microscope”、窝窝网的“Tracing”都是基于这片文章的设计思路而实现的。所以要学习分布式链路追踪，对于 Dapper 论文的了解至关重要。

然而也带来了新的问题：各家的分布式追踪计划是互不兼容的，这才诞生了 OpenTracing。

OpenTracing 是一个 Library，定义了一套通用的数据上报接口，要求各个分布式追踪零碎都来实现这套接口。这样一来，应用程序只须要对接 OpenTracing，而无需关怀后端采纳的到底什么分布式追踪零碎，因而开发者能够无缝切换分布式追踪零碎，也使得在通用代码库减少对分布式追踪的反对成为可能。

OpenTracing 于 2016 年 10 月退出 CNCF 基金会，是继 Kubernetes 和 Prometheus 之后，第三个退出 CNCF 的开源我的项目。它是一个中立的（厂商无关、平台无关）分布式追踪的 API 标准，提供对立接口，可不便开发者在本人的服务中集成一种或多种分布式追踪的实现。

OpenTracing API 目前反对的语言泛滥：

目前，支流的分布式追踪实现根本都曾经反对 OpenTracing。

1.2.1 链路追踪

上面通过官网的一个示例简略介绍阐明什么是 Tracing, 把 Tracing 学完后，更有助于大家使用 Skywalking UI 进行数据分析。

在一个分布式系统中，追踪一个事务或者调用流程，能够用下图形式描绘出来。这类流程图能够看清各组件的组合关系，但它并不能看出一次调用触发了哪个组件调用、什么工夫调用、是串行调用还是并行调用。

一种更无效的展示形式就是下图这样，这是一个典型的 trace 视图，这种展示形式减少显示了执行工夫的上下文，相干服务间的档次关系，过程或者工作的串行或并行调用关系。这样的视图有助于发现零碎调用的要害门路。通过关注要害门路的执行过程，开发团队就能够专一于优化门路中的要害服务，最大幅度的晋升零碎性能。例如下图中，咱们能够看到申请串行的调用了受权服务、订单服务以及资源服务，在资源服务中又并行的执行了三个子工作。咱们还能够看到，在这整个申请的生命周期中，资源服务耗时是最长的。

分布式追踪零碎的原理：

分布式追踪零碎大体分为三个局部，数据采集、数据长久化、数据展现。数据采集是指在代码中埋点，设置申请中要上报的阶段，以及设置以后记录的阶段隶属于哪个下级阶段。数据长久化则是指将上报的数据落盘存储，数据展现则是前端查问与之关联的申请阶段，并在界面上出现。

上图是一个申请的流程例子，申请从客户端收回，达到负载平衡，再顺次进行认证、计费，最初取到指标资源。申请过程被采集之后，会以上图的模式出现，横坐标是工夫，圆角矩形是申请的执行的各个阶段

1.2.2 OpenTracing

学好 OpenTracing，更有助于咱们使用 Skywalking。

1、数据模型：

这部分在 OpenTracing 的标准中写的十分分明，上面只大略翻译一下其中的要害局部，细节可参考原始文档《The OpenTracing Semantic Specification》。

Causal relationships between Spans in a single Trace
解释了 Trace 和 Span 的因果关系

        [Span A]  ←←←(the root span)
            |
     +------+------+
     |             |
 [Span B]      [Span C] ←←←(Span C is a `ChildOf` Span A)
     |             |
 [Span D]      +---+-------+
               |           |
           [Span E]    [Span F] >>> [Span G] >>> [Span H]
                                       ↑
                                       ↑
                                       ↑
                         (Span G `FollowsFrom` Span F)

Trace

一个 Trace 代表一个事务、申请或是流程在分布式系统中的执行过程。OpenTracing 中的一条 Trace 调用链，由多个 Span 组成，一个 Span 代表零碎中具备开始工夫和执行时长的逻辑单元，Span 个别会有一个名称，一条 Trace 中 Span 是首尾连贯的。

Span

Span 代表零碎中具备开始工夫和执行时长的逻辑单元，Span 之间通过嵌套或者顺序排列建设逻辑因果关系。

如果按工夫关系出现的话如下所示：

––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time

 [Span A···················································]
   [Span B··············································]
      [Span D··········································]
    [Span C········································]
         [Span E·······]        [Span F··] [Span G··] [Span H··]

每个 Span 中能够蕴含以下的信息：

• 操作名称：例如拜访的具体 RPC 服务，拜访的 URL 地址等；
• 起始工夫；2021-1-25 22:00:00
• 完结工夫；2021-1-30 22:00:00
• Span Tag：一组键值对（k-v）形成的 Span 标签汇合，其中键必须为字符串类型，值能够是字符串、bool 值或者数字；
• Span Log：一组 Span 的日志汇合；
• SpanContext：Trace 的全局上下文信息；
• References：Span 之间的援用关系，上面具体阐明 Span 之间的援用关系；

在一个 Trace 中，一个 Span 能够和一个或者多个 Span 间存在因果关系。目前，OpenTracing 定义了 ChildOf 和 FollowsFrom 两种 Span 之间的援用关系。这两种援用类型代表了子节点和父节点间的间接因果关系。

• ChildOf 关系：一个 Span 可能是一个父级 Span 的孩子，即为 ChildOf 关系。上面这些状况会形成 ChildOf 关系：

  • 一个 HTTP 申请之中，被调用的服务端产生的 Span，与发动调用的客户端产生的 Span，就形成了 ChildOf 关系；
  • 一个 SQL Insert 操作的 Span，和 ORM 的 save 办法的 Span 形成 ChildOf 关系。

很显著，上述 ChildOf 关系中的父级 Span 都要期待子 Span 的返回，子 Span 的执行工夫影响了其所在父级 Span 的执行工夫，父级 Span 依赖子 Span 的执行后果。除了串行的工作之外，咱们的逻辑中还有很多并行的工作，它们对应的 Span 也是并行的，这种状况下一个父级 Span 能够合并所有子 Span 的执行后果并期待所有并行子 Span 完结。

FollowsFrom 关系：示意追随关系，意为在某个阶段之后产生了另一个阶段，用来形容程序执行关系

Logs

每个 Span 能够进行屡次 Logs 操作，每一次 Logs 操作，都须要带一个工夫戳，以及一个可选的附加信息。

Tags

每个 Span 能够有多个键值对模式的 Tags，Tags 是没有工夫戳的，只是为 Span 增加一些简略解释和补充信息。

SpanContext 和 Baggage

SpanContext 示意过程边界，在跨进调用时须要将一些全局信息，例如，TraceId、以后 SpanId 等信息封装到 Baggage 中传递到另一个过程（上游零碎）中。

Baggage 是存储在 SpanContext 中的一个键值对汇合。它会在一条 Trace 中全局传输，该 Trace 中的所有 Span 都能够获取到其中的信息。

须要留神的是，因为 Baggage 须要跨过程全局传输，就会波及相干数据的序列化和反序列化操作，如果在 Baggage 中寄存过多的数据，就会导致序列化和反序列化操作耗时变长，使整个零碎的 RPC 的提早减少、吞吐量降落。

尽管 Baggage 与 Span Tags 一样，都是键值对汇合，但两者最大区别在于 Span Tags 中的信息不会跨过程传输，而 Baggage 须要全局传输。因而，OpenTracing 要求实现提供 Inject 和 Extract 两种操作，SpanContext 能够通过 Inject 操作向 Baggage 中增加键值对数据，通过 Extract 从 Baggage 中获取键值对数据。

2、外围接口语义

OpenTracing 心愿各个实现平台可能根据上述的外围概念来建模实现，不仅如此，OpenTracing 还提供了外围接口的形容，帮忙开发人员更好的实现 OpenTracing 标准。

• Span 接口

Span 接口必须实现以下的性能：

• • 获取关联的 SpanContext：通过 Span 获取关联的 SpanContext 对象。
  • 敞开（Finish）Span：实现曾经开始的 Span。
  • 增加 Span Tag：为 Span 增加 Tag 键值对。
  • 增加 Log：为 Span 减少一个 Log 事件。
  • 增加 Baggage Item：向 Baggage 中增加一组键值对。
  • 获取 Baggage Item：依据 Key 获取 Baggage 中的元素。
• SpanContext 接口

SpanContext 接口必须实现以下性能，用户能够通过 Span 实例或者 Tracer 的 Extract 能力获取 SpanContext 接口实例。

• Tracer 接口

  Tracer 接口必须实现以下性能：

• 创立 Span：创立新的 Span。
• 注入 SpanContext：次要是将跨过程调用携带的 Baggage 数据记录到以后 SpanContext 中。
• 提取 SpanContext，次要是将以后 SpanContext 中的全局信息提取进去，封装成 Baggage 用于后续的跨过程调用。

1.3 常见 APM 零碎

咱们后面提到了 APM 零碎，APM 零碎（Application Performance Management，即利用性能治理）是对企业的利用零碎进行实时监控，实现对利用性能治理和故障定位的系统化解决方案，在运维中罕用。

• CAT（开源）： 由国内美团点评开源的，基于 Java 语言开发，目前提供 Java、C/C++、Node.js、Python、Go 等语言的客户端，监控数据会全量统计。国内很多公司在用，例如美团点评、携程、拼多多等。CAT 须要开发人员手动在应用程序中埋点，对代码侵入性比拟强。
• Zipkin（开源）： 由 Twitter 公司开发并开源，Java 语言实现。侵入性绝对于 CAT 要低一点，须要对 web.xml 等相干配置文件进行批改，但仍然对系统有肯定的侵入性。Zipkin 能够轻松与 Spring Cloud 进行集成，也是 Spring Cloud 举荐的 APM 零碎。
• Pinpoint（开源）： 韩国团队开源的 APM 产品，使用了字节码加强技术，只须要在启动时增加启动参数即可实现 APM 性能，对代码无侵入。目前反对 Java 和 PHP 语言，底层采纳 HBase 来存储数据，探针收集的数据粒度十分细，但性能损耗较大，因其呈现的工夫较长，完成度也很高，文档也较为丰盛，利用的公司较多。
• SkyWalking（开源）： 国人开源的产品，2019 年 4 月 17 日 SkyWalking 从 Apache 基金会的孵化器毕业成为顶级我的项目。目前 SkyWalking 反对 Java、.Net、Node.js 等探针，数据存储反对 MySQL、ElasticSearch 等。
• 还有很多不开源的 APM 零碎，例如，淘宝鹰眼、Google Dapper 等等。

咱们将学习 Skywalking，Skywalking 有很多优良个性。SkyWalking 对业务代码无侵入，性能体现优良，SkyWalking 增长势头强劲，社区沉闷，中文文档齐全，反对多语言探针，SkyWalking 反对 Dubbo、gRPC、SOFARPC 等很多框架。

1.4 Skywalking 介绍

2015 年由集体吴晟（华为开发者）主导开源，作者是华为开发云监控产品经理，主导监控产品的布局、技术路线及相干研发工作，也是 OpenTracing 分布式追踪规范组织成员，该我的项目 2017 年退出 Apache 孵化器，是一个分布式系统的应用程序性能监控工具（APM），专为微服务、云原生架构和基于容器（Docker、K8s、Mesos）架构而设计。

官方站点：http://skywalking.apache.org/

GitHub 我的项目地址：https://github.com/apache/sky…

Skywalking 是一个可观测性剖析平台和利用性能管理系统，它也是基于 OpenTracing 标准、开源的 AMP 零碎。Skywalking 提供分布式跟踪、服务网格遥测剖析、度量聚合和可视化一体化解决方案。反对 Java，.Net Core, PHP, NodeJS, Golang, LUA, c++ 代理。反对 Istio + 特使服务网格

咱们在学习 Skywalking 之前，能够先拜访官网提供的控制台演示

演示地址：http://demo.skywalking.apache… 账号：skywalking 明码：skywalking

1、SkyWalking 外围性能：

• 指标剖析：服务，实例，端点指标剖析
• 问题剖析：在运行时剖析代码，找到问题的根本原因
• 服务拓扑：提供服务的拓扑图剖析
• 依赖剖析：服务实例和端点依赖性剖析
• 服务检测：检测慢速的服务和端点
• 性能优化：依据服务监控的后果提供性能优化的思路
• 链路追踪：分布式跟踪和上下文流传
• 数据库监控：数据库拜访指标监控统计，检测慢速数据库拜访语句（包含 SQL 语句）

• 服务告警：服务告警性能

  名词解释：

  • 服务（service）：业务资源利用零碎
  • 端点（endpoint）：利用零碎对外裸露的性能接口
  • 实例（instance）：物理机

2、SkyWalking 特点：

• 多语言主动探针，反对 Java、.NET Code 等多种语言。
• 为多种开源我的项目提供了插件，为 Tomcat、HttpClient、Spring、RabbitMQ、MySQL 等常见基础设施和组件提供了主动探针。
• 微内核 + 插件的架构，存储、集群治理、应用插件汇合都能够进行自由选择。
• 反对告警。
• 优良的可视化成果。

3、Skywalking 架构图：

skyWalking 整体可分为：客户端，服务端

客户端：agent 组件

​ 基于探针技术采集服务相干信息（包含跟踪数据和统计数据），而后将采集到的数据上报给 skywalking 的数据收集器

服务端：又分为 OAP，Storage，WebUI

• OAP：observability analysis platform 可观测性剖析平台，负责接管客户端上报的数据，对数据进行剖析，聚合，计算后将数据进行存储，并且还会提供一些查问 API 进行数据的查问，这个模块其实就是咱们所说的链路追踪零碎的 Collector 收集器
• Storage：skyWalking 的存储介质，默认是采纳 H2，同时反对许多其余的存储介质，比方：ElastaticSearch，mysql 等
• WebUI：提供一些图形化界面展现对应的跟踪数据，指标数据等等

2 Skywalking 装置

Skywalking 数据存储形式有 2 种，别离为 H2(内存)和 elasticsearch，如果数据量比拟大，倡议应用后者，工作中也倡议应用后者。

Skywalking 本身提供了 UI 治理控制台，咱们装置的组件：

1:elasticsearch, 倡议应用 elasticsearch7.x
2:elasticsearch-hq,elasticsearch 的管理工具，更方便管理 elasticsearch
3:Skywalking
4:Skywalking-UI

2.1 elasticsearch 装置

1)零碎资源配置批改

elasticsearch 占用系统资源比拟大，咱们须要批改下零碎资源配置，这样能力很好的运行 elasticsearch，批改虚拟机配置，vi /etc/security/limits.conf，追加内容:

* soft nofile 65536
* hard nofile 65536

批改vi /etc/sysctl.conf，追加内容 :

vm.max_map_count=655360

让配置立刻失效：

/sbin/sysctl -p

2)装置 elasticsearch

倡议装置：elasticsearch7.x，咱们这里抉择 7.6.2, 并且采纳容器的装置形式，装置如下：

docker run --name elasticsearch -p 9200:9200  -p 9300:9300 --restart=always -e "discovery.type=single-node" -e ES_JAVA_OPTS="-Xms84m -Xmx512m" -d elasticsearch:7.6.2

3)elasticsearch 跨域配置

elasticsearch 默认是没有开启跨域，咱们须要配置跨域，并配置集群节点名字：

# 进入容器
docker exec -it elasticsearch /bin/bash

批改容器中 /usr/share/elasticsearch/config/elasticsearch.yml 文件，增加配置如下：

cluster.name: "elasticsearch"
http.cors.enabled: true
http.cors.allow-origin: "*"
network.host: 0.0.0.0
discovery.zen.minimum_master_nodes: 1

参数阐明：

cluster.name: 集群服务名字
http.cors.enabled: 开启跨域
http.cors.allow-origin: 容许跨域域名，* 代表所有域名
network.host: 内部拜访的 IP
discovery.zen.minimum_master_nodes: 最小主节点个数

装置实现后，重启容器 docker restart elasticsearch，再拜访http://192.168.200.129:9200/ 成果如下：

装置 ElasticSearch 治理界面 elasticsearch-hq

docker run -d --name elastic-hq -p 5000:5000 --restart always elastichq/elasticsearch-hq

装置实现后，拜访控制台地址 http://192.168.200.129:5000/#!/clusters/elasticsearch

2.2 Skywalking 装置

Skywalking 的装置咱们也采纳 Docker 装置形式，同时咱们须要为 Skywalking 指定存储服务：

# 装置 Skywalking
docker run --name skywalking -d -p 1234:1234 -p 11800:11800 -p 12800:12800 --restart always --link elasticsearch:elasticsearch -e SW_STORAGE=elasticsearch7 -e SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200 apache/skywalking-oap-server

参数阐明：

--link elasticsearch:elasticsearch: 存储服务应用 elasticsearch
-e SW_STORAGE=elasticsearch7：存储服务 elasticsearch 的版本
-e SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200: 存储服务 elasticsearch 的链接地址

接下来装置 Skywalking-UI，须要指定 Skywalking 服务名字：

docker run --name skywalking-ui -d -p 8080:8080 --link skywalking:skywalking -e SW_OAP_ADDRESS=skywalking:12800 --restart always apache/skywalking-ui 

装置实现后，咱们接下来拜访 Skywalking 控制台：http://192.168.200.129:8080

对于 SkywalkingUI 的应用，咱们在下一节知识点具体解说。

2.3 Skywalking 生产环境问题

1)ES 分片数量下限

如果此时拜访 http://192.168.200.129:8080/ 呈现 500 谬误，谬误如下，此时其实是 Elasticsearch 出了问题：

"com.netflix.zuul.exception.ZuulException","message":"GENERAL"

咱们能够查看 skywalking 的日志docker logs --since 30m skywalking，会报如下谬误：

Failed: 1: this action would add [2] total shards, but this cluster currently has [1000]/[1000] maximum shards open;]

这种谬误个别是生产环境中 Elasticsearch 分片数量达到了峰值，es 集群的默认最大分片数是 1000，咱们须要调整 Elasticsearch 的默认分片数量，批改形式有多种，最罕用的是间接批改 elasticsearch.yml 配置文件：

# 进入 elasticsearch 容器
docker exec -it elasticsearch /bin/bash
#编辑
vi /usr/share/elasticsearch/config/elasticsearch.yml
#增加如下配置
cluster.max_shards_per_node: 10000000

保留配置后，记得删除 data/nodes 数据包，再重启 elasticsearch，此时就能够失常拜访了。

2)磁盘清理

如果此时能关上 skywalking-ui 界面，然而没有数据，则须要清理磁盘空间，可能是磁盘空间满了，如果是 docker 容器，能够应用 docker system prune 命令实现清理，docker system prune命令能够用于清理磁盘，删除敞开的容器、无用的数据卷和网络，以及 dangling 镜像（即无 tag 的镜像）。docker system prune -a命令清理得更加彻底，能够将没有容器应用 Docker 镜像都删掉。

2.4 docker-compose 部署

创立 docker-compose.yml 并配置如下

version: '3.3'
services:
  elasticsearch:
    image: elasticsearch:7.6.2
    container_name: elasticsearch
    restart: always
    privileged: true
    hostname: elasticsearch
    ports:
      - 9200:9200
      - 9300:9300
    environment:
      - discovery.type=single-node
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - TZ=Asia/Shanghai
    networks:
      - skywalking
    ulimits:
      memlock:
        soft: -1
        hard: -1
  elasticsearch-hq:
    image: elastichq/elasticsearch-hq
    container_name: elasticsearch-hq
    restart: always
    privileged: true
    hostname: elasticsearch-hq
    ports:
      - 5000:5000
    environment:
      - TZ=Asia/Shanghai
    networks:
      - skywalking
  oap:
    image: apache/skywalking-oap-server:8.3.0-es7
    container_name: oap
    hostname: oap
    privileged: true
    depends_on:
      - elasticsearch
    links:
      - elasticsearch
    restart: always
    ports:
      - 11800:11800
      - 12800:12800
    environment:
      SW_STORAGE: elasticsearch7
      SW_STORAGE_ES_CLUSTER_NODES: elasticsearch:9200
      TZ: Asia/Shanghai
    volumes:
      - ./config/alarm-settings.yml:/skywalking/config/alarm-settings.yml
    networks:
      - skywalking
  ui:
    image: apache/skywalking-ui:8.3.0
    container_name: ui
    privileged: true
    depends_on:
      - oap
    links:
      - oap
    restart: always
    ports:
      - 8080:8080
    environment:
      SW_OAP_ADDRESS: oap:12800
      TZ: Asia/Shanghai
    networks:
      - skywalking

networks:
  skywalking:
    driver: bridge

通过命令一键启动：

docker-compose up -d

启动胜利后拜访 skywalking 的 webui 页面：http://192.168.200.129:8080/

本文由传智教育博学谷 – 狂野架构师教研团队公布，转载请注明出处！

如果本文对您有帮忙，欢送关注和点赞；如果您有任何倡议也可留言评论或私信，您的反对是我保持创作的能源