APM —全链路追踪

全链路追踪目的 

微服务背景下

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就有一个时间戳的一个上限和下限。

注：为保护Dapper的用户意外的过分热衷于日志的记录，每一个跟踪span有一个可配置的总标注量的上限。

Dapper日志收集管道