APM SkyWalking及服务可观察性
|
文件状态： [ ] 草稿 [√] 正在修改 |
|
1.0 |
|
|
1.0; |
|
|
|
杜有龙 |
|
|
|
2021-09-01 |
一、分布式调用链路
1
、分布式调用链路简图
在分布式架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。一个浏览器请求完整的调用链可能如下图所示。
2
、分布式调用链路特点
-
多进程：分布式架构
-
多团队：不同的团队开发
-
多语言：不同的编程语言实现
-
一对多服务：一次请求需要涉及到多个子系统
-
多机房：不同的系统部署在不同的机房
-
多数据中心：不同的系统向不同的数据中心获取数据
3
、调用链路会带来什么问题
常见的问题简图
遇到上述问题，我们会产生诸多疑问
-
如何快速发现问题？
-
如何找到问题？
-
如何判断故障影响范围？
-
如何梳理服务依赖以及依赖的合理性？
-
如何分析链路性能问题？
（用户对搜索的耗时是很敏感的，而任何一个子系统的低效都会导致最终的搜索耗时。）
想要解决分布式系统面临的上述一些列问题，并且理解分布式系统的行为。
就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作。
帮助我们进行系统的持续监控，以便发生问题时，能够快速定位问题所在。
4
、调用链路监控理论（Dapper）
Dapper
，是最早关于调用链路监控的理论。
2010
年Google公开的论文提到了
Dapper
，a Large-Scale Distributed Systems Tracing Infrastructure（大规模分布式系统跟踪基础设施） 。
该论文可以归类为三个核心。
4.1
、请求调用的关注点
关注在请求处理期间各个调用的各项性能指标。
-
吞吐量
：组件、平台、物理设备的实时吞吐量。
-
响应时间
：包括整体调用的响应时间和各个服务的响应时间。
-
错误记录
：根据服务响应错误信息统计单位时间异常次数。
4.2
、调用链路监控的目的
|
|
在全链路监控工具中，能够带给我们什么?
-
故障定位：
可以通过调用链结合业务日志快速定位错误信息
-
部署分析：
准确掌握生产一线应用部署情况
-
性能问题定位：
找到影响性能的位置，可以做以下三方面的优化
-
依赖优化：
梳理各个调用环节的可用性，查找服务依赖关系，进行优化
-
链路优化：
可以得到用户的行为路径，对不合理的链路进行优化调整
-
关键点优化：
从调用链全流程性能角度，识别关键调用链，并进行优化
4.3
、调用链路实现方式：跟踪树与span
Dapper
技术实现核心思想。
Dapper
的核心实现方法是在分布式请求的上下文中加入
span id
以及
parent id
，用于记录请求的上下级关系，这个关系用
树
形结构来表示。
一次特定跟踪会产生一个
trace id
。
一次特定跟踪的所有相关 span 会共享同一个通用的trace id 。
（分布式追踪示意图）
|
|
二、SkyWalking
1
、服务可观察性
1.1
、什么是服务可观察，为什么要做到可观察
服务对运维和开发者是透明的，
在发生问题之前或者发生问题时，
我们是可以观察到服务的运行状况。
|
|
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
:
a
n APM(application performance monitor) system
, especially designed for microservices
,
cloud native and container-based (Docker, Kubernetes, Mesos) architectures.
一种APM（应用程序性能监视器）系统，专为微服务，云原生和基于容器（Docker，Kubernetes，Mesos）架构而设计。
|
|
2.2
、Skywalking主要特性
The core features are following.
-
Distributed tracing
-
Service, service instance, endpoint metrics analysis
-
Root cause analysis. Code on the runtime analysis
-
Service topology map analysis
-
Service, service instance and endpoint dependency analysis
-
Slow services and endpoints detected
-
Database metrics monitoring
-
Alarm
-
Browser performance monitoring
-
Infrastructure
(VM, network, disk etc.) monitoring
-
Metrics, traces, and logs
2.3
、Skywalking对遥测数据来源支持
SkyWalking supports to collect telemetry (metrics, traces, and logs) data from multiple sources and multiple formats, including
-
J
ava, .NET Core, NodeJS, PHP, and Python auto agents.
-
Go and C++ SDKs.
-
Browser agent.
-
Service Mesh Observability.
-
Metrics system, including Prometheus.
-
Logs.
-
Zipkin v1/v2 trace.(No Analysis)
3
、SkyWalking优点
-
支持多语言探针监控。
-
支持自动及手动探针。
自动探针：在使用过程中，完全是0代码，无侵入,无需修改程序源代码;
手动探针：它支持手动探针去追踪业务方法OpenTrackingApi、@Trace注解、trackId集成到日志中。
-
多种后端存储：ElasticSearch，Mysql，TiDB， H2。采用elasticsearch做数据存储，能够达到实时搜索、稳定、可靠
-
现代化Web UI。提供了良好的可视化管理界面，包括应用、实例、服务性能指标分析、拓扑图、分布式追踪、性能预警。
-
日志集成
-
应用、实例和服务的告警
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
实现方式
|
|
|
|
|
|
|
|
|
|
|
|
3.2
接入方式
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.3
通信方式
|
|
|
|
|
|
|
|
|
|
|
|
3.4
常见特性
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.5
数据存储
|
|
|
|
|
|
|
|
|
|
|
|
3.6 UI
展示
|
|
|
|
|
|
|
|
|
|
|
|
3.7
社区活跃度
|
|
|
|
|
|
|
|
|
|
|
|
3.8
缺点
|
|
|
|
|
|
|
|
|
|
|
|