2.【skywalking】从入门到放弃-概念篇开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 3

开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 3 天，点击查看活动详情

1.简介

https://blog.csdn.net/feiying0canglang/article/details/120191083

https://www.jianshu.com/p/5b4bc9eebb04
一个人开发Spring Cloud Alibaba微服务（1）SkyWalking实现Dubbo全链路追踪

https://skywalking.apache.org/zh/2020-04-19-skywalking-quick-start/#  官方中文文档

https://skywalking.apache.org/docs/main/v9.0.0/readme/ 最新版9.0官方英文文档

https://blog.51cto.com/u_14290964/5293648 APM（应用性能管理）

1.1 APM

什么是APM

APM (Application Performance Management) 即应用性能管理（应用性能监控）

APM主要是针对企业关键业务的IT应用性能和用户体验的监测、优化，提高企业IT应用的可靠性和质量。

旨在确保最终用户获得高质量的体验，降低IT总拥有成本（TCO)

TCO （Total Cost of Ownership ），即总拥有成本，包括产品采购到后期使用、维护的成本。这是一种公司经常采用的技术评价标准。

APM介绍

目前市面的系统基本都是参考 Google 的 Dapper（大规模分布式系统的跟踪系统）来做的。

跟踪业务请求的处理过程，完成对应用系统在前后端处理、服务端调用的性能消耗跟踪，提供可视化的界面来展示对跟踪数据的分析。

通过汇聚业务系统各处理环节的实时数据，分析业务系统各事务处理的交易路径和处理时间，实现对应用的全链路性能监测。

APM工具与传统的性能监控工具的区别在于，不仅仅提供一些零散的资源监控点和指标，其主要关注在系统内部执行、系统间调用的性能瓶颈分析，这样更有利于定位到问题的具体原因。

APM致力于检测和诊断应用性能问题，从而能提供应用预期的服务水平。

APM 的核心思想

在应用服务各节点相互调用的时候，从中记录并传递一个应用级别的标记，这个标记可以用来关联各个服务节点之间的关系。

比如两个应用服务节点之间使用 HTTP 作为传输协议的话，那么这些标记就会被加入到 HTTP 头中。

可见如何传递这些标记是与应用服务节点之间使用的通讯协议有关的，常用的协议就相对容易加入这些内容，一些按需定制的可能就相对困难些，这一点也直接决定了实现分布式追踪系统的难度。

1.2 常见的几种APM工具

1. pinpoint

Pinpoint专注于链路和性能监控，韩国研发团队开源，埋点无侵入，UI功能较强。

<https://github.com/pinpoint-apm/pinpoint> 2、skywalking

2. Skywalking是一个国产的开源框架，2015年有吴晟个人开源，2017年加入Apache孵化器，国人开源的产品，主要开发人员来自于华为。Skywalking专注于链路和性能监控，埋点无侵入，UI功能较强。能够加入Apache孵化器，设计思想及代码得到一定认可，后期应该也会有更多的发展空间及研发人员投入。目前使用厂商最多。版本更新较快。

<https://github.com/apache/skywalking> 3、zipkin

3. Zipkin由Twitter开源，调用链分析工具，基于spring-cloud-sleuth得到广泛使用，非常轻量，使用部署简单。

<https://github.com/openzipkin/zipkin> 4、cat

4. CAT是一个更综合性的平台,提供的监控功能最全面，国内几个大厂生产也都在使用。但研发进度及版本更新相对较慢。

<https://github.com/dianping/cat>

名称	用途	研发者	github star
pinpoint	分布式链路追踪系统、APM	naver	12.1k
skywalking	分布式链路追踪系统、APM	2017年加入Apache孵化器	18.9k
zipkin	分布式链路追踪系统	Twitter	15.2k
cat	应用实时监控	携程、大众店品	16.5k

埋点方式

名称	埋点方式	入侵性
pinpoint	java探针	低
skywalking	java探针	低
zipkin	http拦截器	中
cat	代码埋点(拦截器/注解/过滤器)	高

埋点数据传输性能

名称	数据采集	消息传输	业务吞吐量影响	cpu及mem影响
pinpoint	系统层:cpu/mem/disk/load;应用层:jvm/链路/调用关系/执行耗时,业务层:	thrift	中高	<10%
skywalking	同pinpoint	grpc	小	<10%
zipkin	系统层:无,应用层:链路追踪,执行耗时,业务层:无	消息队列/http	中	10%
cat	系统层:cpu/mem/disk/load;应用层:jvm/链路/调用关系/执行耗时,业务层:业务kpi数据(手动埋点)	netty	小	10%

数据存储

名称	存储方式
pinpoint	hbase
skywalking	es/mysql/tidb/h2/sharding sphere
zipkin	mysql/es/cassandra
cat	本地/hdfs/mysql

1.3 SkyWalking

SkyWalking 是什么？

FROM skywalking.apache.org/

是一个开源可观察性平台，用于收集，分析，聚合和可视化来自服务和云原生基础架构的数据。SkyWalking 提供了一种简单的方法来保持分布式系统的清晰视图，甚至可以跨云。它是一种现代 APM，专为微服务、云原生架构和基于容器（Docker、K8s、Mesos）架构而设计。

为什么使用SKyWalking

‎SkyWalking提供了在许多不同的场景中观察和监控分布式系统的解决方案。首先，与传统方法一样，SkyWalking为Java，C#，Node，.js Go，PHP和Nginx LUA等服务提供自动仪器代理。（呼吁Python和C++SDK贡献）。随着多语言开发,持续部署的开发环境环境，云原生基础架构变得更加强大，但也变得更加复杂。SkyWalking 的服务网格接收器允许 SkyWalking 从 Istio/Envoy 和 Linkerd 等服务网格框架接收遥测数据，从而允许用户了解整个分布式系统。‎

‎SkyWalking 为‎‎服务、服务‎实例‎‎、‎‎端点‎‎、‎进程‎‎提供监控功能。术语“服务”、“实例”和“终端”在当今无处不在，因此值得在 SkyWalking 的上下文中定义它们的具体含义：‎

‎Service服务‎‎。表示一组/组工作负荷，这些工作负荷为传入请求提供相同的行为。您可以在使用工具代理或 SDK 时定义服务名称。SkyWalking 也可以使用您在 Istio 等平台中定义的名称。‎

‎Service Instance服务实例‎‎。服务组中的每个工作负荷称为一个实例。就像pods在Kubernetes中一样，它不需要是单个操作系统进程，但是，如果你使用的是仪器代理，实例实际上是一个真正的操作系统进程。‎

Endpoint‎端点‎‎。服务中用于传入请求的路径，例如 HTTP URI 路径或 gRPC 服务类 + 方法签名。‎

‎Process流程‎‎。操作系统进程。在某些情况下，服务实例不是一个进程，例如 Pod Kubernetes 可能包含多个进程。‎

‎通过 SkyWalking，用户可以了解服务和端点之间的拓扑关系，查看每个服务/服务实例/端点的指标并设置报警规则。‎

‎从 v9 开始，SkyWalking 引入了新的核心概念 ‎‎Layer‎‎。 ‎‎Layer‎‎层表示‎计算机科学中的抽象框架，例如操作系统（OS_LINUX层），Kubernetes（k8s层）。所有检测到的实例都属于一个层来表示此实例的运行环境，该服务将根据其实例具有一个或多个层定义。‎

‎此外，您还可以集成‎

‎其他分布式跟踪使用SkyWalk原生代理和SDK与Zipkin，Jaeger和OpenCensus。‎

‎其他指标系统，如Prometheus，Sleuth（Micrometer），OpenTelemetry。‎

1.4 功能列表

SkyWalking 有哪些功能？

FROM skywalking.apache.org/

多种监控手段。可以通过语言探针和 service mesh 获得监控数据。

多个语言自动探针。包括 Java，.NET Core 和 Node.JS。

轻量高效。无需大数据平台，和大量的服务器资源。

模块化。UI、存储、集群管理都有多种机制可选。

支持告警。

优秀的可视化解决方案。

1.5 整体架构

SkyWalking 整体架构如何？

整个架构，分成上、下、左、右四部分：

考虑到让描述更简单，我们舍弃掉 Metric 指标相关，而着重在 Tracing 链路相关功能。

上部分 Agent ：负责从应用中，收集链路信息，发送给 SkyWalking OAP 服务器。目前支持 SkyWalking、Zikpin、Jaeger 等提供的 Tracing 数据信息。而我们目前采用的是，SkyWalking Agent 收集 SkyWalking Tracing 数据，传递给服务器。
下部分 SkyWalking OAP ：负责接收 Agent 发送的 Tracing 数据信息，然后进行分析(Analysis Core) ，存储到外部存储器( Storage )，最终提供查询( Query )功能。
右部分 Storage ：Tracing 数据存储。目前支持 ES、MySQL、Sharding Sphere、TiDB、H2 多种存储器。而我们目前采用的是 ES ，主要考虑是 SkyWalking 开发团队自己的生产环境采用 ES 为主。
左部分 SkyWalking UI ：负责提供控台，查看链路等等。

1.6 官方文档

在 github.com/apache/skyw… 地址下，提供了 SkyWalking 的英文文档。

推荐先阅读 github.com/SkyAPM/docu… 地址，提供了 SkyWalking 的中文文档。

考虑到胖友使用 SkyWalking 的目的，是实现分布式链路追踪的功能，所以最好去了解下相关的知识。这里推荐阅读两篇文章：

1.7 探针简介

参考文档：

https://developer.aliyun.com/article/763498

在 SkyWalking 中, 探针表示集成到目标系统中的代理或 SDK 库, 它负责收集遥测数据, 包括链路追踪和性能指标。根据目标系统的技术栈, 探针可能有差异巨大的方式来达到以上功能. 但从根本上来说都是一样的, 即收集并格式化数据, 并发送到后端。

从高层次上来讲, SkyWalking 探针可分为以下三组：

基于语言的原生代理. 这种类型的代理运行在目标服务的用户空间中, 就像用户代码的一部分一样. 如 SkyWalking Java 代理, 使用 -javaagent 命令行参数在运行期间对代码进行操作, 操作 一词表示修改并注入用户代码. 另一种代理是使用目标库提供的钩子函数或拦截机制. 如你所见, 这些探针是基于特定的语言和库。
服务网格探针. 服务网格探针从服务网格的 Sidecar 和控制面板收集数据. 在以前, 代理只用作整个集群的入口, 但是有了服务网格和 Sidecar 之后, 我们可以基于此进行观测了。
第三方打点类库. SkyWalking 也能够接收其他流行的打点库产生的数据格式. SkyWalking 通过分析数据,将数据格式化成自身的链路和度量数据格式. 该功能最初只能接收 Zipkin 的 span 数据. 更多参考其他追踪系统的接收器。

你不必同时使用 基于语言的原生代理 和 服务网格探针 ，因为两者都收集指标数据，否则你的系统就要承受双倍负载, 且分析数量会翻倍.

有如下几种推荐的方式来使用探针:

只使用 基于语言的原生代理.
只使用 第三方打点库, 如 Zipkin 打点系统.
只使用 服务网格探针.
使用 服务网格探针, 配合 语言原生代理 或 第三方打点库, 来 追踪状态 . (高级用法)

另外，让我们举例说明什么是 追踪状态？

默认情况下, 基于语言的原生代理 和 第三方打点库 都会发送分布式追踪数据到后台, 后者分析/聚合这些追踪数据. 追踪状态意味着, 后端把这些追踪数据看作是日志一类的事情, 仅仅将他们保存下来, 并且在追踪和指标之间建立联系, 比如 这个追踪数据属于哪个入口哪个服务? 。

服务网格探针

参考文档

github.com/SkyAPM/docu…

服务网格探针使用了服务网格实现者中提供的可扩展机制，比如 Istio。

探针从哪里采集数据

Istio 是一个非常典型的服务网格的设计和实现。它定义了 控制平面 和 数据平面，被广泛使用。下面是 Istio 的架构 :

服务网格探针可以选择从 控制平面 和 数据平面 采集数据。在 Istio 中，指的是从 Mixer(Control Panel) 或者 Envoy sidecar(Data Panel) 中采集遥测数据。探针从客户端和服务器端收集每个请求的两个遥测实体，它们其实是相同的数据。

服务网格如何使后端工作

从探针中，您可以看到在这种探针中一定没有相关的跟踪，那么为什么 SkyWalking 平台仍然可以工作？

服务网格探针从每个请求收集遥测数据，因此它知道源、目标、端点、延迟和状态。通过这些，后端可以通过将这些调用合并为行来描述整个拓扑图，以及每个节点通过传入请求的度量。后端解析跟踪数据，请求相同的度量数据。因此，正确的表述是：

服务网格度量就是跟踪解析器生成的度量。他们是相同的。