Dapper监控系统简介
1.基本槪念
对系统行为进行监控的过程非常的复杂，特别是在分布式系统中。为了理解这种复性，首先来看如图2-30^1所示的〜个过程。.
在图中，用户发出一个请求X,它期待得到系统对它做出的应答X。伹ft接收到该请 求的前端A发现该清求的处理需要涉及服务器B和服务器C,因此A又向B.和C发出两个RPC (远程过程调用)。B收到后立刻做出响应，但是C在接到后发现它还需要调用服 务器D和E才能完成请求X,因此C对p和E分别发出了 RPC, D和E接到后分别做出 了应答，收到jD和E的庳答之后C才向A做出响应，在接收到B和C的应答之后A ;才 对用户请求X做出一个应答X。在监控系统中记录下所有这些消息不难，如何将这些消息记录同特定的请求（本例中的X)关联起来才是分布式监控系统设计中需要解决的关键性问题之一。
1.基本槪念
对系统行为进行监控的过程非常的复杂，特别是在分布式系统中。为了理解这种复性，首先来看如图2-30^1所示的〜个过程。.
在图中，用户发出一个请求X,它期待得到系统对它做出的应答X。伹ft接收到该请 求的前端A发现该清求的处理需要涉及服务器B和服务器C,因此A又向B.和C发出两个RPC (远程过程调用)。B收到后立刻做出响应，但是C在接到后发现它还需要调用服 务器D和E才能完成请求X,因此C对p和E分别发出了 RPC, D和E接到后分别做出 了应答，收到jD和E的庳答之后C才向A做出响应，在接收到B和C的应答之后A ;才 对用户请求X做出一个应答X。在监控系统中记录下所有这些消息不难，如何将这些消息记录同特定的请求（本例中的X)关联起来才是分布式监控系统设计中需要解决的关键性问题之一。
—般来说，有两种方案可供选择：黑盒（Black Box)方案及基于注释的监控 (Annotation-based Monitoring)方案。二者比较而言，黑盒方案比较轻便，但是在消息关 系判断的过程中，黑盒方案主要是利用芒些统计学的知识来进行推断，有时不是很准确。 基于注释的方案利用应用程序或中间件给每条记录赋予一个全局性的标示符，借此将相关 消息串联起来。考虑到实际的需求，Google的工程师最终选择了基于注释的方案，为/ 尽可能消除监控系统的应用程序对被监控系统的性能产生的不良影响，Google的工程师 设计并实现了一套轻量级的核心功能库，这将在后面进行介绍。
Dapper监控系统中有三个基本概念：监控树（Trace Tree)、区间（Span)和注释 (Annotation)。如图2-31[18]所示是一个典型的监控树，从中可以看到所谓的监控树实际上就 是一个同特定事件相关的所有消息，只不过这些消息是按照一定的规律以树的形式组织起 来。树中的每一个节点称为一个区间，区间实际上就是一条记录，所有这些记录联系在一 起就构成了对某个事件的完整监控。从图2-31不难看出，每个区间包括如下的内容：区间 名（Span Name)、区间 id (Span id)、父 id (Parent id)和监控 id (Trace id)。区间名主要 是为了方便人们记忆和理解，因此要求这个区间名是人们可以读懂的。区间id是为了在一 棵监控树中区分不同的区间。父id是区间中非常重要的一个内容，正是通过父id才能够对 树中不同区间的关系进行重建，没有父id的区间称为根区间（Root Span)。图2-31中的 Frontend Request就是一个根区间。在图中还能看出，区间的长度实际上包括了区间的开始 及结束时间信息。
监控id在图2-31中并没有列出，一棵监控树中所有区间的监控id是相同的，这个监控 id是随机分配的，且在整个Dapper监控系统中是唯一的。正如区间id是用来在某个监控树 中区分不同的区间一样，监控id是用来在整个Dapper监控系统中区分不同的监控。注释主 要用来辅助推断区间关系，也可以包含一些自定义的内容。图2-32[18】展示了图2-31中 HelperCall区间的更详细信息。
在图2-32中可以清楚地看到这个区间的区间名是“Helper.Call”,监控id是100,区间id是5,父id是3-—个区间既可以只有一台主机的信息，也可以包含来源于多个主机 的信息，事实上，每个RPC区间都包含来自客户端（Client)和服务器端（Server)的注释，这使得双主机区间（Two-host Span)成为最常见的一种。图2-32中的区间就包含了来自客户端的注释信息：“”、“Client Send”、“Client Recv” 和“”，也包含了来自服务器端的注释信
息：“ServerRecv”、“foo”和“Server Send”。除了 “foo”是用户自定义的注释外，其他的注释信息都是和时间相关的信息。Dapper不但支持用户进行简单的文本方式的注释，还支持键-值对方式的注释，这赋予了开发者更多的自由。
Dapper监控系统中有三个基本概念：监控树（Trace Tree)、区间（Span)和注释 (Annotation)。如图2-31[18]所示是一个典型的监控树，从中可以看到所谓的监控树实际上就 是一个同特定事件相关的所有消息，只不过这些消息是按照一定的规律以树的形式组织起 来。树中的每一个节点称为一个区间，区间实际上就是一条记录，所有这些记录联系在一 起就构成了对某个事件的完整监控。从图2-31不难看出，每个区间包括如下的内容：区间 名（Span Name)、区间 id (Span id)、父 id (Parent id)和监控 id (Trace id)。区间名主要 是为了方便人们记忆和理解，因此要求这个区间名是人们可以读懂的。区间id是为了在一 棵监控树中区分不同的区间。父id是区间中非常重要的一个内容，正是通过父id才能够对 树中不同区间的关系进行重建，没有父id的区间称为根区间（Root Span)。图2-31中的 Frontend Request就是一个根区间。在图中还能看出，区间的长度实际上包括了区间的开始 及结束时间信息。
监控id在图2-31中并没有列出，一棵监控树中所有区间的监控id是相同的，这个监控 id是随机分配的，且在整个Dapper监控系统中是唯一的。正如区间id是用来在某个监控树 中区分不同的区间一样，监控id是用来在整个Dapper监控系统中区分不同的监控。注释主 要用来辅助推断区间关系，也可以包含一些自定义的内容。图2-32[18】展示了图2-31中 HelperCall区间的更详细信息。
在图2-32中可以清楚地看到这个区间的区间名是“Helper.Call”,监控id是100,区间id是5,父id是3-—个区间既可以只有一台主机的信息，也可以包含来源于多个主机 的信息，事实上，每个RPC区间都包含来自客户端（Client)和服务器端（Server)的注释，这使得双主机区间（Two-host Span)成为最常见的一种。图2-32中的区间就包含了来自客户端的注释信息：“
息：“ServerRecv”、“foo”和“Server Send”。除了 “foo”是用户自定义的注释外，其他的注释信息都是和时间相关的信息。Dapper不但支持用户进行简单的文本方式的注释，还支持键-值对方式的注释，这赋予了开发者更多的自由。
