作者:穿过生命散发芬芳
链路追踪(tracing)即调用链监控,特点是通过记录多个在请求间跨服务完成的逻辑请求信息,帮助开发人员优化性能和进行问题追踪。链路追踪可以捕获每个请求遇到的异常和错误,以及即时信息和有价值的数据。
随着微服务应用数量的极速增加,服务与服务链路之间的调用关系也变得错综复杂。此时,我们也会碰到各种难题。
市面上的绝大部分 APM 都是以谷歌公开论文中提到的 Dapper 为基础构建而成,先来一起看看调用链监控中的几个重要概念。
指一次完整的分布式调用链路可以看作一棵二叉树,从中我们能直观地看到请求经过所有服务的路径。从请求到服务器开始,到服务器返回响应数据结束,跟踪每次 RPC 调用的耗时,并使用唯一标识 trace id。例如,你完成一次微信支付,从微信扫描二维码到付款成功,唯一 trace id 将保留在整个请求链路中。
服务间经过的分支链路构成了一条完整的链路,其中每一条分支链路都用全局唯一的 trace id 来标识,便于对其上下文进行追踪。
每次进行本地或者远程方法的调用时会创建一个 Span,我们通过一个 64 位 ID 来标识它,Span 中还有其他数据,例如描述信息、时间戳、key-value 对(Annotation)的 tag 信息、parent id 等,其中 parent id 可以表示 Span 调用链路来源。通过 Span 的 ID 我们可以轻松了解服务的父服务是谁,再结合 trace id 就可以将一条完整的请求调用链串联起来。
为附加在 Span 上的日志信息,如下图在请求中的应用。
可以利用 Annotation 里的信息来计算一次调用的耗时,只需将客户端结束的时间点减去客户端开始请求的时间点,如果要计算客户端发送网络耗时,即客户端接收请求的时间点减去客户端发送请求的时间点。
采样率,需在客户端按照比例埋点并将信息提交给服务端。采集信息时的低损耗是这类监控服务设计时的重要标准,如果监控工具采集信息时给微服务造成了严重的性能问题,反而得不偿失。进行样本采样时,应该根据系统业务和技术架构,对每个应用和服务分别设置相应的采样率,每个应用的采样率可以动态调整。在产品的不同阶段采样率可能不同。例如,产品上线后的时段需要大量采样来了解整个系统的运行状态,这就需要提高采样率,当系统处于稳定时期,可以适当降低收集采样的频率。
采样收集包括可变自适应采样与固定采样。
1)可变自适应采样机制是不使用统一的采样率,在低流量负载时会自动提高采样率,而高流量负载则会自动降低采样率,从而掌控性能损耗。
2)而固定采样率模式是设置采样的百分比,可以设置阈值为 0~100 之间,当采样率设置为 100 时,则每次调用都会进行采样收集。
了解了链路追踪工具的原理后,我们来看看业界常用的链路追踪系统 Zipkin、PinPoint、SkyWalking,这里以 SkyWalking 为例子。
SkyWalking 逻辑上分为 4 部分:探针、平台后端、存储和用户界面。
1)探针:基于不同的来源,探针的实现可能不一样,但作用都是收集数据。
2)平台后端:支持数据聚合、数据分析以及获取探针采集到的数据。数据获取与分析来自 SkyWalking 原生追踪和性能指标以及第三方数据来源,第三方数据来源包括 Istio、Envoy telemetry 及 Zipkin 的追踪格式化数据等。我们甚至可以使用可观测分析语言对原生度量指标和计量系统的扩展变量指标进行自定义聚合分析。
3)存储:通过开放的插件化的接口存放 SkyWalking 数据,你可以选择一个既有的存储系统,如 Elasticsearch、H2 或 MySQL 集群(ShardingSphere 管理),也可以选择自己实现一个存储系统。
4)用户界面:一个基于接口并且可定制化的 Web 系统,用户可以查看和管理 SkyWalking 数据。
领取专属 10元无门槛券
私享最新 技术干货