概述

全链路监控元件就在这样的问题背景下产生了。最出名的是Google公开的论文提到的 Google Dapper。想要在这个上下文中理解分散式系统的行为，就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作。

分散式服务呼叫链路

一个请求完整呼叫链

那么在业务规模不断增大、服务不断增多以及频繁变更的情况下，面对复杂的呼叫链路就带来一系列问题：

如何快速发现问题？如何判断故障影响范围？如何梳理服务依赖以及依赖的合理性？如何分析链路效能问题以及实时容量规划？同时需要关注在请求处理期间各个呼叫的各项效能指标，比如：吞吐量（TPS）、响应时间及错误记录等。

吞吐量，根据拓扑可计算相应元件、平台、物理装置的实时吞吐量。响应时间，包括整体呼叫的响应时间和各个服务的响应时间等。错误记录，根据服务返回统计单位时间异常次数。全链路效能监控 从整体维度到区域性维度展示各项指标，将跨应用的所有呼叫链效能资讯集中展现，可方便度量整体和区域性效能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。

有了全链路监控工具，能够达到：

请求链路追踪，故障快速定位：可以通过呼叫链接合业务日志快速定位错误资讯。视觉化： 各个阶段耗时，进行效能分析。依赖优化：各个呼叫环节的可用性、梳理服务依赖关系以及优化。资料分析，优化链路：可以得到使用者的行为路径，汇总分析应用在很多业务场景。

1、全链路监控目标

探针的效能消耗APM元件服务的影响应该做到足够小。服务呼叫埋点本身会带来效能损耗，这就需要呼叫跟踪的低损耗，实际中还会通过配置取样率的方式，选择一部分请求去分析请求路径。在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使线上服务的部署团队不得不将跟踪系统关停。程式码的侵入性即也作为业务元件，应当尽可能少入侵或者无入侵其他业务系统，对于使用方透明，减少开发人员的负担。对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了，往往由于跟踪系统在应用中植入程式码的bug或疏忽导致应用出问题，这样才是无法满足对跟踪系统“无所不在的部署”这个需求。可扩充套件性一个优秀的呼叫跟踪系统必须支援分散式部署，具备良好的可扩充套件性。能够支援的元件越多当然越好。或者提供便捷的外挂开发API，对于一些没有监控到的元件，应用开发者也可以自行扩充套件。资料的分析资料的分析要快 ，分析的维度尽可能多。跟踪系统能提供足够快的资讯反馈，就可以对生产环境下的异常状况做出快速反应。分析的全面，能够避免二次开发。

2、全链路监控功能模组

1、埋点与生成日志

埋点即系统在当前节点的上下文资讯，可以分为 客户端埋点、服务端埋点，以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容traceId、spanId、呼叫的开始时间，协议型别、呼叫方ip和埠，请求的服务名、呼叫耗时，呼叫结果，异常资讯等，同时预留可扩充套件字段，为下一步扩充套件做准备；

2、收集和储存日志

主要支援分散式日志采集的方案，同时增加MQ作为缓冲；

每个机器上有一个 deamon 做日志收集，业务程序把自己的Trace发到daemon，daemon把收集Trace往上一级传送；多级的collector，类似pub/sub架构，可以负载均衡；对聚合的资料进行 实时分析和离线储存；离线分析 需要将同一条呼叫链的日志汇总在一起；3、分析和统计呼叫链路资料，以及时效性

呼叫链跟踪分析：把同一TraceID的Span收集起来，按时间排序就是timeline。把ParentID串起来就是呼叫栈。

抛异常或者超时，在日志里打印TraceID。利用TraceID查询呼叫链情况，定位问题。

依赖度量：

强依赖：呼叫失败会直接中断主流程高度依赖：一次链路中呼叫某个依赖的概率高频繁依赖：一次链路呼叫同一个依赖的次数多离线分析：按TraceID汇总，通过Span的ID和ParentID还原呼叫关系，分析链路形态。

实时分析：对单条日志直接分析，不做汇总，重组。得到当前QPS，延迟。

4、展现以及决策支援

3、Google Dapper

基本工作单元，一次链路呼叫（可以是RPC，DB等没有特定的限制）建立一个span，通过一个64位ID标识它，uuid较为方便，span中还有其他的资料，例如描述资讯，时间戳，key-value对的（Annotation）tag资讯，parent_id等,其中parent-id可以表示span呼叫链路来源。

Span

上图说明了span在一次大的跟踪过程中是什么样的。Dapper记录了span名称，以及每个span的ID和父ID，以重建在一次追踪过程中不同span之间的关系。如果一个span没有父ID被称为root span。所有span都挂在一个特定的跟踪上，也共用一个跟踪id。

3.2 TRACE

类似于 树结构的Span集合，表示一次完整的跟踪，从请求到服务器开始，服务器返回response结束，跟踪每次rpc呼叫的耗时，存在唯一标识trace_id。比如：你执行的分散式大资料储存一次Trace就由你的一次请求组成。

Trace

每种颜色的note标注了一个span，一条链路通过TraceId唯一标识，Span标识发起的请求资讯。树节点是整个架构的基本单元，而每一个节点又是对span的引用。节点之间的连线表示的span和它的父span直接的关系。虽然span在日志档案中只是简单的代表span的开始和结束时间，他们在整个树形结构中却是相对独立的。

3.3 Annotation

注解，用来记录请求特定事件相关资讯（例如时间），一个span中会有多个annotation注解描述。通常包含四个注解资讯：

(1) cs：Client Start，表示客户端发起请求

(2) sr：Server Receive，表示服务端收到请求

(3) ss：Server Send，表示服务端完成处理，并将结果传送给客户端

(4) cr：Client Received，表示客户端获取到服务端返回资讯

4、 方案比较

Zipkin：由Twitter公司开源，开放源代码分散式的跟踪系统，用于收集服务的定时资料，以解决微服务架构中的延迟问题，包括：资料的收集、储存、查询和展现。Pinpoint：一款对Java编写的大规模分散式系统的APM工具，由韩国人开源的分散式跟踪元件。Skywalking：国产的优秀APM元件，是一个对JAVA分散式应用程序丛集的业务执行情况进行追踪、告警和分析的系统。相比之下，Pinpoint 具有压倒性的优势：无需对专案程式码进行任何改动就可以部署探针、追踪资料细粒化到方法呼叫级别、功能强大的使用者界面以及几乎比较全面的 Java 框架支援。

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~