全链路追踪目的
微服务背景下
1.故障快速定位
跨语言实现开发中在业务日志中添加调用链ID,可以通过调用链结合业务日志快速定位错误信息。
2.各个调用环节的性能分析
分析调用链的各个环节耗时,分析系统的性能瓶颈,找到系统的薄弱环节针对性优化
3.数据分析
分析用户的行为路径,经过了哪些服务器上的哪个服务加以应用。
4.调用拓扑图
Trace系统设计目标
低侵入、低损耗、大范围部署
基本实现
埋点日志内容,通过记录traceId、RPCId、调用的开始时间,调用类型,协议类型,调用方ip和端口,请求的服务名等信息;调用耗时,调用结果,异常信息,消息报文等;
典型应用
非开源:Google的Dapper,淘宝的鹰眼,新浪的Watchman,京东的Hydra
开源:zipkin, pinpoint , skywalking
应用及分析
1.鼻祖:Google Dapper
谷歌tracing论文,关键字:低损耗、应用透明的、大范围部署需求;大规模集群的跟踪监控系统;跨应用跨服务器;ops-dev;
应用级透明:把核心跟踪代码做的很轻巧,然后把它植入到那些无所不在的公共组件种,比如线程调用、控制流以及RPC库
实现:为服务器上每一次你发送和接收动作来收集跟踪标识符(message identifiers)和时间戳(timestamped events),通过把代码植入限制在一个很小的通用组件库,实现监测系统的应用对开发人员的透明。
Dapper的跟踪模型:
跟踪树和span
ABCDE 5个span 组成了userRequest的跟踪树。Dapper会记录span名称,以及每个span的ID和父ID,以重建在一次追踪过程中不同span之间的关系。如果一个span没有父ID被称为root span。所有span都挂在一个特定的跟踪上,也共用一个跟踪id。所有这些ID用全局唯一的64位整数标示。
一个单独的span的细节图:
注意时间戳的正确性处理:由于客户端和服务器上的时间戳来自不同的主机,我们必须考虑到时间偏差。在我们的分析工具,我们利用了这个事实:RPC客户端发送一个请求之后,服务器端才能接收到,对于响应也是一样的(服务器先响应,然后客户端才能接收到这个响应)。这样一来,服务器端的RPC就有一个时间戳的一个上限和下限。
注:为保护Dapp