APM SkyWalking及服务可观察性

Posted 2022-01-01 清云逸仙

APM SkyWalking及服务可观察性

文件状态： [ ] 草稿 [√] 正在修改	当前版本	1.0
	历史修订版本	1.0;
	作    者	杜有龙
	完成日期	2021-09-01

一、分布式调用链路

1、分布式调用链路简图

在分布式架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。一个浏览器请求完整的调用链可能如下图所示。

2、分布式调用链路特点

1. 多进程：分布式架构
2. 多团队：不同的团队开发
3. 多语言：不同的编程语言实现
4. 一对多服务：一次请求需要涉及到多个子系统
5. 多机房：不同的系统部署在不同的机房
6. 多数据中心：不同的系统向不同的数据中心获取数据

3、调用链路会带来什么问题

常见的问题简图

遇到上述问题，我们会产生诸多疑问

1. 如何快速发现问题？
2. 如何找到问题？
3. 如何判断故障影响范围？
4. 如何梳理服务依赖以及依赖的合理性？
5. 如何分析链路性能问题？

（用户对搜索的耗时是很敏感的，而任何一个子系统的低效都会导致最终的搜索耗时。）

想要解决分布式系统面临的上述一些列问题，并且理解分布式系统的行为。

就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作。

帮助我们进行系统的持续监控，以便发生问题时，能够快速定位问题所在。

4、调用链路监控理论（Dapper）

       Dapper，是最早关于调用链路监控的理论。

2010年Google公开的论文提到了 Dapper，a Large-Scale Distributed Systems Tracing Infrastructure（大规模分布式系统跟踪基础设施） 。

该论文可以归类为三个核心。

4.1、请求调用的关注点

关注在请求处理期间各个调用的各项性能指标。

1. 吞吐量：组件、平台、物理设备的实时吞吐量。
2. 响应时间：包括整体调用的响应时间和各个服务的响应时间。
3. 错误记录：根据服务响应错误信息统计单位时间异常次数。

4.2、调用链路监控的目的

全链路监控从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。

在全链路监控工具中，能够带给我们什么?

1. 故障定位：可以通过调用链结合业务日志快速定位错误信息
2. 部署分析：准确掌握生产一线应用部署情况
3. 性能问题定位：找到影响性能的位置，可以做以下三方面的优化

• 依赖优化：梳理各个调用环节的可用性，查找服务依赖关系，进行优化
• 链路优化：可以得到用户的行为路径，对不合理的链路进行优化调整
• 关键点优化：从调用链全流程性能角度，识别关键调用链，并进行优化

4.3、调用链路实现方式：跟踪树与span

Dapper技术实现核心思想。

Dapper的核心实现方法是在分布式请求的上下文中加入span id以及 parent id，用于记录请求的上下级关系，这个关系用树形结构来表示。

一次特定跟踪会产生一个trace id。一次特定跟踪的所有相关 span 会共享同一个通用的trace id 。

（分布式追踪示意图）

      

在 Dapper 跟踪树中，树节点是基本单元，我们称之为 span。节点之间的连线表示 span 与其父span 之间的关系。虽然节点在整个跟踪树中的位置是独立的，但 span 也是一个简单的时间戳日志，其中编码了这个 span 的开始时间、结束时间、RPC 时间数据、以及0或多个应用程序相关的标注。 Dapper 为每个 span 记录了一个可读的span name、span id和 parent id，这样就能重建出一次分布式跟踪过程中不同 span 之间的关系。没有parent id 的 span被称为 根span。一次特定跟踪的所有相关 span 会共享同一个通用的trace id （trace id在图中没有绘出）。所有这些 ID 可能是唯一的 64 位整数。在一个典型的 Dapper 跟踪中，我们希望每个 RPC 对应一个 span，每一个组件层对应跟踪树上的一个层级。

二、SkyWalking

1、服务可观察性

1.1、什么是服务可观察，为什么要做到可观察

服务对运维和开发者是透明的，

在发生问题之前或者发生问题时，

我们是可以观察到服务的运行状况。

随着容器化编排、私有云等各项技术的持续进化，为分布式服务化提供了技术层面的支持。随着微服务架构的持续演进，应用和服务数量不断增加，调用关系越来越复杂。无法通过一张静态的架构图来描述微服务架构下的系统部署情况。所以，从开发和运维的角度来看，需要对资源保持可观察性(Observability)。 可观察性要求提供穿越微服务边界的能力，并对应用数据或平台数据进行观测及分析，然后通过高度可视化系统，直观地将系统当前的状态展现出来。

1.2、可观察层次划分

从“可观察”的对象的角度，可以将其归纳为三个层次。

• 基础设施层

对主机、操作系统进行的指标监控。

基础设施层的监控和系统健康度观察大多由平台提供商直接负责。

• 工具层

编排工具的可观察性是微服务体系中的重要一环，随着容器化的不断推进，对Kubernetes和Mesos等容器编排生态工具的监控也越来越多样化。另外，由于DevOps体系的发展，相关工具链(如Git、SVN、CVCD等)的可观察性也成为当今的关注焦点。

工具层的解决方基本是由其核心产品以及周边生态提供的。

• 应用环境层

应用环境层的可观察性是指对应用自身、应用的服务器、数据库、消息队列、缓存等中间件组件进行观察。

1.3、应用环境层的多维度观察

应用环境层，可观察三个核心概念分别为日志（Logging）、指标（Metrics）、追踪（Tracing）。

• 日志（Logging）

描述的是一些不连续的（特性）离散事件。例如，有些业务系统采用ELK(Elasticsearch+Logstash+ Kinaba)或类似技术栈的日志收集系统，它们是分布式监控系统的早期形态，借鉴了传统应用解决问题的方式，是最容易理解的解决方案。

商业化的日志系统Splunk。

• 指标（Metrics）

可累加的，它具有（特性）原子性。每个指标都是一个逻辑计量单元，体现了一段时间之内相关指标的状态。

例如，每分钟请求的次数、内存的使用情况可以定义为一个曲线图。

CNCF生态中的 Prometheus监控系统正是基于指标的典型系统，它通过定义和收集不同的指标数据，以及提供基于时间维度的查询能力，为分布式服务指标提供基础数据保障。

• 追踪（Tracing）

在监控领域通常被称为分布式追踪，是指在单次请求范围内处理信息。任何的数据和元数据信息都被绑定到了系统中的单个事务上。追踪能力是近几年技术人员最为关注的需求，由Twitter开源的ZipKin是目前运用最为广泛的分布式追踪系统。

观察韦恩图，可以发现上面介绍的三个概念并不是相互独立的，往往会有一定的重叠。比如skywalking可以进行日志采集。

复杂和完善的监控系统一般是跨越多个维度的。

充分理解这三个概念，能够更好的定位目前市场上各种开源和商业监控工具或系统，理解它们的核心优势。

2、SkyWalking介绍

SkyWalking由中国人吴晟于2015年创建，早期是一个单纯的分布式追踪系统。目前已发展为一个全功能、多语言、支持多种应用场景的APM系统。

2017年12月8日，Apache软件基金会孵化器项目管理委员会 ASF IPMC宣布“SkyWalking全票通过，进入Apache孵化器”。

Skywalking的定位是apm，不仅提供了自动分布式追踪，还可以通过手动埋探针的方式去处理我们的一些特殊需求。同时它还支持了很多中间件和jvm监控，这是目前一些分布式追踪技术未能解决的问题。

比如zipkin技术，不能解决kafka等一些中间件和jvm的监控功能，也不支持自定义去追踪自己想要了解的链路信息。

在这些方面skywalking做的比较好，通过探针的方式来进行监控做到代码0侵入性，而性能开销极小。

2.1、Apache官网解释

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

一种APM（应用程序性能监视器）系统，专为微服务，云原生和基于容器（Docker，Kubernetes，Mesos）架构而设计。

什么是APM？ 在分布式系统中， 我们就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题，这就是所谓的APM（application performance monitor） 。

2.2、Skywalking主要特性

The core features are following.

1. Distributed tracing
2. Service, service instance, endpoint metrics analysis
3. Root cause analysis. Code on the runtime analysis
4. Service topology map analysis
5. Service, service instance and endpoint dependency analysis
6. Slow services and endpoints detected
7. Database metrics monitoring
8. Alarm
9. Browser performance monitoring
10. Infrastructure(VM, network, disk etc.) monitoring
11. Metrics, traces, and logs

2.3、Skywalking对遥测数据来源支持

SkyWalking supports to collect telemetry (metrics, traces, and logs) data from multiple sources and multiple formats, including

1. Java, .NET Core, NodeJS, php, and Python auto agents.
2. Go and C++ SDKs.
3. Browser agent.
4. Service Mesh Observability.
5. Metrics system, including Prometheus.
6. Logs.
7. Zipkin v1/v2 trace.(No Analysis)

3、SkyWalking优点

1. 支持多语言探针监控。
2. 支持自动及手动探针。

自动探针：在使用过程中，完全是0代码，无侵入,无需修改程序源代码;

手动探针：它支持手动探针去追踪业务方法OpenTrackingApi、@Trace注解、trackId集成到日志中。

1. 多种后端存储：ElasticSearch，mysql，TiDB， H2。采用elasticsearch做数据存储，能够达到实时搜索、稳定、可靠
2. 现代化Web UI。提供了良好的可视化管理界面，包括应用、实例、服务性能指标分析、拓扑图、分布式追踪、性能预警。
3. 日志集成
4. 应用、实例和服务的告警

4、SkyWalking架构

4.1、架构图

说明：

上面的架构图看似模块繁多，但在实际使用时我们并不需要关注太多的实现方式。

HTTP、gRPC 、GraphQL 这些都是其内部架构使用到的技术，我们只需安装 SkyWalking Collecter、Elasticsearch 或 H2，然后在需要追踪的服务内配置少量的代码（Java 项目通过修改 JVM 参数即可），最后通过 SkyWalking UI 查看结果。

4.2、三大组件

4.2.1概述

SkyWalking总体架构分为三部分

• skywalking-agent：探针，用来收集和发送数据到归集器。
• skywalking-collector：链路数据归集器，数据可以落地ElasticSearch，单机也可以落地H2，不推荐，H2仅作为临时演示用。
• skywalking-web：web可视化平台，用来展示落地的数据。

4.2.2关系

4.2.2.1、部署组件

• ES：其中数据存储建议使用elasticsearch
• agent：探针，获取应用信息
• collector：主要为收集agent发送过来的数据，和为web提供接口服务
• web：主要提供UI监控服务

4.2.2.2、关系说明

通过在应用程序中添加 SkyWalking Agent，就可以将接口、服务、数据库、MQ等进行追踪，将追踪结果通过 HTTP 或 gRPC 发送到 SkyWalking Collecter。

SkyWalking Collecter 经过分析和聚合，将结果存储到 Elasticsearch 或 H2。

SkyWalking 同时提供了一个 SkyWalking UI 的可视化界面，UI 以 GraphQL + HTTP 方式获取存储数据进行展示。

三、分布式追踪系统对比

1、常见技术

市场常见调用链技术：Zipkin，Pinpoint，SkyWalking，CAT。

2、技术特点

2.1、Zipkin

是Twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用。特点是轻量，使用部署简单。起步最早，社区体系最为完备。支持语言最为丰富。

但是功能较简单。支持技术栈spring-cloud。

2.2、Pinpoint

是韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具，使用java编写。

特点是支持多种插件，UI功能强大，接入端无代码侵入。

使用java探针字节码增加技术，实现对整个应用的监控。对应用零侵入。

2.3、SkyWalking

是中国开源的基于字节码注入的调用链分析以及应用监控分析工具。

2015年由个人吴晟（华为开发者）开源 ， 2017年加入Apache孵化器，2018年加入Apache顶级孵化项目。

特点是支持多种插件，UI功能较强，接入端无代码侵入。

其核心是个分布式追踪系统。使用java探针字节码增加技术，实现对整个应用的监控。对应用零侵入。

2.4、CAT

是大众点评开源的基于编码和配置的调用链分析，应用监控分析，日志采集，监控报警等一系列的监控平台工具。

集成方案是通过代码埋点的方式来实现监控，比如： 拦截器，注解，过滤器等。   对代码的侵入性很大，集成成本较高。风险较大。

3、特性对比

3.1实现方式

类别	Zipkin	Pinpoint	SkyWalking	CAT
实现方式	拦截请求，发送（HTTP，mq）数据至zipkin服务	java探针，字节码增强	java探针，字节码增强	代码埋点（拦截器，注解，过滤器等）

3.2接入方式

类别	Zipkin	Pinpoint	SkyWalking	CAT
接入方式	引入配置	javaagent字节码	javaagent字节码	代码侵入
OpenTracing	√	×	√	×

3.3通信方式

类别	Zipkin	Pinpoint	SkyWalking	CAT
agent到collector通信	http,MQ	thrift	gRPC	http/tcp

3.4常见特性

类别	Zipkin	Pinpoint	SkyWalking	CAT
颗粒度	接口级	方法级	方法级	代码级
全局调用统计	×	√	√	√
traceid查询	√	×	√	×
报警	×	√	√	直播预告：Apache SkyWalking 在 Service Mesh 中的可观察性应用 apm监控分析及pinpoint和skywalking对比 skywalking --部署、使用、告警、日志集成 skywalking插件工作原理剖析 分布式/微服务必配APM系统，SkyWalking让你不迷路 Skywalking+Elasticsearch安装及应用（邮箱告警）