Skywalking链路追踪
简介
问题分析
服务监控要满足的三要素分别如下
- 日志监控
- 指标监控
- 请求链路追踪
服务监控只要能满足这三个要素,基本就能实现我们想要的监控效果
现在有这样的电商案例
- 用于请求调用服务网关,请求到达后端服务
- 此时用户有可能调用订单服务,订单服务可能调用用户服务,用户服务有可能调用商品服务,商品服务有可能调用用户服务,用户服务有可能调用订单服务
- 在调用过程中存在很多请求跟踪问题,列入如果报错了,哪个环节出错了?这各问题不解决,很难快速定位bug
在为服务场景下,服务之间调用如果不解决调用跟踪问题,就很难排查错误,很难分析服务健康状态
如果我们要解决调用跟踪,了解服务状态又该如何实现?
要素分析
我们可以通过日志(Logging)记录调用链路信息,通过日志统计时间窗口下的指标数据(Metrics),如果服务之间的调用可以通过日志分析出来,那也就解决了调用流程跟踪,也就是链路追踪了(Tracing)了
来看看我Logging,Metrics,Tracing概念
- Logging就是记录系统行为的离散事件,例如,服务在处理某个请求时打印的错误日志,我们可以将这些日志记录到ElasticSearch或是其他存储中,然后通过Kibana或是其他工具来分析这些日志了解服务的行为和状态.大多数情况下,日志记录的数据是很分散的,比如错误日志,请求处理过程中关机步日志等等
- Metrics是系统在一段时间内某一方面的某个度量,例如,电商统计在一分钟内的请求次数.我吗常见的监控系统中记录数据都属于这个范畴,录入Promethus,Open-Falcon等,这些监控系统最终会给运维人员展示的是一张张二维的想着先图,Metrics是可以聚合的,例如,微电商系统中每个http接口添加一个计数器,计算每个接口的QPS(每秒处理事务数),之后我们就可以通过简单的求和计算得到系统的负载情况
- Tracing即我们常说的分布式链路追踪.在微服务架构系统中请求一个会结果很多服务处理,调用链路会非常长,要确定中间哪个服务出现异常是一件非常麻烦的事情.通过分布式链路追踪,运维人员就可以构建一个请求的视图,这个视图上展示了一个请求从进入系统开始到返回响应的整个流程.这样就可以从中了解到服务的异常情况,网络调用,以及系统的性能瓶颈
什么是链路追踪
谷歌在 2010 年 4 月发表了一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》介绍了分布式追踪的概念，之后很多互联网公司都开始根据这篇论文打造自己的分布式链路追踪系统。前面提到的 APM 系统的核心技术就是分布式链路追踪。
OpenTracing提供了一个标准的、与供应商无关的框架，这意味着如果开发者想要尝试一种不同的分布式追踪系统，开发者只需要简单地修改Tracer配置即可，而不需要替换整个分布式追踪系统。
支持java,go,ts,python等等
链路追踪方案
下面通过官方的一个示例简单介绍说明什么是 Tracing,把Tracing学完后，更有助于大家运用Skywalking UI进行数据分析。
在一个分布式系统中，追踪一个事务或者调用流程，可以用下图方式描绘出来。这类流程图可以看清各组件的组合关系，但它并不能看出一次调用触发了哪个组件调用、什么时间调用、是串行调用还是并行调用。
一种更有效的展示方式就是下图这样,这是一个典型的trace视图,这种展示方式显示了执行时间的上下文,相关服务间的层次关系,进程或者任务的串行活并行调用关系.这样的视图有助于发现系统调用的关键路径.通过关注关键路径的执行过程,开发团队就可以专注于优化路径中的关键服务,最大提升系统性能.例如下图中,我们可以看到请求串行调用了授权服务,订单服务以及资源服务,最大幅度提升系统的性能.例如下图中，我们可以看到请求串行的调用了授权服务、订单服务以及资源服务，在资源服务中又并行的执行了三个子任务。我们还可以看到，在这整个请求的生命周期中，资源服务耗时是最长的。
OpenTracing
学好OpenTracing,更有助于我们运用Skywalking UI进行数据分析
trace
一个trace代表一个事务,请求或是在流程在分布式系统中的执行过程.OpenTracing中的一条Trace被认为是一个由多个span组成的有向无环图(DGA图),一个Span代表系统中具有开始时间和执行市场的逻辑单元,Span一般会有一个名称,一条Trace中dSpan是收尾连接的.
span
span代表系统中具有开始时间和执行时长的逻辑单元,span之间通过嵌套或者顺序排列建立逻辑因果关系
每个span可以包含以下信息
- 操作名称:具体的RPC访问地址,访问的URL地址等
- 起始时间:
- 结束时间
- span Tag一组键值对构成的span标签集合,其中键必须为字符串类型,值可以是字符串,bool或者数字
- Span Log一组span的日志集合
- spanContxt:trace的全局上下文信息
- References:span之间的引用关系
在一个Trace中,一个Span可以和一个或者多个Span存在因果关系.目前OpenTracing定义了ChildOf和FollowsFrom 俩种Span之间的引用关系.这俩种引用类型代表了子节点和父节点的直接因果关系
ChildOf
一个span可能是父级span的孩子,即为ChildOf关系,下面这些情况会构成ChildOf关系,下面这些情况会构成ChildOf关系
- 一个http请求中,被调用的服务端产生span,与发起调用的客户端产生的span,就构成了childOf关系
- 一个sql Insert操作的sspan,和ORM的save方法的span构成ChlidOf
很明显上述ChildOf关系中的父级Span都要等待子span的返回,子span的执行时间影响了所在父级span的执行时间.父级span依赖子span的执行结果出了串行的任务外,我们逻辑中还有很多并行的任务,它们对应的span也是并行的,这种情况下一个父级spanky合并所有子span的执行结果并等待所有并行子span结束
FollowsFrom
在分布式系统中,一些上游系统(父节点不以依赖下游系统(子节点)的执行结果),例如,上游系统通过消息队列向下游发送消息.在这种情况下,下游系统对应的子span和上游系统的父级span之间是followsFrom关系
logs
每个span可以进行多次log操作每一次log操作,都需要带一个时间戳,以及一个可选的附加信息
tags
每个span可以有多个键值形式的tags,tags是没有时间戳的,只是为span添加一些简单解释和补充信息
spanContext和Baggage
SpanContext表示进程边界,在跨进调用时需要将一些全局信息,录入TraceId,当前SpanId等信息封装到Baggage中传到另一个进程(下游系统)中
Baggage是存储在spanContext中的一个键值对集合.它会在一条Trace中全局传输,该Trace中所有span都可以获取到其中信息.
需要注意的是,由于Baggage需要跨进程全局传输,就会涉及相关数据的序列化和反序列化操作,如果在Baggage中存放过多的数据,就会导致序列化和反序列化耗时边长,使整个系统的RPC的延迟增加,吞吐量下降
虽然Baggage与Span Tags一样,都是键值对集合,但是俩者最大区别在于SpanTags中的信息不会跨进程传输,而Baggage需要全局传输.因此OpenTracing要求实现提供Inject和Extract俩种操作,SpanContext可以通过Inject操作向Baggage中添加键值对数据,通过Extract从Baggage中获取键值对数据
接口语义
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 接口
用户可以通过 Span 实例或者 Tracer 的 Extract 能力获取 SpanContext 接口实例。
tracer接口
- 创建新的 Span。
- 注入 SpanContext：主要是将跨进程调用携带的 Baggage 数据记录到当前 SpanContext 中。
- 提取 SpanContext ，主要是将当前 SpanContext 中的全局信息提取出来，封装成 Baggage 用于后续的跨进程调用。
SkyWalking
当前主流的分布式链路追踪系统也并非只有Skywalking介绍,但skywalking异常火爆.
主流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有很多优秀特性,比如对代码无入侵,性能优秀,支持多语言探针,社区活跃等.他支持Dubbo,gRPC等很多框架
Skywalking是一个可观测性分析平台和应用性能管理系统，它也是基于OpenTracing规范、开源的AMP系统。Skywalking提供分布式跟踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。支持Java， .Net Core, PHP, NodeJS, Golang, LUA, c++代理。支持Istio +特使服务网格
Skywalking核心功能演示
- 服务,服务实例,端点指标分析
- 服务拓补图分析
- 服务,服务实例和端点(Endpoint)SLA分析
- 慢查询检测
- 告警
- 优秀的可视化效果
架构
- Agent(探针):Agent运行在各个服务实例中,负责采集服务实例的Trace,Metrics等数据,然后通过gRpc方式上报给SkyWalking后端
OAP: SkyWalkiong的后端服务,其主要有俩个
- 一个是负责接收Agent上报来的Trace,Metrics等数据,交给Analysis Core(涉及SkyWalking OAP中的多个模块)进行流式分析,最终分析得到的结果写入持久化存储中.SkyWalking可以使用es,h2,Mysql,等作为其持久化存储,一般线上使用ElasticSerach作为后端存储
- 另一个是负责响应SkyWalking UI界面发送来的查询请求,将前面持久化的数据查询出来,组成正确的响应结果返回给UI进行展示
- UI界面: skyWalking前后端进行分离,该ui界面负责将用户的查询操作封装为GraphQl,提交给OAP后端出发后续的查询操作,待拿到查询结果之后会在前端负责展示