SkyWalking

撰写本文时, 基于当时最新版: SkyWalking_8.6.0, ElasticSearch_7.13.1, 版本编写.

SkyWalking: an APM(application performance monitor) system, especially designed for microservices, cloud native and container-based architectures.

1) 链路追踪

分布式架构给我们带来了很多优势, 当然也带来了一些麻烦:

  1. 无法直接排查并发量高的服务节点, 难点.
  2. 生产环境的异常排查以及解决, 方案有 ELK 等.
  3. 服务器流量统计, 方案较多, Prometheus 相关的 NodeExporter 比较流行.

1.1) Dapper

2010 年 Google 发布了介绍其分布式监控系统 Dapper 的论文: 《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》, (中文版), 之后诞生的很多 APM 监控系统都参考了 Dapper 的实现.

1.2) OpenTracing

由于 Google Dapper 仅仅在 Google 内部使用, 论文发布后, 诞生了很多类似的 APM 系统, 但一直缺少一个比较统一的标准, 所以 OpenTracing 诞生了, 它提供了一套标准以及各种主流语言的 API 接口供于实现, 包括本文的主题 Skywalking 也是基于其标准实现的.

1.3) APM 系统三要素

2017 年, 分布式追踪峰会产生了另一篇比较有名的文章:《Metrics, tracing, and logging》 , 我们可以称之为 APM 系统三要素, 通过其三要素, 来解决分布式系统带来的一些麻烦, 我们可以简单了解一下:

  • Logging: 记录系统行为的离散事件, 如我们可以通过 ELK 记录业务处理中的 Error Log, 分析其行为. 但 Log 一般比较离散.
  • Metrics: 记录系统各个时刻的各种指标, 即各种监控, 如我们可以通过 Promethus 记录系统服务在各个时间节点的 QPS, 统计服务在各个时刻的负载.
  • Tracing: 记录用户访问系统的一些特征, 如在 MicroService 中服务上下游调用的链路, 即记录用户请求被那些服务处理, 服务间的调用顺序等.

2) OpenTracing

从 2016 年以来, OpenTracing 基本成为了行业的标准, 我们先了解一下它. OpenTracing 定义了三种相互关联的类型: Tracer, Span 和 SpanContext.

2.1) Tracer

Tracer 可以创建 Spans, 可以理解为客户端一次请求的会话, 其大概有以下功能:

  • Start a new Span
  • Inject a SpanContext into a carrier
  • Extract a SpanContext from a carrier

2.2) Span

Span 与 Tracer 相关联, 代表我们分布式系统中的请求处理节点, 一次 Tracer 会话可能关联多个 Span, 其大概有以下功能:

  • Retrieve the Spans SpanContext
  • Overwrite the operation name
  • Finish the Span
  • Set a Span tag: Tag 不会传递到下一个 Span, 通常用来记录并存储业务相关数据.
  • Log structured data:
  • Set a baggage item: Baggage 即在一个 Tracer 中, 可以跨 Span 向下级 Span 传递的数据.
  • Get a baggage item

2.3) SpanContext

SpanContext 主要用于封装 Baggage, 在 Span 上级往下级传递数据时使用, 也就是意义上的上下文.

3) 主流开源 APM

  • CAT: 美团开源, 侵入性大, Java 实现.
  • Zipkin: Twitter 开源, 低侵入, Java 实现, 支持部分 OpenTracing.
  • Pinpoint: 韩国开源, 零侵入, Java 实现.
  • SkyWalking: 中国开源, 零侵入, Java 实现, 完全支持 OpenTracing 标准.

4) SkyWalking 简介

可以先从官方演示链接, 预览一下其 UI 效果: http://demo.skywalking.apache.org, 账号密码都为: skywalking

接着再上一张官网的结构图：

SkyWalking 总体上分为四个部分：

  • Probes: 即探针, 也叫 Agent, 负责采集数据, 并将数据上报至 OAP.
  • OAP: SkyWalking 的后端服务, 负责接收探针上报的数据, 聚合分析处理后, 存储至 Storage 中; 且向 UI 提供数据查看接口.
  • Storage: 数据持久化仓库, 可以自行挑选实现如: ES, MySQL, H2, TiDB 等.
  • UI: SkyWalking 还提供了一套官方的可视化界面供于查看监控各数据.

5) SkyWalking 安装

安装 SkyWalking 步骤大概如下, 本文都将其相关应用安装部署在 Docker 上:

    1. 安装 Storage, 用于存储我们的监控数据, 提供查询, 示例使用 ES 作为我们是 Storage 实现, 本文使用 7.13.1 版本演示.
    1. 安装 OAP 后端, 本文使用 8.6.0 版本演示.
    1. 安装 SkyWalking UI 前端, 本文使用与 OAP 配套的 8.6.0 演示.

5.1) SkyWalking Storage 安装

本文以单节点做演示.

docker run --name elasticsearch -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:7.13.1

5.2) SkyWalking OAP 后端安装

请将 SW_STORAGE_ES_CLUSTER_NODES 替换为对应 ES 的容器 Name 以及端口.

$ docker run --name skywalking-oap --restart always -d -e SW_STORAGE=elasticsearch7 -e SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200 apache/skywalking-oap-server:8.6.0-es7

5.3) SkyWalking UI 安装

安装 SkyWalking-UI 时, 请注意其版本与 OAP 是否相互对应, 在撰写本文时, OAP 与其对应的 UI, 版本号相同一一对应.
且将 SW_OAP_ADDRESS 替换为对应 OAP 的容器 Name 以及端口.

$ docker run --name skywalking-ui --restart always -d -e SW_OAP_ADDRESS=skywalking-oap:12800 apache/skywalking-ui:8.6.0

5.4) WkyWalking Server 配置

安装完以上三项后, 需要对 OAP 后端进行配置, 以适应我们项目中不同的技术(如 Nacos, Dubbo, Eureka).

  1. 进入容器: docker exec -it skywalking-oap bash

9) 参考文献

以下排名不分先后: